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 <[email protected]> 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 <[email protected]> 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: [email protected] >> For additional commands, e-mail: [email protected] >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
