let's do that. I'll test it on archetype level and then we'll see to move it later on plugins or maven levels
On Mon, Jul 8, 2013 at 11:02 AM, Stephen Connolly < [email protected]> wrote: > I think ultimately at maven parent, but if you want to play at a less wide > level first I think that could be a good plan too > > > On 8 July 2013 09:59, Arnaud Héritier <[email protected]> wrote: > > > yes, far from me the idea to have such controls for every builds :-) > > either in a dedicated profile launched manually by committers (and CI?) > or > > in the release profile > > Something to add at which level ? plugins parent ? maven parent ? > > > > > > On Mon, Jul 8, 2013 at 10:52 AM, Stephen Connolly < > > [email protected]> wrote: > > > > > On 8 July 2013 09:23, Arnaud Héritier <[email protected]> wrote: > > > > > > > Hi, > > > > > > > > Last night I introduced by error a dependency requiring Java 6 in > the > > > > archetype plugin whereas we are always supposed to support Java 5 > (Yes > > we > > > > can :-) ) > > > > Myself I don't have anymore a Java 5 on my computer and I'm often > > using > > > > Java 7 by default and I'm probably not the only one. Even if we take > > care > > > > of dependencies releases notes and we are taking care of APIs we are > > > using > > > > we may easily introduce some incompatibilities. > > > > Jenkins is configured to use Java 5 thus it detects such errors ( > > > > > > > > > > > > > > https://builds.apache.org/view/M-R/view/Maven/job/maven-archetype-m3/138/console > > > > ) > > > > but myself I don't really succeed to follow its notifications because > > we > > > > have too many false positives. > > > > One think I'm doing at work that allows me to validate these stuffs > > > > locally is to use some enforcer rules (in a release profile) > > > > Bytecode version : > > > > > > > > > > http://mojo.codehaus.org/extra-enforcer-rules/enforceBytecodeVersion.html > > > > Animal Sniffer : http://mojo.codehaus.org/animal-sniffer/ > > > > They are configured with maven.compiler.target thus if a project > > > changes > > > > this property value, our controls are automatically updated. > > > > Could it be useful to have that on our side ? In a parent pom ? > > > > > > > > > > I think if they are in a profile, or enabled by the release profile > then > > > that would be good... but if I need to run those every build then I > would > > > have concerns (alternatively put them late in the lifecycle so you can > at > > > least mvn package... it would make sense to bind them to the verify > > > phase... finally a property to skip them while iterating would make > sense > > > too) > > > > > > > > > > Maybe it's just overkill/useless. > > > > > > > > > > Until we decide to bump up to 1.7 as pre-req I don't think it's useless > > or > > > overkill... overkill is running every build > > > > > > > > > > > > > > WDYT ? > > > > > > > > > > > > ----- > > > > Arnaud Héritier > > > > http://aheritier.net > > > > Mail/GTalk: aheritier AT gmail DOT com > > > > Twitter/Skype : aheritier > > > > > > > > > > > > > > > -- > > ----- > > Arnaud Héritier > > http://aheritier.net > > Mail/GTalk: aheritier AT gmail DOT com > > Twitter/Skype : aheritier > > > -- ----- Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
