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 <r...@e-hoffman.org> 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 > <stephen.alan.conno...@gmail.com> 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 <r...@e-hoffman.org> 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
