maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arnaud Héritier <aherit...@gmail.com>
Subject Re: Java version compatibility
Date Mon, 08 Jul 2013 09:05:09 GMT
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 <
stephen.alan.connolly@gmail.com> 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 <aheritier@gmail.com> 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 <
> > stephen.alan.connolly@gmail.com> wrote:
> >
> > > On 8 July 2013 09:23, Arnaud Héritier <aheritier@gmail.com> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message