Maven 2.x Ear Plugin

if an artifact in the list of ear modules already exists in the ear, the ear mojo will copy it on top of itself, zeroing out the file

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.2
  • Fix Version/s: 2.3
  • Labels:
    None
  • Number of attachments :
    2

Description

The ear plugin doesn't check for artifacts that are already deployed within the ear, and so ends up redundantly copying such artifacts, e.g.:

copy C:/appserver/deploy/my.ear/lib/my.jar C:/appserver/deploy/my.ear/lib/my.jar

and when you copy a file onto itself using the Plexus copy util method, it zeros out the file (a bug in itself IMO but that's beside the point .

A check should be added, so the ear plugin intelligently handles this, albeit unusual, case.

Issue Links

relates to

Bug - A problem which impairs or prevents the functions of the product. PLXUTILS-10 FileUtils.copyFile zeros out the file if source file is the same as destination file

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Stéphane Nicoll added a comment -

How do we reproduce this unusual case?

Show
Stéphane Nicoll added a comment - How do we reproduce this unusual case?
Hide
Permalink
Ian Springer added a comment -

It happens when the "dev" profile I mentioned in an earlier issue is enabled. When dev mode is enabled, things get build directly to the test deployment location, rather than somewhere under target (this is done by using a custom plugin that allows project.build.directory and/or project.build.outputDirectory to be overridden). In this case, we have a couple of jars which are part of our reactor build. When dev mode is enabled, these jars will get built directly to /.../myjboss/.../deploy/my.ear/lib/ rather than to target/ (because project.build.directory has been overridden). When the ear pom in the same reactor is reached later in the build, the "file" fields of the in-memory ActiveProjectArtifacts that represent the two afore-mentioned jars are set to /.../myjboss/.../deploy/my.ear/lib/xxx.jar. And the destination path that the ear plugin computes will also end up pointing to /.../myjboss/.../deploy/my.ear/lib/xxx.jar. So the jar has already been placed where it needs to go earlier in the reactor build.

In case you actually want to try to reproduce this, I'll attach the custom plugin I mentioned which has two goals - one that allows you to override project.build.directory and another that allows you to override project.build.outputDirectory.

Show
Ian Springer added a comment - It happens when the "dev" profile I mentioned in an earlier issue is enabled. When dev mode is enabled, things get build directly to the test deployment location, rather than somewhere under target (this is done by using a custom plugin that allows project.build.directory and/or project.build.outputDirectory to be overridden). In this case, we have a couple of jars which are part of our reactor build. When dev mode is enabled, these jars will get built directly to /.../myjboss/.../deploy/my.ear/lib/ rather than to target/ (because project.build.directory has been overridden). When the ear pom in the same reactor is reached later in the build, the "file" fields of the in-memory ActiveProjectArtifacts that represent the two afore-mentioned jars are set to /.../myjboss/.../deploy/my.ear/lib/xxx.jar. And the destination path that the ear plugin computes will also end up pointing to /.../myjboss/.../deploy/my.ear/lib/xxx.jar. So the jar has already been placed where it needs to go earlier in the reactor build. In case you actually want to try to reproduce this, I'll attach the custom plugin I mentioned which has two goals - one that allows you to override project.build.directory and another that allows you to override project.build.outputDirectory.
Hide
Permalink
Stéphane Nicoll added a comment -

Roger that, I've created the plexus issue and will apply your patch meanwhile.

See PLX-308

Show
Stéphane Nicoll added a comment - Roger that, I've created the plexus issue and will apply your patch meanwhile. See PLX-308
Hide
Permalink
Stéphane Nicoll added a comment -

Applied, thanks!

Show
Stéphane Nicoll added a comment - Applied, thanks!

People

  • Assignee:
    Stéphane Nicoll
    Reporter:
    Ian Springer
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: