Re: Releases, Continuous Delivery and the Future
On Dec 14, 2014, at 8:29 PM, Jason van Zyl ja...@takari.io wrote: What we want is a form of continuous delivery where a version like 3.2.4 is the version that we call it to the outside world (some refer to it as the marketing version) and the qualifier changes from build to build so we have: 3.2.4-qualifier And for simplicity's sake let's just say the qualifier is a build number so we end up with: 3.2.4-01 3.2.4-02 ... 3.2.4-NN +1 This really the only viable scheme I've seen used over the years. It's how we do it at Sonatype and it's never been an issue that the public version is shown with some -build number. We will want to ensure that only one release version gets published though to reduce confusion. Since everything is staged, this should happen normally. For plugins, which are commonly referred to by users in their poms, this might turn out to be a problem as it increases the maintenance load but I think we start trying it and if there is an issue we go to an alternate approach. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Central and Man-in-the-middle
http://blog.sonatype.com/2014/07/ssl_connectivity_for_central/ --Brian (mobile) On Jul 28, 2014, at 11:06 PM, Brian Fox bri...@infinity.nu wrote: We are already in the process of making this open for free to everyone. Way back in 2012 the CDN situation was different but we just renewed the contract and and ssl is part of it. Once this is setup, we should consider changing the superpom to use ssl by default. Obviously doing something to validate pgp signatures is even better. On Mon, Jul 28, 2014 at 10:14 PM, Mark Derricutt m...@talios.com wrote: Hey all, Just been reading [1] after it was mentioned in both #scala and #clojure on irc.freenode.org now, is there anything that can be done to alleviate some of these issues? oss.sonatype.org now requires everything to be GPG signed before being uploaded to central, but I'm not sure about any of the other means of getting artifacts uploaded. Are there any plugins out there to verify GPG signings of dependencies? Something to discuss on the dev-hangout maybe? [1] https://news.ycombinator.com/item?id=8099713 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] ASF Parent pom 13 and Maven parent pom 23
+1 --Brian (mobile) On Jan 17, 2013, at 3:17 PM, Olivier Lamy ol...@apache.org wrote: Hi, I'd like to release both ASF Parent pom 13 and Maven parent pom 23 ASF Parent pom 13: * staging repository: https://repository.apache.org/content/repositories/orgapacheapache-142/ * diff with previous release: http://svn.apache.org/viewvc/maven/pom/tags/apache-13/pom.xml?r1=HEADr2=1404788diff_format=h Maven Parent pom 23: * staging repository: https://repository.apache.org/content/repositories/maven-143/ * diff with previous release: http://svn.apache.org/viewvc/maven/pom/tags/maven-parent-23/pom.xml?r1=HEADr2=1371599diff_format=h Vote open for 72H [+1] [0] [-1] Thanks -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - 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 Central is probably blocked in China
Hi Nicolas, this isn't intentional of course. Let me see what I can dig up based in your traces. --Brian (mobile) On Jul 7, 2012, at 11:45 PM, Niclas Hedhman nic...@hedhman.org wrote: (I am not subscribed, so please CC me on any responses) I live in China. I normally have a VPN enabled to circumvent various blocking (YouTube, Twitter, ++) that the Chinese government has in place. I normally don't think much about it. But, today I had my computer rebooted and couldn't build a project, because Maven Central couldn't be reached. So, before I realized that my VPN wasn't running I tracerouted a bit. repo1 resolved to niclas:~ niclas$ dig repo1.maven.org | grep ^[a-z] repo1.maven.org.1751INCNAMEcentral.maven.org. central.maven.org.212INCNAMEcentral02.maven.org. central02.maven.org.7112INCNAMEwpc.829D.edgecastcdn.net. wpc.829D.edgecastcdn.net. 3164INCNAMEgs1.wpc.edgecastcdn.net. gs1.wpc.edgecastcdn.net. 2292INA68.232.45.253 and from that I also tried central01 niclas:~ niclas$ dig central01.maven.org | grep ^[a-z] central01.maven.org.6477INCNAME central01.maven.org.edgesuite.net. central01.maven.org.edgesuite.net. 20877 IN CNAME a978.g1.akamai.net. a978.g1.akamai.net.4INA124.40.42.31 a978.g1.akamai.net.4INA124.40.42.6 And with tracerouting both (see below), it struck me that VPN might not be enabled and the IP on edgecastcdn.net is probably blocked by China potentially serving something they don't like, could be anything... Yeah, China is BAD, we all know that, but shouldn't we (Apache) try to minimize the problem for your ordinary Chinese developer, could be a student, hobbyist, small entrepreneur and so on, who isn't anti-government (most people here are quite content with the government) to be able to use Apache projects? The fact is now, that without reasonably reliable access to Maven Central, one can not really participate in many, many of the Java projects at ASF. I don't know how the DNS and host resolution is supposed to work, who is participating in the hosting and under what terms. But I think Maven/Sonatype should have in its interest to NOT EXCLUDE some staggering amount of Java programmers, and perhaps try to find a way to get a better SLA here. If you need help from someone to check from the inside the Great Firewall, just let me know... Cheers Niclas traceroute to gs1.wpc.edgecastcdn.net (68.232.45.253), 64 hops max, 52 byte packets 1 192.168.2.1 (192.168.2.1) 1.446 ms 0.980 ms 0.900 ms 2 58.246.152.1 (58.246.152.1) 9.855 ms 11.724 ms 8.662 ms 3 210.22.67.29 (210.22.67.29) 9.563 ms 3.698 ms 1.712 ms 4 112.64.251.165 (112.64.251.165) 1.696 ms 1.819 ms 3.215 ms 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * niclas:qi4j-sdk niclas$ traceroute central01.maven.org traceroute: Warning: central01.maven.org has multiple addresses; using 209.107.203.19 traceroute to a978.g1.akamai.net (209.107.203.19), 64 hops max, 52 byte packets 1 192.168.2.1 (192.168.2.1) 1.681 ms 0.910 ms 0.889 ms 2 58.246.152.1 (58.246.152.1) 14.958 ms 14.339 ms 115.382 ms 3 112.64.251.133 (112.64.251.133) 3.516 ms 2.892 ms 1.682 ms 4 112.64.251.165 (112.64.251.165) 2.117 ms 1.934 ms 1.926 ms 5 112.64.243.170 (112.64.243.170) 3.859 ms 8.432 ms 4.110 ms 6 * * * 7 219.158.9.209 (219.158.9.209) 4.284 ms 3.517 ms 6.284 ms 8 219.158.100.194 (219.158.100.194) 32.392 ms 34.428 ms 32.079 ms 9 219.158.96.230 (219.158.96.230) 33.214 ms 33.501 ms 33.470 ms 10 219.158.96.222 (219.158.96.222) 31.660 ms 31.564 ms 33.370 ms 11 sl-st30-sj-0-4-3-3.sprintlink.net (144.228.111.29) 214.116 ms 466.648 ms 503.740 ms 12 sl-st31-sj-0-12-0-3.sprintlink.net (144.232.3.33) 180.679 ms sl-st31-sj-0-8-0-0.sprintlink.net (144.232.3.29) 214.923 ms 231.186 ms 13 144.232.8.194 (144.232.8.194) 522.103 ms 381.628 ms 221.618 ms 14 te0-0-0-3.ccr22.sjc01.atlas.cogentco.com (154.54.6.109) 219.036 ms te0-3-0-3.ccr22.sjc01.atlas.cogentco.com (154.54.6.101) 184.460 ms te0-1-0-0.ccr21.sjc03.atlas.cogentco.com (66.28.4.53) 305.247 ms 15 te0-3-0-2.ccr22.lax01.atlas.cogentco.com (154.54.2.149) 614.732 ms te0-1-0-0.ccr21.sjc01.atlas.cogentco.com (154.54.83.253) 216.883 ms te0-1-0-3.ccr21.sjc01.atlas.cogentco.com (154.54.6.237) 450.823 ms 16 te9-3.ccr02.lax05.atlas.cogentco.com (154.54.82.154) 662.795 ms 154.54.85.25 (154.54.85.25) 189.819 ms te7-8.ccr02.lax05.atlas.cogentco.com (154.54.30.198) 888.842 ms 17 te4-1.mpd01.lax05.atlas.cogentco.com (154.54.28.69) 693.184 ms te9-6.mpd01.lax05.atlas.cogentco.com (154.54.82.150) 190.542 ms * 18 38.104.84.130 (38.104.84.130) 781.037 ms 38.104.84.126 (38.104.84.126) 425.045 ms 38.104.84.130 (38.104.84.130)
Re: Cleanup to SNAPSHOT version handling
-1 to a, +1 to b --Brian (mobile) On Dec 28, 2010, at 1:20 PM, Jason van Zyl ja...@maven.org wrote: On Dec 28, 2010, at 10:02 AM, Benjamin Bentmann wrote: Brett Porter wrote: I think the original reason the logic is how it is was because just SNAPSHOT (with no leading version) was valid, but that behaviour has long been (unofficially) deprecated. Given this style of versioning is apparently in use and I personally see nothing wrong with having just SNAPSHOT to refer to the HEAD of some project I suggest we go with the following for Maven 3.0.2: a) Treat SNAPSHOT, *-SNAPSHOT and the respective expanded/timestamped forms as snapshot versions, anything else as release b) Emit a model warning if the project version ends with SNAPSHOT but does not match the patterns mentioned in a) +1 I think anything that moves us closer toward the OSGi versioning would be better. I also think being more explicit with the version would be better and accounts for the case where you have multiple branches and you need to identify the tip of each. I don't think we should allow just SNAPSHOT anymore as it provides no version context which I think is important. We often see the following: x-SNAPSHOT x.y-SNAPSHOT x.y.z-SNAPSHOT Which at least provide some version context, but ultimately I think we should try to move toward: http://www.osgi.org/javadoc/r4v42/org/osgi/framework/Version.html So I would opt for b) and emit a warning if not in the *-SNAPSHOT form and officially deprecate SNAPSHOT and think about moving toward x.y.z.qualifier as a standard. I don't think multiple version schemes are truly helpful. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Moving scm to java 1.5
+1 since we moved that way for 2.2 and 3, I think we can safely move all of our cosebases to 1.6 as needed --Brian (mobile) On Dec 28, 2010, at 3:15 PM, Olivier Lamy ol...@apache.org wrote: Hi, As we will start a new year, I'd like to move scm to java 1.5. Let me know if you have any trouble regarding this . (jira entry http://jira.codehaus.org/browse/SCM-591) Thanks, -- Olivier Lamy http://twitter.com/olamy http://www.linkedin.com/in/olamy - 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: How do I get the MavenProject objects of already built modules?
Do you need @aggregator to make sure the reactorProjects is properly populated?
--Brian (mobile)
On Dec 20, 2010, at 12:18 PM, Benjamin Bentmann benjamin.bentm...@udo.edu
wrote:
Bernd Vogt wrote:
when implementing a Mojo (Maven 3), how do I get the MavenProject
objects of the modules that were already built by the current reactor
build?
Sounds either like
/** @parameter default-value=${reactorProjects} */
CollectionMavenProject projects;
or http://jira.codehaus.org/browse/MNG-4943.
Benjamin
-
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 Archetpyes structure
Don't go back to a lower version in the parent unless you change one if the other coords like the artifactid. This causes sorting issues when the metadata needs to be rebuilt. --Brian (mobile) On May 6, 2010, at 4:29 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: ok i'll do the svn update and open a Xircles chord to create ARCHETYPES project Regards, Hervé Le samedi 01 mai 2010, Hervé BOUTEMY a écrit : After releasing an alpha of Archetype components and some archetypes, it becomes clear to me that the actual structure is not ideal. I think that maven-archertype-bundles with all its modules (ie concrete archetypes) should be a separate component, with its own trunk and Jira project, and released as a unique Maven Archetype Bundles version containing every archetypes. Then I'd like to: - move /maven/archetype/trunk/maven-archetype-bundles to /maven/archetypes/trunk - change to an overall 1.2-SNAPSHOT version (yes, actual parent pom is at version 4, but I don't think that it is a problem since it is not used directly) - create MARCHETYPES Jira project, with one component per archetype (will need help on this one, since I don't know how to do that) WDYT? Any objection? Regards, Hervé - 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: [VOTE] Release Maven Compiler Plugin 2.3
+1 --Brian (mobile) On Apr 10, 2010, at 4:40 AM, Jason van Zyl ja...@sonatype.com wrote: Hi, This was simply to bump the default source/target to 1.5. I don't want 3.0-beta-1 released requiring people to set these as they should be defaults now. Staging repo: https://repository.apache.org/content/repositories/maven-011 All we fixed was this: http://jira.codehaus.org/browse/MCOMPILER-80 Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 +1 from me. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release MavenCheckstyle plugin version 2.5
+1 --Brian (mobile) On Feb 8, 2010, at 8:06 AM, Olivier Lamy ol...@apache.org wrote: Hi, I'd like to release maven-checkstyle-plugin version 2.5. It's a small release to make it working with maven 3. We solved 1 issue: http://jira.codehaus.org/browse/MCHECKSTYLE-123 Staging repo: https://repository.apache.org/content/repositories/maven-002/ Staging site: http://maven.apache.org/plugins/maven-checkstyle-plugin-2.5 Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, -- Olivier http://twitter.com/olamy http://fr.linkedin.com/in/olamy - 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: Pushing Maven 2.0.11
All joking aside, 2.0.9 and 2.0.10 have proven to be very stable. We need to keep the same bar for 2.0.11 especially if we intend this to be the end of 2.0.x. That means we need lots of participation during the rc process. --Brian (mobile) On Nov 20, 2009, at 4:23 PM, Brett Porter br...@apache.org wrote: Yes, it's been tagged a while too. I was planning to start the RC process today. On 21/11/2009, at 8:04 AM, Michael wrote: Hi folks, all issues for Maven 2.0.11 have been closed since August [1]. Why hasn't this relese been pushed so far? Thanks, Mike [1] http://jira.codehaus.org/secure/IssueNavigator.jspa?sorter/field=updatedsorter/order=DESC - 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: Update on ASF Release requirements
My plan is to implement the packaging in the maven pom and then later promote it to the apache pom once any kinks are worked out. --Brian (mobile) On May 8, 2009, at 8:17 PM, David Jencks david_jen...@yahoo.com wrote: Could I ask what's going to happen after you get the assembly plugin improved? Will there be an apache 7 pom or, how else would we get this new functionality? thanks david jencks On May 7, 2009, at 8:13 PM, Brian E. Fox wrote: I just need to finish the ITs. --Brian (mobile) On May 7, 2009, at 10:45 PM, Stephane Nicoll stephane.nic...@gmail.com wrote: On Tue, May 5, 2009 at 3:21 AM, Brett Porter br...@apache.org wrote: On 05/05/2009, at 11:01 AM, Brian Fox wrote: To make this happen relatively quickly, I'll take finish my patch by adding tests, and then stage a release of the assembly plugin 2.2-beta-3.1 by applying only this patch to the existing beta-3 tag so we can cut a release without a bunch of hand wrangling over what needs to be fixed in beta-4. Any concerns or objections to the above plan? Only the version. Release it as beta 4 using the approach above (or any since committed fixes) and tell anyone that complains to go jump :) +1 I was about to stage ear plugin 2.3.2 so I suppose I need to wait a bit. Brian, what is the status of this one? Thanks, Stéphane Cheers, Brett --- -- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - 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: Update on ASF Release requirements
I just need to finish the ITs. --Brian (mobile) On May 7, 2009, at 10:45 PM, Stephane Nicoll stephane.nic...@gmail.com wrote: On Tue, May 5, 2009 at 3:21 AM, Brett Porter br...@apache.org wrote: On 05/05/2009, at 11:01 AM, Brian Fox wrote: To make this happen relatively quickly, I'll take finish my patch by adding tests, and then stage a release of the assembly plugin 2.2- beta-3.1 by applying only this patch to the existing beta-3 tag so we can cut a release without a bunch of hand wrangling over what needs to be fixed in beta-4. Any concerns or objections to the above plan? Only the version. Release it as beta 4 using the approach above (or any since committed fixes) and tell anyone that complains to go jump :) +1 I was about to stage ear plugin 2.3.2 so I suppose I need to wait a bit. Brian, what is the status of this one? Thanks, Stéphane Cheers, Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Archetype plugin version 2.0-alpha-5
-1 we need to produce source archives for all releases based on the recent discussions on some other lists. I'm experimenting with some ways to make this inherited but for now you can bind the assembly plugin with the src descriptor to produce the correct zip of the sources. --Brian (mobile) On May 3, 2009, at 11:44 AM, Raphaël Piéroni raf...@apache.org wrote: Hi, We solved 11 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14254styleName=HtmlprojectId=11095 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11095status=1 Staging repo: https://repository.apache.org/content/repositories/maven-staging-003/ Staging site (currently syncing): http://maven.apache.org/plugins/maven-archetype-plugin-2.0-alpha-5/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Apache snapshot repository metadata incorrect.
I will take a look shortly --Brian (mobile) On May 1, 2009, at 4:59 PM, Arnaud HERITIER aherit...@gmail.com wrote: I'm not administrator to verify but perhaps, the job to fix metadata isn't scheduled ? On Fri, May 1, 2009 at 6:09 PM, Nord, James jn...@nds.com wrote: Hi all, The metadata served by nexus for http://repository.apache.org/snapshots/ is incorrect for the archetype plugin. (https://repository.apache.org/content/groups/snapshots/org/apache/maven /plugins/maven-archetype-plugin/) metadata contains lots of snapshot versions but only 2.0-alpha-5-SNAPSHOT is available. (and hence running mvn archetype:generate from the command line fails as it tries to get 12-SNAPSHOT /James ?xml version=1.0 encoding=UTF-8 ? - https://repository.apache.org/content/groups/snapshots/org/apache/maven /plugins/maven-archetype-plugin/maven-metadata.xml# metadata xsi:schemaLocation=http://maven.apache.org/METADATA/1.0.0 http://maven.apache.org/xsd/metadata-1.0.0.xsd; xmlns=http://maven.apache.org/METADATA/1.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; groupIdorg.apache.maven.plugins/groupId artifactIdmaven-archetype-plugin/artifactId version2.0-alpha-4-SNAPSHOT/version - https://repository.apache.org/content/groups/snapshots/org/apache/maven /plugins/maven-archetype-plugin/maven-metadata.xml# versioning latest12-SNAPSHOT/latest release / - https://repository.apache.org/content/groups/snapshots/org/apache/maven /plugins/maven-archetype-plugin/maven-metadata.xml# versions version2.0-alpha-4-SNAPSHOT/version version2.0-alpha-5-SNAPSHOT/version version0.3.0-SNAPSHOT/version version1.0-SNAPSHOT/version version1.0-alpha-2-SNAPSHOT/version version1.0-alpha-3-SNAPSHOT/version version1.0-beta-3-SNAPSHOT/version version1.0.2-SNAPSHOT/version version1.1-SNAPSHOT/version version1.1.1-SNAPSHOT/version version1.2-SNAPSHOT/version version1.2.2-SNAPSHOT/version version1.3-SNAPSHOT/version version2.0-beta-9-SNAPSHOT/version version2.0-beta-10-SNAPSHOT/version version2.0.11-SNAPSHOT/version version2.1.0-SNAPSHOT/version version2.1-SNAPSHOT/version version2.1.0-M2-SNAPSHOT/version version2.2-SNAPSHOT/version version2.3-SNAPSHOT/version version2.4.4-SNAPSHOT/version version2.5-SNAPSHOT/version version3.0-alpha-2-SNAPSHOT/version version11-SNAPSHOT/version version12-SNAPSHOT/version /versions lastUpdated20090417213533/lastUpdated /versioning /metadata *** *** *** *** *** *** This e-mail is confidential, the property of NDS Ltd and intended for the addressee only. Any dissemination, copying or distribution of this message or any attachments by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please immediately notify the postmas...@nds.com and destroy the original message. Messages sent to and from NDS may be monitored. NDS cannot guarantee any message delivery method is secure or error-free. Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission. You should carry out your own virus checks before opening any attachment. Any views or opinions presented are solely those of the author and do not necessarily represent those of NDS. To protect the environment please do not print this e-mail unless necessary. NDS Limited Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales Registered no. 3080780 VAT no. GB 603 8808 40-00 *** *** *** *** *** *** -- Arnaud - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: [VOTE] Release mercury-1.0-alpha-6
+1 -Original Message- From: John Casey [mailto:jdca...@commonjava.org] Sent: Friday, April 10, 2009 3:59 PM To: Maven Developers List Subject: Re: [VOTE] Release mercury-1.0-alpha-6 +1 I didn't see this vote at first because for some reason my email client thought it was part of the alpha-5 vote thread. Sorry for taking so long to vote. -john Oleg Gusakov wrote: Hi, Iterative alpha release. Major fixes: - # of dependencies - less'n 64 were ordered correctly the rest used to be random ordering - bad/missing repository metadata is worked around in most cases Mercury-ant is now successfully used to bootstrap build Maven3 trunk. Working towards implementing Maven repository system. We solved 7 issues: http://jira.codehaus.org/browse/MERCURY/fixforversion/14964 Staging repo: https://repository.apache.org/content/repositories/maven-staging-002/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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: Is it now possible to affect reactor build ordering without using a normal module dependency?
No, it hasn't changed. This won't happen until 3.x when there is the ability for a plugin to introspect the build plan pre-execution. -Original Message- From: James Carpenter [mailto:nawk...@gmail.com] Sent: Friday, April 03, 2009 12:11 PM To: dev@maven.apache.org Subject: Is it now possible to affect reactor build ordering without using a normal module dependency? In the past plugins such as the dependency plugin didn't have a way to affect the reactor build order without having the user add a real dependency (say test scope) to the module using the plugin (or having the plugin programatically do the same) just to ensure proper build ordering. I assume this problem will eventually be solved in some manner (say a ghost dependency scope), but that it is likely a difficult one for some reason or other and therefore has not been solved long ago. If all the referenced artifacts are jars one can sometimes workaround the problem using plugin dependencies like I did when enhancing the exec:java plugin for non-java modules. http://mojo.codehaus.org/exec-maven-plugin/examples/example-exec-using-p lugin-dependencies.html I am about to write a plugin which automatically downloads a few archives specified by GAVs, and I'm wondering if the situation has improved. If not I will simply use have to work around the issue. Can anyone provide some color the current status of this issue? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: Is it now possible to affect reactor build ordering without using a normal module dependency?
It's because a plugin may have a defacto dependency based on something in its configuration. Maven won't know about this so if that dep is in the same reactor, it may not be ordered correctly. The dependency:copy is an example of this. There should be a way for a plugin to participate in the reactor ordering for cases like this. There's a proposal but I can't find it at this time. -Original Message- From: David Jencks [mailto:david_jen...@yahoo.com] Sent: Friday, April 03, 2009 12:34 PM To: Maven Developers List Subject: Re: Is it now possible to affect reactor build ordering without using a normal module dependency? Why do you want to affect the reactor build ordering without using a dependency? The only use for something like this I have thought of so this might be a feature request is that I would like to be able to assure that a large project with deeply nested structure can be built in stages. For instance if I have a project like this: base -sub1 --p1 --p2 -sub2 --p3 --p4 where base, sub1 and sub2 are pom packaging and p1...p4 have the code in them, I would like to be able to assure that all of sub1 gets built before any of sub2 to assist in preventing any dependencies of p1 or p2 on p3 or p4. AFAICT the current behavior is that maven puts p1...p4 in a single bucket and tries to find a build order that satisfies the dependencies. thanks david jencks On Apr 3, 2009, at 9:11 AM, James Carpenter wrote: In the past plugins such as the dependency plugin didn't have a way to affect the reactor build order without having the user add a real dependency (say test scope) to the module using the plugin (or having the plugin programatically do the same) just to ensure proper build ordering. I assume this problem will eventually be solved in some manner (say a ghost dependency scope), but that it is likely a difficult one for some reason or other and therefore has not been solved long ago. If all the referenced artifacts are jars one can sometimes workaround the problem using plugin dependencies like I did when enhancing the exec:java plugin for non-java modules. http://mojo.codehaus.org/exec-maven-plugin/examples/example-exec-using-p lugin-dependencies.html I am about to write a plugin which automatically downloads a few archives specified by GAVs, and I'm wondering if the situation has improved. If not I will simply use have to work around the issue. Can anyone provide some color the current status of this issue? - 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: Is it now possible to affect reactor build ordering without using a normal module dependency?
That's what I want in maven 3, but it's not there yet. -Original Message- From: David Jencks [mailto:david_jen...@yahoo.com] Sent: Friday, April 03, 2009 2:29 PM To: Maven Developers List Subject: Re: Is it now possible to affect reactor build ordering without using a normal module dependency? On Apr 3, 2009, at 10:14 AM, Brian E. Fox wrote: It's because a plugin may have a defacto dependency based on something in its configuration. Maven won't know about this so if that dep is in the same reactor, it may not be ordered correctly. The dependency:copy is an example of this. There should be a way for a plugin to participate in the reactor ordering for cases like this. There's a proposal but I can't find it at this time. Hmmm I guess when I read the dependency plugin docs and it said that it could download artifacts all by itself it didn't really register. I don't really understand any point of view other than these required artifacts are dependencies that happen to be declared only in the plugin configuration, not in the normal dependencies section of the pom. As such I'd expect that if you don't want to have to explicitly list them as dependencies then the plugin ought to get a chance to add dependencies during some kind of setup phase. I have a plugin for which this would be extremely handy. Is this what is planned for 3.0 or is there another point of view I have yet to comprehend? thanks david jencks -Original Message- From: David Jencks [mailto:david_jen...@yahoo.com] Sent: Friday, April 03, 2009 12:34 PM To: Maven Developers List Subject: Re: Is it now possible to affect reactor build ordering without using a normal module dependency? Why do you want to affect the reactor build ordering without using a dependency? The only use for something like this I have thought of so this might be a feature request is that I would like to be able to assure that a large project with deeply nested structure can be built in stages. For instance if I have a project like this: base -sub1 --p1 --p2 -sub2 --p3 --p4 where base, sub1 and sub2 are pom packaging and p1...p4 have the code in them, I would like to be able to assure that all of sub1 gets built before any of sub2 to assist in preventing any dependencies of p1 or p2 on p3 or p4. AFAICT the current behavior is that maven puts p1...p4 in a single bucket and tries to find a build order that satisfies the dependencies. thanks david jencks On Apr 3, 2009, at 9:11 AM, James Carpenter wrote: In the past plugins such as the dependency plugin didn't have a way to affect the reactor build order without having the user add a real dependency (say test scope) to the module using the plugin (or having the plugin programatically do the same) just to ensure proper build ordering. I assume this problem will eventually be solved in some manner (say a ghost dependency scope), but that it is likely a difficult one for some reason or other and therefore has not been solved long ago. If all the referenced artifacts are jars one can sometimes workaround the problem using plugin dependencies like I did when enhancing the exec:java plugin for non-java modules. http://mojo.codehaus.org/exec-maven-plugin/examples/example-exec-using-p lugin-dependencies.html I am about to write a plugin which automatically downloads a few archives specified by GAVs, and I'm wondering if the situation has improved. If not I will simply use have to work around the issue. Can anyone provide some color the current status of this issue? - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: [RESULT] [VOTE] Release Maven Release plugin version 2.0-beta-9 and scm 1.2
It's in the process of syncing to central now. -Original Message- From: oliver.l...@gmail.com [mailto:oliver.l...@gmail.com] On Behalf Of Olivier Lamy Sent: Saturday, March 28, 2009 3:42 AM To: Maven Developers List; scm-...@maven.apache.org Subject: Re: [RESULT] [VOTE] Release Maven Release plugin version 2.0-beta-9 and scm 1.2 Hi, I have use the nexus ui to promote artifacts. The release plugin is on central repo but not scm artifacts !! Can someone have a look ? Other issue : one day after site deploy on p.a.o sites are not yet sync (release plugin and scm site) Thanks! -- Olivier 2009/3/27 Olivier Lamy ol...@apache.org: Hi, The votes has passed with the following result : +1 (binding) : Arnaud HERITIER, Jason van Zyl,Emmanuel Venisse, Olivier Lamy +1 (non-binding) : Marc Struberg I will move artifacts to central repo and publish the site. Thanks, -- Olivier - 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: [ANN] Maven Release Plugin 2.0-beta-9 Released
All set. -Original Message- From: Niall Pemberton [mailto:niall.pember...@gmail.com] Sent: Saturday, March 28, 2009 5:52 PM To: Maven Developers List Subject: Re: [ANN] Maven Release Plugin 2.0-beta-9 Released The parent pom doesn't seem to have found its way to the public repo yet, is it on its way? http://repo1.maven.org/maven2/org/apache/maven/release/maven-release/ Niall On Sat, Mar 28, 2009 at 5:36 PM, Olivier Lamy ol...@apache.org wrote: Hi, The Maven team is pleased to announce the release of the Maven Release Plugin, version 2.0-beta-9. http://maven.apache.org/plugins/maven-release-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-release-plugin/artifactId version2.0-beta-9/version /plugin Release Notes - Maven 2.x Release Plugin - Version 2.0-beta-9 ** Bug * [MRELEASE-273] - Regression: NullPointerException at end of standalone release:perform * [MRELEASE-375] - release plugin does not work with subversion 1.5.0 * [MRELEASE-379] - return results after performing a release * [MRELEASE-381] - url syntax not good enough for the git scm provider * [MRELEASE-386] - Sneaky bug in DefaultReleaseManager.perform() * [MRELEASE-393] - NoSuchMethodError when using InvokerMavenExecutor with cmd line arg --quiet * [MRELEASE-405] - Wrong branch-name parameter ** Improvement * [MRELEASE-385] - Upgrade to last scm version (1.2) * [MRELEASE-392] - Align release-parent, release-manager and release-plugin versions * [MRELEASE-427] - Add a mojo parameter for using the new remote tagging for svn scm provider (to prevent issue with svn 1.5.0) * [MRELEASE-429] - Support for a [token]-SNAPSHOT in addition to [number]-SNAPSHOT ** Task * [MRELEASE-390] - Add VSS dependency Have Fun! -- The Maven Team - 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: [RESULT] [VOTE] Release Maven Release plugin version 2.0-beta-9 and scm 1.2
All set. This was the same problem we saw with the install plugin missing a file, the issue has been corrected now and shouldn't happen any more. -Original Message- From: oliver.l...@gmail.com [mailto:oliver.l...@gmail.com] On Behalf Of Olivier Lamy Sent: Saturday, March 28, 2009 6:00 PM To: Maven Developers List Subject: Re: [RESULT] [VOTE] Release Maven Release plugin version 2.0-beta-9 and scm 1.2 So it looks they are still issues with groupId org.apache.maven.release which is not sync. Can you fix that too ? The new release of release plugin is still not usuable. Thanks, -- Olivier 2009/3/28 Olivier Lamy ol...@apache.org: I can see the artifacts on central now. Thanks Brian ! -- Olivier 2009/3/28 Brian E. Fox bri...@reply.infinity.nu: It's in the process of syncing to central now. -Original Message- From: oliver.l...@gmail.com [mailto:oliver.l...@gmail.com] On Behalf Of Olivier Lamy Sent: Saturday, March 28, 2009 3:42 AM To: Maven Developers List; scm-...@maven.apache.org Subject: Re: [RESULT] [VOTE] Release Maven Release plugin version 2.0-beta-9 and scm 1.2 Hi, I have use the nexus ui to promote artifacts. The release plugin is on central repo but not scm artifacts !! Can someone have a look ? Other issue : one day after site deploy on p.a.o sites are not yet sync (release plugin and scm site) Thanks! -- Olivier 2009/3/27 Olivier Lamy ol...@apache.org: Hi, The votes has passed with the following result : +1 (binding) : Arnaud HERITIER, Jason van Zyl,Emmanuel Venisse, Olivier Lamy +1 (non-binding) : Marc Struberg I will move artifacts to central repo and publish the site. Thanks, -- Olivier - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: Re : Re : [VOTE] Release Maven eclipse plugin version 2.6
Ok I just wasn't sure because there was lots of talk about eclipse plugin fixes in parallel so I lost track. -Original Message- From: Barrie Treloar [mailto:baerr...@gmail.com] Sent: Friday, March 27, 2009 2:52 AM To: Maven Developers List Subject: Re: Re : Re : [VOTE] Release Maven eclipse plugin version 2.6 On Fri, Mar 27, 2009 at 4:48 PM, Arnaud HERITIER aherit...@gmail.com wrote: No, there's no reason to stop it.We'll publish a 1.6.1 in few days if necessary Except the current vote count :) +1 (binding): aherit...@gmail.com +1 (non binding): belling...@gmail.com nicolas.del...@gmail.com baerr...@gmail.com We need some more PMC votes please. - 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 Enterprise Edition from Overall.ca?
It looks like a hardware tracking / provisioning tool not a build system. Shrug. Not related to Apache Maven at all it appears to me. -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: Thursday, March 26, 2009 2:19 AM To: Maven Developers List Subject: Maven Enterprise Edition from Overall.ca? Just saw something odd in Gmail web clip/sponsored link while browsing emails to the list... Maven Enterprise Edition - www.overall.ca/maven - Build the ultimate toolbox for your Windows support tools From their site: Introducing Maven Enterprise Edition Your enterprise data is typically found in multiple sources. Maven Enterprise Edition enables your organization to build and deploy a complete Windows support dashboard, with all of the queries, support tools, scripts and enterprise information required to rapidly service your IT infrastructure. Your service desk can do what they do best; service your organization. Their About Us says they've been around since 2002. Click into the forums and the oldest post is 2008-12-02, so its hard to tell how old their Maven Enterprise Edition tool really is. Anyone know these guys? Obviously their Maven has no relationship whatsoever to this one. Pretty bad choice of names on their part, imo. Wayne - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: Re : Re : [VOTE] Release Maven eclipse plugin version 2.6
Has this vote been officially cancelled? -Original Message- From: Julien HENRY [mailto:henr...@yahoo.fr] Sent: Tuesday, March 24, 2009 11:27 AM To: Maven Developers List Subject: Re : Re : [VOTE] Release Maven eclipse plugin version 2.6 Done: http://jira.codehaus.org/browse/MECLIPSE-536 - Message d'origine De : Arnaud HERITIER aherit...@gmail.com À : Maven Developers List dev@maven.apache.org Envoyé le : Mardi, 24 Mars 2009, 10h23mn 10s Objet : Re: Re : [VOTE] Release Maven eclipse plugin version 2.6 yes please. 2009/3/24 Julien HENRY henr...@yahoo.fr I got the following error: mvn clean install eclipse:eclipse -Pstaged -cpu ... [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Internal error in the plugin manager executing goal 'org..apache.maven.plugins:maven-eclipse-plugin:2.6:eclipse': Unable to load the mojo 'org.apache.maven.plugins:maven-eclipse-plugin:2.6:eclipse' in the plugin 'org.apache.maven.plugins:maven-eclipse-plugin'. A required class is missing: org/codehaus/plexus/resource/loader/ResourceNotFoundException mvn -v Apache Maven 2.1.0-RC3 (r754932; 2009-03-16 17:31:06+0100) Java version: 1.4.2_17 Java home: C:\j2sdk1.4.2_17\jre Default locale: fr_FR, platform encoding: Cp1252 OS name: windows xp version: 5.1 arch: x86 Family: windows Do you want I open an issue in JIRA with full stack trace? Regards, Julien - Message d'origine De : Barrie Treloar baerr...@gmail.com À : Maven Developers List dev@maven.apache.org Envoyé le : Mardi, 24 Mars 2009, 1h05mn 40s Objet : [VOTE] Release Maven eclipse plugin version 2.6 Hi, We solved 35 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14163styleName=HtmlprojectId=11133 There remaining issues left in JIRA: http://jira.codehaus. .org/secure/IssueNavigator.jspa?reset=truepid=11133status=1 Staging repo: https://repository.apache.org/content/repositories/maven-staging-52acfb2f215fcf/ Staging site: http://maven.apache.org/plugins/maven-eclipse-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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 -- Arnaud - 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: Recording build environment
It seems like if there were some properties available, or known to the resources plugin, then you could filter these values in anywhere you wanted them. -Original Message- From: Paul Gier [mailto:pg...@redhat.com] Sent: Wednesday, March 25, 2009 11:54 AM To: Maven Developers List Subject: Recording build environment I'd like to be able to record the build environment (maven version, java, OS, etc) for each build that is run in a standard way. I originally created a jira issue in the release plugin (MRELEASE-352) to record information just for releases. But now I'm thinking that this could be useful for any build. I'd just like to get a few other opinions about this before working on it. Is there any existing plugin that might be a good fit for this type of functionality? Or should it be a new plugin? Or would this type of thing be better handled by something like Hudson? Thanks! - 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
potential 2.1.0 regression?
I tried a build with -N (non recursive) and I get an error with 2.1.0: [INFO] Parent project loaded from repository. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error when populating modules Embedded error: Unable to read local module-POM Unable to download the artifact from any repository Anyone else seen this? -- Brian Fox Apache Maven PMC http://blogs.sonatype.com/brian/
RE: Recording build environment
Not a property, but there's a component - RuntimeInformation iirc that has it. Take a look at the enforcer:display-info goal code, it shows all of it for you. -Original Message- From: Paul Gier [mailto:pg...@redhat.com] Sent: Wednesday, March 25, 2009 3:21 PM To: Maven Developers List Subject: Re: Recording build environment That's true, I can get the OS and Java version from standard properties, and then put them in the Manifest or somewhere else. Is there a property that contains the current running version of maven? Brian E. Fox wrote: It seems like if there were some properties available, or known to the resources plugin, then you could filter these values in anywhere you wanted them. -Original Message- From: Paul Gier [mailto:pg...@redhat.com] Sent: Wednesday, March 25, 2009 11:54 AM To: Maven Developers List Subject: Recording build environment I'd like to be able to record the build environment (maven version, java, OS, etc) for each build that is run in a standard way. I originally created a jira issue in the release plugin (MRELEASE-352) to record information just for releases. But now I'm thinking that this could be useful for any build. I'd just like to get a few other opinions about this before working on it. Is there any existing plugin that might be a good fit for this type of functionality? Or should it be a new plugin? Or would this type of thing be better handled by something like Hudson? Thanks! - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: potential 2.1.0 regression?
It happened on the enforcer plugin parent. I was testing the upgraded repo so I changed the tlp to a release test version, then did mvn deploy -N. I tried again later and got the same behavior with 2.0.10 so it's not a regression in 2.1 but I've yet to check 2.0.9 -Original Message- From: John Casey [mailto:jdca...@commonjava.org] Sent: Wednesday, March 25, 2009 3:21 PM To: Maven Developers List Subject: Re: potential 2.1.0 regression? File it, and if you have a test project setup that we can use to duplicate it, we'll take a look. That's the best I can tell you...the console output you included really isn't much to go on. Sorry, -john Brian E. Fox wrote: I tried a build with -N (non recursive) and I get an error with 2.1.0: [INFO] Parent project loaded from repository. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error when populating modules Embedded error: Unable to read local module-POM Unable to download the artifact from any repository Anyone else seen this? -- Brian Fox Apache Maven PMC http://blogs.sonatype.com/brian/ - 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: Release for maven-archetype-plugin
don't forget to use the new snapshot repository http://repository.zones.apache.org/content/groups/snapshots/ The correct url is http://repository.apache.org/snapshots/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: deprecating MavenSession.lookup( role|class ) and prefer injection in plugins
The enforcer uses this to hand components over to the rules via a get Component method (it implements the expressionevaluator interface). I would probably need to convert all the rules over to actual plexus components to use injection. -Original Message- From: Jason van Zyl [mailto:jvan...@sonatype.com] Sent: Monday, March 23, 2009 7:51 PM To: Maven Developers List Subject: deprecating MavenSession.lookup( role|class ) and prefer injection in plugins Hi, I would like to remove the MavenSession.lookup( class|role ) methods in Maven 3.x so I would like to start deprecating them and prefer injecting anything required using a javadoc annotation (current plugin api) and an annotation (the new plugin api). General access to the container is not required more with the new annotation-based Plexus containers and it's really a bad practice not to have injected all the things you need. Plexus used in Maven 3.x injects collections properly and as new components enter the system they find their way into the correct collections. So, for example, if a new lifecycle mapping is discovered in the system it will just automatically show up it the MapString,Lifecycle inside the LifecycleExecutor. This was the primary reason why we exposed the container and it's not required anymore. So if we deprecate starting now, folks will know long before Maven 3.x comes out. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition - 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: [vote] Maven 2.1.0
+1 I tested briefly against 2.0.x build with various values of parallel downloads and everything seems ok. -Original Message- From: Arnaud HERITIER [mailto:aherit...@gmail.com] Sent: Friday, March 20, 2009 2:07 PM To: Maven Developers List Subject: Re: [vote] Maven 2.1.0 +1 Arnaud On Fri, Mar 20, 2009 at 9:55 PM, Vincent Siveton vsive...@apache.orgwrote: +1 Vincent 2009/3/18 John Casey jdca...@commonjava.org: Hi everyone, It looks like Maven 2.1.0 is ready to release. You can try the binaries here: http://tinyurl.com/maven-2-1-0-vote ( https://repository.apache.org/content/repositories/maven-staging-511ea88 2714d8b/org/apache/maven/apache-maven/2.1.0/ ) We've resolved 85 issues for this release (enumerated at the end of this message): http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleNa me=Htmlversion=14587 Vote's open for 72 hours. Please cast your vote: [ ] +1 [ ] +0 [ ] -1 Here's my +1. Thanks, -john === Release Notes - Maven 2 - Version 2.1.0 ** Sub-task * [MNG-4025] - Prominently document opt-out setting for parallel artifact resolution for users * [MNG-4042] - Use plexus-sec-dispatcher 1.0 in Maven core when it is released ** Bug * [MNG-1349] - openssl checksums are not accepted by maven * [MNG-1585] - debug logging from wagon not shown in debug mode * [MNG-1992] - CLI -D should override properties in settings.xml * [MNG-1999] - Reporting inheritance does not work properly * [MNG-2432] - Apache and Mojo plugins take precendence over plugins in the pom. * [MNG-2433] - Maven looks for snapshots in offline mode * [MNG-2605] - Profiles in profiles.xml are active by default * [MNG-2668] - Plugin dependencies should be considered when the reactor creates the build order list * [MNG-2690] - DefaultPluginManager.getConfiguredMojo() doesn't handle NoClassDefFoundError correctly * [MNG-2695] - -o makes build fail for snapshot plugins * [MNG-2720] - Multiproject dependencies not accurate for project.compileClasspathElements when run from root project * [MNG-3023] - Reactor projects should be included in dependency resolution * [MNG-3057] - properties not expanded in generated POMs when building A/B/C nested projects * [MNG-3139] - The skin does not exist: Unable to determine the release version * [MNG-3217] - a plugin's dependencies can influence other plugins in a build * [MNG-3228] - Maven profile activation does not work when profile is defined in inherited 'parent' pom * [MNG-3271] - excludeDefaults does not seem to work * [MNG-3284] - Cached plugins are used, even when the specifically declared * [MNG-3314] - offline build not running, when having SNAPSHOT dependencies * [MNG-3621] - site url inheritance broken for UNC paths * [MNG-3628] - When running offline, snapshot artifcats cannot be resolved even if they have previously be dowloaded from a repository * [MNG-3641] - Lack of error checks on profiles * [MNG-3645] - Maven doesn't do strict model validation for POMs in the current reactor * [MNG-3719] - [regression] plugin execution ordering no longer POM ordered in 2.0.9 * [MNG-3757] - Setting M2_HOME to nothing and running ant delets contents of the current folder * [MNG-3769] - [regression] Excluding relocated transitive dependencies does not work * [MNG-3776] - Namespace misspelled in settings.xml * [MNG-3808] - Execution order of report plugins is arbitrary if inheritance is involved * [MNG-3810] - [regression] Null Pointer Exception when Activation Profile Property is Empty * [MNG-3811] - Report plugins don't inherit configuration * [MNG-3899] - Inheritance does not merge extensions with same gid and aid * [MNG-3906] - Project-level plugin dependencies are in random order after merging * [MNG-3920] - Problem using velocity component * [MNG-3930] - mvn.bat doesn't handle ampersand in Windows user name properly * [MNG-3933] - Profiles.xml does not pickup OS family * [MNG-3940] - Interpolation of environment variables is not case-insensitive on Windows * [MNG-3948] - Remote repos defined by profiles outside of settings.xml are not used to resolve parent POMs * [MNG-3974] - New mirror syntax is not stopping on first match * [MNG-4016] - Properties with the prefix project/pom are not interpolated from the properties section * [MNG-4023] - Profiles from parent POM are injected multiple times if parent is part of reactor build * [MNG-4026] - [regression] Order of project class path does not match POM order during reactor build * [MNG-4032] - Test jar dependency not available for for main classes in multi module builds * [MNG-4043] - Resolve or rollback WebDAV wagon deployment issue where hostname is
RE: Current status of moving apache projects to apache's nexus instance?
David, the process to migrate the process is covered here: https://issues.apache.org/jira/browse/INFRA-1896 The usage docs for the Maven release process covers everything else once you are setup: http://maven.apache.org/developers/release/releasing.html -Original Message- From: David Jencks [mailto:david_jen...@yahoo.com] Sent: Tuesday, March 17, 2009 3:48 PM To: Maven Developers List Cc: Portals Discussion Subject: Current status of moving apache projects to apache's nexus instance? I'm trying to help the apache portals project set up some root poms. They are currently using the apache pom version 5 which IIUC deploys releases and snapshots to the apache nexus instance. I googled but couldn't find any instructions on how to proceed with this. I think it would be pretty handy if the maven site had a page linked from the front page with some up to date instructions. For instance IIUC when portals releases these poms (to nexus, right?) all the existing portals stuff also has to be moved by hand to nexus and all future portals releases have to go to nexus. Or did I make this up? Something else I'd find pretty helpful is info on what the recommended release profile for apache projects is and whether you even need one or if some default is adequate. In case anyone wants to review the portals poms to advise on whether they are likely to work... https://svn.apache.org/repos/asf/portals/portals-pom/trunk/pom.xml https://svn.apache.org/repos/asf/portals/applications/applications-pom/t runk/pom.xml thanks david jencks - 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: Current status of moving apache projects to apache's nexus instance?
I'll write some docs to cover this for Apache globally, but iirc there weren't docs before for p.a.o, so the current docs have to be better than what was there previously. Each project presumably has their own release docs similar to what we have for Maven that I've pointed projects to as they migrate. I'll make some docs but its not immediately clear where I should put them for apache wide resources. -Original Message- From: David Jencks [mailto:david_jen...@yahoo.com] Sent: Wednesday, March 18, 2009 11:42 AM To: Maven Developers List Cc: Portals Discussion Subject: Re: Current status of moving apache projects to apache's nexus instance? jdcasey helped a bit on IRC, thanks. I think the documentation on this is really unsatisfactory. At least I can't find anything by googling. John pointed be to the maven release instructions http://maven.apache.org/developers/release/releasing.html which might be OK for maven components but are a bit lacking as a guide to best practices for apache projects. I've opened a jira with a few suggestions for improvements to this page http://jira.codehaus.org/browse/MNG-4095 Having the apache nexus instance there is great but I'm afraid you'll get extremely bad press if the apache 5 pom is out there and there is no trivially accessible documentation about what the consequences are of using it. For instance portals recently decided having a root pom might be a good idea and naturally chose the most recent apache pom as the parent with no awareness of the consequences about where their deployments will end up and whether or not any other steps need to be taken for other portals project release destinations. thanks david jencks On Mar 17, 2009, at 3:48 PM, David Jencks wrote: I'm trying to help the apache portals project set up some root poms. They are currently using the apache pom version 5 which IIUC deploys releases and snapshots to the apache nexus instance. I googled but couldn't find any instructions on how to proceed with this. I think it would be pretty handy if the maven site had a page linked from the front page with some up to date instructions. For instance IIUC when portals releases these poms (to nexus, right?) all the existing portals stuff also has to be moved by hand to nexus and all future portals releases have to go to nexus. Or did I make this up? Something else I'd find pretty helpful is info on what the recommended release profile for apache projects is and whether you even need one or if some default is adequate. In case anyone wants to review the portals poms to advise on whether they are likely to work... https://svn.apache.org/repos/asf/portals/portals-pom/trunk/pom.xml https://svn.apache.org/repos/asf/portals/applications/applications-pom/t runk/pom.xml thanks david jencks - 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 release...in progress
The issue is resolved so you can go ahead and release. -Original Message- From: John Casey [mailto:jdca...@commonjava.org] Sent: Wednesday, March 18, 2009 12:36 PM To: Maven Developers List Subject: Maven release...in progress Hi, I just wanted to let everyone know that I'm currently in the process of staging the 2.1.0 artifacts so I can call the vote to release. However, I'm stuck with a problem out on repository.apache.org, and I'm sorry to say I don't have the expertise with Nexus to know how to fix it. I've already emailed Brian to get his help, but I think he may be on the road today. I wanted to let everyone know this so you don't think we're stuck in limbo with this release process. Everything is looking good for the release, and as soon as I can jump this technical hurdle we'll be back on track! Thanks, -john - 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: svn commit: r753302 - in /maven/plugins/trunk/maven-compiler-plugin/src: it/alt-src-output-directories-MCOMPILER-91/ it/alt-src-output-directories-MCOMPILER-91/src/ it/alt-src-output-directories-M
Why doesn't the buildhelper plugin work for this use case? That lets you attach many source folders. -Original Message- From: Paul Gier [mailto:pg...@redhat.com] Sent: Friday, March 13, 2009 2:58 PM To: Maven Developers List Subject: Re: svn commit: r753302 - in /maven/plugins/trunk/maven-compiler-plugin/src: it/alt-src-output-directories-MCOMPILER-91/ it/alt-src-output-directories-MCOMPILER-91/src/ it/alt-src-output-directories-MCOMPILER-91/src/my-classes/ it/alt-src-output-directori Do you have an issue with it in both the compile and test-compile mojos? Or is the test-compile mojo ok? The test-compile mojo is where I need it because I have multiple sets of test classes that require different compile parameters. Jason van Zyl wrote: -1 I don't want people to start abusing this and directly using multiple source directories. This will get abused so fast and is only required by people who have messed up systems. On 13-Mar-09, at 8:37 AM, pg...@apache.org wrote: Author: pgier Date: Fri Mar 13 15:37:13 2009 New Revision: 753302 URL: http://svn.apache.org/viewvc?rev=753302view=rev Log: [MCOMPILER-91] Allow source and output directories to be configured. Patch from Peter Janes (peterj). Added: maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/ maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/pom.xml (with props) maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/src/ maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/src/my-classes/ maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/src/my-classes/java/ maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/src/my-classes/java/MyTest.java (with props) maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/verify.bsh (with props) Modified: maven/plugins/trunk/maven-compiler-plugin/src/main/java/org/apache/maven /plugin/CompilerMojo.java maven/plugins/trunk/maven-compiler-plugin/src/main/java/org/apache/maven /plugin/TestCompilerMojo.java Added: maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/pom.xml URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-compiler-plugin/s rc/it/alt-src-output-directories-MCOMPILER-91/pom.xml?rev=753302view=au to == --- maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/pom.xml (added) +++ maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/pom.xml Fri Mar 13 15:37:13 2009 @@ -0,0 +1,82 @@ +?xml version=1.0 encoding=UTF-8? +!-- + ~ Licensed to the Apache Software Foundation (ASF) under one + ~ or more contributor license agreements. See the NOTICE file + ~ distributed with this work for additional information + ~ regarding copyright ownership. The ASF licenses this file + ~ to you under the Apache License, Version 2.0 (the + ~ License); you may not use this file except in compliance + ~ with the License. You may obtain a copy of the License at + ~ + ~ http://www.apache.org/licenses/LICENSE-2.0 + ~ + ~ Unless required by applicable law or agreed to in writing, + ~ software distributed under the License is distributed on an + ~ AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + ~ KIND, either express or implied. See the License for the + ~ specific language governing permissions and limitations + ~ under the License. + -- + +project xmlns=http://maven.apache.org/POM/4.0.0; + xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; + xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; + modelVersion4.0.0/modelVersion + + groupIdorg.apache.maven.plugins.compiler/groupId + artifactIdaltconfig/artifactId + version1.0-SNAPSHOT/version + + nameTest for alternative source/target configuration/name + + properties + project.build.sourceEncodingUTF-8/project.build.sourceEncoding + /properties + + dependencies +dependency + groupIdjunit/groupId + artifactIdjunit/artifactId + version3.8.2/version +/dependency + /dependencies + + build +plugins + plugin +groupIdorg.apache.maven.plugins/groupId +artifactIdmaven-compiler-plugin/artifactId +version@pom.version@/version +executions + execution +idmy-classes/id +phasecompile/phase +goals + goalcompile/goal +/goals +configuration + compileSourceRoots +
RE: install:install-file Repository MetaData files maven-metadata-local.xml
In order for maven to look in the right place for the shorthand lookup, you need to add a pluginGroup in your settings. By default, maven only uses org.apache.maven.plugins and org.codehaus.mojo. -Original Message- From: Kaveh Goudarzi [mailto:ka...@itkaa.com] Sent: Friday, March 13, 2009 11:22 AM To: dev@maven.apache.org Subject: install:install-file Repository MetaData files maven-metadata-local.xml Hi All, I've implemented a maven plugin which when installed via the mvn install command as part of the build is installed correctly in the local repository. By adding the plugin group reference to the ~/.m2/settings.xml I'm able to then invoke the plugin using it's short hand prefix or without specifying the version. So far so good. However I find that when I send the users the jar file alone and ask them to install the plugin using the following command mvn install:install-file -Dfile=maven-mytest-plugin-1.1.jar \ -DgroupId=com.my.package \ -DartifactId=maven-mytest-plugin \ -Dpackaging=maven-plugin \ -Dversion=1.1 \ -DupdateReleaseInfo=true \ -DcreateChecksum=true \ -DgeneratePom=true The users always have to supply the full plugin group:artifact-id:version:goal and are not able to use the short-hand or the default latest version of the plugin. Comparing the maven repository files I see that when I install the plugin on my dev machine using the mvn install command two crucial files are created which are absent when the mvn install:install-file command is invoked. These are: ~/.m2/repositories/com/my/package/maven-metadata-local.xml -- ?xml version=1.0 encoding=UTF-8?metadata plugins plugin namemaven-mytest-plugin Maven Mojo/name prefixmytest/prefix artifactIdmaven-mytest-plugin/artifactId /plugin /plugins /metadata and another one at ~/.m2/repositories/com/my/package/maven-mytest-plugin/maven-metadata-loc al.xml -- ?xml version=1.0 encoding=UTF-8?metadata groupIdcom.my.package/groupId artifactIdmaven-mytest-plugin/artifactId version1.1/version versioning latest1.1/latest versions version1.1/version /versions lastUpdated20090312204457/lastUpdated /versioning /metadata These two files appear to be crucial in allowing me to invoke the plugin using the long-hand but not specifying the version and for it to default to the latest version and also to allow the short hand prefix invocation. So my questions is what is the correct way of installing such a plugin? ... am I missing some crucial step? I found this link but couldn't understand if it applies http://docs.codehaus.org/display/MAVEN/Repository+Metadata I'm using 2.0.9 writing plugins in java mvn -version Maven version: 2.0.9 Java version: 1.5.0_16 OS name: mac os x version: 10.5.6 arch: i386 Family: unix thanks in advance for you help + kind regards, Kaveh. - 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-site-plugin pre 2.0 not in maven-metadata.xml
Yes, we are fixing it now. -Original Message- From: oliver.l...@gmail.com [mailto:oliver.l...@gmail.com] On Behalf Of Olivier Lamy Sent: Friday, March 13, 2009 5:26 AM To: Maven Developers List Subject: Fwd: maven-site-plugin pre 2.0 not in maven-metadata.xml Hi, First sorry for cross posting. But it looks the deployement through staging via nexus override/delete metadata. I have checked and there is the same issue with the ear plugin (recently deployed with the new process). Is-it possible to fix that ? (and restoring correct metadata ? ) Thanks, -- Olivier -- Forwarded message -- From: Jean-Marc Lugrin f...@lugrin.ch Date: 2009/3/13 Subject: maven-site-plugin pre 2.0 not in maven-metadata.xml To: us...@maven.apache.org us...@maven.apache.org We are still using maven 2.0.4 and we depend on maven-site-plugin pre 2.0 (some of the beta). The repository location repo1 /maven2/org/apache/maven/plugins/maven-site-plugin/ contains the beta versions, but the file maven-metadata.xml only references the version 2.0. Should it not reference the other versions as well ? After a download via the maven proxy, the file maven-metada from repo1 was loaded locally and the previous versions (that we have locally) are not found anymore ny maven. Jean-Marc - 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: svn commit: r753302 - in /maven/plugins/trunk/maven-compiler-plugin/src: it/alt-src-output-directories-MCOMPILER-91/ it/alt-src-output-directories-MCOMPILER-91/src/ it/alt-src-output-directories-M
Can you do it with multiple compiler executions? I'm thinking something like add all the src folders, and then exclude them in one execution and vice-versa in the other. -Original Message- From: Paul Gier [mailto:pg...@redhat.com] Sent: Friday, March 13, 2009 4:15 PM To: Maven Developers List Subject: Re: svn commit: r753302 - in /maven/plugins/trunk/maven-compiler-plugin/src: it/alt-src-output-directories-MCOMPILER-91/ it/alt-src-output-directories-MCOMPILER-91/src/ it/alt-src-output-directories-MCOMPILER-91/src/my-classes/ it/alt-src-output-directori The build helper plugin allows me to add more source directories, but doesn't allow me to have different compiler configurations for the different directories. And also doesn't allow me to specify separate output directories. I have some situations where it is useful to have two separate test sources that are compiled differently and then output to different locations. For the main sources it's not as much of an issue. Brian E. Fox wrote: Why doesn't the buildhelper plugin work for this use case? That lets you attach many source folders. -Original Message- From: Paul Gier [mailto:pg...@redhat.com] Sent: Friday, March 13, 2009 2:58 PM To: Maven Developers List Subject: Re: svn commit: r753302 - in /maven/plugins/trunk/maven-compiler-plugin/src: it/alt-src-output-directories-MCOMPILER-91/ it/alt-src-output-directories-MCOMPILER-91/src/ it/alt-src-output-directories-MCOMPILER-91/src/my-classes/ it/alt-src-output-directori Do you have an issue with it in both the compile and test-compile mojos? Or is the test-compile mojo ok? The test-compile mojo is where I need it because I have multiple sets of test classes that require different compile parameters. Jason van Zyl wrote: -1 I don't want people to start abusing this and directly using multiple source directories. This will get abused so fast and is only required by people who have messed up systems. On 13-Mar-09, at 8:37 AM, pg...@apache.org wrote: Author: pgier Date: Fri Mar 13 15:37:13 2009 New Revision: 753302 URL: http://svn.apache.org/viewvc?rev=753302view=rev Log: [MCOMPILER-91] Allow source and output directories to be configured. Patch from Peter Janes (peterj). Added: maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/ maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/pom.xml (with props) maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/src/ maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/src/my-classes/ maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/src/my-classes/java/ maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/src/my-classes/java/MyTest.java (with props) maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/verify.bsh (with props) Modified: maven/plugins/trunk/maven-compiler-plugin/src/main/java/org/apache/maven /plugin/CompilerMojo.java maven/plugins/trunk/maven-compiler-plugin/src/main/java/org/apache/maven /plugin/TestCompilerMojo.java Added: maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/pom.xml URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-compiler-plugin/s rc/it/alt-src-output-directories-MCOMPILER-91/pom.xml?rev=753302view=au to == --- maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/pom.xml (added) +++ maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/pom.xml Fri Mar 13 15:37:13 2009 @@ -0,0 +1,82 @@ +?xml version=1.0 encoding=UTF-8? +!-- + ~ Licensed to the Apache Software Foundation (ASF) under one + ~ or more contributor license agreements. See the NOTICE file + ~ distributed with this work for additional information + ~ regarding copyright ownership. The ASF licenses this file + ~ to you under the Apache License, Version 2.0 (the + ~ License); you may not use this file except in compliance + ~ with the License. You may obtain a copy of the License at + ~ + ~ http://www.apache.org/licenses/LICENSE-2.0 + ~ + ~ Unless required by applicable law or agreed to in writing, + ~ software distributed under the License is distributed on an + ~ AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + ~ KIND, either express or implied. See the License for the + ~ specific language governing permissions and limitations + ~ under the License. + -- + +project xmlns=http://maven.apache.org/POM/4.0.0; + xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
RE: install:install-file Repository MetaData files maven-metadata-local.xml
Ah, I see. The install-file doesn't understand what should be done for plugins, which is why it's there for you but not someone else. Why not publish this plugin to a repo that your users can access? It will make your life easier. -Original Message- From: Kaveh Goudarzi [mailto:ka...@itkaa.com] Sent: Friday, March 13, 2009 4:18 PM To: Maven Developers List Subject: Re: install:install-file Repository MetaData files maven-metadata-local.xml Hi Brian, In both cases the pluginGroup is added to my settings.xml e.g ~/.m2/settings.xml -- settings pluginGroups pluginGroupcom.my.pacakge/pluginGroup /pluginGroups /settings -- However it only appears to work if the two maven-metadata-local.xml files exist otherwise the short-hand or non-specific-version invocations fail. Any thoughts? thanks in advance. Kaveh. Brian E. Fox wrote: In order for maven to look in the right place for the shorthand lookup, you need to add a pluginGroup in your settings. By default, maven only uses org.apache.maven.plugins and org.codehaus.mojo. -Original Message- From: Kaveh Goudarzi [mailto:ka...@itkaa.com] Sent: Friday, March 13, 2009 11:22 AM To: dev@maven.apache.org Subject: install:install-file Repository MetaData files maven-metadata-local.xml Hi All, I've implemented a maven plugin which when installed via the mvn install command as part of the build is installed correctly in the local repository. By adding the plugin group reference to the ~/.m2/settings.xml I'm able to then invoke the plugin using it's short hand prefix or without specifying the version. So far so good. However I find that when I send the users the jar file alone and ask them to install the plugin using the following command mvn install:install-file -Dfile=maven-mytest-plugin-1.1.jar \ -DgroupId=com.my.package \ -DartifactId=maven-mytest-plugin \ -Dpackaging=maven-plugin \ -Dversion=1.1 \ -DupdateReleaseInfo=true \ -DcreateChecksum=true \ -DgeneratePom=true The users always have to supply the full plugin group:artifact-id:version:goal and are not able to use the short-hand or the default latest version of the plugin. Comparing the maven repository files I see that when I install the plugin on my dev machine using the mvn install command two crucial files are created which are absent when the mvn install:install-file command is invoked. These are: ~/.m2/repositories/com/my/package/maven-metadata-local.xml -- ?xml version=1.0 encoding=UTF-8?metadata plugins plugin namemaven-mytest-plugin Maven Mojo/name prefixmytest/prefix artifactIdmaven-mytest-plugin/artifactId /plugin /plugins /metadata and another one at ~/.m2/repositories/com/my/package/maven-mytest-plugin/maven-metadata-loc al.xml -- ?xml version=1.0 encoding=UTF-8?metadata groupIdcom.my.package/groupId artifactIdmaven-mytest-plugin/artifactId version1.1/version versioning latest1.1/latest versions version1.1/version /versions lastUpdated20090312204457/lastUpdated /versioning /metadata These two files appear to be crucial in allowing me to invoke the plugin using the long-hand but not specifying the version and for it to default to the latest version and also to allow the short hand prefix invocation. So my questions is what is the correct way of installing such a plugin? ... am I missing some crucial step? I found this link but couldn't understand if it applies http://docs.codehaus.org/display/MAVEN/Repository+Metadata I'm using 2.0.9 writing plugins in java mvn -version Maven version: 2.0.9 Java version: 1.5.0_16 OS name: mac os x version: 10.5.6 arch: i386 Family: unix thanks in advance for you help + kind regards, Kaveh. - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: svn commit: r753302 - in /maven/plugins/trunk/maven-compiler-plugin/src: it/alt-src-output-directories-MCOMPILER-91/ it/alt-src-output-directories-MCOMPILER-91/src/ it/alt-src-output-directories-M
Yes it is odd, but I share jason's concern that sending the source folders directly to the compiler plugin is bad because then tools that look at the pom won't find the sources. (which btw is the case even with the buildhelper) -Original Message- From: Paul Gier [mailto:pg...@redhat.com] Sent: Friday, March 13, 2009 4:51 PM To: Maven Developers List Subject: Re: svn commit: r753302 - in /maven/plugins/trunk/maven-compiler-plugin/src: it/alt-src-output-directories-MCOMPILER-91/ it/alt-src-output-directories-MCOMPILER-91/src/ it/alt-src-output-directories-MCOMPILER-91/src/my-classes/ it/alt-src-output-directori Yeah, it probably could be done like that. But it seems a little strange way to accomplish it. Also that would put all the output into a single directory, and I would prefer to keep the classes separate in the output. Brian E. Fox wrote: Can you do it with multiple compiler executions? I'm thinking something like add all the src folders, and then exclude them in one execution and vice-versa in the other. -Original Message- From: Paul Gier [mailto:pg...@redhat.com] Sent: Friday, March 13, 2009 4:15 PM To: Maven Developers List Subject: Re: svn commit: r753302 - in /maven/plugins/trunk/maven-compiler-plugin/src: it/alt-src-output-directories-MCOMPILER-91/ it/alt-src-output-directories-MCOMPILER-91/src/ it/alt-src-output-directories-MCOMPILER-91/src/my-classes/ it/alt-src-output-directori The build helper plugin allows me to add more source directories, but doesn't allow me to have different compiler configurations for the different directories. And also doesn't allow me to specify separate output directories. I have some situations where it is useful to have two separate test sources that are compiled differently and then output to different locations. For the main sources it's not as much of an issue. Brian E. Fox wrote: Why doesn't the buildhelper plugin work for this use case? That lets you attach many source folders. -Original Message- From: Paul Gier [mailto:pg...@redhat.com] Sent: Friday, March 13, 2009 2:58 PM To: Maven Developers List Subject: Re: svn commit: r753302 - in /maven/plugins/trunk/maven-compiler-plugin/src: it/alt-src-output-directories-MCOMPILER-91/ it/alt-src-output-directories-MCOMPILER-91/src/ it/alt-src-output-directories-MCOMPILER-91/src/my-classes/ it/alt-src-output-directori Do you have an issue with it in both the compile and test-compile mojos? Or is the test-compile mojo ok? The test-compile mojo is where I need it because I have multiple sets of test classes that require different compile parameters. Jason van Zyl wrote: -1 I don't want people to start abusing this and directly using multiple source directories. This will get abused so fast and is only required by people who have messed up systems. On 13-Mar-09, at 8:37 AM, pg...@apache.org wrote: Author: pgier Date: Fri Mar 13 15:37:13 2009 New Revision: 753302 URL: http://svn.apache.org/viewvc?rev=753302view=rev Log: [MCOMPILER-91] Allow source and output directories to be configured. Patch from Peter Janes (peterj). Added: maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/ maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/pom.xml (with props) maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/src/ maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/src/my-classes/ maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/src/my-classes/java/ maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/src/my-classes/java/MyTest.java (with props) maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/verify.bsh (with props) Modified: maven/plugins/trunk/maven-compiler-plugin/src/main/java/org/apache/maven /plugin/CompilerMojo.java maven/plugins/trunk/maven-compiler-plugin/src/main/java/org/apache/maven /plugin/TestCompilerMojo.java Added: maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/pom.xml URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-compiler-plugin/s rc/it/alt-src-output-directories-MCOMPILER-91/pom.xml?rev=753302view=au to == --- maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/pom.xml (added) +++ maven/plugins/trunk/maven-compiler-plugin/src/it/alt-src-output-director ies-MCOMPILER-91/pom.xml Fri Mar 13 15:37:13 2009 @@ -0,0 +1,82 @@ +?xml version=1.0 encoding=UTF-8? +!-- + ~ Licensed to the Apache Software Foundation (ASF) under one + ~ or more
RE: [Maven Deploy Plugin] Add consistency check when specifying POM file and mojo parameters
You could use the Nexus UI to upload it directly, or if you need to automate you could use the REST api. -Original Message- From: Olivier Billard [mailto:olivier.bill...@gmail.com] Sent: Thursday, March 12, 2009 7:57 AM To: dev@maven.apache.org Subject: [Maven Deploy Plugin] Add consistency check when specifying POM file and mojo parameters Hi all, I would like to propose an enhancement to the maven deploy plugin, specifically the deploy-file mojo, and to propose a contribution. Please tell me if this could be interesting for the community. Among other tasks, my team manages the corporate repository manager (Nexus), and the deployment policy of internal/third party artifacts on this repo. We have the use case where we would like to specify both POM file AND artifactId/groupId/version to the maven-deploy-plugin, and we need to ensure that this information is consistent. Currently, no check is done by the mojo, but we would like to add optional consistency checking : to verify that there is a perfect match between POM file and corresponding mojo parameters. Would the community be interested with such a contribution to the plugin ? Did someone met this need, and solved this in another way ? Thank you for answers, -- Olivier Billard -- View this message in context: http://www.nabble.com/-Maven-Deploy-Plugin--Add-consistency-check-when-s pecifying-POM-file-and-mojo-parameters-tp22477729p22477729.html Sent from the Maven Developers mailing list archive at Nabble.com. - 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: Is this the place for archetype questions?
If it's about developing archetypes, otherwise the user list will have quicker responses. -Original Message- From: Derek Chen-Becker [mailto:j...@chen-becker.org] Sent: Thursday, March 12, 2009 4:38 PM To: dev@maven.apache.org Subject: Is this the place for archetype questions? I have a few questions about archetypes but I wasn't sure if this is the best place to ask them or if there's a better list. Apologies in advance if this is the wrong place. Derek - 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 Meetup @ Sonatype on March 19th 20th
As an addendum to the meetup, we're also going to conduct a keysigning party. For more information about a key signing party, take a look at these excellent documents for how the ApacheCon party runs: http://wiki.apache.org/apachecon/PgpKeySigning Note, that this requires a tiny bit of preparation, and that is simply to send me your public key ahead of time. This way we can print out the list for all attendees. You can export your key like this: gpg --armor --export KEY_ID mykey.asc and then send that file to me via email (bri...@infinity.nu or bri...@sonatype.com) -Original Message- From: Jason van Zyl [mailto:jvan...@sonatype.com] Sent: Wednesday, March 11, 2009 10:03 PM To: Maven Users List Subject: Maven Meetup @ Sonatype on March 19th 20th Hi, For those interested in knowing what Sonatype is working on in the Maven community, we're having a Maven Meetup the week before EclipseCon in Mountain View. It's a full day of presentations on Maven and related technologies like m2eclipse, Nexus, Tycho, Hudson, NMaven, NAR, FlexMojos and more. That will be followed up by a full day hackathon. You can see the full description here: http://www.sonatype.com/people/2009/03/sonatype-maven-meetup-on-march-19 th-20th/ And you can signup to attend here: https://docs.sonatype.org/display/COMM/Maven+Meetup+on+March+19th+and+20 th+at+Sonatype We are syncing up with the Hippo folks who are putting on the Maven Meetup in Amsterdam (unfortunately the conference organizers didn't notice that EclipseCon and ApacheCon are in the same week) as none of the Sonatype folks can attend ApacheCon. We are planning to record all the sessions on the 19th and so they should be available for everyone at ApacheCon. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- 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: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: [PLEASE TEST] Maven 2.1.0-RC1
I would change the tag. -Original Message- From: John Casey [mailto:jdca...@commonjava.org] Sent: Wednesday, March 11, 2009 8:22 AM To: Maven Developers List Subject: Re: [PLEASE TEST] Maven 2.1.0-RC1 Mistake on my part. I realized it when I started working on the bugfixes described in this thread. Sorry for the confusion. I'll amend the tag, too, if you want...just so it's not sitting out there as 2.1.0. -john Brett Porter wrote: Just been generally using it and no additional problems. Just curious - why 2.1.0 in the version that was released instead of 2.1.0-RC1? Though we now have the SVN Rev # in there, it could prove confusing for anyone that holds on to it. Cheers, Brett On 10/03/2009, at 3:00 AM, John Casey wrote: Hi everyone, I've rolled the first release candidate for Maven 2.1.0. It's available at: http://tinyurl.com/maven-2-1-0-RC1 (https://repository.apache.org/content/repositories/maven-staging-4e4fa4 8c70323f/org/apache/maven/apache-maven/2.1.0/) The staging repository root is at: https://repository.apache.org/content/repositories/maven-staging-4e4fa48 c70323f If you have time, please take a look and see if you can break it! BTW, the JIRA version notes for this release are at: http://tinyurl.com/maven-2-1-0-jira (http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleN ame=Htmlversion=14587) If we can't find anything wrong with this release candidate after maybe four or five days at most, I'll call the vote for a release. Hopefully we can coast in on the effort we put forth in the last release, at least to some extent! :-) Thanks, -john - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - 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: Migrate Maven Dependency Plugin to use Invoker Plugin for ITs
Nope, go ahead. The enforcer applies also. -Original Message- From: Benjamin Bentmann [mailto:benjamin.bentm...@udo.edu] Sent: Tuesday, March 10, 2009 3:36 AM To: Maven Developers List Subject: Migrate Maven Dependency Plugin to use Invoker Plugin for ITs Hi, This is mostly a question to Brian: Any objections if we migrate the Dependency Plugin to use the Invoker Plugin instead of SHITTY for the ITs? I am asking because MSHITTY-10 will bite us in CI once we upgrade Hudson to use Maven 2.1.0 or someday 3.x. Benjamin - 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: [vote] promote pdf plugin
+1 -Original Message- From: Lukas Theussl [mailto:ltheu...@apache.org] Sent: Monday, March 09, 2009 6:31 AM To: Maven Developers List Subject: [vote] promote pdf plugin Hi, With Doxia 1.1 released, I'd like to promote the pdf plugin out of the sandbox so we can release it. Snapshot is deployed: https://repository.apache.org/content/repositories/snapshots/org/apache/maven/plugins/maven-pdf-plugin/ The site with basic instructions is here: http://people.apache.org/~ltheussl/maven-pdf-plugin/ Some examples of pdfs created with the plugin are already on-line, eg the plugin itself (http://people.apache.org/~ltheussl/maven-pdf-plugin/maven-pdf-plugin.pdf), the Doxia site (http://maven.apache.org/doxia/Doxia.pdf) and the Continuum site (http://continuum.apache.org/docs/1.3.2-SNAPSHOT/apache-continuum.pdf). +1 -Lukas - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: MPIR 2.3-snapshot
I'm saying it's a minor annoyance now because it only affects people with snapshots enabled, when it becomes released, it will be annoying everyone. -Original Message- From: Brett Porter [mailto:br...@porterclan.net] On Behalf Of Brett Porter Sent: Wednesday, March 04, 2009 11:35 PM To: Maven Developers List Subject: Re: MPIR 2.3-snapshot On 05/03/2009, at 1:39 PM, Brian E. Fox wrote: No, I mean, why do we need to set the prereq...i understand how it works ;-) Can we work it so a prereq isn't needed is the question. Agree (and it should be possible), was just confused by the later portion below that you seemed to say it wasn't working and would cause headaches. - Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - 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: Maven2 mirror @ netcologne
Ibiblio only gets updated once a day starting at 1am CST, so every 2 hours is overkill. You could wait until 2am CST and then pull your copy. -Original Message- From: Mirror-Service [mailto:mirror-serv...@netcologne.de] Sent: Thursday, March 05, 2009 3:11 AM To: dev@maven.apache.org Subject: Maven2 mirror @ netcologne Hello Maven Dev-Team, we would love to setup a mirror of the maven2 repository in Germany. As there are currently no mirrors in Germany at all, and only two danish mirrors in europe. The NetCologne GmbH is a local ISP in the greater Cologne area. Our machine mirror.netcologne.de currently runs on this hardware: 2x 3Ghz Intel Xeon CPU 2 GB RAM (to be upgraded to 4GB) 3 TB of mirror storage total The machine currently already mirrors a few linux distros (mainly debian) and other free software projects. Regarding internet connectivity, the machine itself has 2 Gigabit/s uplink. Our backbone is then connected to all major peering points in europe (DECIX, AMSIX, LINX) with 20 Gbit/s each. We are also peering in the US (2x EQUINIX) and maintain quite a few private peering with other ISPs including Deutsche Telekom (DTAG) and the DFN (Deutsches Forschungsnetz, the German university network). IPv6 connectivity is coming very soon, so mark that as checked. We configured the rsync to sync with: mirrors.ibiblio.org::maven2 every two hours in the 42nd minute. Please let me know if that's ok, or if we need to adjust that. The repo is already available on [rsync|ftp|http]://mirror.netcologne.de/maven2 If you need to contact me, just mail to crohm...@netcologne.de, as official contact for the mirror use mirror-serv...@netcologne.de. -- Mit freundlichen Grüßen Christian Rohmann --- Network Engineering and Design Tel.: +49 221 -5751 Fax.: +49 221 -75751 NetCologne Gesellschaft für Telekommunikation mbH Am Coloneum 9 50829 Köln Geschäftsführer: Werner Hanf, Karl- Heinz Zankel, Dipl. Ing. HRB 25580, AG Köln www.netcologne.de - 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: [VOTE] Release Maven Doxia version 1.1
-1, the doxia tools release isn't signed: https://repository.apache.org/content/repositories/maven-staging-4c838f3 8e6b44b/org/apache/maven/doxia/doxia-converter/1.0/ The others looked ok. -Original Message- From: vincent.sive...@gmail.com [mailto:vincent.sive...@gmail.com] On Behalf Of Vincent Siveton Sent: Tuesday, March 03, 2009 5:35 PM To: Maven Developers List Subject: [VOTE] Release Maven Doxia version 1.1 Hi, We solved more than 100 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13617styleName =HtmlprojectId=10780 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10780 status=1 Staging repo: Doxia https://repository.apache.org/content/repositories/maven-staging-4c8268a 400077f/ Doxia Sitetools https://repository.apache.org/content/repositories/maven-staging-4c831d5 8591989 Doxia tools https://repository.apache.org/content/repositories/maven-staging-4c838f3 8e6b44b/ Staging site: http://maven.apache.org/doxia Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Vincent - 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: [VOTE] Release Maven Doxia version 1.1
Ok, The doxia tools are restaged here: https://repository.apache.org/content/repositories/maven-staging-4cc3f47 d7847b8/ +1 (procedural checking, I didn't test them directly, but I did rebuild the tools and it was ok) -Original Message- From: Brian E. Fox [mailto:bri...@reply.infinity.nu] Sent: Wednesday, March 04, 2009 8:40 AM To: Maven Developers List Subject: RE: [VOTE] Release Maven Doxia version 1.1 -1, the doxia tools release isn't signed: https://repository.apache.org/content/repositories/maven-staging-4c838f3 8e6b44b/org/apache/maven/doxia/doxia-converter/1.0/ The others looked ok. -Original Message- From: vincent.sive...@gmail.com [mailto:vincent.sive...@gmail.com] On Behalf Of Vincent Siveton Sent: Tuesday, March 03, 2009 5:35 PM To: Maven Developers List Subject: [VOTE] Release Maven Doxia version 1.1 Hi, We solved more than 100 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13617styleName =HtmlprojectId=10780 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10780 status=1 Staging repo: Doxia https://repository.apache.org/content/repositories/maven-staging-4c8268a 400077f/ Doxia Sitetools https://repository.apache.org/content/repositories/maven-staging-4c831d5 8591989 Doxia tools https://repository.apache.org/content/repositories/maven-staging-4c838f3 8e6b44b/ Staging site: http://maven.apache.org/doxia Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Vincent - 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
MPIR 2.3-snapshot
Is there a way to avoid requiring 2.1.0-M2 for the mpir 2.3 snapshot? [INFO] snapshot org.apache.maven.plugins:maven-project-info-reports-plugin:2.3-SNAPSHOT: checking for updates from central [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error resolving version for 'org.apache.maven.plugins:maven-project-info-reports-plugin': Plugin requir es Maven version 2.1.0-M2-SNAPSHOT Everytime I build a site, I run into this and I have to go lockdown the report. This is going to cause massive headaches when this gets released. It would be nice if Maven could see that the LATEST isn't compatible and falls back to the latest that is...I know the range code handles similar logic. -- Brian Fox Apache Maven PMC http://blogs.sonatype.com/brian/
RE: MPIR 2.3-snapshot
No, I mean, why do we need to set the prereq...i understand how it works ;-) Can we work it so a prereq isn't needed is the question. -Original Message- From: Brett Porter [mailto:br...@porterclan.net] On Behalf Of Brett Porter Sent: Wednesday, March 04, 2009 10:49 AM To: Maven Developers List Subject: Re: MPIR 2.3-snapshot On 05/03/2009, at 2:29 AM, Brian E. Fox wrote: Everytime I build a site, I run into this and I have to go lockdown the report. This is going to cause massive headaches when this gets released. It would be nice if Maven could see that the LATEST isn't compatible and falls back to the latest that is...I know the range code handles similar logic. prerequisites / does that, assuming your metadata is correct. It might be ignored if you've installed a snapshot that you've built yourself though - I'd need to check. Or perhaps it's not working for reports. - Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - 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 2.1.0 and Doxia
1.1 is NOT under development anymore, it hasn't been for at least over a year. All we did was small bug fixes and enhancements that came along on the way because there was nothing else to do. I don't follow this logic, if it's been done for over a year, why has it been discussed for the last 3 maven releases and still no release? It only seems relevant when a maven release is coming up and then it's a hurry up and wait for doxia pattern.
RE: Maven 2.1.0 and Doxia
The more this thread goes on, the less optimistic I feel about this going into 2.1. We already know the 2.1M1 is stable and the point was to get it out in a release that people can use, ie non-milestone. Making radical changes at the last minute is not good for stability and not good for the users. I think this should go into 2.2 and there should be a release cut and integrated into the 2.2 snapshots immediately so we have time to understand the issues. Using a maven release to effectively test doxia goes against all the progress we've made in the last year to stabilize the releases and improve quality. (this is the same argument I think I used in 2.0.9, 2.0.10, and since the release didn't happen, it's still valid imo) -Original Message- From: John Casey [mailto:jdca...@commonjava.org] Sent: Tuesday, March 03, 2009 9:51 AM To: Maven Developers List Subject: Re: Maven 2.1.0 and Doxia Lukas Theussl wrote: Hi John, If you would have used the time it took you to write this email for installing and testing Doxia 1.1 you probably wouldn't have to ask anymore if it's a terrible idea. ;) In my experience, five minutes isn't enough time to do anything when you've got more than one snapshot dependency/plugin you're trying to use. It's not trivial to replace a whole stack of artifacts with another whole stack of artifacts, then dig up a test project that will put the snapshots through their paces properly. However, the main point is that I also see no reason for NOT upgrading now (as I do not accept your FUD arguments). This is not merely my blowing smoke and trying to inject fear; we've been bitten time and again by bad/untested dependencies that get pushed out just ahead of a Maven release. I've spent quite a lot of time in the past on the front lines after these releases, answering questions about why things are messed up and debugging problems for people to find a workaround. I don't think taking a slightly more conservative view of the release process as a result is in any way FUD. These are not unfounded views. A few people have now taken their time to test 1.1 and have provided positive feedback (Brett, Herve, Wendy). Doxia 1.1 (then beta-1) was present in the 2.0.x core for 4 months [1], unfortunately it was reverted for the 2.0.10 release [2] for reasons that I do not recall These reasons were failing tests. I guess we didn't have the test coverage in place to figure that out for four months...good thing we're all set now, though. As for the improvements you propose, it certainly sounds good and all, and IIUC along the lines of what Jason is planning for Maven 3 [3], but as long as there is nothing concrete on the table I don't see why we shouldn't use what we have now (ie Doxia 1.1). IMO, the only thing we know we have now is the released and battle-proven versions that went out with the previous release(s). These may have warts, but they're known quantities. We don't have a Doxia 1.1, that's kind of the point I was trying to make. We *may* have one soon, and maybe it'll work or maybe it won't. Maybe it'll introduce a crop of bugs that keep us from saying that this Maven release is *definitely* progress, *definitely* better. Our problems with upgrading Doxia in Maven core are not simply prejudice, they have a long history of causing really difficult problems. This means Doxia has to be subject to extraordinary scrutiny before we include a new release in Maven itself. -john - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: decision on Doxia for 2.1.0?
Yeah double it up to reduce the overall timeline. -Original Message- From: Brett Porter [mailto:br...@porterclan.net] On Behalf Of Brett Porter Sent: Monday, March 02, 2009 5:57 AM To: Maven Developers List Subject: Re: decision on Doxia for 2.1.0? On 02/03/2009, at 9:45 PM, Vincent Siveton wrote: 2009/3/1, Jason van Zyl jvan...@sonatype.com: Why is Doxia dependent on MPIR? We can't make mvn site due to MPIR-146. Ah, sorry for the out of sequence reply. I think it's ok to stage/ publish sites using the staged release of MPIR so that version is in the release so that the votes can happen concurrently, we do that all the time with parents, dependencies, etc. - Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - 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 2.1.0 and Doxia
I'm venting because I'm a little frustrated that this conversation came up back in August and here we are talking about it again...and again, we have no released version of Doxia to consume. So, we're in a position of rushing out a release of Doxia so we can push an unproven dependency into Maven just in time for a release. Doesn't this seem like a terrible idea to anyone else? It does to me, and this is why it got yanked from 2.0.9. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: stuck on gpg:sign while staging ear plugin
Maybe it's waiting for the password?
-Original Message-
From: Stephane Nicoll [mailto:stephane.nic...@gmail.com]
Sent: Sunday, March 01, 2009 10:57 AM
To: Maven Developers List
Subject: stuck on gpg:sign while staging ear plugin
Hey guys,
I am trying to stage EAR plugin 2.3.2 before calling for a vote. I've
followed everything as described on[1] but the mvn process is stuck on
the
gpg sign goal
[INFO] [INFO] [gpg:sign {execution: default}]
I have MacOS 10.5.6 with maven 2.0.9 and gpg 1.4.9
snic...@cobra:~$ gpg --version
gpg (GnuPG) 1.4.9
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
I installed gpg with port.
Any idea?
S.
[1] http://maven.apache.org/developers/release/releasing.html
--
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck -- S.Yegge
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
RE: decision on Doxia for 2.1.0?
When can we get 1.1? I think 2.1.0 is essentially ready to go now. -Original Message- From: Hervé BOUTEMY [mailto:herve.bout...@free.fr] Sent: Sunday, March 01, 2009 2:44 PM To: Maven Developers List Subject: Re: decision on Doxia for 2.1.0? We made tests with Vincent today and found little problems with backward compatibility that Vincent fixed immediately. Now everything is ok for me. I tested Modello's site with success: MPIR, PMD, Checkstyle, Surefire and taglist reports were fine (after the fixes...). I'm now confident that this change will be fully backward compatible with every reporting plugin. then +1 to include Doxia 1.1 in Maven 2.1.0 To have your own test: - mvn install Doxia and Doxia Site Tools 1.1-SNAPSHOT (= trunk), - install and use Maven 2.1-SNAPSHOT after upgrading doxia-sink-api to 1.1-SNAPSHOT (in main pom.xml) - mvn install maven-site-plugin 2.1-SNAPSHOT from https://svn.apache.org/repos/asf/maven/plugins/branches/maven-site-plugin-doxia-1.1 Then choose the project of your choice you want to test: upgrade maven-site-plugin to 2.1-SNAPSHOT and generate the site. If you're like me, there are some warnings like [WARNING] Profile with id: 'reporting' has not been activated. or [WARNING] A dependency of the current project (or of one the plugins used in its build)was found in the reactor, but had not been built at the time it was requested. It will be resolved from the repository instead.. But everything works well HTH Regards, Hervé Le dimanche 01 mars 2009, Dennis Lundberg a écrit : This sound like a good plan to me. Release Doxia 1.1 and put it into 2.1.0. If things start to go horribly wrong pull it out again. Brett Porter wrote: Hi, So I did additional testing and while there is no way to do the separation without busting things up at this stage, upgrading to Doxia 1.1 does appear to be backwards compatible (the old and the new site plugin work with it, and old and new reports work with the old site plugin on the new doxia - got that mouthful? :) I think John is about to call the other release, so this will be the last queued issue for 2.1.0 before starting the RC phase. So, do we upgrade or postpone? Doxia 1.1 looks ready to release according to JIRA. So, IMO - if that release can be started right away, we can include it for the RC cycle - we need to break this deadlock. But at the first sign of major trouble it would be back to 1.0. If the release isn't ready to go we would also have to stick to 1.0. Objections? Cheers, Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - 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: MNG-4056, please comment
Seems logical to me. I don't know why there are these special mappings in the first place. Sources is the other one that comes to mind... if true you should handle that the same. -Original Message- From: Benjamin Bentmann [mailto:benjamin.bentm...@udo.edu] Sent: Sunday, March 01, 2009 9:11 AM To: Maven Developers List Subject: MNG-4056, please comment Hi, I recently created a patch for MNG-4056 and would appreciate some comments whether that's the proper way to address the issue. In short, this issue is about the subtle difference between dependency groupIdgid/groupId artifactIdaid/artifactId version0.1/version classifiertests/classifier /dependency and dependency groupIdgid/groupId artifactIdaid/artifactId version0.1/version typetest-jar/type /dependency i.e. typetest-jar/type vs. classifiertests/classifier. While both declarations work during builds of the consumer project that run up to the install phase, only the latter declaration will allow proper dependency resolution from the reactor during an earlier lifecycle phase like package (see also comments in MNG-2045 [0]). The cause for this difference is that resolution from the reactor matches artifacts by their dependency conflict id which has the form gid:aid:type:classifier. For the first dependency declaration above, the type is jar which doesn't match the type test-jar as used for the attached test JAR. In case matching by dependency conflict id fails, the proposed patch falls back to another id I called repository conflict id (well, it needed to have a name...). The important difference is that the repository conflict id has the form gid:aid:extension:classifier, i.e. uses the file extension instead of the type. The rationale for this approach is the observation that the repository layout does not use the artifact type but the file extension to distinguish files. In other words, the ids gid:aid:test-jar:tests:0.1 and gid:aid:jar:tests:0.1 get mapped to the same physical file in the repository, namely gid/aid/0.1/aid-0.1/aid-0.1-tests.jar i.e. there's an aliasing effect in the repository which the patch mimics for dependency resolution from the reactor. It solves the problem from a user's perspective but I'm not sure whether this kind of artifact identity is clean from a design perspective. WDYT? Benjamin [0] http://jira.codehaus.org/browse/MNG-2045?focusedCommentId=152064page=co m.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_ 152064 - 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: Code provenance checks for Plexus components
Plexus is a codehaus component, so Apache would most likely not have these checks. -Original Message- From: Abel Muiño [mailto:amu...@gmail.com] Sent: Friday, February 27, 2009 1:18 PM To: dev@maven.apache.org Subject: Code provenance checks for Plexus components The Eclipse legal team is having a hard time trying to confirm code provenance for the plexus components required by the 3.0 maven embedder. I suppose that the Apache Foundation has already done similar provenance checks before distributing the components... so can you please help us with the Eclipse review? Specifically, the legal team has asked: ··· For example, it would be helpful to know whether Plexus project members and contributors are asked to acknowledge anything regarding their contribution in an e-mail (e.g. I wrote the code, it's mine, and I'm contributing it to Plexus for distribution under the Apache 1.1 or Apache 2.0 license). ··· Does such thing (or anything similar) exist? Does Apache keep some records regarding the 3rd party checks it performs before a release? Thanks! - http://www.linkedin.com/in/amuino Abel Muintilde;o Vizcaino - http://ramblingabout.wordpress.com http://ramblingabout.wordpress.com -- View this message in context: http://www.nabble.com/Code-provenance-checks-for-Plexus-components-tp22251436p22251436.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: settings security: --enc-passwd / --enc-master-passwd options
+1 for no abbreviations. We have enough crazy options to memorize on the cli as it is. (ie is it maven.tests.skip or maven.skip.tests?) -Original Message- From: Brett Porter [mailto:br...@porterclan.net] On Behalf Of Brett Porter Sent: Thursday, February 26, 2009 8:52 AM To: Maven Developers List Subject: Re: settings security: --enc-passwd / --enc-master-passwd options On 27/02/2009, at 12:45 AM, Jason van Zyl wrote: I thought Oleg asked for the use of the password? Did you mean plugin? I don't want there to be a way in 2.1.x and then it be completely different in the 3.x line. It needs to be the same. Certainly - would follow with an IT if we agree to have a CLI option (and what the spelling should be :) On 26-Feb-09, at 3:27 AM, Brett Porter wrote: With 2.1.0 imminent, we'll need to finalise on this soon - are the current options satisfactory? Cheers, Brett I have never seen an environment where read-only access to central or central replica is authenticated. Short of that it's just another plugin to be downloaded and used. Or I completely missed the question? That's right, it's the situation I was thinking of. I was thinking along the lines of a vetted repository where direct use of central is not used. It's maybe still unlikely that would be authenticated, but I wouldn't rule it out. Thinking it through, to me this actually feels a more natural fit in the CLI now, along with the other settings-based operations, pretty much symmetrical with the location of the operation to decode the passwords in the settings file. For a user, manipulation of the settings file is generally a set-up task, before you do anything else. This location also makes it very snappy, not going through the whole plugin cycle, and had very little impact on the code since it was already mostly achieved through the sec-dispatcher and cipher. A plugin for this would see infrequent releases - perhaps none - which seems an odd evolutionary cycle for an independent piece of code. Not that tied to it being in the CLI if a suitable replacement is already in place, but I hope this is somewhat convincing :) -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - 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: svn commit: r748226 - in /maven/components/trunk/maven-project/src/main/java/org/apache/maven: profiles/ProfilesConversionUtils.java profiles/build/DefaultProfileAdvisor.java profiles/build/Profil
That doesn't negate the need for an issue and some tracking of these changes. -Original Message- From: Shane Isbell [mailto:shane.isb...@gmail.com] Sent: Thursday, February 26, 2009 1:57 PM To: Maven Developers List Subject: Re: svn commit: r748226 - in /maven/components/trunk/maven-project/src/main/java/org/apache/maven: profiles/ProfilesConversionUtils.java profiles/build/DefaultProfileAdvisor.java profiles/build/ProfileAdvisor.java project/DefaultMavenProjectBuilder.j This is permanent. From my understanding, profiles.xml is almost never used, so it's not really worth the added complexity of keeping it. On Thu, Feb 26, 2009 at 10:35 AM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Hi Shane, Author: sisbell Date: Thu Feb 26 17:46:01 2009 New Revision: 748226 URL: http://svn.apache.org/viewvc?rev=748226view=rev Log: Removed support for profiles.xml Will this be re-instantiated later or is this a permanent difference between 2.x and 3.x? In the latter case, shouldn't we create JIRAs for this and similar changes (like r747652) to have the breaking changes visible in the release notes somehow? Otherwise I imagine we get some more bug reports from unaware users. Benjamin - 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: settings security: --enc-passwd / --enc-master-passwd options
A gui is overkill here. -Original Message- From: Oleg Gusakov [mailto:oleg.subscripti...@gmail.com] Sent: Thursday, February 26, 2009 11:28 AM To: Maven Developers List Subject: Re: settings security: --enc-passwd / --enc-master-passwd options Jason van Zyl wrote: This doesn't need to go into the core, I think a plugin is better. I was thinking about GUI in the plugin - that way we either go by -Dsettings-master-password and -Dsettings-server-password or have the same options available via swing GUI Thanks, Oleg On 26-Feb-09, at 6:22 AM, Brian E. Fox wrote: +1 for no abbreviations. We have enough crazy options to memorize on the cli as it is. (ie is it maven.tests.skip or maven.skip.tests?) -Original Message- From: Brett Porter [mailto:br...@porterclan.net] On Behalf Of Brett Porter Sent: Thursday, February 26, 2009 8:52 AM To: Maven Developers List Subject: Re: settings security: --enc-passwd / --enc-master-passwd options On 27/02/2009, at 12:45 AM, Jason van Zyl wrote: I thought Oleg asked for the use of the password? Did you mean plugin? I don't want there to be a way in 2.1.x and then it be completely different in the 3.x line. It needs to be the same. Certainly - would follow with an IT if we agree to have a CLI option (and what the spelling should be :) On 26-Feb-09, at 3:27 AM, Brett Porter wrote: With 2.1.0 imminent, we'll need to finalise on this soon - are the current options satisfactory? Cheers, Brett I have never seen an environment where read-only access to central or central replica is authenticated. Short of that it's just another plugin to be downloaded and used. Or I completely missed the question? That's right, it's the situation I was thinking of. I was thinking along the lines of a vetted repository where direct use of central is not used. It's maybe still unlikely that would be authenticated, but I wouldn't rule it out. Thinking it through, to me this actually feels a more natural fit in the CLI now, along with the other settings-based operations, pretty much symmetrical with the location of the operation to decode the passwords in the settings file. For a user, manipulation of the settings file is generally a set-up task, before you do anything else. This location also makes it very snappy, not going through the whole plugin cycle, and had very little impact on the code since it was already mostly achieved through the sec-dispatcher and cipher. A plugin for this would see infrequent releases - perhaps none - which seems an odd evolutionary cycle for an independent piece of code. Not that tied to it being in the CLI if a suitable replacement is already in place, but I hope this is somewhat convincing :) -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - 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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- Simplex sigillum veri. (Simplicity is the seal of truth.) - 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: [vote] release maven-enforcer-plugin 1.0-beta-1
Results: Binding: +7 Brian, Jason, Arnaud, Lukas, Vincent, Olivier, Brett Non binding: +3 Jason Dillon, Oleg, Nicolas I'll publish the sites and artifacts now. -Original Message- From: Brian E. Fox [mailto:bri...@reply.infinity.nu] Sent: Sunday, February 22, 2009 10:20 PM To: Maven Developers List Subject: [vote] release maven-enforcer-plugin 1.0-beta-1 Time to release a beta with a few bug fixes: Release Notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14948styleName =HtmlprojectId=11530Create=Create Staged site: http://people.apache.org/~brianf/staging/people.apache.org/www/maven.apa che.org/enforcer/ Artifacts Staged at: https://repository.apache.org/content/repositories/maven-staging-49da452 d70c062/ 72hrs, +1 -- Brian Fox Apache Maven PMC http://blogs.sonatype.com/brian/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: License for maven 3.0 artifacts
Yes, they are ASL. -Original Message- From: Abel Muiño [mailto:amu...@gmail.com] Sent: Tuesday, February 24, 2009 1:58 PM To: dev@maven.apache.org Subject: License for maven 3.0 artifacts I have not been able to get information about these two artifacts (transitive dependencies of the maven embedder 3.0). I guess that they are licensed under ASL 2.0, but I could not find a public site with information on licensing or purpose. * org.sonatype.plexus:plexus-plugin-manager:1.0-alpha-1 * org.sonatype.spice:model-builder:1.3 Can this be confirmed, please? - http://www.linkedin.com/in/amuino Abel Muintilde;o Vizcaino - http://ramblingabout.wordpress.com http://ramblingabout.wordpress.com -- View this message in context: http://www.nabble.com/License-for-maven-3.0-artifacts-tp22188188p22188188.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: New repository for Maven snapshots
We don't yet have an official cert from infra yet (INFRA-1891). So you need to install the current cert, see http://repository.apache.org/ssl for instructions. The rest of the info is updated on the release docs of the site, but you just need to use apache.snapshots.https / apache.releases.https in your server settings with your apache creds. -Original Message- From: Stephane Nicoll [mailto:stephane.nic...@gmail.com] Sent: Sunday, February 22, 2009 12:24 PM To: Maven Developers List Subject: Re: New repository for Maven snapshots Weird ... caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:221) at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:145) at sun.security.validator.Validator.validate(Validator.java:203) at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:172) at com.sun.net.ssl.internal.ssl.JsseX509TrustManager.checkServerTrusted(SSLContextImpl.java:320) at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:841) ... 36 more Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:236) at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:194) at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:216) ... 41 more On Sun, Feb 22, 2009 at 5:43 PM, Stephane Nicoll stephane.nic...@gmail.comwrote: What should we do to be able to deploy snapshots again? [INFO] Retrieving previous build number from apache.snapshots.https [WARNING] repository metadata for: 'snapshot org.apache.maven.plugins:maven-ear-plugin:2.3.2-SNAPSHOT' could not be retrieved from repository: apache.snapshots.https due to an error: Error transferring file [INFO] Repository 'apache.snapshots.https' will be blacklisted Uploading: https://repository.apache.org/content/repositories/snapshots/org/apache/maven/plugins/maven-ear-plugin/2.3.2-SNAPSHOT/maven-ear-plugin-2.3.2-20090222.164123-1.jar Thanks, Stéphane On Sun, Feb 22, 2009 at 2:10 AM, Brian E. Fox bri...@reply.infinity.nuwrote: The Maven project has recently moved to a new repository within the Apache infrastructure. The repository that was previously at: http://people.apache.org/repo/m2-snapshot-repository is deprecated. All new snapshots are being deployed to http://repository.apache.org/snapshots . Note that this is a logical grouping with a proxy of the old repository so the new url can safely supersede the old one for other apache projects as well. -- Brian Fox Apache Maven PMC http://blogs.sonatype.com/brian/ -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: archetype completely broken or just me?
Ok I probably did have a snapshot since I had built/deployed everything to the new repo. -Original Message- From: Raphaël Piéroni [mailto:raphaelpier...@gmail.com] Sent: Sunday, February 22, 2009 1:10 PM To: Maven Developers List Subject: Re: archetype completely broken or just me? Are you using the latest unreleased snapshot ? If yep, that could be the problem. The next release will change the default catalog location from internal (created at release time using MAVENUSER) to repo1/maven2/archetype-catalog.xml. Obviously, that release will be postponed until the creation of that file in repo1 using the nexus index. talked with tamas some weeks ago to add this feature (the automatic creation of the catalog in repo1) WDYT? Ragards, Raphaël 2009/2/21 Brian E. Fox bri...@reply.infinity.nu [WARNING] Error reading archetype catalog http://repo1.maven.org/maven2 org.apache.maven.archetype.source.ArchetypeDataSourceException: Error parsing ar chetype catalog. at org.apache.maven.archetype.source.CatalogArchetypeDataSource.readCata log(CatalogArchetypeDataSource.java:202) at org.apache.maven.archetype.source.RemoteCatalogArchetypeDataSource.ge tArchetypeCatalog(RemoteCatalogArchetypeDataSource.java:91) at org.apache.maven.archetype.DefaultArchetype.getRemoteCatalog(DefaultA rchetype.java:197) at org.apache.maven.archetype.DefaultArchetype.getRemoteCatalog(DefaultA rchetype.java:186) at org.apache.maven.archetype.ui.DefaultArchetypeSelector.getArchetypesB yCatalog(DefaultArchetypeSelector.java:278) at org.apache.maven.archetype.ui.DefaultArchetypeSelector.selectArchetyp e(DefaultArchetypeSelector.java:74) at org.apache.maven.archetype.mojos.CreateProjectFromArchetypeMojo.execu te(CreateProjectFromArchetypeMojo.java:183) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:453) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone Goal(DefaultLifecycleExecutor.java:513) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:483) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:331) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:228) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:301) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: Unrecognise d tag: 'html' (position: START_TAG seen html... @1:6) at org.apache.maven.archetype.catalog.io.xpp3.ArchetypeCatalogXpp3Reader .parseArchetypeCatalog(ArchetypeCatalogXpp3Reader.java:529) at org.apache.maven.archetype.catalog.io.xpp3.ArchetypeCatalogXpp3Reader .read(ArchetypeCatalogXpp3Reader.java:821) at org.apache.maven.archetype.catalog.io.xpp3.ArchetypeCatalogXpp3Reader .read(ArchetypeCatalogXpp3Reader.java:835) at org.apache.maven.archetype.source.CatalogArchetypeDataSource.readCata log(CatalogArchetypeDataSource.java:194) ... 24 more [INFO] No archetype defined. Using maven-archetype-quickstart (org.apache.maven. archetypes:maven-archetype-quickstart:1.0) Choose archetype: -- Brian Fox Apache Maven PMC http://blogs.sonatype.com/brian/
RE: New repository for Maven snapshots
There is now an official certificate on there so there shouldn't be trouble going forward. -Original Message- From: Stephane Nicoll [mailto:stephane.nic...@gmail.com] Sent: Sunday, February 22, 2009 1:11 PM To: Maven Developers List Subject: Re: New repository for Maven snapshots Okay that fixes the issue. Thanks, Stéphane On Sun, Feb 22, 2009 at 6:57 PM, Brian E. Fox bri...@reply.infinity.nuwrote: We don't yet have an official cert from infra yet (INFRA-1891). So you need to install the current cert, see http://repository.apache.org/ssl for instructions. The rest of the info is updated on the release docs of the site, but you just need to use apache.snapshots.https / apache.releases.https in your server settings with your apache creds. -Original Message- From: Stephane Nicoll [mailto:stephane.nic...@gmail.com] Sent: Sunday, February 22, 2009 12:24 PM To: Maven Developers List Subject: Re: New repository for Maven snapshots Weird ... caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:221) at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:145) at sun.security.validator.Validator.validate(Validator.java:203) at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:172) at com.sun.net.ssl.internal.ssl.JsseX509TrustManager.checkServerTrusted(SSLContextImpl.java:320) at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:841) ... 36 more Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:236) at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:194) at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:216) ... 41 more On Sun, Feb 22, 2009 at 5:43 PM, Stephane Nicoll stephane.nic...@gmail.comwrote: What should we do to be able to deploy snapshots again? [INFO] Retrieving previous build number from apache.snapshots.https [WARNING] repository metadata for: 'snapshot org.apache.maven.plugins:maven-ear-plugin:2.3.2-SNAPSHOT' could not be retrieved from repository: apache.snapshots.https due to an error: Error transferring file [INFO] Repository 'apache.snapshots.https' will be blacklisted Uploading: https://repository.apache.org/content/repositories/snapshots/org/apache/maven/plugins/maven-ear-plugin/2.3.2-SNAPSHOT/maven-ear-plugin-2.3.2-20090222.164123-1.jar Thanks, Stéphane On Sun, Feb 22, 2009 at 2:10 AM, Brian E. Fox bri...@reply.infinity.nu wrote: The Maven project has recently moved to a new repository within the Apache infrastructure. The repository that was previously at: http://people.apache.org/repo/m2-snapshot-repository is deprecated. All new snapshots are being deployed to http://repository.apache.org/snapshots . Note that this is a logical grouping with a proxy of the old repository so the new url can safely supersede the old one for other apache projects as well. -- Brian Fox Apache Maven PMC http://blogs.sonatype.com/brian/ -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[vote] release maven-enforcer-plugin 1.0-beta-1
Time to release a beta with a few bug fixes: Release Notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14948styleName =HtmlprojectId=11530Create=Create Staged site: http://people.apache.org/~brianf/staging/people.apache.org/www/maven.apa che.org/enforcer/ Artifacts Staged at: https://repository.apache.org/content/repositories/maven-staging-49da452 d70c062/ 72hrs, +1 -- Brian Fox Apache Maven PMC http://blogs.sonatype.com/brian/
RE: svn commit: r746002 - in /maven/components/trunk: maven-core/src/main/java/org/apache/maven/plugin/ maven-embedder/src/main/java/org/apache/maven/embedder/ maven-project-builder/ maven-project-bui
I'll take a look but I'm generally in favor of using Maven to do these things
rather than duplicating the effort over again in Hudson specific config.
-Original Message-
From: Vincent Siveton [mailto:vincent.sive...@gmail.com]
Sent: Saturday, February 21, 2009 8:45 AM
To: Maven Developers List
Subject: Re: svn commit: r746002 - in /maven/components/trunk:
maven-core/src/main/java/org/apache/maven/plugin/
maven-embedder/src/main/java/org/apache/maven/embedder/ maven-project-builder/
maven-project-builder/src/main/java/org/apache/maven/project/builde
+1
Vincent
2009/2/21, Hervé BOUTEMY herve.bout...@free.fr:
oh yes, something like Violations Hudson plugin [1] for example would be a
great enhancement, since this would be on a central machine and give history.
Definitely helpful and should not be too complicated to add to existing CI
instances.
I'm not a Hudson expert, nor do I really know this plugin: I found it in
Apache's Hudson instance then read the manual, I even not tried it. If
anybody knows another plugin, no problem for me: for example, just found
another one [2] that seems quite equivalent.
There is still one feature missing: automatic blame when reports get worse on
a commit. I didn't find anything like this.
Regards,
Hervé
[1] http://wiki.hudson-ci.org/display/HUDSON/Violations
[2] http://wiki.hudson-ci.org/display/HUDSON/Static+Code+Analysis+Plug-ins
Le vendredi 20 février 2009, Brian E. Fox a écrit :
Ok, I mean either enable it all the time, or get some reports or CI etc.
-Original Message-
From: Dennis Lundberg [mailto:denn...@apache.org]
Sent: Friday, February 20, 2009 11:26 AM
To: Maven Developers List
Subject: Re: svn commit: r746002 - in /maven/components/trunk:
maven-core/src/main/java/org/apache/maven/plugin/
maven-embedder/src/main/java/org/apache/maven/embedder/
maven-project-builder/
maven-project-builder/src/main/java/org/apache/maven/project/builder/ ma
We already have it in the Maven parent POM.
When using the reporting profile you get a Checkstyle report for the
current artifact.
Brian E. Fox wrote:
Why don't we just hookup checkstyle to maven?
-Original Message-
From: Hervé BOUTEMY [mailto:herve.bout...@free.fr]
Sent: Thursday, February 19, 2009 7:08 PM
To: dev@maven.apache.org
Subject: Re: svn commit: r746002 - in /maven/components/trunk:
maven-core/src/main/java/org/apache/maven/plugin/
maven-embedder/src/main/java/org/apache/maven/embedder/
maven-project-builder/
maven-project-builder/src/main/java/org/apache/maven/project/builder/ ma
Hi Shane,
There are a lot of coding style conventions problems in this commit:
- whitespace,
- implements/throws on a separate line,
+private String parentGroupId = null, parentArtifactId = null,
parentVersion = null, parentId = null, parentRelativePath;
each attribute should be declared on it own line
-import java.io.File;
-import java.io.IOException;
+import java.io.*;
no wildcard imports
+finally
+{
+if ( out != null )
+{
+out.close();
+}
+}
prefer IOUtil.close( out ) from plexus-utils, which has the necessary
try/catch to enforce safe code in any cases (I know this case is
in-memory, then not absolutely necessary)
Regards,
Hervé
Le jeudi 19 février 2009, sisb...@apache.org a écrit :
Author: sisbell
Date: Thu Feb 19 21:22:46 2009
New Revision: 746002
URL: http://svn.apache.org/viewvc?rev=746002view=rev
Log:
Refactored out more uses of modello and moved classes from maven-project
to maven-project-builder. Doing this so that maven-mercury will not have
direct dependency on modello or maven model.
[SNAP]
-
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
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
archetype completely broken or just me?
[WARNING] Error reading archetype catalog http://repo1.maven.org/maven2 org.apache.maven.archetype.source.ArchetypeDataSourceException: Error parsing ar chetype catalog. at org.apache.maven.archetype.source.CatalogArchetypeDataSource.readCata log(CatalogArchetypeDataSource.java:202) at org.apache.maven.archetype.source.RemoteCatalogArchetypeDataSource.ge tArchetypeCatalog(RemoteCatalogArchetypeDataSource.java:91) at org.apache.maven.archetype.DefaultArchetype.getRemoteCatalog(DefaultA rchetype.java:197) at org.apache.maven.archetype.DefaultArchetype.getRemoteCatalog(DefaultA rchetype.java:186) at org.apache.maven.archetype.ui.DefaultArchetypeSelector.getArchetypesB yCatalog(DefaultArchetypeSelector.java:278) at org.apache.maven.archetype.ui.DefaultArchetypeSelector.selectArchetyp e(DefaultArchetypeSelector.java:74) at org.apache.maven.archetype.mojos.CreateProjectFromArchetypeMojo.execu te(CreateProjectFromArchetypeMojo.java:183) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:453) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone Goal(DefaultLifecycleExecutor.java:513) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:483) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:331) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:228) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:301) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: Unrecognise d tag: 'html' (position: START_TAG seen html... @1:6) at org.apache.maven.archetype.catalog.io.xpp3.ArchetypeCatalogXpp3Reader .parseArchetypeCatalog(ArchetypeCatalogXpp3Reader.java:529) at org.apache.maven.archetype.catalog.io.xpp3.ArchetypeCatalogXpp3Reader .read(ArchetypeCatalogXpp3Reader.java:821) at org.apache.maven.archetype.catalog.io.xpp3.ArchetypeCatalogXpp3Reader .read(ArchetypeCatalogXpp3Reader.java:835) at org.apache.maven.archetype.source.CatalogArchetypeDataSource.readCata log(CatalogArchetypeDataSource.java:194) ... 24 more [INFO] No archetype defined. Using maven-archetype-quickstart (org.apache.maven. archetypes:maven-archetype-quickstart:1.0) Choose archetype: -- Brian Fox Apache Maven PMC http://blogs.sonatype.com/brian/
New repository for Maven snapshots
The Maven project has recently moved to a new repository within the Apache infrastructure. The repository that was previously at: http://people.apache.org/repo/m2-snapshot-repository is deprecated. All new snapshots are being deployed to http://repository.apache.org/snapshots . Note that this is a logical grouping with a proxy of the old repository so the new url can safely supersede the old one for other apache projects as well. -- Brian Fox Apache Maven PMC http://blogs.sonatype.com/brian/
RE: svn commit: r746002 - in /maven/components/trunk: maven-core/src/main/java/org/apache/maven/plugin/ maven-embedder/src/main/java/org/apache/maven/embedder/ maven-project-builder/ maven-project-bui
Ok, I mean either enable it all the time, or get some reports or CI etc.
-Original Message-
From: Dennis Lundberg [mailto:denn...@apache.org]
Sent: Friday, February 20, 2009 11:26 AM
To: Maven Developers List
Subject: Re: svn commit: r746002 - in /maven/components/trunk:
maven-core/src/main/java/org/apache/maven/plugin/
maven-embedder/src/main/java/org/apache/maven/embedder/ maven-project-builder/
maven-project-builder/src/main/java/org/apache/maven/project/builder/ ma
We already have it in the Maven parent POM.
When using the reporting profile you get a Checkstyle report for the
current artifact.
Brian E. Fox wrote:
Why don't we just hookup checkstyle to maven?
-Original Message-
From: Hervé BOUTEMY [mailto:herve.bout...@free.fr]
Sent: Thursday, February 19, 2009 7:08 PM
To: dev@maven.apache.org
Subject: Re: svn commit: r746002 - in /maven/components/trunk:
maven-core/src/main/java/org/apache/maven/plugin/
maven-embedder/src/main/java/org/apache/maven/embedder/
maven-project-builder/
maven-project-builder/src/main/java/org/apache/maven/project/builder/ ma
Hi Shane,
There are a lot of coding style conventions problems in this commit:
- whitespace,
- implements/throws on a separate line,
+private String parentGroupId = null, parentArtifactId = null,
parentVersion = null, parentId = null, parentRelativePath;
each attribute should be declared on it own line
-import java.io.File;
-import java.io.IOException;
+import java.io.*;
no wildcard imports
+finally
+{
+if ( out != null )
+{
+out.close();
+}
+}
prefer IOUtil.close( out ) from plexus-utils, which has the necessary
try/catch to enforce safe code in any cases (I know this case is in-memory,
then not absolutely necessary)
Regards,
Hervé
Le jeudi 19 février 2009, sisb...@apache.org a écrit :
Author: sisbell
Date: Thu Feb 19 21:22:46 2009
New Revision: 746002
URL: http://svn.apache.org/viewvc?rev=746002view=rev
Log:
Refactored out more uses of modello and moved classes from maven-project to
maven-project-builder. Doing this so that maven-mercury will not have
direct dependency on modello or maven model.
[SNAP]
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
Dennis Lundberg
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
RE: [vote] release asf/maven/maven-plugins/maven-shared poms
Dennis, can you take another look and hopefully update your vote? -Original Message- From: Dennis Lundberg [mailto:denn...@apache.org] Sent: Thursday, February 19, 2009 4:15 PM To: Maven Developers List Subject: Re: [vote] release asf/maven/maven-plugins/maven-shared poms -1 on the maven-plugins POM after a quick glance. It still has a SNAPSHOT version on the tag http://svn.apache.org/viewvc/maven/plugins/tags/maven-plugins-13/pom.xml ?revision=745340view=markup Brian E. Fox wrote: New parents need to be released with the new distributionManagement sections pointed at repository.apache.org: Apache Pom Diffs: http://svn.apache.org/viewvc/maven/pom/tags/apache-5/pom.xml?r1=639584r 2=745325diff_format=h Staged at: https://repository.apache.org/content/repositories/staging-484a2aeeabd6a 7/ Diffs: http://svn.apache.org/viewvc/maven/pom/tags/maven-parent-11/pom.xml?r1=7 39516r2=745330diff_format=h http://svn.apache.org/viewvc/maven/plugins/tags/maven-plugins-13/pom.xml ?r1=728991r2=745340diff_format=h http://svn.apache.org/viewvc/maven/shared/tags/maven-shared-components-1 1/pom.xml?r1=739774r2=745352diff_format=h Maven Parent and Maven-Plugins Parent Staged at: https://repository.apache.org/content/repositories/maven-staging-484a998 2bc6221/ 72hrs, +1 -- Brian Fox Apache Maven PMC http://www.sonatype.com/people/author/brian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - 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: [vote] release asf/maven/maven-plugins/maven-shared poms
Grrr. It's fixed now: https://repository.apache.org/content/repositories/maven-staging-493287f 5223d96/org/apache/maven/plugins/maven-plugins/13/ FWIW, the release plugin puked on this file because it found a cycle in the plugins even though I specified the -N flag, so I had to effectively finish the release by hand and missed the tags. I found the same problem in the shared one, it's fixed here: https://repository.apache.org/content/repositories/maven-staging-4932ea7 c147076/org/apache/maven/shared/maven-shared-components/11/maven-shared- components-11.pom -Original Message- From: Dennis Lundberg [mailto:denn...@apache.org] Sent: Friday, February 20, 2009 6:16 PM To: Maven Developers List Subject: Re: [vote] release asf/maven/maven-plugins/maven-shared poms ASF and Maven POMs are ok. +1 for those The scm section point to trunk for maven-plugins-13. It's the same in the staged POM. Still -1 I'm afraid The staged POM for shared also has an scm section that points to trunk. -1 Brian E. Fox wrote: Dennis, can you take another look and hopefully update your vote? -Original Message- From: Dennis Lundberg [mailto:denn...@apache.org] Sent: Thursday, February 19, 2009 4:15 PM To: Maven Developers List Subject: Re: [vote] release asf/maven/maven-plugins/maven-shared poms -1 on the maven-plugins POM after a quick glance. It still has a SNAPSHOT version on the tag http://svn.apache.org/viewvc/maven/plugins/tags/maven-plugins-13/pom.xml ?revision=745340view=markup Brian E. Fox wrote: New parents need to be released with the new distributionManagement sections pointed at repository.apache.org: Apache Pom Diffs: http://svn.apache.org/viewvc/maven/pom/tags/apache-5/pom.xml?r1=639584r 2=745325diff_format=h Staged at: https://repository.apache.org/content/repositories/staging-484a2aeeabd6a 7/ Diffs: http://svn.apache.org/viewvc/maven/pom/tags/maven-parent-11/pom.xml?r1=7 39516r2=745330diff_format=h http://svn.apache.org/viewvc/maven/plugins/tags/maven-plugins-13/pom.xml ?r1=728991r2=745340diff_format=h http://svn.apache.org/viewvc/maven/shared/tags/maven-shared-components-1 1/pom.xml?r1=739774r2=745352diff_format=h Maven Parent and Maven-Plugins Parent Staged at: https://repository.apache.org/content/repositories/maven-staging-484a998 2bc6221/ 72hrs, +1 -- Brian Fox Apache Maven PMC http://www.sonatype.com/people/author/brian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - 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: Release/staging question
Best to wait, I just fixed the issues you found, if you change your vote, we can release them, it's been 72hrs. -Original Message- From: Dennis Lundberg [mailto:denn...@apache.org] Sent: Friday, February 20, 2009 6:49 PM To: Maven Developers List Subject: Release/staging question Hi I'm about to stage the release of Doxia Sitetools 1.0. Do I have to wait for the new parent POMs to come through, and upgrade to those? Or can I use the deploy.altRepository in my release profile in settings.xml? If so, should I use the URL https://repository.apache.org/service/local/staging/deploy/maven2/ -- Dennis Lundberg - 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: [vote] release asf/maven/maven-plugins/maven-shared poms
Results: Binding +8: Brian, John, Jason, Arnaud, Brett, Vincent, Olivier, Dennis NB +2: Oleg, Mark Struberg I'll promote the poms. -Original Message- From: Dennis Lundberg [mailto:denn...@apache.org] Sent: Friday, February 20, 2009 7:08 PM To: Maven Developers List Subject: Re: [vote] release asf/maven/maven-plugins/maven-shared poms Yep, looks fine now +1 Brian E. Fox wrote: Grrr. It's fixed now: https://repository.apache.org/content/repositories/maven-staging-493287f 5223d96/org/apache/maven/plugins/maven-plugins/13/ FWIW, the release plugin puked on this file because it found a cycle in the plugins even though I specified the -N flag, so I had to effectively finish the release by hand and missed the tags. I found the same problem in the shared one, it's fixed here: https://repository.apache.org/content/repositories/maven-staging-4932ea7 c147076/org/apache/maven/shared/maven-shared-components/11/maven-shared- components-11.pom -Original Message- From: Dennis Lundberg [mailto:denn...@apache.org] Sent: Friday, February 20, 2009 6:16 PM To: Maven Developers List Subject: Re: [vote] release asf/maven/maven-plugins/maven-shared poms ASF and Maven POMs are ok. +1 for those The scm section point to trunk for maven-plugins-13. It's the same in the staged POM. Still -1 I'm afraid The staged POM for shared also has an scm section that points to trunk. -1 Brian E. Fox wrote: Dennis, can you take another look and hopefully update your vote? -Original Message- From: Dennis Lundberg [mailto:denn...@apache.org] Sent: Thursday, February 19, 2009 4:15 PM To: Maven Developers List Subject: Re: [vote] release asf/maven/maven-plugins/maven-shared poms -1 on the maven-plugins POM after a quick glance. It still has a SNAPSHOT version on the tag http://svn.apache.org/viewvc/maven/plugins/tags/maven-plugins-13/pom.xml ?revision=745340view=markup Brian E. Fox wrote: New parents need to be released with the new distributionManagement sections pointed at repository.apache.org: Apache Pom Diffs: http://svn.apache.org/viewvc/maven/pom/tags/apache-5/pom.xml?r1=639584r 2=745325diff_format=h Staged at: https://repository.apache.org/content/repositories/staging-484a2aeeabd6a 7/ Diffs: http://svn.apache.org/viewvc/maven/pom/tags/maven-parent-11/pom.xml?r1=7 39516r2=745330diff_format=h http://svn.apache.org/viewvc/maven/plugins/tags/maven-plugins-13/pom.xml ?r1=728991r2=745340diff_format=h http://svn.apache.org/viewvc/maven/shared/tags/maven-shared-components-1 1/pom.xml?r1=739774r2=745352diff_format=h Maven Parent and Maven-Plugins Parent Staged at: https://repository.apache.org/content/repositories/maven-staging-484a998 2bc6221/ 72hrs, +1 -- Brian Fox Apache Maven PMC http://www.sonatype.com/people/author/brian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - 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: Permission denied to access some artefacts on central repo
I'll just put a script to fix all the permissions? -Original Message- From: Arnaud HERITIER [mailto:aherit...@gmail.com] Sent: Thursday, February 19, 2009 5:33 PM To: Maven Developers List Subject: Re: Permission denied to access some artefacts on central repo Jason, I reported the issue in January but it was fixed by Brian http://www.nabble.com/Re:-403-errors-td21564203.html I think rsync will revert your fix :-( http://repo2.maven.org/maven2/hibernate/hibernate-tools/3.2.3.GA/hiberna te-tools-3.2.3.GA.jarreturns a 403 for example. Perhaps a rsync was done since you fix it. What can we do ? Is it a problem of setup in our rsync ? Arnuad On Thu, Feb 19, 2009 at 3:43 PM, Richard Chamberlain richard.chamberl...@caplin.com wrote: Entity manager 3.4.0 seems to be fixed, /hibernate/hibernate-tools/3.2.3.GA/** is still giving me a 403. Thanks, Richard -Original Message- From: Jason van Zyl [mailto:jvan...@sonatype.com] Sent: 19 February 2009 13:44 To: Maven Users List Subject: Re: Permission denied to access some artefacts on central repo Fixed. On 19-Feb-09, at 6:40 AM, Richard Chamberlain wrote: Hi, When browsing the central repo I get 403-forbidden on a few files. Is there a reason for this? http://repo1.maven.org/maven2/hibernate/hibernate-entitymanager/3.4.0.GA /hibernate-entitymanager-3.4.0.GA.jar http://repo1.maven.org/maven2/hibernate/hibernate-tools/3.2.3.GA/hiberna te-tools-3.2.3.GA.jar Thanks Richard Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com http://twitter.com/jvanzyl -- A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Arnaud - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: [vote] release asf/maven/maven-plugins/maven-shared poms
Somehow the tag is messed up, the actual file is ok: https://repository.apache.org/content/groups/staging/org/apache/maven/pl ugins/maven-plugins/13/maven-plugins-13.pom I'll fix the tag. -Original Message- From: Dennis Lundberg [mailto:denn...@apache.org] Sent: Thursday, February 19, 2009 4:15 PM To: Maven Developers List Subject: Re: [vote] release asf/maven/maven-plugins/maven-shared poms -1 on the maven-plugins POM after a quick glance. It still has a SNAPSHOT version on the tag http://svn.apache.org/viewvc/maven/plugins/tags/maven-plugins-13/pom.xml ?revision=745340view=markup Brian E. Fox wrote: New parents need to be released with the new distributionManagement sections pointed at repository.apache.org: Apache Pom Diffs: http://svn.apache.org/viewvc/maven/pom/tags/apache-5/pom.xml?r1=639584r 2=745325diff_format=h Staged at: https://repository.apache.org/content/repositories/staging-484a2aeeabd6a 7/ Diffs: http://svn.apache.org/viewvc/maven/pom/tags/maven-parent-11/pom.xml?r1=7 39516r2=745330diff_format=h http://svn.apache.org/viewvc/maven/plugins/tags/maven-plugins-13/pom.xml ?r1=728991r2=745340diff_format=h http://svn.apache.org/viewvc/maven/shared/tags/maven-shared-components-1 1/pom.xml?r1=739774r2=745352diff_format=h Maven Parent and Maven-Plugins Parent Staged at: https://repository.apache.org/content/repositories/maven-staging-484a998 2bc6221/ 72hrs, +1 -- Brian Fox Apache Maven PMC http://www.sonatype.com/people/author/brian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - 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: Permission denied to access some artefacts on central repo
I wish there was a way to see the actual rsync command, it must be pulling over the permissions? -Original Message- From: Arnaud HERITIER [mailto:aherit...@gmail.com] Sent: Thursday, February 19, 2009 6:04 PM To: Maven Developers List Subject: Re: Permission denied to access some artefacts on central repo which will be launched after each rsync ? it's a possibility if it's not too long to repair all rigths. On Thu, Feb 19, 2009 at 11:46 PM, Brian E. Fox bri...@reply.infinity.nuwrote: I'll just put a script to fix all the permissions? -Original Message- From: Arnaud HERITIER [mailto:aherit...@gmail.com] Sent: Thursday, February 19, 2009 5:33 PM To: Maven Developers List Subject: Re: Permission denied to access some artefacts on central repo Jason, I reported the issue in January but it was fixed by Brian http://www.nabble.com/Re:-403-errors-td21564203.html I think rsync will revert your fix :-( http://repo2.maven.org/maven2/hibernate/hibernate-tools/3.2.3.GA/hiberna te-tools-3.2.3.GA.jarreturnshttp://repo2.maven.org/maven2/hibernate/hib ernate-tools/3.2.3.GA/hiberna%0Ate-tools-3.2.3.GA.jarreturns a 403 for example. Perhaps a rsync was done since you fix it. What can we do ? Is it a problem of setup in our rsync ? Arnuad On Thu, Feb 19, 2009 at 3:43 PM, Richard Chamberlain richard.chamberl...@caplin.com wrote: Entity manager 3.4.0 seems to be fixed, /hibernate/hibernate-tools/3.2.3.GA/** is still giving me a 403. Thanks, Richard -Original Message- From: Jason van Zyl [mailto:jvan...@sonatype.com] Sent: 19 February 2009 13:44 To: Maven Users List Subject: Re: Permission denied to access some artefacts on central repo Fixed. On 19-Feb-09, at 6:40 AM, Richard Chamberlain wrote: Hi, When browsing the central repo I get 403-forbidden on a few files. Is there a reason for this? http://repo1.maven.org/maven2/hibernate/hibernate-entitymanager/3.4.0.GA /hibernate-entitymanager-3.4.0.GA.jar http://repo1.maven.org/maven2/hibernate/hibernate-tools/3.2.3.GA/hiberna te-tools-3.2.3.GA.jar Thanks Richard Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com http://twitter.com/jvanzyl -- A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Arnaud - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Arnaud - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: Permission denied to access some artefacts on central repo
It's fixed now. The problem was I fixed org/hibernate/* before not /hibernate. Anyone know why these same files exist in both paths? -Original Message- From: Brian E. Fox [mailto:bri...@reply.infinity.nu] Sent: Thursday, February 19, 2009 6:23 PM To: Maven Developers List Subject: RE: Permission denied to access some artefacts on central repo I wish there was a way to see the actual rsync command, it must be pulling over the permissions? -Original Message- From: Arnaud HERITIER [mailto:aherit...@gmail.com] Sent: Thursday, February 19, 2009 6:04 PM To: Maven Developers List Subject: Re: Permission denied to access some artefacts on central repo which will be launched after each rsync ? it's a possibility if it's not too long to repair all rigths. On Thu, Feb 19, 2009 at 11:46 PM, Brian E. Fox bri...@reply.infinity.nuwrote: I'll just put a script to fix all the permissions? -Original Message- From: Arnaud HERITIER [mailto:aherit...@gmail.com] Sent: Thursday, February 19, 2009 5:33 PM To: Maven Developers List Subject: Re: Permission denied to access some artefacts on central repo Jason, I reported the issue in January but it was fixed by Brian http://www.nabble.com/Re:-403-errors-td21564203.html I think rsync will revert your fix :-( http://repo2.maven.org/maven2/hibernate/hibernate-tools/3.2.3.GA/hiberna te-tools-3.2.3.GA.jarreturnshttp://repo2.maven.org/maven2/hibernate/hib ernate-tools/3.2.3.GA/hiberna%0Ate-tools-3.2.3.GA.jarreturns a 403 for example. Perhaps a rsync was done since you fix it. What can we do ? Is it a problem of setup in our rsync ? Arnuad On Thu, Feb 19, 2009 at 3:43 PM, Richard Chamberlain richard.chamberl...@caplin.com wrote: Entity manager 3.4.0 seems to be fixed, /hibernate/hibernate-tools/3.2.3.GA/** is still giving me a 403. Thanks, Richard -Original Message- From: Jason van Zyl [mailto:jvan...@sonatype.com] Sent: 19 February 2009 13:44 To: Maven Users List Subject: Re: Permission denied to access some artefacts on central repo Fixed. On 19-Feb-09, at 6:40 AM, Richard Chamberlain wrote: Hi, When browsing the central repo I get 403-forbidden on a few files. Is there a reason for this? http://repo1.maven.org/maven2/hibernate/hibernate-entitymanager/3.4.0.GA /hibernate-entitymanager-3.4.0.GA.jar http://repo1.maven.org/maven2/hibernate/hibernate-tools/3.2.3.GA/hiberna te-tools-3.2.3.GA.jar Thanks Richard Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com http://twitter.com/jvanzyl -- A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Arnaud - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Arnaud - 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: svn commit: r746002 - in /maven/components/trunk: maven-core/src/main/java/org/apache/maven/plugin/ maven-embedder/src/main/java/org/apache/maven/embedder/ maven-project-builder/ maven-project-bui
Why don't we just hookup checkstyle to maven?
-Original Message-
From: Hervé BOUTEMY [mailto:herve.bout...@free.fr]
Sent: Thursday, February 19, 2009 7:08 PM
To: dev@maven.apache.org
Subject: Re: svn commit: r746002 - in /maven/components/trunk:
maven-core/src/main/java/org/apache/maven/plugin/
maven-embedder/src/main/java/org/apache/maven/embedder/ maven-project-builder/
maven-project-builder/src/main/java/org/apache/maven/project/builder/ ma
Hi Shane,
There are a lot of coding style conventions problems in this commit:
- whitespace,
- implements/throws on a separate line,
+private String parentGroupId = null, parentArtifactId = null,
parentVersion = null, parentId = null, parentRelativePath;
each attribute should be declared on it own line
-import java.io.File;
-import java.io.IOException;
+import java.io.*;
no wildcard imports
+finally
+{
+if ( out != null )
+{
+out.close();
+}
+}
prefer IOUtil.close( out ) from plexus-utils, which has the necessary
try/catch to enforce safe code in any cases (I know this case is in-memory,
then not absolutely necessary)
Regards,
Hervé
Le jeudi 19 février 2009, sisb...@apache.org a écrit :
Author: sisbell
Date: Thu Feb 19 21:22:46 2009
New Revision: 746002
URL: http://svn.apache.org/viewvc?rev=746002view=rev
Log:
Refactored out more uses of modello and moved classes from maven-project to
maven-project-builder. Doing this so that maven-mercury will not have
direct dependency on modello or maven model.
[SNAP]
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r744288 - in /maven/pom/trunk: asf/pom.xml maven/pom.xml
As far as I know, I've been using it but haven't cleared my repo. If you browse it's only going to show stuff that has been proxied, not the entire contents of p.a.o. On 2/18/09 10:41 AM, Brett Porter br...@apache.org wrote: On 15/02/2009, at 2:05 AM, Brian E. Fox wrote: This is probably moreso for the repositories elements - there's a chance some projects will be referring to snapshots in both places. The current one is a group that is logically combining the old and new repos, there's no reason not to use the r.a.o group for any project instead of p.a.o since it is the only place that will have all snapshots. Is this working? I only see a few projects in there. I also see metadata from external stuff (opensymphony) which seems wrong. Thanks, Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - 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: svn commit: r744288 - in /maven/pom/trunk: asf/pom.xml maven/pom.xml
Seems to be proxying just fine: http://repository.apache.org/snapshots/org/apache/asyncweb/asyncweb-spri ng/maven-metadata.xml http://repository.apache.org/snapshots/org/apache/maven/maven-project-bu ilder/3.0-SNAPSHOT/maven-metadata.xml -Original Message- From: Brian E. Fox [mailto:bri...@reply.infinity.nu] Sent: Wednesday, February 18, 2009 1:52 PM To: Maven Developers List Subject: Re: svn commit: r744288 - in /maven/pom/trunk: asf/pom.xml maven/pom.xml As far as I know, I've been using it but haven't cleared my repo. If you browse it's only going to show stuff that has been proxied, not the entire contents of p.a.o. On 2/18/09 10:41 AM, Brett Porter br...@apache.org wrote: On 15/02/2009, at 2:05 AM, Brian E. Fox wrote: This is probably moreso for the repositories elements - there's a chance some projects will be referring to snapshots in both places. The current one is a group that is logically combining the old and new repos, there's no reason not to use the r.a.o group for any project instead of p.a.o since it is the only place that will have all snapshots. Is this working? I only see a few projects in there. I also see metadata from external stuff (opensymphony) which seems wrong. Thanks, Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - 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: svn commit: r744288 - in /maven/pom/trunk: asf/pom.xml maven/pom.xml
Just testing the wrapping problem I seem to have: http://repository.apache.org/snapshots/org/apache/asyncweb/asyncweb-spri ng/maven-metadata.xml -Original Message- From: Brian E. Fox [mailto:bri...@reply.infinity.nu] Sent: Wednesday, February 18, 2009 2:37 PM To: Maven Developers List Subject: RE: svn commit: r744288 - in /maven/pom/trunk: asf/pom.xml maven/pom.xml Seems to be proxying just fine: http://repository.apache.org/snapshots/org/apache/asyncweb/asyncweb-spri ng/maven-metadata.xml http://repository.apache.org/snapshots/org/apache/maven/maven-project-bu ilder/3.0-SNAPSHOT/maven-metadata.xml -Original Message- From: Brian E. Fox [mailto:bri...@reply.infinity.nu] Sent: Wednesday, February 18, 2009 1:52 PM To: Maven Developers List Subject: Re: svn commit: r744288 - in /maven/pom/trunk: asf/pom.xml maven/pom.xml As far as I know, I've been using it but haven't cleared my repo. If you browse it's only going to show stuff that has been proxied, not the entire contents of p.a.o. On 2/18/09 10:41 AM, Brett Porter br...@apache.org wrote: On 15/02/2009, at 2:05 AM, Brian E. Fox wrote: This is probably moreso for the repositories elements - there's a chance some projects will be referring to snapshots in both places. The current one is a group that is logically combining the old and new repos, there's no reason not to use the r.a.o group for any project instead of p.a.o since it is the only place that will have all snapshots. Is this working? I only see a few projects in there. I also see metadata from external stuff (opensymphony) which seems wrong. Thanks, Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 2.1.0 Plans (a proposal of sorts)
Sorry, I only read the first part of your email. I think the controlling the threads with a setting is a good idea. I don't see any point in doing another milestone release. The current code is as stable as 2.0.9/10 yet noone can use it because it's a milestone. It serves us no point because we don't get any feedback. The original intent of the milestones was to give the team targets to work towards quickly to get 2.1 out. Since no work was made towards those targets in the last 6 months, we should just cut the release and move on. When a feature appears and is ready with tests, then we can include it and release it. The nature of the oss developent timeline is too haphazard to fully schedule releases like we tried and in the meantime good code sits unused. I think we should fix the minimum bugs that are regressions, clean up what is already there and do a 2.1.0 release asap. Everything else can be 2.2 (features) or 2.1.1 (bugs) On 2/14/09 7:22 AM, Brett Porter br...@apache.org wrote: So, there seems to be some agreement. However, I've come back from underground and now there are *two* snapshots on trunk. I'm already spending valentine's day alone, so I didn't really need another reason to curl up in the corner and cry :) I would really like to pull an M2 release in the next week with the stuff that is already there. John, what do you think? Thanks, Brett On 10/02/2009, at 9:43 AM, Brian E. Fox wrote: Yep good idea. -Original Message- From: Brett Porter [mailto:br...@porterclan.net] On Behalf Of Brett Porter Sent: Monday, February 09, 2009 7:44 PM To: Maven Developers List Subject: Re: Maven 2.1.0 Plans (a proposal of sorts) I'm +1 for including it and providing an opt-out switch to turn it off. If we can make that switch stick permanently via the settings.xml, so much the better. +1 (even better, configure number of parallel threads, just set it to 1 to turn it off). On 09/02/2009, at 11:18 PM, John Casey wrote: I'll rearrange the JIRA versions today, then...it looks like we're all in agreement about moving directly toward 2.1.0 generally. Let's slow down a bit... We are totally in agreement to moving towards 2.1.0 generally, and the list in JIRA now reflects that. However, I don't see why we'd cancel a milestone release when there's already been good progress. I was all ready to roll that once the remaining snapshot was released (I've been working on it since December since you said you didn't have time), but now JIRA has been transformed and any release is 23 issues (I'm guessing probably 2 weeks minimum) away. Then the RC cycle will be more brutal. Why couldn't we stick to the plan as it was yesterday? Same issues, more intermediate releases. - Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - 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 -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - 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: [VOTE] Release Maven Doxia version 1.0
I'll copy the artifacts to a staging repo for you tonight and then you can promote it when the vote is closed. On 2/17/09 1:25 PM, Dennis Lundberg denn...@apache.org wrote: +1 from me Dennis Lundberg wrote: Hi, (resending due to SMTP-server problems) The time has finally come to release Doxia 1.0. For more info on the relationship to plugins and other components, see the Doxia Release Plan at http://docs.codehaus.org/display/MAVEN/Doxia+Release+Plan We've solved 1 issue: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10780styleName=Ht mlversion=14834 There are still lots of issues left in JIRA, but they will go into later versions: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10780stat us=1 Staging repo: http://people.apache.org/~dennisl/staging-repo/doxia/ Staging site: http://maven.apache.org/doxia/doxia-1.0.x/staging/ Well, at least it should be there, but I'm bitten by http://jira.codehaus.org/browse/MSITE-384 so I can't deploy the full staging site from my Windows box. I tried to deploy it using Ubuntu running in Virtual Box, but that hasn't worked out completely either. If someone with a non-Windows box could check out https://svn.apache.org/repos/asf/maven/doxia/doxia/tags/doxia-1.0/ and the run 'mvn package site:stage-deploy' on it I'd sure appreciate it. Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: Maven 2.1.0 Plans (a proposal of sorts)
Well lets get a release then so we have something to try. It's been a waiting game it seems so far. If there's a release we can integrate soon enough into the cycle, then we have a chance of detecting and fixing any issues. It always seems to come up far too late in the cycle to do anything about it. So I say if we want to get it included, then let's have a release right away -Original Message- From: Dennis Lundberg [mailto:denn...@apache.org] Sent: Tuesday, February 17, 2009 6:50 PM To: Maven Developers List Subject: Re: Maven 2.1.0 Plans (a proposal of sorts) I'm undecided about what version number to use, and leave that decision to others. One issue that I strongly feel needs to go into 2.1.0 final is MNG-3602, the inclusion of Doxia 1.1 into the core. According to the release plan for Doxia [1], Lukas had agreed to release Doxia 1.1. If he's not available to do it I can do it. [1] http://docs.codehaus.org/display/MAVEN/Doxia+Release+Plan John Casey wrote: I fully agree with Brian about the version naming for the next release. Given its track record over the last 6 months, using -M1 for the last release crippled it unfairly in the public view; it's at least as stable as 2.0.9, even with the problems we had concerning wagon 1.0-beta-4. IMO, there is absolutely no reason to do another milestone release. We should be moving toward 2.1.0 final, resolving the worst regressions and the most watched/voted-for issues before doing so. Currently, we have what looks like 4 major issues still unresolved in the 2.1.0 bucket, judging from the votes. Three of these are in progress, I think. I know I'm working on MNG-3057, for instance, and I thought Oleg was working on MNG-553 still...Brett, are you still working on MNG-3379, and did you plan to finish that before we release 2.1.0? The fourth top issue seems on the face of it to be based on a common misunderstanding about how profiles are triggered and applied...probably more of a documentation/education task than anything else. Beyond that, I'm alright releasing 2.1.0 final provided we can be sure that the wagon version we're using is stable. I seem to remember an issue coming up shortly after the release of 2.1.0-M1 related to one of the new Wagon implementations - WebDAV, maybe? I'm having some trouble remembering/finding that issue in my gmail, but we need to make sure that doesn't get left out of this release. If it means rolling back to an older wagon version, then let's do that. I'm not in favor of releasing another milestone of 2.1.0 at this point. Sure, we should have done more work to execute that release plan last fall. I for one got very sidetracked putting together a build farm that we can use to help verify future releases of Maven proactively. In any case, I think the value of milestone releases is greatly diminished at this point, and we need to get serious about 2.1.0 final. We can push off the non-critical JIRAs currently slated for 2.1.0 into the 2.1.1 bucket, and get on with it once we have these four dealt with. -john Brett Porter wrote: So, there seems to be some agreement. However, I've come back from underground and now there are *two* snapshots on trunk. I'm already spending valentine's day alone, so I didn't really need another reason to curl up in the corner and cry :) I would really like to pull an M2 release in the next week with the stuff that is already there. John, what do you think? Thanks, Brett On 10/02/2009, at 9:43 AM, Brian E. Fox wrote: Yep good idea. -Original Message- From: Brett Porter [mailto:br...@porterclan.net] On Behalf Of Brett Porter Sent: Monday, February 09, 2009 7:44 PM To: Maven Developers List Subject: Re: Maven 2.1.0 Plans (a proposal of sorts) I'm +1 for including it and providing an opt-out switch to turn it off. If we can make that switch stick permanently via the settings.xml, so much the better. +1 (even better, configure number of parallel threads, just set it to 1 to turn it off). On 09/02/2009, at 11:18 PM, John Casey wrote: I'll rearrange the JIRA versions today, then...it looks like we're all in agreement about moving directly toward 2.1.0 generally. Let's slow down a bit... We are totally in agreement to moving towards 2.1.0 generally, and the list in JIRA now reflects that. However, I don't see why we'd cancel a milestone release when there's already been good progress. I was all ready to roll that once the remaining snapshot was released (I've been working on it since December since you said you didn't have time), but now JIRA has been transformed and any release is 23 issues (I'm guessing probably 2 weeks minimum) away. Then the RC cycle will be more brutal. Why couldn't we stick to the plan as it was yesterday? Same issues, more intermediate releases. - Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter
RE: [VOTE] Release Maven Doxia version 1.0
The new staging repo location is: https://repository.apache.org/content/repositories/maven-staging-4847e34 062fc70/ Just double check that everything looks ok to you. -Original Message- From: Dennis Lundberg [mailto:denn...@apache.org] Sent: Tuesday, February 17, 2009 2:26 PM To: Maven Developers List Subject: Re: [VOTE] Release Maven Doxia version 1.0 Thanks Brian. I'm reading up on the new repo as we speak. Brian E. Fox wrote: I'll copy the artifacts to a staging repo for you tonight and then you can promote it when the vote is closed. On 2/17/09 1:25 PM, Dennis Lundberg denn...@apache.org wrote: +1 from me Dennis Lundberg wrote: Hi, (resending due to SMTP-server problems) The time has finally come to release Doxia 1.0. For more info on the relationship to plugins and other components, see the Doxia Release Plan at http://docs.codehaus.org/display/MAVEN/Doxia+Release+Plan We've solved 1 issue: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10780styleNa me=Ht mlversion=14834 There are still lots of issues left in JIRA, but they will go into later versions: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10780 stat us=1 Staging repo: http://people.apache.org/~dennisl/staging-repo/doxia/ Staging site: http://maven.apache.org/doxia/doxia-1.0.x/staging/ Well, at least it should be there, but I'm bitten by http://jira.codehaus.org/browse/MSITE-384 so I can't deploy the full staging site from my Windows box. I tried to deploy it using Ubuntu running in Virtual Box, but that hasn't worked out completely either. If someone with a non-Windows box could check out https://svn.apache.org/repos/asf/maven/doxia/doxia/tags/doxia-1.0/ and the run 'mvn package site:stage-deploy' on it I'd sure appreciate it. Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - 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
[vote] release asf/maven/maven-plugins/maven-shared poms
New parents need to be released with the new distributionManagement sections pointed at repository.apache.org: Apache Pom Diffs: http://svn.apache.org/viewvc/maven/pom/tags/apache-5/pom.xml?r1=639584r 2=745325diff_format=h Staged at: https://repository.apache.org/content/repositories/staging-484a2aeeabd6a 7/ Diffs: http://svn.apache.org/viewvc/maven/pom/tags/maven-parent-11/pom.xml?r1=7 39516r2=745330diff_format=h http://svn.apache.org/viewvc/maven/plugins/tags/maven-plugins-13/pom.xml ?r1=728991r2=745340diff_format=h http://svn.apache.org/viewvc/maven/shared/tags/maven-shared-components-1 1/pom.xml?r1=739774r2=745352diff_format=h Maven Parent and Maven-Plugins Parent Staged at: https://repository.apache.org/content/repositories/maven-staging-484a998 2bc6221/ 72hrs, +1 -- Brian Fox Apache Maven PMC http://www.sonatype.com/people/author/brian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: [PROPOSAL] Start using bugtraq in our subversion repository
Nope it's just another one of the bugtraq options that can take a regex. Been a few years since I looked at it so I don't recall the exact setting. -Original Message- From: Dennis Lundberg [mailto:denn...@apache.org] Sent: Sunday, February 15, 2009 9:48 AM To: Maven Developers List Subject: Re: [PROPOSAL] Start using bugtraq in our subversion repository I wasn't aware that you could use it as a reminder. Would that require some pre-commit hooks to work? Brian E. Fox wrote: You can regexp the comment to make sure every comment has an issue in it, and you can tweak the dialog so it has a prompt for the issue. Otherwise it doesn't do much else that I recall...it's just an aid/reminder to get the issue in the comment. -Original Message- From: Benjamin Bentmann [mailto:benjamin.bentm...@udo.edu] Sent: Thursday, February 12, 2009 12:01 PM To: Maven Developers List Subject: Re: [PROPOSAL] Start using bugtraq in our subversion repository Dennis Lundberg wrote: I would like to start using bugtraq [1] in our subversion repositories. If we set a bunch of svn properties in the repository, then version control tools can link to issues in JIRA. +1. Will it automatically parse [MNG-] or does a committer need to take special steps? Benjamin - 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 -- Dennis Lundberg - 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: [vote] release maven 2.0.10
Vote results: Binding: +10 -- Brian, Jason, Olivier, John, Arnaud, Ben, Vincent, Stephane, Herve, Brett Non Binding: +4 -- Raphael, Oleg, Henry, Mark The vote is successful, I will promote the artifacts and produce the release notes and setup the distribution. -Original Message- From: Brian E. Fox [mailto:bri...@reply.infinity.nu] Sent: Monday, February 09, 2009 11:32 PM To: Maven Developers List Subject: [vote] release maven 2.0.10 It's finally time after 8 Release Candidates: Issues fixed: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14112styleName =HtmlprojectId=10500Create=Create NOTE: The urls below are using a self-signed certificate. There is an issue requesting an official cert at: https://issues.apache.org/jira/browse/INFRA-1891 Staging repo: https://repository.apache.org/content/repositories/maven-staging-45dca90 660cc84/ Binaries are at: https://repository.apache.org/content/repositories/maven-staging-45dca90 660cc84/org/apache/maven/apache-maven/2.0.10/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Brian Fox Apache Maven PMC http://www.sonatype.com/people/author/brian/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: svn commit: r744288 - in /maven/pom/trunk: asf/pom.xml maven/pom.xml
Isn't modifying the ASF POM premature? I'm not sure if other projects are using the POM or not (they should be), but they may not be using this system. There are a few other projects looking to use the new structure and this would make it easier for them to do. Projects not using the new repo can continue to use the 4.x versions of the pom. There's no requirement for them to have the last parent for these purposes. It's either that or we fork the parent. I don't think it's a great idea to require every project to overload the same things over and over. + pluginRepositories +pluginRepository + idapache.snapshots/id + nameApache Snapshot Repository/name + urlhttp://repository.apache.org/content/groups/snapshots// url + releases +enabledfalse/enabled + /releases +/pluginRepository + /pluginRepositories Isn't this badness for pre-Maven 2.0.9 users? It only applies to building our stuff, which often requires plugin snapshots anyway. It shouldn't hurt their builds, unless I'm not thinking of something. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: svn commit: r744288 - in /maven/pom/trunk: asf/pom.xml maven/pom.xml
I do like the hook to get people to actually use the parent POM, but at the same time it feels back to front (We probably don't need another pom release, but if we did that would then have to be a fork...). What about having them use the properties as their distMgmt settings for now? We can put a property in the release section as well that can be overridden I guess. Having consistent overridable properties ASF wide is important as it more easily lets users build and deploy versions internally without hacking the poms. This is probably moreso for the repositories elements - there's a chance some projects will be referring to snapshots in both places. The current one is a group that is logically combining the old and new repos, there's no reason not to use the r.a.o group for any project instead of p.a.o since it is the only place that will have all snapshots. + pluginRepositories +pluginRepository + idapache.snapshots/id + nameApache Snapshot Repository/name + urlhttp://repository.apache.org/content/groups/snapshots// url + releases +enabledfalse/enabled + /releases +/pluginRepository + /pluginRepositories Isn't this badness for pre-Maven 2.0.9 users? It only applies to building our stuff, which often requires plugin snapshots anyway. It shouldn't hurt their builds, unless I'm not thinking of something. If they haven't given a version for a plugin that is hosted at Apache, they start getting snapshots resolved for it. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - 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: [vote] release maven 2.0.10
Yep, I'll double check it before I call the vote and push the site (probably tonight or tomorrow) and update it appropriately. -Original Message- From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] On Behalf Of Paul Benedict Sent: Saturday, February 14, 2009 3:51 PM To: Maven Developers List Subject: Re: [vote] release maven 2.0.10 If the --showVersion patch wasn't applied to 2.0.10, can someone check? I'd like to bump the ticket to 2.0.11 so it does not appear in this version's release notes before it gets published. Paul On Sat, Feb 14, 2009 at 7:03 AM, Brett Porter br...@apache.org wrote: ++1 I ran the integration tests as confirmation. On 10/02/2009, at 12:32 PM, Brian E. Fox wrote: It's finally time after 8 Release Candidates: Issues fixed: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14112styleName =HtmlprojectId=10500Create=Create NOTE: The urls below are using a self-signed certificate. There is an issue requesting an official cert at: https://issues.apache.org/jira/browse/INFRA-1891 Staging repo: https://repository.apache.org/content/repositories/maven-staging-45dca90 660cc84/ Binaries are at: https://repository.apache.org/content/repositories/maven-staging-45dca90 660cc84/org/apache/maven/apache-maven/2.0.10/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Brian Fox Apache Maven PMC http://www.sonatype.com/people/author/brian/ -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - 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: [VOTE] Release mercury-1.0-alpha-5
+1 -Original Message- From: Oleg Gusakov [mailto:oleg.subscripti...@gmail.com] Sent: Wednesday, February 11, 2009 12:58 AM To: Maven Developers List Subject: [VOTE] Release mercury-1.0-alpha-5 Hi, Main reason for this release - bug fixes. A lot of testing done on the repository side, IT coverage on repository components is 60-70 % We solved 11 issues: http://jira.codehaus.org/browse/MERCURY/fixforversion/14955 Staging repo: https://repository.apache.org/content/repositories/maven-staging-4630e65601be12/ Staging site: published and will be synced to: http://maven.apache.org/mercury/staging/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: [VOTE] Release Maven Doxia version 1.0
It must replace the old process because we can't accurately sync to central the same artifacts from two places. The metadata will get hosed. Go ahead with the vote, and then I'll do the promotion via Nexus for you. -Original Message- From: Dennis Lundberg [mailto:denn...@apache.org] Sent: Thursday, February 12, 2009 11:18 AM To: Maven Developers List Subject: Re: [VOTE] Release Maven Doxia version 1.0 Sorry, but I haven't followed the threads about the Nexus repo as much as would have liked. Are you saying that it has completely replaced the old file based release repo at ASF? And that the only way to release an ASF artifact is through the Nexus instance? If it's possible I'd like to continue this release with the artifacts that were already built. I've been through hell and back already trying to get this release out the door. Brian E. Fox wrote: Dennis, your call. If you want to respin the release with the new distMgt and stage it to Nexus, that will work. Otherwise, I'll have to manually import your existing artifacts to the new system so they get merged correctly. I don't mind either way since I'm still working on getting the poms fixed up. -Original Message- From: Jason van Zyl [mailto:jvan...@sonatype.com] Sent: Wednesday, February 11, 2009 8:37 PM To: Maven Developers List Subject: Re: [VOTE] Release Maven Doxia version 1.0 Brian has moved everything over to the Nexus instance and we can't manage artifact in two separate repositories. Brian wrote up full documentation and staging to Nexus is pretty easy, and then promoting is dead simple. On 11-Feb-09, at 5:56 PM, Dennis Lundberg wrote: Hi, (resending due to SMTP-server problems) The time has finally come to release Doxia 1.0. For more info on the relationship to plugins and other components, see the Doxia Release Plan at http://docs.codehaus.org/display/MAVEN/Doxia+Release+Plan We've solved 1 issue: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10780styleNa me=Htmlversion=14834 There are still lots of issues left in JIRA, but they will go into later versions: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10780 status=1 Staging repo: http://people.apache.org/~dennisl/staging-repo/doxia/ Staging site: http://maven.apache.org/doxia/doxia-1.0.x/staging/ Well, at least it should be there, but I'm bitten by http://jira.codehaus.org/browse/MSITE-384 so I can't deploy the full staging site from my Windows box. I tried to deploy it using Ubuntu running in Virtual Box, but that hasn't worked out completely either. If someone with a non-Windows box could check out https://svn.apache.org/repos/asf/maven/doxia/doxia/tags/doxia-1.0/ and the run 'mvn package site:stage-deploy' on it I'd sure appreciate it. Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org 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: 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 -- Dennis Lundberg - 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: [PROPOSAL] Start using bugtraq in our subversion repository
You can regexp the comment to make sure every comment has an issue in it, and you can tweak the dialog so it has a prompt for the issue. Otherwise it doesn't do much else that I recall...it's just an aid/reminder to get the issue in the comment. -Original Message- From: Benjamin Bentmann [mailto:benjamin.bentm...@udo.edu] Sent: Thursday, February 12, 2009 12:01 PM To: Maven Developers List Subject: Re: [PROPOSAL] Start using bugtraq in our subversion repository Dennis Lundberg wrote: I would like to start using bugtraq [1] in our subversion repositories. If we set a bunch of svn properties in the repository, then version control tools can link to issues in JIRA. +1. Will it automatically parse [MNG-] or does a committer need to take special steps? Benjamin - 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: [PROPOSAL] Start using bugtraq in our subversion repository
Doesn't jira already scrape the svn repo for the tickets? I used the bugtraq stuff before and seem to recall that it only helps for clients that pay attention to it, so it's not an enforcement tool. That said, it does make life a little easier if you do have a client that obeys it. -Original Message- From: Dennis Lundberg [mailto:denn...@apache.org] Sent: Wednesday, February 11, 2009 5:52 PM To: Maven Developers List Subject: [PROPOSAL] Start using bugtraq in our subversion repository Hi I would like to start using bugtraq [1] in our subversion repositories. If we set a bunch of svn properties in the repository, then version control tools can link to issues in JIRA. What do you think? [1] http://tortoisesvn.net/issuetracker_integration -- Dennis Lundberg - 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
