You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Arnaud Héritier <ah...@gmail.com> on 2013/07/08 10:23:43 UTC
Java version compatibility
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 ?
Maybe it's just overkill/useless.
WDYT ?
-----
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier
Re: Java version compatibility
Posted by Arnaud Héritier <ah...@gmail.com>.
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 <ah...@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 <ah...@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
Re: Java version compatibility
Posted by Stephen Connolly <st...@gmail.com>.
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 <ah...@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 <ah...@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
>
Re: Java version compatibility
Posted by Arnaud Héritier <ah...@gmail.com>.
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 <ah...@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
Re: Java version compatibility
Posted by Stephen Connolly <st...@gmail.com>.
On 8 July 2013 09:23, Arnaud Héritier <ah...@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
>