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: coast clear, + status report on shade
On Sat, Jul 2, 2011 at 8:13 PM, Benson Margulies bimargul...@gmail.com wrote: The problem I reported with svn was local to my checkout; my checkin had succeeded. I've applied all the patches with tests, and even written tests for two without tests. I've invited two others to provide tests, and there's one interesting patch that poses a legal issue: the submitted just posted a github pull request, so since the JIRA is at codehaus, I have legal qualms. I've asked legal-discuss. In a week, with or without these, I propose to release. Thanks for the hard work :-) I plan to work on some more documentation patches today. I'll go through and comment on all the remaining open JIRAs sometime soonish. Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Another maven pom release
I still have a few changes that I'd want to do before the release I'll try to do them today Regards, Hervé Le dimanche 3 juillet 2011, Benson Margulies a écrit : I just realized rather inefficiently that the change to default to 1.5 is still pending for the maven-parent pom, along with a raft of others. Any objection to staging a release? - 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: compiler plugin config in plugins -- recent parent change seems ineffectual
yes, MPOM-13 :) Le dimanche 3 juillet 2011, Benson Margulies a écrit : Oh, Duh, I see. It's only in a profile in the plugin parent. oops. On Sat, Jul 2, 2011 at 8:04 PM, Benson Margulies bimargul...@gmail.com wrote: OK, well, I'm stumped. In maven-shade-plugin, I modified my local copy to point to maven-plugins version 20 as parent. This in turn points to maven parent 20. Which configures the compiler plugin for source level 1.5. Yet, help:effective-pom shows me source level 1.4, and adding in a generic gets an error. Now, I can add the compiler plugin to the shade pom, but I'd like to understand what I'm missing here. - 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: [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: svn commit: r1142363 - /maven/pom/trunk/maven/pom.xml
notice that since maven-project-info-reports 2.3, you can write a timezone as a fully formatted timezone, like Eurpoe/London, instead of an offset (which ignores daylight saving) [1] Regards, Hervé [1] http://jira.codehaus.org/browse/MPIR-171 Le dimanche 3 juillet 2011, bimargul...@apache.org a écrit : Author: bimargulies Date: Sun Jul 3 02:37:31 2011 New Revision: 1142363 URL: http://svn.apache.org/viewvc?rev=1142363view=rev Log: Add myself as a committer. Modified: maven/pom/trunk/maven/pom.xml Modified: maven/pom/trunk/maven/pom.xml URL: http://svn.apache.org/viewvc/maven/pom/trunk/maven/pom.xml?rev=1142363r1= 1142362r2=1142363view=diff == --- maven/pom/trunk/maven/pom.xml (original) +++ maven/pom/trunk/maven/pom.xml Sun Jul 3 02:37:31 2011 @@ -388,6 +388,14 @@ under the License. /roles timezone+1/timezone /developer +developer + nameBenson Margulies/name + emailbimargul...@apache.org/email + roles +roleCommitter/role + /roles + timezone-5/timezone +/developer !--End Committers-- developer idaramirez/id - 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: coast clear, + status report on shade
On Sun, Jul 3, 2011 at 8:38 AM, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: On Sat, Jul 2, 2011 at 8:13 PM, Benson Margulies bimargul...@gmail.com wrote: The problem I reported with svn was local to my checkout; my checkin had succeeded. I've applied all the patches with tests, and even written tests for two without tests. I've invited two others to provide tests, and there's one interesting patch that poses a legal issue: the submitted just posted a github pull request, so since the JIRA is at codehaus, I have legal qualms. I've asked legal-discuss. In a week, with or without these, I propose to release. Thanks for the hard work :-) I plan to work on some more documentation patches today. http://jira.codehaus.org/browse/MSHADE-102 I'll go through and comment on all the remaining open JIRAs sometime soonish. I'm working now on an integration test for http://jira.codehaus.org/browse/MSHADE-94 Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[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
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. 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
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
property question
Dear Sir/Madam,
Here is some part of our existing pom.xml.
build
...
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.0.2/version
configuration
source1.5/source
target1.5/target
/configuration
/plugin
/plugins
...
/build
However, we need to use 1.6 instead of 1.5 sometime. So we defined property
properties
java.source.home1.6/java.source.home
java.source.home1.6/java.source.home
/properties
in each parent and child pom.xml.
So our pom.xml file for same portion above will be
build
...
properties
java.source.home1.6/java.source.home
java.target.home1.6/java.target.home
/properties
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.0.2/version
configuration
source${java.source.home}/source
target${java.target.home}/target
/configuration
/plugin
/plugins
...
/build
*
My question is if we run a maven build : mvn clean install
-Djava.source.home=1.5 -Djava.target.home=1.5
Will all ${java.source.home} and ${java.target.home} in each parent and child
pom.xml be overrided with value 1.5? We have more than one level of
parents/child.
Thanks.
Walt
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
prepare goal doesn't apply the profile to submodules
I have the following setup: - root - module1 (defined under profile P) -- module11 (defined under profile P) -- module12 (defined under profile P) - module2 When I'm executing the prepare stage, it seems that for some reasons, the 2 modules (module11 and module12) are simply ignored. My guess is that the profile is only use to get the modules from the root to module1, but not from module1 to module11 and module12. Because the 2 modules do not get released, their version isn't changed so the dependencies further down the line fail at some point. Is there something I'm missing with this? Any help is appreciated. Thanks. Eugen.
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
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. 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.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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: coast clear, + status report on shade
On Sun, Jul 3, 2011 at 11:36 AM, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: I'm working now on an integration test for http://jira.codehaus.org/browse/MSHADE-94 Done Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
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
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? 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.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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
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:
[maven-shade-plugin] Factor Out ResourceMerger ...?
A number of feature requests [1][2] could be implemented in an elegant way by introducing an interface (ResourceMerger, say) similar to ResourceTransformer. I'm happy to dive in and provide integration and unit tests for this change, plus implementations for the requested features if the consensus is that it'd be a good change. Opinions? Improvements? Objections? Robert [1] http://jira.codehaus.org/browse/MSHADE-96 [2] http://jira.codehaus.org/browse/MSHADE-91 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1142412 - /maven/pom/trunk/maven/pom.xml
Hi Benson, Here are a few problems with actual config: - you should add your apache id - your entry should be sorted by id - [WARNING] The time zone 'America/Boston' for the developer 'Benson Margulies' is not a recognised time zone Notice: with actual pom documentation, you can check your entry with mvn -f site-pom.xml site Regards, Hervé Le dimanche 3 juillet 2011, bimargul...@apache.org a écrit : Author: bimargulies Date: Sun Jul 3 10:50:09 2011 New Revision: 1142412 URL: http://svn.apache.org/viewvc?rev=1142412view=rev Log: Fix time zone for me to include DST as per Herve's suggestion. Modified: maven/pom/trunk/maven/pom.xml Modified: maven/pom/trunk/maven/pom.xml URL: http://svn.apache.org/viewvc/maven/pom/trunk/maven/pom.xml?rev=1142412r1= 1142411r2=1142412view=diff == --- maven/pom/trunk/maven/pom.xml (original) +++ maven/pom/trunk/maven/pom.xml Sun Jul 3 10:50:09 2011 @@ -394,7 +394,7 @@ under the License. roles roleCommitter/role /roles - timezone-5/timezone + timezoneAmerica/Boston/timezone /developer !--End Committers-- developer - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Another maven pom release
I did quite a lot of modifications to every parent poms Maven Shared Components documentation is still missing, but it's too late for today I'll continue tomorrow, and we should be able to have a release in a few days. Regards, Hervé Le dimanche 3 juillet 2011, Hervé BOUTEMY a écrit : I still have a few changes that I'd want to do before the release I'll try to do them today Regards, Hervé Le dimanche 3 juillet 2011, Benson Margulies a écrit : I just realized rather inefficiently that the change to default to 1.5 is still pending for the maven-parent pom, along with a raft of others. Any objection to staging a release? - 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: [maven-shade-plugin] Factor Out ResourceMerger ...?
So, I'm a mostly a monkey here, but it seems very sensible to me. Perhaps Dan Kulp would chime in? On Sun, Jul 3, 2011 at 2:11 PM, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: A number of feature requests [1][2] could be implemented in an elegant way by introducing an interface (ResourceMerger, say) similar to ResourceTransformer. I'm happy to dive in and provide integration and unit tests for this change, plus implementations for the requested features if the consensus is that it'd be a good change. Opinions? Improvements? Objections? Robert [1] http://jira.codehaus.org/browse/MSHADE-96 [2] http://jira.codehaus.org/browse/MSHADE-91 - 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: [maven-shade-plugin] Factor Out ResourceMerger ...?
On Sunday, July 03, 2011 7:19:36 PM Benson Margulies wrote: So, I'm a mostly a monkey here, but it seems very sensible to me. Perhaps Dan Kulp would chime in? It sounds reasonable to me. I know I copied one of the transforms into CXF at one point to make some small modifications. If it could have been accomplished as a subclass of some sort, that may have been avoidable. Dan On Sun, Jul 3, 2011 at 2:11 PM, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: A number of feature requests [1][2] could be implemented in an elegant way by introducing an interface (ResourceMerger, say) similar to ResourceTransformer. I'm happy to dive in and provide integration and unit tests for this change, plus implementations for the requested features if the consensus is that it'd be a good change. Opinions? Improvements? Objections? Robert [1] http://jira.codehaus.org/browse/MSHADE-96 [2] http://jira.codehaus.org/browse/MSHADE-91 - 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 -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
