You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Henrique Prange <hp...@gmail.com> on 2010/04/29 18:24:11 UTC
Compilation problem with Maven 3.0-beta-1
Hi all,
I've tried to build a project with multiple modules using Maven
3.0-beta-1 unsuccessfully. I got some weird compilation problems on
child modules when trying to build from the parent module. But if I try
to build the child module directly, it works.
Any thoughts if is it a bug or something am I doing wrong?
By the way, it is an open source project and you can check the
configuration here [1].
[1]https://wonder.svn.sourceforge.net/svnroot/wonder/trunk/Wonder
Cheers,
Henrique
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Compilation problem with Maven 3.0-beta-1
Posted by Henrique Prange <hp...@gmail.com>.
Hi Jason,
On 01/05/10 13:54, Jason van Zyl wrote:
>
> On May 1, 2010, at 10:31 AM, Benjamin Bentmann wrote:
>
>> Jason van Zyl wrote:
>>
>>> Didn't Henrique just remove the packaging element from the component definition of the artifact handler to get this to work?
>>
In fact, I have also changed the plug-in implementation to not create
the dummy woframework artifact.
Cheers,
Henrique
>> Yes, to get the artifact handler to work with Maven 2 as originally intended.
>>
>
> That's what I was saying we should ignore. If we ignored that packaging element in the component descriptor for the artifact handler Henrique would not have had to make any changes, yes? If that's the case we should just knock them out automatically for users.
>
>>
>> Benjamin
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> A man enjoys his work when he understands the whole and when he
> is responsible for the quality of the whole
>
> -- Christopher Alexander, A Pattern Language
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Compilation problem with Maven 3.0-beta-1
Posted by Jason van Zyl <ja...@sonatype.com>.
On May 1, 2010, at 10:31 AM, Benjamin Bentmann wrote:
> Jason van Zyl wrote:
>
>> Didn't Henrique just remove the packaging element from the component definition of the artifact handler to get this to work?
>
> Yes, to get the artifact handler to work with Maven 2 as originally intended.
>
That's what I was saying we should ignore. If we ignored that packaging element in the component descriptor for the artifact handler Henrique would not have had to make any changes, yes? If that's the case we should just knock them out automatically for users.
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole
-- Christopher Alexander, A Pattern Language
Re: Compilation problem with Maven 3.0-beta-1
Posted by Benjamin Bentmann <be...@udo.edu>.
Jason van Zyl wrote:
> Didn't Henrique just remove the packaging element from the component definition of the artifact handler to get this to work?
Yes, to get the artifact handler to work with Maven 2 as originally
intended.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Compilation problem with Maven 3.0-beta-1
Posted by Jason van Zyl <ja...@sonatype.com>.
On May 1, 2010, at 7:15 AM, Benjamin Bentmann wrote:
> Jason van Zyl wrote:
>
>> Why don't we just proactively ignore the packaging in artifact handlers?
>
> M3 already does, that was the reason for the issue because the maven-wolifecycle-plugin relies on the bug in Maven 2.
>
Didn't Henrique just remove the packaging element from the component definition of the artifact handler to get this to work?
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
A language that doesn’t affect the way you think about programming is not worth knowing.
-— Alan Perlis
Re: Compilation problem with Maven 3.0-beta-1
Posted by Benjamin Bentmann <be...@udo.edu>.
Jason van Zyl wrote:
> Why don't we just proactively ignore the packaging in artifact handlers?
M3 already does, that was the reason for the issue because the
maven-wolifecycle-plugin relies on the bug in Maven 2.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Compilation problem with Maven 3.0-beta-1
Posted by Jason van Zyl <ja...@sonatype.com>.
On Apr 30, 2010, at 3:59 PM, Benjamin Bentmann wrote:
> Henrique Prange wrote:
>
>> It did the trick. The solution worked for both Maven 2.2.1 and Maven 3,
>> as you said.
>
> Glad to hear.
>
Why don't we just proactively ignore the packaging in artifact handlers?
>> Just out of curiosity, will the definition of a lifecycle extension
>> change after Maven 3 integration with Guice is complete?
>
> Not sure what kind of change you exactly had in mind but the goal is to be backward-compatible. Stuart McCulloch created a Plexus shim that makes Plexus components like artifact handlers, lifecycle mappings, mojos and all the other Maven bits work unchanged.
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people.
-- Paul Graham
Re: Compilation problem with Maven 3.0-beta-1
Posted by Benjamin Bentmann <be...@udo.edu>.
Henrique Prange wrote:
> It did the trick. The solution worked for both Maven 2.2.1 and Maven 3,
> as you said.
Glad to hear.
> Just out of curiosity, will the definition of a lifecycle extension
> change after Maven 3 integration with Guice is complete?
Not sure what kind of change you exactly had in mind but the goal is to
be backward-compatible. Stuart McCulloch created a Plexus shim that
makes Plexus components like artifact handlers, lifecycle mappings,
mojos and all the other Maven bits work unchanged.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Compilation problem with Maven 3.0-beta-1
Posted by Henrique Prange <hp...@gmail.com>.
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Compilation problem with Maven 3.0-beta-1
Posted by Benjamin Bentmann <be...@udo.edu>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Compilation problem with Maven 3.0-beta-1
Posted by Henrique Prange <hp...@gmail.com>.
Hi Benjamin,
Thanks for your response.
On 29/04/10 14:14, Benjamin Bentmann wrote:
> Henrique Prange wrote:
>
>> I've tried to build a project with multiple modules using Maven
>> 3.0-beta-1 unsuccessfully. I got some weird compilation problems
>
> "weird compilation problems" belong to those kind of problems that are
> nearly impossible to troubleshoot. Concrete solutions require concrete
> error logs.
>
I've checked Maven logs carefully and discovered something that can be
the cause of the problem.
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.
Project Wonder uses a 3rd party plug-in [1] to build woframework
artifacts. WOFrameworks artifacts are JAR files with a special directory
structure.
So, is it a Maven 3 problem? Is it a problem in the 3rd party plug-in?
Is there any known required modification that must be made on plug-ins
that provide lifecycle enhancements?
Attached is the entire log of the build failure just in case.
>> By the way, it is an open source project and you can check the
>> configuration here [1].
>> [1]https://wonder.svn.sourceforge.net/svnroot/wonder/trunk/Wonder
>
> My quick attempt to build this failed with both Maven 2.x and 3.x due to
> an unresolvable dependency on com.webobjects:JavaFoundation:jar that
> can't be found in any repository being.
>
Sorry for that. I can't host those libraries because of license issues. :(
> Bottom line: Unless you provide comprehensive details about the error or
> a minimal example project to reproduce the issue, this problem can't be
> analyzed further.
>
> The one thing I noticed is that your build doesn't lock down plugin
> versions which makes it generally non-reproducible and could explain
> build differences between Maven 2.x and 3.x due different plugin default
> versions.
>
Sure. I'm checking Maven 3 warnings to fix these kind of problems.
Thank you very much.
[1]https://svn.objectstyle.org/repos/woproject/trunk/woproject/maven2/maven-wolifecycle-plugin
Cheers,
Henrique
Re: Compilation problem with Maven 3.0-beta-1
Posted by Benjamin Bentmann <be...@udo.edu>.
Henrique Prange wrote:
> I've tried to build a project with multiple modules using Maven
> 3.0-beta-1 unsuccessfully. I got some weird compilation problems
"weird compilation problems" belong to those kind of problems that are
nearly impossible to troubleshoot. Concrete solutions require concrete
error logs.
> By the way, it is an open source project and you can check the
> configuration here [1].
>
> [1]https://wonder.svn.sourceforge.net/svnroot/wonder/trunk/Wonder
My quick attempt to build this failed with both Maven 2.x and 3.x due to
an unresolvable dependency on com.webobjects:JavaFoundation:jar that
can't be found in any repository being.
Bottom line: Unless you provide comprehensive details about the error or
a minimal example project to reproduce the issue, this problem can't be
analyzed further.
The one thing I noticed is that your build doesn't lock down plugin
versions which makes it generally non-reproducible and could explain
build differences between Maven 2.x and 3.x due different plugin default
versions.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org