Hi Benjamin,
It did the trick. The solution worked for both Maven 2.2.1 and Maven 3,
as you said.
Just out of curiosity, will the definition of a lifecycle extension
change after Maven 3 integration with Guice is complete?
Thank you very much for your help.
Cheers,
Henrique
On 30/04/10 10:47, Benjamin Bentmann wrote:
Henrique Prange wrote:
When building from the parent module using Maven 3, the following
classpath entry has been produced:
[...]/Wonder/Frameworks/Core/JavaWOExtensions/target/JavaWOExtensions-5.0.0-SNAPSHOT.woframework
And the produced classpath entry for the same build using Maven 2.2.1:
[...]/Wonder/Frameworks/Core/JavaWOExtensions/target/JavaWOExtensions-5.0.0-SNAPSHOT.jar
Note the file extension is wrong. It should be .jar instead of
.woframework.
Yes, that's the relevant log demonstrating the discrepancy, thanks.
So, is it a Maven 3 problem? Is it a problem in the 3rd party plug-in?
There's a change in behavior between Maven 2 and 3 regarding the
artifact handler being used for the project main artifact in combination
with extension plugins.
The project JavaWOExtensions uses <packaging>woframework</packaging> and
the corresponding artifact handler definition from the
maven-wolifecycle-plugin looks basically like this:
<configuration>
<type>woframework</type>
<extension>jar</extension>
<packaging>jar</packaging>
</configuration>
However, in Maven 2, this artifact handler is *not* used for the main
artifact of JavaWOExtensions, because Maven looks for a matching
artifact handler based on the handler's <packaging> (which is "jar"
here) instead of matching via the handler's <type>.
This opens the door for some oddities. The lookup via handler packaging
is inconsistent with the way artifact handlers are determined for all
the other plugin/dependency artifacts encountered in the build. Besides,
having this kind of artifact handler lookup only happen in the presence
of one or more extension plugins effectively means an ordinary project
with packaging=jar and some extension plugin might end up using the
artifact handler of type "test-jar" because this handler has the same
packaging as the handler of type "jar". The same goes for projects with
packaging "ejb" that non-deterministically chose from either the handler
of type "ejb" or "ejb-client". The lucky incidence that those handlers
have equal characteristics regarding file extension and class path
handling made this internal oddity never show up to users.
In the concrete case of the maven-wolifecycle-plugin, this yields to
projects that produce/install/deploy artifacts named
JavaWOExtensions-5.0.0-SNAPSHOT.woframework. However, projects with
packaging=woframework are supposed to produce JARs and so the plugin
authors worked around this by
a) attaching their intended main artifact like
JavaWOExtensions-5.0.0-SNAPSHOT.jar as an artifact of type "jar"
b) took the thoroughness to document that the actual project main file
*.woframework is unwanted garbage by writing this as its contents:
"This is an empty file created beacuse of the Maven extension mechanism."
After some chat with Brett about the selection of artifact handlers
based on their packaging, we both agree that this is actually a bug in
Maven 2 and the behavior of Maven 3 is correct. The only reason artifact
handlers have a <packaging> appears to be support for the legacy
repository layout.
Henrique, seeing that you're also a committer on the WOProject, I
suggest you simply remove the <packaging> field from all the custom
artifact handlers defined in the components.xml of the
maven-wolifecycle-plugin. <packaging> defaults to <type> so this
effectively seems to only change the behavior of the problematic
woframework handler. This change will make the artifact handler behave
the same in Maven 2 and 3 and should allow you to produce the proper
project output without the need of some attached artifact.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
