maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Java version compatibility
Date Mon, 08 Jul 2013 09:02:07 GMT
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
>

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