Re: [VOTE] Release Maven Enforcer version 1.3
+1 2013/6/22 Robert Scholte : > Hi, > > We solved 15 issues: > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530&version=19011 > > There are still a couple of issues left in JIRA: > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11530&status=1 > > Staging repo: > https://repository.apache.org/content/repositories/maven-056/ > https://repository.apache.org/content/repositories/maven-056/org/apache/maven/enforcer/enforcer/1.3/enforcer-1.3-source-release.zip > > Staging site: > http://maven.apache.org/enforcer-archives/enforcer-LATEST/ > > 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 > -- Olivier Lamy Ecetera: http://ecetera.com.au 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
Re: Poposed Sandbox plugins - digest and gpg:signfiles
We can work a bit with those snapshots for review etc.. Then promote to non snapshot path and release it. BTW if you prefer move those plugins to mojo@codehaus svn it's possible too. 2013/6/23 sebb : > On 23 June 2013 01:00, Olivier Lamy wrote: >> 2013/6/23 sebb : >>> Also, is there a Sandbox repo where the plugins can be deployed for testing? >>> Or is it up to users to checkout the source and install the plugins locally? >> >> We can deploy snapshots to repository.a.o > > OK but what about non-snapshot versions? > Obviously they cannot be published to the Maven Central repo, but is > there a local repo like Codehaus have? > >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> >> >> -- >> Olivier Lamy >> Ecetera: http://ecetera.com.au >> 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 > -- Olivier Lamy Ecetera: http://ecetera.com.au 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
Re: Poposed Sandbox plugins - digest and gpg:signfiles
On 23 June 2013 01:00, Olivier Lamy wrote: > 2013/6/23 sebb : >> Also, is there a Sandbox repo where the plugins can be deployed for testing? >> Or is it up to users to checkout the source and install the plugins locally? > > We can deploy snapshots to repository.a.o OK but what about non-snapshot versions? Obviously they cannot be published to the Maven Central repo, but is there a local repo like Codehaus have? >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > > > -- > Olivier Lamy > Ecetera: http://ecetera.com.au > 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: Poposed Sandbox plugins - digest and gpg:signfiles
2013/6/23 sebb : > I've just been told about the Maven Sandbox, which seems like it might > be a better location for two general purpose plugins that are > currently being developed at Apache Commons. > > Digest > The digest plugin is a simple plugin that can generate hashes > (currently just MD5 and SHA1) for any files specified via > includes/excludes (or on command-line). > Although it's possible to use Antrun to create the hashes, it's a bit > awkward to configure. > The plugin could be extended to check digests as well, and of course > to generate other digest types. > I'm hoping it might be generally useful. > > Gpg-signfiles > This is an extension of the Maven Gpg Plugin which can sign arbitrary > files, not just ones attached to the project > I'm hoping it might be merged with the existing Gpg plugin one day; > having the code in the sandbox should make it easier for other Maven > devs to help. > > I propose creating the following directories under > https://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins > > maven-digest-plugin > maven-gpgsignfiles-plugin > > Any objections? Just do it! > > Also, is there a Sandbox repo where the plugins can be deployed for testing? > Or is it up to users to checkout the source and install the plugins locally? We can deploy snapshots to repository.a.o > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Olivier Lamy Ecetera: http://ecetera.com.au 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
Re: [VOTE] Release Maven Enforcer version 1.3
+1 (non-binding) tested with two homegrown plugins, the extra-enforcer-rules and one small multi-module project. Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ On Sat, Jun 22, 2013 at 2:26 PM, Robert Scholte wrote: > Hi, > > We solved 15 issues: > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530&version=19011 > > There are still a couple of issues left in JIRA: > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11530&status=1 > > Staging repo: > https://repository.apache.org/content/repositories/maven-056/ > https://repository.apache.org/content/repositories/maven-056/org/apache/maven/enforcer/enforcer/1.3/enforcer-1.3-source-release.zip > > Staging site: > http://maven.apache.org/enforcer-archives/enforcer-LATEST/ > > 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
Poposed Sandbox plugins - digest and gpg:signfiles
I've just been told about the Maven Sandbox, which seems like it might be a better location for two general purpose plugins that are currently being developed at Apache Commons. Digest The digest plugin is a simple plugin that can generate hashes (currently just MD5 and SHA1) for any files specified via includes/excludes (or on command-line). Although it's possible to use Antrun to create the hashes, it's a bit awkward to configure. The plugin could be extended to check digests as well, and of course to generate other digest types. I'm hoping it might be generally useful. Gpg-signfiles This is an extension of the Maven Gpg Plugin which can sign arbitrary files, not just ones attached to the project I'm hoping it might be merged with the existing Gpg plugin one day; having the code in the sandbox should make it easier for other Maven devs to help. I propose creating the following directories under https://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins maven-digest-plugin maven-gpgsignfiles-plugin Any objections? Also, is there a Sandbox repo where the plugins can be deployed for testing? Or is it up to users to checkout the source and install the plugins locally? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3.1.0-beta-1
OK, thanks for the clarification. Vincent 2013/6/22 Jason van Zyl : > > On Jun 21, 2013, at 11:48 PM, Vincent Latombe > wrote: > >> Hello, >> >> I have a question about the alpha-1 release. I see that Aether has >> been updated to 0.9.0 M2. >> Does it implies that issue MNG-2802 (Concurrent-safe access to local >> Maven repository) is now implemented ? >> > > No, it does not. > >> If this is the case, then IMHO this should be mentioned, even >> highlighted in the release notes. I think this kind of improvement is >> very expected for all people doing CI, as this would allow a major >> speed up and reduce storage for local repositories in this kind of >> environment. >> >> Cheers, >> >> Vincent >> >> >> 2013/6/21 Jörg Schaible >>> >>> Hi Jason, >>> >>> first, thanks that you actually take your time to look into it! >>> >>> Jason van Zyl wrote: >>> I unpacked your example and ran your preparation script and it fails in 2.2.1 as well: https://gist.github.com/jvanzyl/5824206 >>> >>> The submodules are independent projects, you have to run "clean install". >>> See the following session (I have modified the POMs of the children by >>> adding a "" element, the original example is now ~2 years >>> old): >>> >>> https://gist.github.com/joehni/6aa8516bd5408144ec53 >>> >>> Note, that after a successful run with M221, the build with M3x will no >>> longer fail, but pack stale snapshots. To raise an error, you have to clean >>> the repo from snapshots in /bugs/maven. >>> What's the overall usecase? You have a build with snapshots and you find you need to go back to a release so you lock down to a previous release and want to use that? >>> >>> The final distribution of our product or projects typically consists of >>> hundreds of artifacts, where most of them have individual release cycles. In >>> the HEAD revision those are linked in a nested directory structure using >>> "builder POMs" i.e. POMs that have only modules declared, but get never >>> released themselves (like the POM in the root of the example). The versions >>> of the individual artifact are managed in a shared parent POM. In HEAD those >>> are typically all snapshot versions. >>> >>> This changes after a major release of the overall product, then all those >>> versions become final, the shared parent is released first followed by all >>> other artifacts in dependency order using this released parent. This works >>> all fine. >>> >>> Now we get into maintenance mode of that major release. Due to the >>> independence of the artifacts we have to branch only the affected projects >>> in case of bugs. Say we have JAR artifacts JAR-A to JAR-Z and we develop bug >>> fixes for JAR-C and JAR-S. This means we branch the shared parent, set JAR-C >>> and JAR-S to snapshot and also the artifacts that will assemble those to two >>> jars, say WAR-X and DIST-ZIP. Then we create a builder for the maintenance >>> branch that contains those jars, the war and the distribution zip as module. >>> Building this we should get a war that contains JAR-C and JAR-S as snapshot >>> and all the others as release and the distribution contains the affected >>> WAR-X as snapshot and all other stuff as released version - the perfect >>> situation to test the fix. >>> >>> Unfortunately M3 fails here, because it is under some circumstance not able >>> to calculate the proper build order (maybe it does no longer take attached >>> snapshot artifacts into account ?!?) and will either pack a stale snapshot >>> from the local repository or fail, because the snapshot is built at a later >>> time. >>> If you want to iteratively work on it together put it in a github repo. >>> >>> If you bear with me, may day-to-day work is with svn only and my learning >>> curve with git/github is still steep, e.g. I did not know about gists, so I >>> already learned something new. >>> >>> Cheers and thanks for your time, >>> Jörg >>> >>> >>> >>> - >>> 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 & CTO, Sonatype > 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: Maven 3.1.0-beta-1
On Jun 21, 2013, at 11:48 PM, Vincent Latombe wrote: > Hello, > > I have a question about the alpha-1 release. I see that Aether has > been updated to 0.9.0 M2. > Does it implies that issue MNG-2802 (Concurrent-safe access to local > Maven repository) is now implemented ? > No, it does not. > If this is the case, then IMHO this should be mentioned, even > highlighted in the release notes. I think this kind of improvement is > very expected for all people doing CI, as this would allow a major > speed up and reduce storage for local repositories in this kind of > environment. > > Cheers, > > Vincent > > > 2013/6/21 Jörg Schaible >> >> Hi Jason, >> >> first, thanks that you actually take your time to look into it! >> >> Jason van Zyl wrote: >> >>> I unpacked your example and ran your preparation script and it fails in >>> 2.2.1 as well: >>> >>> https://gist.github.com/jvanzyl/5824206 >> >> The submodules are independent projects, you have to run "clean install". >> See the following session (I have modified the POMs of the children by >> adding a "" element, the original example is now ~2 years >> old): >> >> https://gist.github.com/joehni/6aa8516bd5408144ec53 >> >> Note, that after a successful run with M221, the build with M3x will no >> longer fail, but pack stale snapshots. To raise an error, you have to clean >> the repo from snapshots in /bugs/maven. >> >>> What's the overall usecase? You have a build with snapshots and you find >>> you need to go back to a release so you lock down to a previous release >>> and want to use that? >> >> The final distribution of our product or projects typically consists of >> hundreds of artifacts, where most of them have individual release cycles. In >> the HEAD revision those are linked in a nested directory structure using >> "builder POMs" i.e. POMs that have only modules declared, but get never >> released themselves (like the POM in the root of the example). The versions >> of the individual artifact are managed in a shared parent POM. In HEAD those >> are typically all snapshot versions. >> >> This changes after a major release of the overall product, then all those >> versions become final, the shared parent is released first followed by all >> other artifacts in dependency order using this released parent. This works >> all fine. >> >> Now we get into maintenance mode of that major release. Due to the >> independence of the artifacts we have to branch only the affected projects >> in case of bugs. Say we have JAR artifacts JAR-A to JAR-Z and we develop bug >> fixes for JAR-C and JAR-S. This means we branch the shared parent, set JAR-C >> and JAR-S to snapshot and also the artifacts that will assemble those to two >> jars, say WAR-X and DIST-ZIP. Then we create a builder for the maintenance >> branch that contains those jars, the war and the distribution zip as module. >> Building this we should get a war that contains JAR-C and JAR-S as snapshot >> and all the others as release and the distribution contains the affected >> WAR-X as snapshot and all other stuff as released version - the perfect >> situation to test the fix. >> >> Unfortunately M3 fails here, because it is under some circumstance not able >> to calculate the proper build order (maybe it does no longer take attached >> snapshot artifacts into account ?!?) and will either pack a stale snapshot >> from the local repository or fail, because the snapshot is built at a later >> time. >> >>> If you want to iteratively work on it together put it in a github repo. >> >> If you bear with me, may day-to-day work is with svn only and my learning >> curve with git/github is still steep, e.g. I did not know about gists, so I >> already learned something new. >> >> Cheers and thanks for your time, >> Jörg >> >> >> >> - >> 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 & CTO, Sonatype 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
[VOTE] Release Maven Enforcer version 1.3
Hi, We solved 15 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530&version=19011 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11530&status=1 Staging repo: https://repository.apache.org/content/repositories/maven-056/ https://repository.apache.org/content/repositories/maven-056/org/apache/maven/enforcer/enforcer/1.3/enforcer-1.3-source-release.zip Staging site: http://maven.apache.org/enforcer-archives/enforcer-LATEST/ 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
