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
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 Just for the record, with Maven 3, this has totally been removed from core - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException
I just read this mail after reploying to previous, saying that I didn't see how Doxia could be involved a nightmare, that's it: I don't understand how something about Doxia could fix something in Maven core But it's working: let's celebrate (I still think I wouldn't be confident when using this rebuilt Maven version...) Le dimanche 3 juillet 2011, Kasun Gajasinghe a écrit : 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
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
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) 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
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
Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException
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? 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? 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...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
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:
Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException
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 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/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,
Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException
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 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 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
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]
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 is the
Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException
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. But if you want to try, why not :) So, this is the step we take to have a custom maven build tailored to Gentoo system satisfying all the constraints. --Kasun - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException
I don't see anything obvious Le samedi 2 juillet 2011, Kasun Gajasinghe a écrit : 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-a nt -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
Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException
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
Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException
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. 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
Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException
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 ? 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. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
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
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 ? 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.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 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: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException
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. I remember going thru the same pains with Redhat/JPackage when they tried the same with. -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Sun, Jul 3, 2011 at 3:38 AM, Kasun Gajasinghe kasu...@gmail.com wrote: 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.
