ClassCastException in m-surefire-p in custom-built maven!
Hi,
We're very close to have the results.
maven-{clean,resources,compile}-plugin works as expected. Now, I'm at
[surefire:test {execution: default-test}] phase. Well, m-surefire-p is
giving me issues.
I'm getting a weird ClassCastException for
org.apache.maven.plugin.surefire.SurefirePlugin.
java.lang.ClassCastException:
org.apache.maven.plugin.surefire.SurefirePlugin cannot be cast to
org.apache.maven.plugin.Mojo
It's just basics. Don't understand why it fails. SurefirePlugin class
implements (actually, by it's parent's parent) the Mojo interface. So,
this class should be able to cast to Mojo, right? But this cast in
DefaultPluginManager [1] fails.
plugin = (Mojo) pluginContainer.lookup( Mojo.ROLE,
mojoDescriptor.getRoleHint() );
The SurefirePlugin Mojo is somewhat same as other mojos such as
CleanMojo with some differences I noticed.
* SurefirePluginMojo has an additional abstraction layer named
AbstractSurefireMojo class.
* SurefirePlugin mojo class name does not end with *Mojo like all
the mojos are. (Not sure whether this doesn't even need to consider.
May be there's a class filtering mechanism?)
Would these play a part here?
Please let me know if you have any idea worth trying. The error log is
given below. mvn -X output is at [2]
[1]
http://www.jarvana.com/jarvana/view/org/apache/maven/maven-core/2.2.1/maven-core-2.2.1-sources.jar!/org/apache/maven/plugin/DefaultPluginManager.java?format=ok
[2] http://pastebin.com/gR6D2aLb
The error log -
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] org.apache.maven.plugin.surefire.SurefirePlugin cannot be cast
to org.apache.maven.plugin.Mojo
[INFO]
[DEBUG] Trace
java.lang.ClassCastException:
org.apache.maven.plugin.surefire.SurefirePlugin cannot be cast to
org.apache.maven.plugin.Mojo
at
org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:652)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:468)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Thanks,
--Kasun
--
~~~***'***~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://blog.kasunbg.org
Twitter: http://twitter.com/kasunbg
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: ClassCastException in m-surefire-p in custom-built maven!
On Mon, Aug 15, 2011 at 1:05 PM, Barrie Treloar baerr...@gmail.com wrote:
On Mon, Aug 15, 2011 at 4:55 PM, Kasun Gajasinghe kasu...@gmail.com wrote:
Hi,
We're very close to have the results.
maven-{clean,resources,compile}-plugin works as expected. Now, I'm at
[surefire:test {execution: default-test}] phase. Well, m-surefire-p is
giving me issues.
I'm getting a weird ClassCastException for
org.apache.maven.plugin.surefire.SurefirePlugin.
java.lang.ClassCastException:
org.apache.maven.plugin.surefire.SurefirePlugin cannot be cast to
org.apache.maven.plugin.Mojo
I'm no expert in this particular error, but I thought I'd throw out
that ClassCastExceptions also arise from ClassLoader issues as the
same class loaded via two different class loaders are considered
different and will give ClassCastExceptions.
Perhaps you are running into this.
Barrie,
Indeed, it's probably due to a ClassLoader issue. I'm gonna look in to
this path further. But I doubt it's because of the same class in two
places because every Jar is loaded under highly controlled
environment. And, there's only one version of *surefire-* jars (2.9,
the latest) installed. There are two SurefirePlugin classes in
m-surefire-p, but they belong to two different packages.
I looked at the possible classloader issues causing
classcastexceptions [1]. There are three possibilities. But, I don't
see anything applies to this case since we know that it works fine in
the official distribution! I should read it again.
If you have any other possibilities popped up in your head, just let me know!
Thanks,
--Kasun
[1]
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/rtrb_classload_viewer.html
--
~~~***'***~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://blog.kasunbg.org
Twitter: http://twitter.com/kasunbg
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Issue in m-compiler-p probably related to maven-toolchain
Hi devs, As you may have probably heard, Maven integration in Gentoo is fully working for user-level. Currently, I'm working on getting the system-level integration working, which is the main goal of this project. I'm now faced with an issue related to m-compiler-p when compiling a simple project at sys-level. I should note that I'm using the custom-built maven NOT the official build. I'm asking this question from you to get a _hint_ to fix this issue. m-compiler-p fails with, [INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile': Unable to find the mojo 'compile' (or one of its required components) in the plugin 'org.apache.maven.plugins:maven-compiler-plugin' Can not set org.apache.maven.toolchain.DefaultToolchainManager field org.apache.maven.plugin.AbstractCompilerMojo.toolchainManager to org.apache.maven.toolchain.DefaultToolchainManager Full build stack trace is at [1]. I've checked the components.xml file of maven-toolchain-1.0, but couldn't figure out the issue. The implementation for the role org.apache.maven.toolchain.ToolchainManager is org.apache.maven.toolchain.DefaultToolchainManager. So, it should work. I've gone through the source file of AbstractCompilerMojo [2] as well without any success. Can anyone let me know where I should I look to fix this issue? I understand that this is not the official build, so you all don't need to be concerned with this. But any help to figure this out is much appreciated! [1] http://pastebin.com/e6E0VtW6 [2] http://svn.apache.org/viewvc/maven/plugins/tags/maven-compiler-plugin-2.3.2/src/main/java/org/apache/maven/plugin/AbstractCompilerMojo.java?view=markup Thanks, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg
Re: Issue in m-compiler-p probably related to maven-toolchain
Mark, On Sat, Aug 13, 2011 at 2:19 PM, Mark Struberg strub...@yahoo.de wrote: Hi! Lets try to follow the logical route. It's either a.) cannot find the 'compile' mojo or b.) 'or one of its required components' Ad a.): Maven plugins have xdoc annotations which will be used to generate a META-INF/maven/plugin.xml file in the plugins jar. Can you check if this exists and looks good? Did you try other plugins? A plain 'mvn clean' works well? Starting mvn with -X might also give you a bit more clue about whats going on.\ b) would be the most probable reason here. Further, I suspect that one component fails at runtime. The build error returned via mvn -X is at http://pastebin.com/e6E0VtW6 . Would you need the full build log? In line 49 of the given pastebin, I see the following. Caused by: org.codehaus.plexus.component.composition.CompositionException: Composition failed for the field toolchainManager in object of type org.apache.maven.plugin.CompilerMojo And, in the plugin.xml, there's this requirement which I suspect is failing. requirement roleorg.apache.maven.toolchain.ToolchainManager/role field-nametoolchainManager/field-name /requirement I guess this confirms that the issue is in a component? The CompilerMojo class in m-compiler-p contains the variable toolchainManager with the annotation '@component'. The class is in [2]. Things I checked are seems to be in-place. No idea why it fails. A mojo with 'compile' goal' is available in the plugin.xml at the location you said. The file is available to look at [3] in case you think more details are needed. And, `mvn clean` worked flawlessly, as well as the job of maven-resources-plugin. I guess we need to go in to second step? [3] http://pastebin.com/yWyGAG2G Thanks for your response! --Kasun LieGrue, strub --- On Sat, 8/13/11, Kasun Gajasinghe kasu...@gmail.com wrote: From: Kasun Gajasinghe kasu...@gmail.com Subject: Issue in m-compiler-p probably related to maven-toolchain To: Maven Developers List dev@maven.apache.org Cc: kiorky kio...@cryptelium.net, Serkan Kaba ser...@gentoo.org, Alistair Bush ali_b...@gentoo.org Date: Saturday, August 13, 2011, 6:14 AM Hi devs, As you may have probably heard, Maven integration in Gentoo is fully working for user-level. Currently, I'm working on getting the system-level integration working, which is the main goal of this project. I'm now faced with an issue related to m-compiler-p when compiling a simple project at sys-level. I should note that I'm using the custom-built maven NOT the official build. I'm asking this question from you to get a _hint_ to fix this issue. m-compiler-p fails with, [INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile': Unable to find the mojo 'compile' (or one of its required components) in the plugin 'org.apache.maven.plugins:maven-compiler-plugin' Can not set org.apache.maven.toolchain.DefaultToolchainManager field org.apache.maven.plugin.AbstractCompilerMojo.toolchainManager to org.apache.maven.toolchain.DefaultToolchainManager Full build stack trace is at [1]. I've checked the components.xml file of maven-toolchain-1.0, but couldn't figure out the issue. The implementation for the role org.apache.maven.toolchain.ToolchainManager is org.apache.maven.toolchain.DefaultToolchainManager. So, it should work. I've gone through the source file of AbstractCompilerMojo [2] as well without any success. Can anyone let me know where I should I look to fix this issue? I understand that this is not the official build, so you all don't need to be concerned with this. But any help to figure this out is much appreciated! [1] http://pastebin.com/e6E0VtW6 [2] http://svn.apache.org/viewvc/maven/plugins/tags/maven-compiler-plugin-2.3.2/src/main/java/org/apache/maven/plugin/AbstractCompilerMojo.java?view=markup Thanks, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg
Re: Issue in m-compiler-p probably related to maven-toolchain
On Sat, Aug 13, 2011 at 3:25 PM, Robert Scholte rfscho...@codehaus.orgwrote: Is maven-toolchains-1.0 the right version for the forked Maven? http://findjar.com/class/org/apache/maven/toolchain/ToolchainManager.html I have set maven-toolchain-1.0 explicitly in the maven-compiler-plugin. So, I guess this is correct. Is there a way to verify this at runtime? I'm afraid that the maven-toolchain-2.2.1 would interfere, which is bundled in the maven-uber-jar! But I didn't see any interference in the debug output. Since I didn't have a proper way of verifying, I've tested it by changing the dependency version of maven-toolchain in m-compiler-p from 1.0 to 2.2.1. It works fine too with the official build. I should note that we specify the dependencies via systemPath element in dependency. And, the groupId:artifactId combination is not exactly the same as org.apache.maven:maven-toolchain but something like gentoo.groupid:gentoo12 if it matters. Thanks, --Kasun -Robert From: kasu...@gmail.com Date: Sat, 13 Aug 2011 15:07:17 +0530 Subject: Re: Issue in m-compiler-p probably related to maven-toolchain To: dev@maven.apache.org CC: kio...@cryptelium.net; ser...@gentoo.org; ali_b...@gentoo.org Mark, On Sat, Aug 13, 2011 at 2:19 PM, Mark Struberg strub...@yahoo.de wrote: Hi! Lets try to follow the logical route. It's either a.) cannot find the 'compile' mojo or b.) 'or one of its required components' Ad a.): Maven plugins have xdoc annotations which will be used to generate a META-INF/maven/plugin.xml file in the plugins jar. Can you check if this exists and looks good? Did you try other plugins? A plain 'mvn clean' works well? Starting mvn with -X might also give you a bit more clue about whats going on.\ b) would be the most probable reason here. Further, I suspect that one component fails at runtime. The build error returned via mvn -X is at http://pastebin.com/e6E0VtW6 . Would you need the full build log? In line 49 of the given pastebin, I see the following. Caused by: org.codehaus.plexus.component.composition.CompositionException: Composition failed for the field toolchainManager in object of type org.apache.maven.plugin.CompilerMojo And, in the plugin.xml, there's this requirement which I suspect is failing. requirement roleorg.apache.maven.toolchain.ToolchainManager/role field-nametoolchainManager/field-name /requirement I guess this confirms that the issue is in a component? The CompilerMojo class in m-compiler-p contains the variable toolchainManager with the annotation '@component'. The class is in [2]. Things I checked are seems to be in-place. No idea why it fails. A mojo with 'compile' goal' is available in the plugin.xml at the location you said. The file is available to look at [3] in case you think more details are needed. And, `mvn clean` worked flawlessly, as well as the job of maven-resources-plugin. I guess we need to go in to second step? [3] http://pastebin.com/yWyGAG2G Thanks for your response! --Kasun LieGrue, strub --- On Sat, 8/13/11, Kasun Gajasinghe kasu...@gmail.com wrote: From: Kasun Gajasinghe kasu...@gmail.com Subject: Issue in m-compiler-p probably related to maven-toolchain To: Maven Developers List dev@maven.apache.org Cc: kiorky kio...@cryptelium.net, Serkan Kaba ser...@gentoo.org, Alistair Bush ali_b...@gentoo.org Date: Saturday, August 13, 2011, 6:14 AM Hi devs, As you may have probably heard, Maven integration in Gentoo is fully working for user-level. Currently, I'm working on getting the system-level integration working, which is the main goal of this project. I'm now faced with an issue related to m-compiler-p when compiling a simple project at sys-level. I should note that I'm using the custom-built maven NOT the official build. I'm asking this question from you to get a _hint_ to fix this issue. m-compiler-p fails with, [INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile': Unable to find the mojo 'compile' (or one of its required components) in the plugin 'org.apache.maven.plugins:maven-compiler-plugin' Can not set org.apache.maven.toolchain.DefaultToolchainManager field org.apache.maven.plugin.AbstractCompilerMojo.toolchainManager to org.apache.maven.toolchain.DefaultToolchainManager Full build stack trace is at [1]. I've checked the components.xml file of maven-toolchain-1.0, but couldn't figure out the issue. The implementation for the role org.apache.maven.toolchain.ToolchainManager is org.apache.maven.toolchain.DefaultToolchainManager. So, it should work. I've gone through
Re: Issue in m-compiler-p probably related to maven-toolchain
It turned out that the issue is gone the requirement specified in the plugin.xml [3] (lines 679-682) is manually commented out. I don't get why this error causes. I have a feeling that this could be because of an issue related to Plexus components. Commenting out that section is not really a solution since that requirement is there for a reason! Any insights? requirement roleorg.apache.maven.toolchain.ToolchainManager/role field-nametoolchainManager/field-name /requirement [3] http://pastebin.com/yWyGAG2G --Kasun On Sat, Aug 13, 2011 at 3:07 PM, Kasun Gajasinghe kasu...@gmail.com wrote: Mark, On Sat, Aug 13, 2011 at 2:19 PM, Mark Struberg strub...@yahoo.de wrote: Hi! Lets try to follow the logical route. It's either a.) cannot find the 'compile' mojo or b.) 'or one of its required components' Ad a.): Maven plugins have xdoc annotations which will be used to generate a META-INF/maven/plugin.xml file in the plugins jar. Can you check if this exists and looks good? Did you try other plugins? A plain 'mvn clean' works well? Starting mvn with -X might also give you a bit more clue about whats going on.\ b) would be the most probable reason here. Further, I suspect that one component fails at runtime. The build error returned via mvn -X is at http://pastebin.com/e6E0VtW6 . Would you need the full build log? In line 49 of the given pastebin, I see the following. Caused by: org.codehaus.plexus.component.composition.CompositionException: Composition failed for the field toolchainManager in object of type org.apache.maven.plugin.CompilerMojo And, in the plugin.xml, there's this requirement which I suspect is failing. requirement roleorg.apache.maven.toolchain.ToolchainManager/role field-nametoolchainManager/field-name /requirement I guess this confirms that the issue is in a component? The CompilerMojo class in m-compiler-p contains the variable toolchainManager with the annotation '@component'. The class is in [2]. Things I checked are seems to be in-place. No idea why it fails. A mojo with 'compile' goal' is available in the plugin.xml at the location you said. The file is available to look at [3] in case you think more details are needed. And, `mvn clean` worked flawlessly, as well as the job of maven-resources-plugin. I guess we need to go in to second step? [3] http://pastebin.com/yWyGAG2G Thanks for your response! --Kasun LieGrue, strub --- On Sat, 8/13/11, Kasun Gajasinghe kasu...@gmail.com wrote: From: Kasun Gajasinghe kasu...@gmail.com Subject: Issue in m-compiler-p probably related to maven-toolchain To: Maven Developers List dev@maven.apache.org Cc: kiorky kio...@cryptelium.net, Serkan Kaba ser...@gentoo.org, Alistair Bush ali_b...@gentoo.org Date: Saturday, August 13, 2011, 6:14 AM Hi devs, As you may have probably heard, Maven integration in Gentoo is fully working for user-level. Currently, I'm working on getting the system-level integration working, which is the main goal of this project. I'm now faced with an issue related to m-compiler-p when compiling a simple project at sys-level. I should note that I'm using the custom-built maven NOT the official build. I'm asking this question from you to get a _hint_ to fix this issue. m-compiler-p fails with, [INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile': Unable to find the mojo 'compile' (or one of its required components) in the plugin 'org.apache.maven.plugins:maven-compiler-plugin' Can not set org.apache.maven.toolchain.DefaultToolchainManager field org.apache.maven.plugin.AbstractCompilerMojo.toolchainManager to org.apache.maven.toolchain.DefaultToolchainManager Full build stack trace is at [1]. I've checked the components.xml file of maven-toolchain-1.0, but couldn't figure out the issue. The implementation for the role org.apache.maven.toolchain.ToolchainManager is org.apache.maven.toolchain.DefaultToolchainManager. So, it should work. I've gone through the source file of AbstractCompilerMojo [2] as well without any success. Can anyone let me know where I should I look to fix this issue? I understand that this is not the official build, so you all don't need to be concerned with this. But any help to figure this out is much appreciated! [1] http://pastebin.com/e6E0VtW6 [2] http://svn.apache.org/viewvc/maven/plugins/tags/maven-compiler-plugin-2.3.2/src/main/java/org/apache/maven/plugin/AbstractCompilerMojo.java?view=markup Thanks, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg
surefire-api not relocating the classes of commons-lang though it's in m-shade-p config
Hi, I was recently looking at surefire-api-2.9.jar for my work. According to the pom, it uses m-shade-p to shade two artifacts org.codehaus.plexus:plexus-utils and commons-lang:commons-lang with their relocations clearly specified. But I don't see the shaded classes for commons-lang in the generated jar. Plexus-utils is shaded to org.apache.maven.surefire.shade.org.codehaus.plexus.util correctly though. commons-lang is not a dependency of surefire as I see. Is it an obsolete code in the pom or is it the behavior expected for surefire-api? Please clarify. mvn log for the shade:shade execution is at [1]. There isn't any word about commons-lang either! I'm using the official build maven-2.2.1 [1] http://paste.pocoo.org/show/451244/ Thanks, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: surefire-api not relocating the classes of commons-lang though it's in m-shade-p config
On Tue, Aug 2, 2011 at 7:52 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: It's not used and obsolete as of now. This may change in the future. Ok, thanks... --Kasun Kristian Den 2. aug. 2011 kl. 16:16 skrev Kasun Gajasinghe kasu...@gmail.com: Hi, I was recently looking at surefire-api-2.9.jar for my work. According to the pom, it uses m-shade-p to shade two artifacts org.codehaus.plexus:plexus-utils and commons-lang:commons-lang with their relocations clearly specified. But I don't see the shaded classes for commons-lang in the generated jar. Plexus-utils is shaded to org.apache.maven.surefire.shade.org.codehaus.plexus.util correctly though. commons-lang is not a dependency of surefire as I see. Is it an obsolete code in the pom or is it the behavior expected for surefire-api? Please clarify. mvn log for the shade:shade execution is at [1]. There isn't any word about commons-lang either! I'm using the official build maven-2.2.1 [1] http://paste.pocoo.org/show/451244/ Thanks, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - 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 -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Set specific plugin versions for a project - issue in plugin-registry.xml/maven-metada-local.xml
On Wed, Jul 27, 2011 at 10:05 PM, Ansgar Konermann ansgar.konerm...@googlemail.com wrote: Am 27.07.2011 08:16, schrieb Kasun Gajasinghe: We don't allow downloading of different versions of same plugin which in most cases does the 'same' job! So, we need the ability to set a default plugin versions that are available on the gentoo system. Hi Kasun, what about this: configure a local pluginRepository in Maven's global settings.xml [1] file. Pre-load it with all the plugins and plugin dependencies your maven installation will be allowed to use. Ansgar, well, this is possible, I'm working on some subtle gentoo-specific things I need to do first to test this out. Anyway, I already know this, and have specified about this in my original post. I'm looking for this and something beyond that. That is, set checkLatest true and retrieve plugins version from there. [2] says, checkLatest - Specifies whether the LATEST artifact metadata should be consulted while determining versions for unregistered plugins. I'm looking for that. I figured that it needs to set via maven-metadata.xml files. I'm not exactly sure that maven-metadata.xml is the file to be used for this purpose though. [2] http://maven.apache.org/guides/introduction/introduction-to-plugin-registry.html Best Ansgar [1] http://maven.apache.org/settings.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Set specific plugin versions for a project - issue in plugin-registry.xml/maven-metada-local.xml
On 27 Jul 2011, at 01:27, Ansgar Konermann ansgar.konerm...@googlemail.com wrote: Am 26.07.2011 00:56, schrieb Kasun Gajasinghe: So, doesn't having an intermediary layer that will point to newer set of plugins is justified? Sure. Simplest solution that will work: use your own parent pom with an updated pluginManagement section. As I explained before, parent pom thing has few caveats. Btw, lot of problems occured to me because of the maven super pom, which, apparently has some hard-coded (quite old) plugin versions. (As I've read [1], the super pom is something like Java's java.lang.Object that every class inherits properties from.) So, I could get over some issues if I can patch the plugin versions in super pom according to our needs. Unfortunately, I can't find it exists in source. Can anyone shed a light on where I could find the super pom? Thanks, Kasun [1] http://maven.apache.org/pom.html#The_Super_POM Ansgar - 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
Set specific plugin versions for a project - issue in plugin-registry.xml/maven-metada-local.xml
Hi, I have a requirement where I need to specify specific versions for a set of (basic) plugins. Adding the versions to the pom isn't an option because we need to set the plugin versions for a vast number of _unrelated_ builds. As I've found at [1], I've manually created a plugin-registry.xml file with needed plugin versions added. In addition to that, I've created maven-metadata-local.xml file in the m2 repo under the plugin directories, pointing to latest and release versions. But, unfortunately, these specified versions were not picked up by mvn. I needed latest maven-compiler-plugin version 2.3.2, but it always try to use 2.0.2. I've noticed that [1] is somewhat outdated because --check-plugin-latest parameter doesn't available anymore. So, I'm asking, does the plugin-registry.xml is still used by maven? If not what is the mechanism for specifying specific plugin versions (apart from current/parent pom)? (I've seen in some posts that the plugin-registry.xml isn't used anymore, but debug mode shows that mvn retrieves data from that file. ) Apparently, maven-metada-local.xml isn't created automatically for me either. How I can instruct mvn to do that? My plugin-registry.xml is at [2]. (There wasn't a template for that. So, hope the format is correct!). maven-metadata-local.xml of maven-compiler-plugin is at [3]. I'm using official apache maven-2.2.1 build. Your help is much appreciated. [1] http://maven.apache.org/guides/introduction/introduction-to-plugin-registry.html [2] http://pastebin.com/yprQU2D2 [3] http://pastebin.com/Y375dwMg Thanks, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Set specific plugin versions for a project - issue in plugin-registry.xml/maven-metada-local.xml
On 25 Jul 2011, at 17:13, Benson Margulies bimargul...@gmail.com wrote: I don't know about plugin-registry.xml, but you can distribute a settings.xml for use with -gs that has an active-by-default profile with a pluginManagement section that does the job. Benson, That would do the job though that's not exactly the need. We need the ability to specify the version per plugin, ie using maven-metadata.xml files under each plugin dir (in m2 repo.) I should've more clear in the previous mail. What I've did was trying to activate maven-metadata.XML files by setting the checkLatest tag true in p-r.xml file. Plugin-registryxml then will only contain static plugin versions that will be overridden by maven-metadata.xml files. maven-metadata.xml thing should work, I'm missing something important! The issue of using settings.xml is, settings.xml is owned by maven package. therefore the plugin-packages can't update the settings.xml file later on about the newly installed files. That comes in OS world I guess. Thanks, Kasun Ps: Excuse for spelling mistakes, I'm sending this mail via mobile. Facts were not verified. ~~**~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka On Mon, Jul 25, 2011 at 3:02 AM, Kasun Gajasinghe kasu...@gmail.com wrote: Hi, I have a requirement where I need to specify specific versions for a set of (basic) plugins. Adding the versions to the pom isn't an option because we need to set the plugin versions for a vast number of _unrelated_ builds. As I've found at [1], I've manually created a plugin-registry.xml file with needed plugin versions added. In addition to that, I've created maven-metadata-local.xml file in the m2 repo under the plugin directories, pointing to latest and release versions. But, unfortunately, these specified versions were not picked up by mvn. I needed latest maven-compiler-plugin version 2.3.2, but it always try to use 2.0.2. I've noticed that [1] is somewhat outdated because --check-plugin-latest parameter doesn't available anymore. So, I'm asking, does the plugin-registry.xml is still used by maven? If not what is the mechanism for specifying specific plugin versions (apart from current/parent pom)? (I've seen in some posts that the plugin-registry.xml isn't used anymore, but debug mode shows that mvn retrieves data from that file. ) Apparently, maven-metada-local.xml isn't created automatically for me either. How I can instruct mvn to do that? My plugin-registry.xml is at [2]. (There wasn't a template for that. So, hope the format is correct!). maven-metadata-local.xml of maven-compiler-plugin is at [3]. I'm using official apache maven-2.2.1 build. Your help is much appreciated. [1] http://maven.apache.org/guides/introduction/introduction-to-plugin-registry.html [2] http://pastebin.com/yprQU2D2 [3] http://pastebin.com/Y375dwMg Thanks, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Set specific plugin versions for a project - issue in plugin-registry.xml/maven-metada-local.xml
On Mon, Jul 25, 2011 at 5:34 PM, Damian Bradicich dbradic...@sonatype.com wrote: err...pluginManagement section even ;) Damian On Mon, Jul 25, 2011 at 8:02 AM, Damian Bradicich dbradic...@sonatype.comwrote: Why not define the pluginDependency section in a parent pom, then each of your projects uses this as a parent, and pulls in all the plugin dep versions defined in it (or overrides in project pom if necessary). Seems that would be simplest solution Since these projects are unrelated, they can't be glued together via a parent pom. Thanks, --Kasun Damian On Mon, Jul 25, 2011 at 7:43 AM, Benson Margulies bimargul...@gmail.comwrote: I don't know about plugin-registry.xml, but you can distribute a settings.xml for use with -gs that has an active-by-default profile with a pluginManagement section that does the job. On Mon, Jul 25, 2011 at 3:02 AM, Kasun Gajasinghe kasu...@gmail.com wrote: Hi, I have a requirement where I need to specify specific versions for a set of (basic) plugins. Adding the versions to the pom isn't an option because we need to set the plugin versions for a vast number of _unrelated_ builds. As I've found at [1], I've manually created a plugin-registry.xml file with needed plugin versions added. In addition to that, I've created maven-metadata-local.xml file in the m2 repo under the plugin directories, pointing to latest and release versions. But, unfortunately, these specified versions were not picked up by mvn. I needed latest maven-compiler-plugin version 2.3.2, but it always try to use 2.0.2. I've noticed that [1] is somewhat outdated because --check-plugin-latest parameter doesn't available anymore. So, I'm asking, does the plugin-registry.xml is still used by maven? If not what is the mechanism for specifying specific plugin versions (apart from current/parent pom)? (I've seen in some posts that the plugin-registry.xml isn't used anymore, but debug mode shows that mvn retrieves data from that file. ) Apparently, maven-metada-local.xml isn't created automatically for me either. How I can instruct mvn to do that? My plugin-registry.xml is at [2]. (There wasn't a template for that. So, hope the format is correct!). maven-metadata-local.xml of maven-compiler-plugin is at [3]. I'm using official apache maven-2.2.1 build. Your help is much appreciated. [1] http://maven.apache.org/guides/introduction/introduction-to-plugin-registry.html [2] http://pastebin.com/yprQU2D2 [3] http://pastebin.com/Y375dwMg Thanks, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - 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 -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Set specific plugin versions for a project - issue in plugin-registry.xml/maven-metada-local.xml
On Mon, Jul 25, 2011 at 9:46 PM, Damian Bradicich dbradic...@sonatype.com wrote: But why ? simply have a top level parent pom that is solely for defining your plugin versions (and anything else that may cover all of your projects), you don't need any project specific logic in there. The parent doesn't need to list any of the children that use it (and act as an aggregator), that is just a common use of a parent. This would not work because the parent-pom file you are saying will be static. By static I meant that the parent pom file can not be modified later on after it goes in to the m2 repo. So, when a need arise to add a new plugin version, how it can be done? The way to do this is by maintaining maven-metadata.xml files which exists one per plugin under m2 repo (for example, for maven-compiler-plugin, it's in ~/.m2/repository/org/apache/maven/plugins/maven-compiler-plugin/maven-metadata*.xml). This way, I don't have a problem when a new plugin is added to the repo, right? It doesn't really matter whether this can be done via maven-metadata.xml or by some other means. We just need to make the setting details file per-plugin. --Kasun Damian On Mon, Jul 25, 2011 at 11:30 AM, Kasun Gajasinghe kasu...@gmail.comwrote: On Mon, Jul 25, 2011 at 5:34 PM, Damian Bradicich dbradic...@sonatype.com wrote: err...pluginManagement section even ;) Damian On Mon, Jul 25, 2011 at 8:02 AM, Damian Bradicich dbradic...@sonatype.comwrote: Why not define the pluginDependency section in a parent pom, then each of your projects uses this as a parent, and pulls in all the plugin dep versions defined in it (or overrides in project pom if necessary). Seems that would be simplest solution Since these projects are unrelated, they can't be glued together via a parent pom. Thanks, --Kasun Damian On Mon, Jul 25, 2011 at 7:43 AM, Benson Margulies bimargul...@gmail.comwrote: I don't know about plugin-registry.xml, but you can distribute a settings.xml for use with -gs that has an active-by-default profile with a pluginManagement section that does the job. On Mon, Jul 25, 2011 at 3:02 AM, Kasun Gajasinghe kasu...@gmail.com wrote: Hi, I have a requirement where I need to specify specific versions for a set of (basic) plugins. Adding the versions to the pom isn't an option because we need to set the plugin versions for a vast number of _unrelated_ builds. As I've found at [1], I've manually created a plugin-registry.xml file with needed plugin versions added. In addition to that, I've created maven-metadata-local.xml file in the m2 repo under the plugin directories, pointing to latest and release versions. But, unfortunately, these specified versions were not picked up by mvn. I needed latest maven-compiler-plugin version 2.3.2, but it always try to use 2.0.2. I've noticed that [1] is somewhat outdated because --check-plugin-latest parameter doesn't available anymore. So, I'm asking, does the plugin-registry.xml is still used by maven? If not what is the mechanism for specifying specific plugin versions (apart from current/parent pom)? (I've seen in some posts that the plugin-registry.xml isn't used anymore, but debug mode shows that mvn retrieves data from that file. ) Apparently, maven-metada-local.xml isn't created automatically for me either. How I can instruct mvn to do that? My plugin-registry.xml is at [2]. (There wasn't a template for that. So, hope the format is correct!). maven-metadata-local.xml of maven-compiler-plugin is at [3]. I'm using official apache maven-2.2.1 build. Your help is much appreciated. [1] http://maven.apache.org/guides/introduction/introduction-to-plugin-registry.html [2] http://pastebin.com/yprQU2D2 [3] http://pastebin.com/Y375dwMg Thanks, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - 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 -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com
Re: Set specific plugin versions for a project - issue in plugin-registry.xml/maven-metada-local.xml
On Tue, Jul 26, 2011 at 3:33 AM, Benson Margulies bimargul...@gmail.com wrote: As a general principle, the design of maven is trending toward locking down the versions of plugins for a build. Otherwise, you can't grab an old version of the source from a tag and depend on building it. Therefore, the idea of a separate 'control panel' for plugin versions is not popular. Global settings.xml is about the best you are going to do. Some day, conceivably, even that might stop working, but don't lose sleep over it. Yeah? Well I'm not sure about the reasons for the decision of maven devs, but I can tell this. Currently, all poms extend maven Super Pom [1] which contains some set of plugins at the release of maven. Most of the plugins are much older (some from 2007/08) in the super pom. for example, maven-compiler-plugin version is 2.0.2 in the super pom, which is from 2007. So, doesn't having an intermediary layer that will point to newer set of plugins is justified? At least It's ok if maven just picked the latest plugin version installed in the m2 repo which might be set via a setting. Anyway, I just needed to know the current implementation details. To give my two cents, I think the docs need an update especially since maven came to 3.0 era. (Yes, I understand the time constraints. Just expressing my thoughts.) [1] http://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Super_POM Thanks, --Kasun On Mon, Jul 25, 2011 at 5:26 PM, Kasun Gajasinghe kasu...@gmail.com wrote: On Mon, Jul 25, 2011 at 9:46 PM, Damian Bradicich dbradic...@sonatype.com wrote: But why ? simply have a top level parent pom that is solely for defining your plugin versions (and anything else that may cover all of your projects), you don't need any project specific logic in there. The parent doesn't need to list any of the children that use it (and act as an aggregator), that is just a common use of a parent. This would not work because the parent-pom file you are saying will be static. By static I meant that the parent pom file can not be modified later on after it goes in to the m2 repo. So, when a need arise to add a new plugin version, how it can be done? The way to do this is by maintaining maven-metadata.xml files which exists one per plugin under m2 repo (for example, for maven-compiler-plugin, it's in ~/.m2/repository/org/apache/maven/plugins/maven-compiler-plugin/maven-metadata*.xml). This way, I don't have a problem when a new plugin is added to the repo, right? It doesn't really matter whether this can be done via maven-metadata.xml or by some other means. We just need to make the setting details file per-plugin. --Kasun Damian On Mon, Jul 25, 2011 at 11:30 AM, Kasun Gajasinghe kasu...@gmail.comwrote: On Mon, Jul 25, 2011 at 5:34 PM, Damian Bradicich dbradic...@sonatype.com wrote: err...pluginManagement section even ;) Damian On Mon, Jul 25, 2011 at 8:02 AM, Damian Bradicich dbradic...@sonatype.comwrote: Why not define the pluginDependency section in a parent pom, then each of your projects uses this as a parent, and pulls in all the plugin dep versions defined in it (or overrides in project pom if necessary). Seems that would be simplest solution Since these projects are unrelated, they can't be glued together via a parent pom. Thanks, --Kasun Damian On Mon, Jul 25, 2011 at 7:43 AM, Benson Margulies bimargul...@gmail.comwrote: I don't know about plugin-registry.xml, but you can distribute a settings.xml for use with -gs that has an active-by-default profile with a pluginManagement section that does the job. On Mon, Jul 25, 2011 at 3:02 AM, Kasun Gajasinghe kasu...@gmail.com wrote: Hi, I have a requirement where I need to specify specific versions for a set of (basic) plugins. Adding the versions to the pom isn't an option because we need to set the plugin versions for a vast number of _unrelated_ builds. As I've found at [1], I've manually created a plugin-registry.xml file with needed plugin versions added. In addition to that, I've created maven-metadata-local.xml file in the m2 repo under the plugin directories, pointing to latest and release versions. But, unfortunately, these specified versions were not picked up by mvn. I needed latest maven-compiler-plugin version 2.3.2, but it always try to use 2.0.2. I've noticed that [1] is somewhat outdated because --check-plugin-latest parameter doesn't available anymore. So, I'm asking, does the plugin-registry.xml is still used by maven? If not what is the mechanism for specifying specific plugin versions (apart from current/parent pom)? (I've seen in some posts that the plugin-registry.xml isn't used anymore, but debug mode shows that mvn retrieves data from that file. ) Apparently, maven-metada-local.xml isn't created automatically for me either. How I can instruct mvn to do that? My
Re: Set specific plugin versions for a project - issue in plugin-registry.xml/maven-metada-local.xml
On Tue, Jul 26, 2011 at 3:58 AM, Damian Bradicich dbradic...@sonatype.com wrote: I'm still not seeing the problem, certainly a specific release of a parent pom would be static, but if you need to update versions, you update the pom and release a new version, then update your projects to use it as necessary. It is a simple workflow, and leaves a single place where all versions are defined, and will give you the least amount of trouble as you are not trying to hack up some local repo metadata to achieve the exact same thing. I mean this is the _exact_ kind of thing maven excels at. You will forever have the release of the parent pom, and will always be able to build older releases of your projects (as i see benson has already mentioned in his latest reply), anyone with simple pom knowledge can update the parent pom to use a new version of plugin A/B/C. As I said, this is a solution, but in our case, unfortunately, only partial. You may have not aware that I'm working on building packages to be installed at system level in Gentoo Linux. The overhead that adds for a new parent pom like this is pretty high. I'll just say that there are complications (such as build-order, which package owns the pom, maven re-installations etc.) when it comes to packaging at operating system level. I have more than enough pom knowledge to update the pom if needed. But our pom handling and maven invocation is automated. Manually, editing the pom with the available plugin versions is much complicated, and may not be possible with the limitations imposed by the system. Anyway, I'm evaluating this solution deeply as well. I'm just looking for the optimal, and elegant solution that maven already has as I figured. In the given solutions, I like this most because this gives the needed control to some extent. But I (like maven) can't force you into anything, just guide you to the best solution ;-) I know, and I respect that. :) Thanks, --Kasun Damian On Mon, Jul 25, 2011 at 5:26 PM, Kasun Gajasinghe kasu...@gmail.com wrote: On Mon, Jul 25, 2011 at 9:46 PM, Damian Bradicich dbradic...@sonatype.com wrote: But why ? simply have a top level parent pom that is solely for defining your plugin versions (and anything else that may cover all of your projects), you don't need any project specific logic in there. The parent doesn't need to list any of the children that use it (and act as an aggregator), that is just a common use of a parent. This would not work because the parent-pom file you are saying will be static. By static I meant that the parent pom file can not be modified later on after it goes in to the m2 repo. So, when a need arise to add a new plugin version, how it can be done? The way to do this is by maintaining maven-metadata.xml files which exists one per plugin under m2 repo (for example, for maven-compiler-plugin, it's in ~/.m2/repository/org/apache/maven/plugins/maven-compiler-plugin/maven-metadata*.xml). This way, I don't have a problem when a new plugin is added to the repo, right? It doesn't really matter whether this can be done via maven-metadata.xml or by some other means. We just need to make the setting details file per-plugin. --Kasun Damian On Mon, Jul 25, 2011 at 11:30 AM, Kasun Gajasinghe kasu...@gmail.com wrote: On Mon, Jul 25, 2011 at 5:34 PM, Damian Bradicich dbradic...@sonatype.com wrote: err...pluginManagement section even ;) Damian On Mon, Jul 25, 2011 at 8:02 AM, Damian Bradicich dbradic...@sonatype.comwrote: Why not define the pluginDependency section in a parent pom, then each of your projects uses this as a parent, and pulls in all the plugin dep versions defined in it (or overrides in project pom if necessary). Seems that would be simplest solution Since these projects are unrelated, they can't be glued together via a parent pom. Thanks, --Kasun Damian On Mon, Jul 25, 2011 at 7:43 AM, Benson Margulies bimargul...@gmail.comwrote: I don't know about plugin-registry.xml, but you can distribute a settings.xml for use with -gs that has an active-by-default profile with a pluginManagement section that does the job. On Mon, Jul 25, 2011 at 3:02 AM, Kasun Gajasinghe kasu...@gmail.com wrote: Hi, I have a requirement where I need to specify specific versions for a set of (basic) plugins. Adding the versions to the pom isn't an option because we need to set the plugin versions for a vast number of _unrelated_ builds. As I've found at [1], I've manually created a plugin-registry.xml file with needed plugin versions added. In addition to that, I've created maven-metadata-local.xml file in the m2 repo under the plugin directories, pointing to latest and release versions. But, unfortunately, these specified versions were not picked up by mvn. I needed latest maven-compiler-plugin version 2.3.2
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
On Mon, Jul 4, 2011 at 11:31 AM, Ralph Goers ralph.go...@dslextreme.comwrote: The point I am making is that if you have all those jars together something is not going to work correctly. SLF4J only allows one logging implementation. If you have all of SLF4J's jars, including the binding for Log4j as well as Logback, then SLF4J will throw a runtime exception. Commons Logging also has quirks. If Log4j is present then it will be used by default, otherwise it will do something else. When you start dumping a whole bunch of jars together in one directory you had better understand how they are all going to relate to each other. I don't get it. log4j and logback won't be included in gentoo's uber-jar since they aren't dependencies of apache-maven [1]. commons-logging and slf4j will be integrated since they are integrated in the upstream official build as well. What makes you think that I'm bundling together all the available logging implementations? Is there a need to? [1] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html Regards, --Kasun
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
On Mon, Jul 4, 2011 at 8:34 PM, Ralph Goers ralph.go...@dslextreme.comwrote: The question I asked was, will you be putting the slf4j, Log4j, commons-logging, and Logback into your shared library - presumably under /usr/shared. This has nothing to do with Maven, per se. Maybe I'm not clear on what you are doing but I see two possibilities: 1. You are placing all the resultant jars in a common directory, such as /usr/share/lib, where applications will use them. This won't work for the reasons below. This isn't the case. 2. You are building all these projects as independent entities under /usr/share. If this is the case then it sounds like you are (sort of) duplicating the Maven repository and I have no idea why this is of benefit to anyone, especially since you will only support a single version of an artifact. Almost true. For example, slf4j jar is under /usr/share/slf4j/lib/slf4j.jar. And, we have a concept called SLOT which is almost acts like the first level of a two level index if you are familiar with DBMS. A particular SLOT contains a set of versions (ex. 1.1, 1.12, 1.2 etc.) which are compatible with each other. So, only one jar can be installed in a particular SLOT. There can be several SLOTs, implying we can have more than one version of an artifact. ex. jarjar new version is in SLOT 1, i.e. /usr/share/jarjar-1/ And, these jars in /usr/share/*/lib/*.jar are not only for maven. To be specific not intended for maven. These are for system use. Any application maven or not is able to benefit from these. What we are doing is using these jars under maven, so we don't have to download these again. I could understand this if you are building applications end users can use that are written in Java, but in that case I'd wonder why you don't just use out-of-the-box Maven and either a) just download the dependencies from the central repo or b) build the dependencies from their source and deploy them to your local repository. Of course, with the second option you would have to build several versions of the dependencies. To reiterate, our main usecase is supporting packagers at system level. There's a need to have a custom build for them. It's not like we blind-foldly building maven again instead of using official maven build! To answer your question; at system-level, maven should be run completely offline (even at first time!). We have mechanisms in place to take care of the deps via DEPEND in ebuilds, which I'm not going to explain. Read about Gentoo if you got spare time. It'll be interesting! :) --Kasun Ralph On Jul 4, 2011, at 6:11 AM, Kasun Gajasinghe wrote: On Mon, Jul 4, 2011 at 11:31 AM, Ralph Goers ralph.go...@dslextreme.com wrote: The point I am making is that if you have all those jars together something is not going to work correctly. SLF4J only allows one logging implementation. If you have all of SLF4J's jars, including the binding for Log4j as well as Logback, then SLF4J will throw a runtime exception. Commons Logging also has quirks. If Log4j is present then it will be used by default, otherwise it will do something else. When you start dumping a whole bunch of jars together in one directory you had better understand how they are all going to relate to each other. I don't get it. log4j and logback won't be included in gentoo's uber-jar since they aren't dependencies of apache-maven [1]. commons-logging and slf4j will be integrated since they are integrated in the upstream official build as well. What makes you think that I'm bundling together all the available logging implementations? Is there a need to? [1] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html Regards, --Kasun - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
On Tue, Jul 5, 2011 at 1:57 AM, Ralph Goers ralph.go...@dslextreme.comwrote: From Kasun's answers it is quite clear to me that we will need to add something to Jira where it asks for the operating system for all the Java projects I work on at the ASF. If the O.S. is Gentoo then we will have to reject any issues coming from the stuff that comes as part of the O.S. as it can't be trusted. Binary official build also available in Gentoo already. On Jul 4, 2011, at 11:48 AM, Robert Burrell Donkin wrote: On Mon, Jul 4, 2011 at 7:32 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: look, what you are trying to do is move an object of infinite mass, keeping the lever length and force applied finite. good luck, it will be fun for us watching from the sidelines... fundamentally maven is about downloading dependencies on demand from the network rather than building from source... gentoo is about building from source rather than downloading binaries from the network... (as a gentoo user myself...) The bytecode languages don't fit well into the Gentoo model. Even though bytecode is an intermediary source form compiled from source, Gentoo tries to treat it as a platform dependent binary. The Java team then fights a losing battle to cobble together enough accurate builds for the library chain to get anything useful to work. Even then, because the source bytecode doesn't necessarily match the official release, strange issue keep cropping up. After many problems, I've now opted to uninstall the official Maven and Ant packages (and Eclipse...), and use instead a set of scripts which accurately and flexibly allow me to configure exactly the official bytecode I want to use (a little bit like a better eselect). By official did you meant the upstream packages available as binary like maven-bin? If that's the case, these -bins are the same as upstream build. I guess you meant that since there's only the binary maven is available now. What did you find wrong? It has always struck me as somewhat ironic that if the Gentoo team donned their clue-hats and treated bytecode as the source form then they might quickly have one of the best development environments for the bytecode languages... I too kind of agree to this since the point being the built jars are platform independent. If anybody like to know the points for it - http://www.gentoo.org/proj/en/java/why-build-from-source.xml I'm not going to discuss why building from source is good or bad any further and is off-topic! ;) Regards, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg
Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException
After this brainstorming with all of you, finally figured out the error. The issue was with doxia, that is in the site-tools. The build failed in a compile section, so I didn't thought that caused the issue. I have incorporated an older incompatible doxia version, thinking I can fix the site-related stuff later. With the new version, it worked. It's not related to bootstrapping anyway. Thanks to Hervé, Kristian, Martin and all the others for helping! On Sun, Jul 3, 2011 at 8:19 AM, Mark Derricutt m...@talios.com wrote: I think I died a little reading this. Maven itself already has subtle strange issues and problems working with dependency ranges, having a gentoo specific version of maven that does even more different things with artifact resolution would be a nightmare to deal with. Esp. if you have developers working on different distributions or OS's. Oh well, 'nightmare' is probably the word that suits in here as well! But this is a long-time blocker in Gentoo. maven-bin is already available for users, this effort is for the packagers. There was an effort several years ago, which got stalled due to developer got hit by bus factor. Now is the time to get this right! --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg
Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException
On Sun, Jul 3, 2011 at 1:28 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Yes, 3.0.3 looks cleaner. Well, I answered the points for choosing 2.2.1. We surely need to support 3.0.3 too, the future of maven. Is it possible Doxia plays a part here too? We haven't really bothered about these site stuff, and therefore, doxia version we have is a little older. no, Doxia shouldn't be involved in your actual problems: it's used only for reporting, and there is only a simple doxia API that is included in Maven core Yes, but the said issue is more related to the remote-resources-plugin. It too only use doxia-sink-api though. Anyway, there's some bond between that plugin and doxia. In [1] line 1348, the failed component's role-hint is doxia-default. And, the nightmare I referred is not doxia, but the whole process. There were around 50 ebuilds that I've bumped in the process, and there were lot of understanding to do in Maven as well. And, we just started the testing phase, so it's not suitable to put in to main tree in Gentoo. [1] http://paste.pocoo.org/show/426899/ There's another little issue with hidden classes in the uber jar. It suits for a new thread i guess. --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg
Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException
On Sun, Jul 3, 2011 at 2:28 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: uh, you've got doxia-module-*.jar in your /usr/share/maven-2/lib/ directory? but these are not in Maven core: only doxia-api and doxia-logging-api are part of Maven core [2] Other Doxia artifacts are used in site plugin only, and should not be shared in core. Your problem seems to be related: this doxia-default role has been added in doxia-sitetools component, which should not be in the classpath. see DOXIA-147 [3] IMHO, with full Doxia in Maven core classloader, you'll have failures with reporting plugins (if not strange issues like the one you had here) Yes, I've removed the doxia modules and added the needed doxia-sink-api and doxia-logging-api. I think you meant to doxia-sink-api not doxia-api. The issue is resolved! Thanks, --Kasun Regards, Hervé [2] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html [3] http://jira.codehaus.org/browse/DOXIA-147 Le dimanche 3 juillet 2011, Kasun Gajasinghe a écrit : On Sun, Jul 3, 2011 at 1:28 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Yes, 3.0.3 looks cleaner. Well, I answered the points for choosing 2.2.1. We surely need to support 3.0.3 too, the future of maven. Is it possible Doxia plays a part here too? We haven't really bothered about these site stuff, and therefore, doxia version we have is a little older. no, Doxia shouldn't be involved in your actual problems: it's used only for reporting, and there is only a simple doxia API that is included in Maven core Yes, but the said issue is more related to the remote-resources-plugin. It too only use doxia-sink-api though. Anyway, there's some bond between that plugin and doxia. In [1] line 1348, the failed component's role-hint is doxia-default. And, the nightmare I referred is not doxia, but the whole process. There were around 50 ebuilds that I've bumped in the process, and there were lot of understanding to do in Maven as well. And, we just started the testing phase, so it's not suitable to put in to main tree in Gentoo. [1] http://paste.pocoo.org/show/426899/ There's another little issue with hidden classes in the uber jar. It suits for a new thread i guess. --Kasun - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg
[Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
Hi, Is it possible to have the .java source files which got shaded by maven-shade-plugin? Currently, it generates the uberjar without leaving the shaded sources files. There's obviously an intermediary step in which these source files will be transformed to shaded java packages like hidden.org.codehaus.plexus.util.*. So, like to know whether it's possible to have those .java files. Any complications involved? [1] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html Thanks, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
On Sun, Jul 3, 2011 at 4:23 PM, Benson Margulies bimargul...@gmail.comwrote: I'm not sure what you are asking. Shade is a binary operation that uses asm. It renames packages. There is no feature of creating corresponding source. I see. It means what I asked is not possible. I wasn't aware that it's a binary operation. What I want to do is to relocate the packages such as org.codehaus.plexus.util, org.apache.xerces that are shaded by maven in the official build. As you know, these should be shaded, else these classes will conflict with a different version of the same class that a project would be using. Because of the approach we are taking, we can't invoke maven-shade-plugin and get the job done. I think I'll have to manually patch the maven sources to get the said functionality. Have to proceed on this track if there's no other way. Can you please let me know the changes required to get this done? Thanks, --Kasun If you just want the original source, the plugin doesn't get into that business either, that would be a whole 'nother plugin. On Sun, Jul 3, 2011 at 6:39 AM, Kasun Gajasinghe kasu...@gmail.com wrote: Hi, Is it possible to have the .java source files which got shaded by maven-shade-plugin? Currently, it generates the uberjar without leaving the shaded sources files. There's obviously an intermediary step in which these source files will be transformed to shaded java packages like hidden.org.codehaus.plexus.util.*. So, like to know whether it's possible to have those .java files. Any complications involved? [1] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html Thanks, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
On Sun, Jul 3, 2011 at 6:30 PM, Benson Margulies bimargul...@gmail.comwrote: I'm not sure that the operation you are asking for is well-defined. Shade combines, renames, and transforms, using arbitrary Java plugins that operate entirely on binaries, which can themselves be the output of, well, shade. Trying to read the source and perform the same transformations would be very, very, hard. You might be able to grab jarjar, a non-maven tool with similar capabilities, build it from source, and use it for these simple cases as part of your bootstrap. Or, for bootstrap, you could leave out the shading and just depend on Xerces unrenamed, go all the way around, build shade, and then rebuild. I've ran jarjar with some samples and checked. This would indeed do the job. I hope there is no concerning bugs. I see a bug report saying it fails with ant 1.8. Well, I'm going to go ahead with this. Thanks for the suggestion Benson! --Kasun Or you might be able to cherry-pick the maven-shade-plugin source. It could be that there is a clean separation in there between code connected to the plugin framework and code that does the work. On Sun, Jul 3, 2011 at 7:38 AM, Kasun Gajasinghe kasu...@gmail.com wrote: On Sun, Jul 3, 2011 at 4:23 PM, Benson Margulies bimargul...@gmail.com wrote: I'm not sure what you are asking. Shade is a binary operation that uses asm. It renames packages. There is no feature of creating corresponding source. I see. It means what I asked is not possible. I wasn't aware that it's a binary operation. What I want to do is to relocate the packages such as org.codehaus.plexus.util, org.apache.xerces that are shaded by maven in the official build. As you know, these should be shaded, else these classes will conflict with a different version of the same class that a project would be using. Because of the approach we are taking, we can't invoke maven-shade-plugin and get the job done. I think I'll have to manually patch the maven sources to get the said functionality. Have to proceed on this track if there's no other way. Can you please let me know the changes required to get this done? Thanks, --Kasun If you just want the original source, the plugin doesn't get into that business either, that would be a whole 'nother plugin. On Sun, Jul 3, 2011 at 6:39 AM, Kasun Gajasinghe kasu...@gmail.com wrote: Hi, Is it possible to have the .java source files which got shaded by maven-shade-plugin? Currently, it generates the uberjar without leaving the shaded sources files. There's obviously an intermediary step in which these source files will be transformed to shaded java packages like hidden.org.codehaus.plexus.util.*. So, like to know whether it's possible to have those .java files. Any complications involved? [1] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html Thanks, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
On Sun, Jul 3, 2011 at 10:42 PM, Ralph Goers ralph.go...@dslextreme.comwrote: Out of curiosity, you said you are putting building your jars and putting them in a shared library. What are you going to do with SLF4J, Log4J, Commons Logging and Logback? slf4j, commons-logging etc. will also be installed at /usr/share as usual. Maven needs to shade these jars and few others. So, these jars will be shaded, and packaged together to make an uber-jar. slf4j, commons-logging system jars won't be changed. What exactly the point you are trying to make? And, how does log4j and Logback relates to core maven? I haven't seen these as dependencies! --Kasun Ralph On Jul 3, 2011, at 9:57 AM, Kasun Gajasinghe wrote: On Sun, Jul 3, 2011 at 6:30 PM, Benson Margulies bimargul...@gmail.com wrote: I'm not sure that the operation you are asking for is well-defined. Shade combines, renames, and transforms, using arbitrary Java plugins that operate entirely on binaries, which can themselves be the output of, well, shade. Trying to read the source and perform the same transformations would be very, very, hard. You might be able to grab jarjar, a non-maven tool with similar capabilities, build it from source, and use it for these simple cases as part of your bootstrap. Or, for bootstrap, you could leave out the shading and just depend on Xerces unrenamed, go all the way around, build shade, and then rebuild. I've ran jarjar with some samples and checked. This would indeed do the job. I hope there is no concerning bugs. I see a bug report saying it fails with ant 1.8. Well, I'm going to go ahead with this. Thanks for the suggestion Benson! --Kasun Or you might be able to cherry-pick the maven-shade-plugin source. It could be that there is a clean separation in there between code connected to the plugin framework and code that does the work. On Sun, Jul 3, 2011 at 7:38 AM, Kasun Gajasinghe kasu...@gmail.com wrote: On Sun, Jul 3, 2011 at 4:23 PM, Benson Margulies bimargul...@gmail.com wrote: I'm not sure what you are asking. Shade is a binary operation that uses asm. It renames packages. There is no feature of creating corresponding source. I see. It means what I asked is not possible. I wasn't aware that it's a binary operation. What I want to do is to relocate the packages such as org.codehaus.plexus.util, org.apache.xerces that are shaded by maven in the official build. As you know, these should be shaded, else these classes will conflict with a different version of the same class that a project would be using. Because of the approach we are taking, we can't invoke maven-shade-plugin and get the job done. I think I'll have to manually patch the maven sources to get the said functionality. Have to proceed on this track if there's no other way. Can you please let me know the changes required to get this done? Thanks, --Kasun If you just want the original source, the plugin doesn't get into that business either, that would be a whole 'nother plugin. On Sun, Jul 3, 2011 at 6:39 AM, Kasun Gajasinghe kasu...@gmail.com wrote: Hi, Is it possible to have the .java source files which got shaded by maven-shade-plugin? Currently, it generates the uberjar without leaving the shaded sources files. There's obviously an intermediary step in which these source files will be transformed to shaded java packages like hidden.org.codehaus.plexus.util.*. So, like to know whether it's possible to have those .java files. Any complications involved? [1] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html Thanks, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com
[Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException
Hi, First of all, the good news. We were able to integrate maven successfully to Gentoo. Now, it was able to do most of the general compiling and building stuff. We build maven-from-source which involve considerable work to integrate. But, there's few glitches. There's an error in some builds which use maven-remote-resources-plugin. This happened to me when testing the build wagon-1.0-beta-7 tag, and few other builds. It fails with ClassNotFoundException for the class org.codehaus.plexus.velocity.DefaultVelocityComponent which is in the package plexus-velocity. The stack trace is at http://pastebin.com/p8YUsGw7. Does maven-2.2.1 need plexus-velocity as a dependency? I haven't noticed. In fact, plexus-velocity is in the m2 repo, though, apparently it's not used by the mvn. I tried adding plexus-velocity as a dependency (to uber jar if you may). We don't actually use the uber jar, but we put the needs jars to maven lib/ directory, which gets identified by classworlds. It solved the said issue. But, then it asked for the artifact velocity. See: http://pastebin.com/r9vsM85k Oh well, what option I have now. I've included velocity as well to be picked by classworlds when launching mvn. It brought me here where I got stuck: http://pastebin.com/WvLSsupa Any help please? We are much close to the finish-line. Thanks, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg
Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException
On Sat, Jul 2, 2011 at 2:03 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: remember that Maven is a core engine to run plugins. Maven core does not depend on plexus-velocity [1], but maven-remote-resources- plugin does [2] Maven distribution does not contain every library needed by every plugin, but the logic to download them (hence the Maven downloads the internet effect some complain about). Each plugin is isolated to have access to its dependencies independently from others, and even independently from Maven core dependencies as much as possible. So I understand that you rebuilt Maven core from sources to match Gentoo spirit. What about core dependencies [1]? Did you download them (as done by build.xml) or modified the build to use you own compiled from source version? And what about dependencies needed by plugins? To give a introduction read this. Skip if this's too long. What we've done is that we grabbed all the maven core dependencies, converted those to ant projects (via maven-ant-plugin), tarballed it, and uploaded to a separate server. Then, when user emerge (install) maven, it downloads all these core dependencies, compiles them and installs to an appropriate location in /usr/share. for example: /usr/share/maven-artifact and the jar will be at lib/maven-artifact.jar. Then, maven collect these deps to a one place by creating symlinks to those dependency jars in /usr/share/maven-2/lib/. This effectively drops the need to create the uberjar in lib/. when the classworlds is launched, it'll identify the dependency jars. See this post as well. http://maven.40175.n5.nabble.com/maven-core-tests-fail-when-invoked-via-ant-td4502850.html Now, back to the issue in question. Maven's core dependency is handled via maven-2.2.1-uber.jar. We use almost same mechanism. That part is done. Maven plugins handling was left ENTIRELY to the built maven. Therefore, I expected that our maven build will take care of plugin dependencies by downloading and resolving those. Maven did download the dependency jars of the plugins as I've seen; in this case, plexus-velocity. But, it doesn't correctly resolve the dependencies to make it available at plugin runtime. So, I'm asking the question back from you. How does the plugin dependencies are handled by maven? What are the points I should consider? In fact, we expect to bundle the maven-plugins to be compiled and installed via Gentoo package management system (portage) too. So, your inputs about how maven handles plugin _dependencies_ will be much useful. (The comping and installing happens via portage, i.e. we do not worry maven about it.) What's your strategy about built-from-source vs binary-downloaded-from- central-repository? Where do you put the limit? Do you intent to build your own repository containing only artifacts built by Gentoo people? There are two aspects. The maven user's aspect, and gentoo packager's aspect. User's aspect is the concern now. In user's case, maven will download the dependency binary jars of the package they are building from maven-central. I _assumed_ plugins also behave like any other jar. Packager's aspect is a little different, and doesn't need to be worried, right now! Thanks, --Kasun Regards, Hervé [1] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html [2] http://maven.apache.org/plugins/maven-remote-resources- plugin/dependencies.html Le samedi 2 juillet 2011, Kasun Gajasinghe a écrit : Hi, First of all, the good news. We were able to integrate maven successfully to Gentoo. Now, it was able to do most of the general compiling and building stuff. We build maven-from-source which involve considerable work to integrate. But, there's few glitches. There's an error in some builds which use maven-remote-resources-plugin. This happened to me when testing the build wagon-1.0-beta-7 tag, and few other builds. It fails with ClassNotFoundException for the class org.codehaus.plexus.velocity.DefaultVelocityComponent which is in the package plexus-velocity. The stack trace is at http://pastebin.com/p8YUsGw7. Does maven-2.2.1 need plexus-velocity as a dependency? I haven't noticed. In fact, plexus-velocity is in the m2 repo, though, apparently it's not used by the mvn. I tried adding plexus-velocity as a dependency (to uber jar if you may). We don't actually use the uber jar, but we put the needs jars to maven lib/ directory, which gets identified by classworlds. It solved the said issue. But, then it asked for the artifact velocity. See: http://pastebin.com/r9vsM85k Oh well, what option I have now. I've included velocity as well to be picked by classworlds when launching mvn. It brought me here where I got stuck: http://pastebin.com/WvLSsupa Any help please? We are much close to the finish-line. Thanks, --Kasun - To unsubscribe, e-mail: dev-unsubscr
Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException
On Sat, Jul 2, 2011 at 7:43 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: yes, plugin depdendencies are downloaded like any other artifacts via DefaultArtifactResolver in maven-artifact-manager for Maven 2 [1]. Plugin resolution and classloader preparation is done in DefaultPluginManager in maven-core [2] Velocity and plexus-velocity are nothing different than any library. I don't see any obvious reason why it fails: mvn -X debugging seems to be necessary, comparing output from official Maven build and Gentoo's one I see. Well, I did look at the debug output with my limited understanding, but couldn't find the error. It's much appreciated if you can have a quick look at it and let me know what you see. As I see, the error comes at the following line. Maven has reloaded all the core maven dependencies since the gentoo maven build shows loading them urls[x]. official maven build shows this. [INFO] Setting property: classpath.resource.loader.class = 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. [INFO] Setting property: velocimacro.messages.on = 'false'. [INFO] Setting property: resource.loader = 'classpath'. [0] Official maven build http://paste.pocoo.org/show/426913/ [1] Gentoo maven build http://paste.pocoo.org/show/426899/ [2] The diff from [0] to [1] http://paste.pocoo.org/show/426901/ Thanks, --Kasun Regards, Hervé [1] http://maven.apache.org/ref/2.2.1/maven-artifact-manager [2] http://maven.apache.org/ref/2.2.1/maven-core Le samedi 2 juillet 2011, Kasun Gajasinghe a écrit : On Sat, Jul 2, 2011 at 2:03 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: remember that Maven is a core engine to run plugins. Maven core does not depend on plexus-velocity [1], but maven-remote-resources- plugin does [2] Maven distribution does not contain every library needed by every plugin, but the logic to download them (hence the Maven downloads the internet effect some complain about). Each plugin is isolated to have access to its dependencies independently from others, and even independently from Maven core dependencies as much as possible. So I understand that you rebuilt Maven core from sources to match Gentoo spirit. What about core dependencies [1]? Did you download them (as done by build.xml) or modified the build to use you own compiled from source version? And what about dependencies needed by plugins? To give a introduction read this. Skip if this's too long. What we've done is that we grabbed all the maven core dependencies, converted those to ant projects (via maven-ant-plugin), tarballed it, and uploaded to a separate server. Then, when user emerge (install) maven, it downloads all these core dependencies, compiles them and installs to an appropriate location in /usr/share. for example: /usr/share/maven-artifact and the jar will be at lib/maven-artifact.jar. Then, maven collect these deps to a one place by creating symlinks to those dependency jars in /usr/share/maven-2/lib/. This effectively drops the need to create the uberjar in lib/. when the classworlds is launched, it'll identify the dependency jars. See this post as well. http://maven.40175.n5.nabble.com/maven-core-tests-fail-when-invoked-via-ant -td4502850.html Now, back to the issue in question. Maven's core dependency is handled via maven-2.2.1-uber.jar. We use almost same mechanism. That part is done. Maven plugins handling was left ENTIRELY to the built maven. Therefore, I expected that our maven build will take care of plugin dependencies by downloading and resolving those. Maven did download the dependency jars of the plugins as I've seen; in this case, plexus-velocity. But, it doesn't correctly resolve the dependencies to make it available at plugin runtime. So, I'm asking the question back from you. How does the plugin dependencies are handled by maven? What are the points I should consider? In fact, we expect to bundle the maven-plugins to be compiled and installed via Gentoo package management system (portage) too. So, your inputs about how maven handles plugin _dependencies_ will be much useful. (The comping and installing happens via portage, i.e. we do not worry maven about it.) What's your strategy about built-from-source vs binary-downloaded-from- central-repository? Where do you put the limit? Do you intent to build your own repository containing only artifacts built by Gentoo people? There are two aspects. The maven user's aspect, and gentoo packager's aspect. User's aspect is the concern now. In user's case, maven will download the dependency binary jars of the package they are building from maven-central. I _assumed_ plugins also behave like any other jar. Packager's aspect is a little different, and doesn't need to be worried, right now! Thanks, --Kasun Regards, Hervé [1] http://maven.apache.org/ref
Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException
On Sat, Jul 2, 2011 at 7:45 PM, Ralph Goers ralph.go...@dslextreme.comwrote: Not to belittle what you are doing, but on every system I use I 1) Download the maven gziip. 2) unzip it in /opt 3) create a symlink of /opt/maven to the maven I downloaded 4) add /opt/maven/bin to the path in /etc/profile 5) add an export for M2_HOME to /opt/maven in /etc/profile. Then I start using maven. Even if Maven is installed on the system I do this. If I want to use Ant I do the same thing. I got burned enough times by the crappy way RedHat installed Java and Ant on their systems that I just will not use them and I now assume that whatever things the system builder did to install those components probably broke it. I know that won't discourage you from doing what you are doing, but from a user's perspective I'd rather have a system that did the above for me than what you describe below. Obviously, installing into /usr/share instead of /opt wouldn't make much of a difference to the process. Ralph, No, you are not discouraging me in anyway. This stage is just the first step of a much wider task. The ultimate goal of this work is to provide the ability to package maven-based builds to Gentoo system. Gentoo encourages and the package-management installs packages by first compiling them from source. So, as you can understand, if the package source uses maven as the build management tool, it needs maven to do the building and generate the jar. Further, there are other constraints involved. Mainly the packages should be able to use the existing jars available in the system (under /usr/share), and we've are not strict about having a specific version as a dep as long the existing system jar is api-compatible. So, this is the step we take to have a custom maven build tailored to Gentoo system satisfying all the constraints. --Kasun Ralph On Jul 2, 2011, at 3:59 AM, Kasun Gajasinghe wrote: On Sat, Jul 2, 2011 at 2:03 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: remember that Maven is a core engine to run plugins. Maven core does not depend on plexus-velocity [1], but maven-remote-resources- plugin does [2] Maven distribution does not contain every library needed by every plugin, but the logic to download them (hence the Maven downloads the internet effect some complain about). Each plugin is isolated to have access to its dependencies independently from others, and even independently from Maven core dependencies as much as possible. So I understand that you rebuilt Maven core from sources to match Gentoo spirit. What about core dependencies [1]? Did you download them (as done by build.xml) or modified the build to use you own compiled from source version? And what about dependencies needed by plugins? To give a introduction read this. Skip if this's too long. What we've done is that we grabbed all the maven core dependencies, converted those to ant projects (via maven-ant-plugin), tarballed it, and uploaded to a separate server. Then, when user emerge (install) maven, it downloads all these core dependencies, compiles them and installs to an appropriate location in /usr/share. for example: /usr/share/maven-artifact and the jar will be at lib/maven-artifact.jar. Then, maven collect these deps to a one place by creating symlinks to those dependency jars in /usr/share/maven-2/lib/. This effectively drops the need to create the uberjar in lib/. when the classworlds is launched, it'll identify the dependency jars. See this post as well. http://maven.40175.n5.nabble.com/maven-core-tests-fail-when-invoked-via-ant-td4502850.html Now, back to the issue in question. Maven's core dependency is handled via maven-2.2.1-uber.jar. We use almost same mechanism. That part is done. Maven plugins handling was left ENTIRELY to the built maven. Therefore, I expected that our maven build will take care of plugin dependencies by downloading and resolving those. Maven did download the dependency jars of the plugins as I've seen; in this case, plexus-velocity. But, it doesn't correctly resolve the dependencies to make it available at plugin runtime. So, I'm asking the question back from you. How does the plugin dependencies are handled by maven? What are the points I should consider? In fact, we expect to bundle the maven-plugins to be compiled and installed via Gentoo package management system (portage) too. So, your inputs about how maven handles plugin _dependencies_ will be much useful. (The comping and installing happens via portage, i.e. we do not worry maven about it.) What's your strategy about built-from-source vs binary-downloaded-from- central-repository? Where do you put the limit? Do you intent to build your own repository containing only artifacts built by Gentoo people? There are two aspects. The maven user's aspect, and gentoo packager's aspect. User's aspect
Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException
On Sun, Jul 3, 2011 at 12:30 AM, Hervé BOUTEMY herve.bout...@free.frwrote: Le samedi 2 juillet 2011, Kasun Gajasinghe a écrit : No, you are not discouraging me in anyway. This stage is just the first step of a much wider task. The ultimate goal of this work is to provide the ability to package maven-based builds to Gentoo system. Gentoo encourages and the package-management installs packages by first compiling them from source. So, as you can understand, if the package source uses maven as the build management tool, it needs maven to do the building and generate the jar. Further, there are other constraints involved. Mainly the packages should be able to use the existing jars available in the system (under /usr/share), and we've are not strict about having a specific version as a dep as long the existing system jar is api-compatible. honestly, this is the part I really doubt about: it will be hard to do (will need to change the way Maven resolves dependencies), and I expect there will be a lot of failures since dependencies version modification in general causes failures. As a proof of concept, I find the task fun. As a user, I expect a lot of problems and wouldn't really be confident about this. To re-iterate, as a 'user' this will have a 'normal' behavior of Maven. It's the system part that will be different, and have the said constraints. And, maven is packaged with almost the same dependency versions of Maven. There were few exceptions in some Plexus packages, but the versions are close enough and api-compatible. Do you really think this leads to the said error? But if you want to try, why not :) Well, we have packaged ant and is in a good working condition. Now, unfortunately, maven-based projects don't have a simpler way to package their projects, to be installed via portage (the package mgt system). We are going to provide a direct way for this. --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg
Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException
On Sun, Jul 3, 2011 at 1:05 AM, Benson Margulies bimargul...@gmail.comwrote: This strikes me as forking maven, making a fundamental changing in the behavior, and then passing off the results as still 'maven'. I'm not sure if 'trademark' is the right stepping-off point here, but something about it seems very wrong. Oh, I won't go that far. :) We haven't forked, and didn't change a single bit of code in Maven. There were few changes in the dependencies (for example having wagon-* 1.0_beta7 versions instead of 1.0_beta6.), but I don't think that's a fork per se. And, for the _system_, there will be a maven eclass, which handles the versioning. Gentoo has the concept of SLOTs, the which you can think of as baskets, each containing a set of compatible versions. I may not be the right person to answer this type of issue anyway! --Kasun On Sat, Jul 2, 2011 at 3:22 PM, Ralph Goers ralph.go...@dslextreme.com wrote: On Jul 2, 2011, at 8:38 AM, Kasun Gajasinghe wrote: Ralph, No, you are not discouraging me in anyway. This stage is just the first step of a much wider task. The ultimate goal of this work is to provide the ability to package maven-based builds to Gentoo system. Gentoo encourages and the package-management installs packages by first compiling them from source. So, as you can understand, if the package source uses maven as the build management tool, it needs maven to do the building and generate the jar. Further, there are other constraints involved. Mainly the packages should be able to use the existing jars available in the system (under /usr/share), and we've are not strict about having a specific version as a dep as long the existing system jar is api-compatible. This makes me wonder if anyone you are working with has experience working with Java applications. What you are doing sounds like it is ripe for problems. API dependencies aren't the only things that change between versions. You might have new configuration attributes added, additional dependencies, etc. Trying to get a whole pile of Java-based applications to use the same versions of jars is a problem in an application server, let alone across a whole operating system. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg
Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException
On Sun, Jul 3, 2011 at 3:46 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: lø., 02.07.2011 kl. 12.22 -0700, skrev Ralph Goers: On Jul 2, 2011, at 8:38 AM, Kasun Gajasinghe wrote: Ralph, No, you are not discouraging me in anyway. This stage is just the first step of a much wider task. The ultimate goal of this work is to provide the ability to package maven-based builds to Gentoo system. Gentoo encourages and the package-management installs packages by first compiling them from source. So, as you can understand, if the package source uses maven as the build management tool, it needs maven to do the building and generate the jar. Further, there are other constraints involved. Mainly the packages should be able to use the existing jars available in the system (under /usr/share), and we've are not strict about having a specific version as a dep as long the existing system jar is api-compatible. I think what you're trying to do is tremendously gutsy, but I would expect no less from gentoo :) Would you basically be trying to build the whole stack more or less from trunk, or would you be going off the latest released versions ? We are building the stack with Maven 2.2.1 tag. For the deps plexus and wagon, we tried to go with the latest released version available where we can. I can't directly help you with the problem you're facing, but it would sound like it might be coming in somewhere related to the site stuff, which is integrated in 2.2.1 core. This was totally removed from 3.x core, which is another reason why starting the whole lot with 3.x might be easier; it has a simpler dependency profile. But I'm not going to re-iterate that. Yes, 3.0.3 looks cleaner. Well, I answered the points for choosing 2.2.1. We surely need to support 3.0.3 too, the future of maven. Is it possible Doxia plays a part here too? We haven't really bothered about these site stuff, and therefore, doxia version we have is a little older. --Kasun Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg
Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException
On Sun, Jul 3, 2011 at 6:06 AM, Martin Gainty mgai...@hotmail.com wrote: there are 4 classpath properties you pass to the maven-ant runtime environment property name=compile_classpath refid=maven.compile.classpath/ property name=runtime_classpath refid=maven.runtime.classpath/ property name=test_classpath refid=maven.test.classpath/ property name=plugin_classpath refid=maven.plugin.classpath/if the missing jar is located on maven.runtime.classpath then the ant runtime should resolve the classpath http://maven.apache.org/plugins/maven-antrun-plugin/examples/classpaths.html when you get a chance could you explain why you are repackaging maven in an ant environment seems like you're effort is to stuff a mercedes engine in a yugo ? You are missing the point. We are not running ant inside maven. We use ant only for packaging maven itself (bootstrapping). That's the solution for the hen and egg problem in maven. There is no need of AntRun plugin. Thanks for trying to help anyway. --Kasun Martin Gainty __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. From: kasu...@gmail.com Date: Sun, 3 Jul 2011 05:44:37 +0530 Subject: Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException To: dev@maven.apache.org On Sun, Jul 3, 2011 at 12:30 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le samedi 2 juillet 2011, Kasun Gajasinghe a écrit : No, you are not discouraging me in anyway. This stage is just the first step of a much wider task. The ultimate goal of this work is to provide the ability to package maven-based builds to Gentoo system. Gentoo encourages and the package-management installs packages by first compiling them from source. So, as you can understand, if the package source uses maven as the build management tool, it needs maven to do the building and generate the jar. Further, there are other constraints involved. Mainly the packages should be able to use the existing jars available in the system (under /usr/share), and we've are not strict about having a specific version as a dep as long the existing system jar is api-compatible. honestly, this is the part I really doubt about: it will be hard to do (will need to change the way Maven resolves dependencies), and I expect there will be a lot of failures since dependencies version modification in general causes failures. As a proof of concept, I find the task fun. As a user, I expect a lot of problems and wouldn't really be confident about this. To re-iterate, as a 'user' this will have a 'normal' behavior of Maven. It's the system part that will be different, and have the said constraints. And, maven is packaged with almost the same dependency versions of Maven. There were few exceptions in some Plexus packages, but the versions are close enough and api-compatible. Do you really think this leads to the said error? But if you want to try, why not :) Well, we have packaged ant and is in a good working condition. Now, unfortunately, maven-based projects don't have a simpler way to package their projects, to be installed via portage (the package mgt system). We are going to provide a direct way for this. --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg
Re: maven-core tests fail when invoked via ant.
On Mon, Jun 20, 2011 at 11:41 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I somehow think that if I was to do this integration I'd consider reversing the order; build maven3 from scratch and then use maven3 to build the older versions. Kristian, Thanks for the suggestion. But we've come this far, now only few packages left. So, I think it's better to go ahead with current implementation and then add maven3, isn't it? And, regarding the compiling **/cli/**java with 1.4, I actually don't see that when compiling via maven either. I'm probably wrong here, but I see that during the execution default everything compiles. When it comes to cli execution phase, what I see is [INFO] Nothing to compile - all classes are up to date. (Yes, I did a mvn clean first!) The debug log is at http://pastebin.com/EK01GFRf This is just what I noticed, and there's high chance that I didn't correctly understand the debug logs. :-) Thanks, --Kasun Kristian Den 20.06.2011 07:52, skrev Kasun Gajasinghe: Hi Brett, On Mon, Jun 20, 2011 at 5:41 AM, Brett Porterbr...@apache.org wrote: The problem you're seeing is probably related to an incorrect definition of a META-INF/plexus/components.xml file related to that SecDispatcher component. You're probably pulling in a file you didn't intend to. Hopefully you can grep through the test resources and find the culprit. Yes, thanks. maven-core uses plexus-sec-dispatcher version 1.3, which doesn't contain arole-hint in META-INF/plexus/components.**xml. So, I've updated the version to 1.4, and the test error I mentioned is gone. Well, now there's a test _failure_ (not error), in MavenCliTest, which I've identified as due to the wrong compilation version. i.e. according to maven-core pom, **/cli/*.java files should be compiled using JDK 1.4 while the rest of classes using 1.5. But apparently, the generated build.xml disregard this setting and compiles the whole bunch using 1.5. Is this a bug in the maven ant plugin or ant is incapable of handling this kind of thing? Is there a reason you can't use the build.xml we've already provided for those that need to bootstrap? Hopefully that would simplify things for you. Since we have to package the sub-modules separately, we can't use the provided build.xml. Building via mvn ant:ant too isn't a much of a problem. But these test failures is a concern. Thanks for the help! --Kasun - Brett On 19/06/2011, at 4:34 PM, Kasun Gajasinghe wrote: Hi, We are in the process of integrating Maven in to Gentoo. Currently, we are trying to bootstrap maven. Our strategy is to integrate each and every sub-project of Maven-2.2.1 [1] separately. So, we first transformed these to an ant projects by generating the build.xml via `mvn ant:ant`. I know that Maven provides a build.xml in the parent, but we have to integrate each and every project separately. We will be moving to 3.x after 2.x is complete. We chose 2.x as it's much stable, and is much popular currently. So far, we have successfully integrated project up-to maven-core in the build order. But, we are encountering an issue in maven-core. When invoked via mvn (mvn install), it passes the tests successfully (obviously!). But when I invoke the project via ant, a test fails with an ERROR. I'm sending this to the dev group thinking this error is probably obvious to you all. ==**=== test: [mkdir] Created dir: /gentoo-sources/maven/maven-2/**tags/maven-2.2.1/maven-core-2.** 2.1/target/test-reports [junit] Running org.apache.maven.**WagonSelectorTest [junit] Testsuite: org.apache.maven.**WagonSelectorTest [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 2.361 sec [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 2.361 sec [junit] [junit] Testcase: testSelectHttpWagonFromDefault took 0.358 sec [junit] Caused an ERROR [junit] Error starting container [junit] org.codehaus.plexus.**PlexusContainerException: Error starting container [junit] at org.codehaus.plexus.**DefaultPlexusContainer.start(** DefaultPlexusContainer.java:**795) [junit] at org.codehaus.plexus.**PlexusTestCase.setUp(**PlexusTestCase.java:121) [junit] at org.apache.maven.**WagonSelectorTest.setUp(**WagonSelectorTest.java:76) [junit] Caused by: org.codehaus.plexus.component.**repository.exception.** ComponentRepositoryException: Component descriptor role: 'org.sonatype.plexus.**components.sec.dispatcher.**SecDispatcher', implementation: 'org.sonatype.plexus.**components.sec.dispatcher.** DefaultSecDispatcher', role hint: 'maven' has a hint, but there are other implementations that don't [junit] at org.codehaus.plexus.component.**repository.** DefaultComponentRepository.**addComponentDescriptor(** DefaultComponentRepository.**java:184) [junit] at org.codehaus.plexus
maven-core tests fail when invoked via ant.
Hi, We are in the process of integrating Maven in to Gentoo. Currently, we are trying to bootstrap maven. Our strategy is to integrate each and every sub-project of Maven-2.2.1 [1] separately. So, we first transformed these to an ant projects by generating the build.xml via `mvn ant:ant`. I know that Maven provides a build.xml in the parent, but we have to integrate each and every project separately. We will be moving to 3.x after 2.x is complete. We chose 2.x as it's much stable, and is much popular currently. So far, we have successfully integrated project up-to maven-core in the build order. But, we are encountering an issue in maven-core. When invoked via mvn (mvn install), it passes the tests successfully (obviously!). But when I invoke the project via ant, a test fails with an ERROR. I'm sending this to the dev group thinking this error is probably obvious to you all. = test: [mkdir] Created dir: /gentoo-sources/maven/maven-2/tags/maven-2.2.1/maven-core-2.2.1/target/test-reports [junit] Running org.apache.maven.WagonSelectorTest [junit] Testsuite: org.apache.maven.WagonSelectorTest [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 2.361 sec [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 2.361 sec [junit] [junit] Testcase: testSelectHttpWagonFromDefault took 0.358 sec [junit] Caused an ERROR [junit] Error starting container [junit] org.codehaus.plexus.PlexusContainerException: Error starting container [junit] at org.codehaus.plexus.DefaultPlexusContainer.start(DefaultPlexusContainer.java:795) [junit] at org.codehaus.plexus.PlexusTestCase.setUp(PlexusTestCase.java:121) [junit] at org.apache.maven.WagonSelectorTest.setUp(WagonSelectorTest.java:76) [junit] Caused by: org.codehaus.plexus.component.repository.exception.ComponentRepositoryException: Component descriptor role: 'org.sonatype.plexus.components.sec.dispatcher.SecDispatcher', implementation: 'org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher', role hint: 'maven' has a hint, but there are other implementations that don't [junit] at org.codehaus.plexus.component.repository.DefaultComponentRepository.addComponentDescriptor(DefaultComponentRepository.java:184) [junit] at org.codehaus.plexus.DefaultPlexusContainer.addComponentDescriptor(DefaultPlexusContainer.java:515) [junit] at org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:738) [junit] at org.codehaus.plexus.DefaultPlexusContainer.start(DefaultPlexusContainer.java:779) [junit] BUILD FAILED /gentoo-sources/maven/maven-2/tags/maven-2.2.1/maven-core-2.2.1/maven-build.xml:206: Test org.apache.maven.WagonSelectorTest failed = Any clues on getting rid of this error? I'm thinking whether the generated build.xml has some issue. Much appreciate your help! The maven-build.xml is at [2]. The full ant output of the test failure is at [3]. I'm using maven-ant-plugin-2.3 with maven-2.2.1. The test fails with both ant 1.7.1 and 1.8.1. Please do let me know if any other information is needed. [1] https://svn.apache.org/repos/asf/maven/maven-2/tags/maven-2.2.1/maven-core/ [2] http://pastebin.com/9eWM0xjN [3] http://pastebin.com/vRC6qVa8 Thanks, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa Blog: http://kasunbg.blogspot.com Twitter: http://twitter.com/kasunbg
Re: maven-core tests fail when invoked via ant.
Hi Brett, On Mon, Jun 20, 2011 at 5:41 AM, Brett Porter br...@apache.org wrote: The problem you're seeing is probably related to an incorrect definition of a META-INF/plexus/components.xml file related to that SecDispatcher component. You're probably pulling in a file you didn't intend to. Hopefully you can grep through the test resources and find the culprit. Yes, thanks. maven-core uses plexus-sec-dispatcher version 1.3, which doesn't contain a role-hint in META-INF/plexus/components.xml. So, I've updated the version to 1.4, and the test error I mentioned is gone. Well, now there's a test _failure_ (not error), in MavenCliTest, which I've identified as due to the wrong compilation version. i.e. according to maven-core pom, **/cli/*.java files should be compiled using JDK 1.4 while the rest of classes using 1.5. But apparently, the generated build.xml disregard this setting and compiles the whole bunch using 1.5. Is this a bug in the maven ant plugin or ant is incapable of handling this kind of thing? Is there a reason you can't use the build.xml we've already provided for those that need to bootstrap? Hopefully that would simplify things for you. Since we have to package the sub-modules separately, we can't use the provided build.xml. Building via mvn ant:ant too isn't a much of a problem. But these test failures is a concern. Thanks for the help! --Kasun - Brett On 19/06/2011, at 4:34 PM, Kasun Gajasinghe wrote: Hi, We are in the process of integrating Maven in to Gentoo. Currently, we are trying to bootstrap maven. Our strategy is to integrate each and every sub-project of Maven-2.2.1 [1] separately. So, we first transformed these to an ant projects by generating the build.xml via `mvn ant:ant`. I know that Maven provides a build.xml in the parent, but we have to integrate each and every project separately. We will be moving to 3.x after 2.x is complete. We chose 2.x as it's much stable, and is much popular currently. So far, we have successfully integrated project up-to maven-core in the build order. But, we are encountering an issue in maven-core. When invoked via mvn (mvn install), it passes the tests successfully (obviously!). But when I invoke the project via ant, a test fails with an ERROR. I'm sending this to the dev group thinking this error is probably obvious to you all. = test: [mkdir] Created dir: /gentoo-sources/maven/maven-2/tags/maven-2.2.1/maven-core-2.2.1/target/test-reports [junit] Running org.apache.maven.WagonSelectorTest [junit] Testsuite: org.apache.maven.WagonSelectorTest [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 2.361 sec [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 2.361 sec [junit] [junit] Testcase: testSelectHttpWagonFromDefault took 0.358 sec [junit] Caused an ERROR [junit] Error starting container [junit] org.codehaus.plexus.PlexusContainerException: Error starting container [junit] at org.codehaus.plexus.DefaultPlexusContainer.start(DefaultPlexusContainer.java:795) [junit] at org.codehaus.plexus.PlexusTestCase.setUp(PlexusTestCase.java:121) [junit] at org.apache.maven.WagonSelectorTest.setUp(WagonSelectorTest.java:76) [junit] Caused by: org.codehaus.plexus.component.repository.exception.ComponentRepositoryException: Component descriptor role: 'org.sonatype.plexus.components.sec.dispatcher.SecDispatcher', implementation: 'org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher', role hint: 'maven' has a hint, but there are other implementations that don't [junit] at org.codehaus.plexus.component.repository.DefaultComponentRepository.addComponentDescriptor(DefaultComponentRepository.java:184) [junit] at org.codehaus.plexus.DefaultPlexusContainer.addComponentDescriptor(DefaultPlexusContainer.java:515) [junit] at org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:738) [junit] at org.codehaus.plexus.DefaultPlexusContainer.start(DefaultPlexusContainer.java:779) [junit] BUILD FAILED /gentoo-sources/maven/maven-2/tags/maven-2.2.1/maven-core-2.2.1/maven-build.xml:206: Test org.apache.maven.WagonSelectorTest failed = Any clues on getting rid of this error? I'm thinking whether the generated build.xml has some issue. Much appreciate your help! The maven-build.xml is at [2]. The full ant output of the test failure is at [3]. I'm using maven-ant-plugin-2.3 with maven-2.2.1. The test fails with both ant 1.7.1 and 1.8.1. Please do let me know if any other information is needed. [1] https://svn.apache.org/repos/asf/maven/maven-2/tags/maven-2.2.1/maven-core/ [2] http://pastebin.com/9eWM0xjN [3] http://pastebin.com/vRC6qVa8 Thanks, --Kasun
