Re: [VOTE] Release Apache Maven 3.0-beta-3
-1 - I'm getting NullPointerExceptions with the aether in todays current nightly build when doing releases. https://gist.github.com/8ac6e71ad49cf8928549 Raised as http://jira.codehaus.org/browse/MNG-4779 -- Pull me down under... On Thu, Aug 26, 2010 at 2:59 PM, Oleg Gusakov wrote: > +1 > > 20-some module project with AspectJ & Terracotta - no issues. > > > On 8/25/10 4:36 PM, Benjamin Bentmann wrote: > >> Hi, >> >> apart from another few regression fixes, this release includes Guice and >> Aether [0] and shall help to get some more community testing on these new >> components. Overall, we solved 16 issues: >> >> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=16681 >> >> There are still a couple of issues left in JIRA: >> >> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&status=1 >> >> Staging repo: >> https://repository.apache.org/content/repositories/maven-146/ >> >> Staged source and binary distros: >> >> https://repository.apache.org/content/repositories/maven-146/org/apache/maven/apache-maven/3.0-beta-3/ >> >> 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 >> >> >> Benjamin >> >> >> [0] http://github.com/sonatype/sonatype-aether >> >> - >> 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 Apache Maven 3.0-beta-3
+1 20-some module project with AspectJ & Terracotta - no issues. On 8/25/10 4:36 PM, Benjamin Bentmann wrote: Hi, apart from another few regression fixes, this release includes Guice and Aether [0] and shall help to get some more community testing on these new components. Overall, we solved 16 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=16681 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&status=1 Staging repo: https://repository.apache.org/content/repositories/maven-146/ Staged source and binary distros: https://repository.apache.org/content/repositories/maven-146/org/apache/maven/apache-maven/3.0-beta-3/ 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 Benjamin [0] http://github.com/sonatype/sonatype-aether - 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
NullPointerExceptions with todays maven 3 build and the release plugin
Hey all, Just doing a bunch of artifact releases today and noticed that I'm getting NPEs. I guess this is related to the Guice/aether merge. The log/error can be seen at https://gist.github.com/8ac6e71ad49cf8928549 Where do we raise issues for this now? Mark -- Pull me down under...
Re: Filling in a few gaps with enforcer rules
Yes, these are useful rules, although we have some that sound the same, but maybe there's a subtle difference? http://maven.apache.org/enforcer/enforcer-rules/requireReleaseDeps.html http://maven.apache.org/enforcer/enforcer-rules/requireReleaseVersion.html On Wed, Aug 25, 2010 at 6:26 PM, Rex Hoffman wrote: > Just want to make sure before I do this that there is desire for these > kinds of enforcer rules in the community. > Don't want to engage in the extra effort if others dont feel the need > for rules like these. > Wont be hard to split the functionality, will just result in a shared > library or (some) duplicated code. > > Rex > > On Wed, Aug 25, 2010 at 3:01 PM, Stephen Connolly > wrote: >> IMHO, if you can separate the rules by function and file enhancement JIRAs >> with the appropriate patches attached to each, that would probably be the >> best way >> >> -Stephen >> >> On 25 August 2010 20:00, Rex Hoffman wrote: >> >>> So I felt there are few gaps in the maven release process (and >>> enforcing a project or a reactor project is releasable). >>> >>> Perceived gaps: >>> >>> 1) Maven should fail a build if it is building a release version >>> number and any of it's dependencies (including transitive dependencies >>> on plugins, or inherited, etc...) are snapshot dependencies. >>> >>> 2) Maven should have the option of forcing developers to ensure >>> dependencies converge rather than relying on the "closest to the top" >>> rule it uses by default. In large projects this can be problematic. >>> >>> I have written an enforcer rule that supports this >>> >>> For my current employers needs I also felt that we should demand all >>> modules in a reactor build should have the same version number, so I >>> built a rule for that as well. >>> >>> I wrote this in my time, have them hosted on my server, have no >>> encumbrances on this code and would like to contribute it to the >>> apache project proper. I'd be happy to help maintain them as well, >>> actively developing and answering questions of anyone who would like >>> to work on them. >>> >>> They are tested fully both with src/it tests and in my organization. >>> >>> I have them hosted here (with some other open source I've written) >>> http://www.e-hoffman.org/released/ >>> >>> The source is include in the source jar files, but I have also >>> included them as zips here, so that the project structure and tests >>> are preserved. >>> >>> Rex Hoffman >>> >>> >>> - >>> 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 Apache Maven 3.0-beta-3
+1 On Aug 25, 2010, at 4:36 PM, Benjamin Bentmann wrote: > Hi, > > apart from another few regression fixes, this release includes Guice and > Aether [0] and shall help to get some more community testing on these new > components. Overall, we solved 16 issues: > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=16681 > > There are still a couple of issues left in JIRA: > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&status=1 > > Staging repo: > https://repository.apache.org/content/repositories/maven-146/ > > Staged source and binary distros: > https://repository.apache.org/content/repositories/maven-146/org/apache/maven/apache-maven/3.0-beta-3/ > > 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 > > > Benjamin > > > [0] http://github.com/sonatype/sonatype-aether > > - > 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 - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
[VOTE] Release Apache Maven 3.0-beta-3
Hi, apart from another few regression fixes, this release includes Guice and Aether [0] and shall help to get some more community testing on these new components. Overall, we solved 16 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=16681 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&status=1 Staging repo: https://repository.apache.org/content/repositories/maven-146/ Staged source and binary distros: https://repository.apache.org/content/repositories/maven-146/org/apache/maven/apache-maven/3.0-beta-3/ 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 Benjamin [0] http://github.com/sonatype/sonatype-aether - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Filling in a few gaps with enforcer rules
Just want to make sure before I do this that there is desire for these kinds of enforcer rules in the community. Don't want to engage in the extra effort if others dont feel the need for rules like these. Wont be hard to split the functionality, will just result in a shared library or (some) duplicated code. Rex On Wed, Aug 25, 2010 at 3:01 PM, Stephen Connolly wrote: > IMHO, if you can separate the rules by function and file enhancement JIRAs > with the appropriate patches attached to each, that would probably be the > best way > > -Stephen > > On 25 August 2010 20:00, Rex Hoffman wrote: > >> So I felt there are few gaps in the maven release process (and >> enforcing a project or a reactor project is releasable). >> >> Perceived gaps: >> >> 1) Maven should fail a build if it is building a release version >> number and any of it's dependencies (including transitive dependencies >> on plugins, or inherited, etc...) are snapshot dependencies. >> >> 2) Maven should have the option of forcing developers to ensure >> dependencies converge rather than relying on the "closest to the top" >> rule it uses by default. In large projects this can be problematic. >> >> I have written an enforcer rule that supports this >> >> For my current employers needs I also felt that we should demand all >> modules in a reactor build should have the same version number, so I >> built a rule for that as well. >> >> I wrote this in my time, have them hosted on my server, have no >> encumbrances on this code and would like to contribute it to the >> apache project proper. I'd be happy to help maintain them as well, >> actively developing and answering questions of anyone who would like >> to work on them. >> >> They are tested fully both with src/it tests and in my organization. >> >> I have them hosted here (with some other open source I've written) >> http://www.e-hoffman.org/released/ >> >> The source is include in the source jar files, but I have also >> included them as zips here, so that the project structure and tests >> are preserved. >> >> Rex Hoffman >> >> >> - >> 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: Filling in a few gaps with enforcer rules
IMHO, if you can separate the rules by function and file enhancement JIRAs with the appropriate patches attached to each, that would probably be the best way -Stephen On 25 August 2010 20:00, Rex Hoffman wrote: > So I felt there are few gaps in the maven release process (and > enforcing a project or a reactor project is releasable). > > Perceived gaps: > > 1) Maven should fail a build if it is building a release version > number and any of it's dependencies (including transitive dependencies > on plugins, or inherited, etc...) are snapshot dependencies. > > 2) Maven should have the option of forcing developers to ensure > dependencies converge rather than relying on the "closest to the top" > rule it uses by default. In large projects this can be problematic. > > I have written an enforcer rule that supports this > > For my current employers needs I also felt that we should demand all > modules in a reactor build should have the same version number, so I > built a rule for that as well. > > I wrote this in my time, have them hosted on my server, have no > encumbrances on this code and would like to contribute it to the > apache project proper. I'd be happy to help maintain them as well, > actively developing and answering questions of anyone who would like > to work on them. > > They are tested fully both with src/it tests and in my organization. > > I have them hosted here (with some other open source I've written) > http://www.e-hoffman.org/released/ > > The source is include in the source jar files, but I have also > included them as zips here, so that the project structure and tests > are preserved. > > Rex Hoffman > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org >
