Re: No more uber jar
/me cheers Yep, go for it. This will also mean producing shaded versions of the wagons though I think, or creating a shaded "built-in wagons" JAR, to prevent some of their dependencies being forced on plugins. The ITs for MNG-3581/3599 might pick this up, but it would be worth an extra IT to verify. Cheers, Brett On 23/09/2008, at 3:00 AM, Jason van Zyl wrote: I made the uber jar and I think it was a mistake. It's a complete PITA to swap in new jars and test and the shading can work on the JARs necessary. I would like to remove the uber jar in 2.1 and do it on the 2.2 branch as well. Any objections? Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No more uber jar
Just means we use a shaded version of plexus instead of shading the entire Maven runtime. Wouldn't change anything. Plugins could still use their own version of p-u. On 22-Sep-08, at 7:12 PM, Benjamin Bentmann wrote: Jason van Zyl wrote: I would like to remove the uber jar in 2.1 and do it on the 2.2 branch as well. Any objections? How does this relate to MNG-2892? Are there other means that allow plugins to use different versions of the libs that are used by the core like plexus-utils? Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Three people can keep a secret provided two of them are dead. -- Unknown - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: m-eclipse-p: use ~/.m2/repository for cache files?
On Sat, Sep 20, 2008 at 1:17 AM, Eugene Kuleshov <[EMAIL PROTECTED]> wrote: > > > Out of curiosity, why are you prefer m-e-p plugin over IDE support? > > For example, m2eclipse [1] can import Maven projects without running > intermediate commands and it does cache if source artifacts are present or > not (among bunch of other things). > > regards, > Eugene > > [1] http://m2eclipse.codehaus.org/ Our codebase is about to move into maintenance and I don't want such a large change. So I figured patching m-e-p would be easier. I need to re-evaluate m2eclipse but not right now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven archetype plugin version 2.0-alpha-4
+1 (obviously) Raphaël 2008/9/22, Raphaël Piéroni <[EMAIL PROTECTED]>: > Hi, > > We solved 19 issues: > > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11095&styleName=Html&version=14253 > > Staging repo: > http://people.apache.org/~rafale/archetype-stage-repository/ > Beware of MNG-2974, a workaround is currently to use a repository manager. > > Staging site: > http://maven.apache.org/plugins/maven-archetype-plugin-2.0-alpha-4/ > Sync not made at writing time, meanwhile please use > http://people.apache.org/~rafale/site/maven-archetype-plugin/ > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > Regards, > > > Raphaël Piéroni >
[VOTE] Release Maven archetype plugin version 2.0-alpha-4
Hi, We solved 19 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11095&styleName=Html&version=14253 Staging repo: http://people.apache.org/~rafale/archetype-stage-repository/ Beware of MNG-2974, a workaround is currently to use a repository manager. Staging site: http://maven.apache.org/plugins/maven-archetype-plugin-2.0-alpha-4/ Sync not made at writing time, meanwhile please use http://people.apache.org/~rafale/site/maven-archetype-plugin/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Regards, Raphaël Piéroni
Re: No more uber jar
Sounds good to me, as long as we test to make sure it doesn't affect plugins using things like a different version of plexus-utils. -j --- John Casey Developer and PMC Member, Apache Maven (http://maven.apache.org) Member, Apache Software Foundation Blog: http://www.ejlife.net/blogs/buildchimp Jason van Zyl wrote: I made the uber jar and I think it was a mistake. It's a complete PITA to swap in new jars and test and the shading can work on the JARs necessary. I would like to remove the uber jar in 2.1 and do it on the 2.2 branch as well. Any objections? Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No more uber jar
Please imagine the sound of an intermediate level of APPLAUSE for this suggestion. Jason van Zyl <[EMAIL PROTECTED] m> To Maven Developers List 09/22/2008 10:00 AM cc Subject Please respond to No more uber jar "Maven Developers List" <[EMAIL PROTECTED] org> I made the uber jar and I think it was a mistake. It's a complete PITA to swap in new jars and test and the shading can work on the JARs necessary. I would like to remove the uber jar in 2.1 and do it on the 2.2 branch as well. Any objections? Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] American Express made the following annotations on Mon Sep 22 2008 11:48:04 -- "This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you." American Express a ajouté le commentaire suivant le Mon Sep 22 2008 11:48:04 Ce courrier et toute pièce jointe qu'il contient sont réservés au seul destinataire indiqué et peuvent renfermer des renseignements confidentiels et privilégiés. Si vous n'êtes pas le destinataire prévu, toute divulgation, duplication, utilisation ou distribution du courrier ou de toute pièce jointe est interdite. Si vous avez reçu cette communication par erreur, veuillez nous en aviser par courrier et détruire immédiatement le courrier et les pièces jointes. Merci. ** --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: No more uber jar
Hey, so how's the vacation going? Will Mark still be contacting us after Oct 1? Gil -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, September 22, 2008 10:01 AM To: Maven Developers List Subject: No more uber jar I made the uber jar and I think it was a mistake. It's a complete PITA to swap in new jars and test and the shading can work on the JARs necessary. I would like to remove the uber jar in 2.1 and do it on the 2.2 branch as well. Any objections? Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No more uber jar
Jason van Zyl wrote: I would like to remove the uber jar in 2.1 and do it on the 2.2 branch as well. Any objections? How does this relate to MNG-2892? Are there other means that allow plugins to use different versions of the libs that are used by the core like plexus-utils? Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
No more uber jar
I made the uber jar and I think it was a mistake. It's a complete PITA to swap in new jars and test and the shading can work on the JARs necessary. I would like to remove the uber jar in 2.1 and do it on the 2.2 branch as well. Any objections? Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shortening paths for core ITs
+1 All of this sounds great to me. Thanks for taking this on. Benjamin Bentmann wrote: Brett Porter wrote: I would prefer core-it-suite to core-its, but it's a small thing. So we would have core-it-suite and core-it-support, looks nice IMHO and is still reasonably short (which is all I am interested in). So unless somebody objects, let's go for that ;-) I additionally think the src/main/resources/* paths could be reduced to just the issue number (mng-1234), without the description of the problem (the description can be retained in Java test class). +1 from me. However, since this changes a naming scheme that was previously established by some reasoning I assume, I would like to get some more feedback on this particular change before I take actions in this direction. Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shortening paths for core ITs
On 22-Sep-08, at 2:14 PM, Benjamin Bentmann wrote: Brett Porter wrote: I would prefer core-it-suite to core-its, but it's a small thing. So we would have core-it-suite and core-it-support, looks nice IMHO and is still reasonably short (which is all I am interested in). So unless somebody objects, let's go for that ;-) I additionally think the src/main/resources/* paths could be reduced to just the issue number (mng-1234), without the description of the problem (the description can be retained in Java test class). +1 from me. However, since this changes a naming scheme that was previously established by some reasoning I assume, I would like to get some more feedback on this particular change before I take actions in this direction. I think much of the naming was haphazard in that a bunch of people start adding/changing things without talking to other people. So while you're taking a full pass through the system, you're doing the work and you have a flare for consistency (a complement) so if no one responds to your queries then do as you see fit. Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Three people can keep a secret provided two of them are dead. -- Unknown - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shortening paths for core ITs
Brett Porter wrote: I would prefer core-it-suite to core-its, but it's a small thing. So we would have core-it-suite and core-it-support, looks nice IMHO and is still reasonably short (which is all I am interested in). So unless somebody objects, let's go for that ;-) I additionally think the src/main/resources/* paths could be reduced to just the issue number (mng-1234), without the description of the problem (the description can be retained in Java test class). +1 from me. However, since this changes a naming scheme that was previously established by some reasoning I assume, I would like to get some more feedback on this particular change before I take actions in this direction. Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shortening paths for core ITs
Arnaud HERITIER wrote: Just a remark : sometime you replace integration-tests by "its" otherwise by "it". Perhaps we could unify them . Yes, you're right. The distinction between singular/plural is rather irrelevant here so I agree, let's have it all "it" for consistency. Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
