You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Stephen Connolly <st...@gmail.com> on 2009/04/04 23:30:05 UTC
versions:analyze
Hi,
ok so I'm working on a new goal for the versions plugin, analyze (and an
associated report analysis-report)
I would like this goal to highlight potential issues with respect to
versions....
first problem I see is:
1. Referencing a reactor project as a plugin or plugin dependency consumed
later in the reactor (since plugins must be class-loaded prior to starting
the build life cycle, and the artifacts will not be available until after
the package phase at least
Anyone any other suggestions for possible problems (which are to do with
versions and the reactor)
2. Using a dependency which is produced by the reactor, but not using the
version from the reactor (this is more of a warning than a problem as I can
see times when you might want to do this)
Oh, and by the way, these will not fail the build, that's the job of the
enforcer plugin... I want this report to help steer people towards best
practice
-Stephen
Re: versions:analyze
Posted by Mark Hobson <ma...@gmail.com>.
Sounds like a handy goal. A few more checks that would be handy until
we have usable version ranges:
- Warn if an artifact's version resolves to a version lower than one
specified in a transitive pom (i.e. a dependency is being downgraded
because it is nearest)
- As above, but also comparing against transitive dependency
management blocks, since dependency management is not transitive.
Mark
2009/4/6 HUYNH GIANG SON <hu...@gmail.com>:
> Thanks
>
> -----Original Message-----
> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> Sent: Monday, April 06, 2009 4:20 PM
> To: Stephen Connolly
> Cc: Maven Users List; user@mojo.codehaus.org; Maven Developers List;
> dev@mojo.codehaus.org
> Subject: Re: versions:analyze
>
> 5. When locked snapshots are in use ( i.e. 1.0-20090406.102308-2 and not
> 1.0-SNAPSHOT ) (minor warning)
>
> 2009/4/6 Stephen Connolly <st...@gmail.com>
>
>> 3. when the same plugin is specified in multiple projects in the reactor,
>> using different versions (severe warning fir 2.x minor for 3.x)
>>
>> 4. when reporting plugins specify a different version from build plugins
>>
>> Sent from my [rhymes with myPod] ;-)
>>
>>
>> On 4 Apr 2009, at 22:30, Stephen Connolly
> <st...@gmail.com>
>> wrote:
>>
>> Hi,
>>>
>>> ok so I'm working on a new goal for the versions plugin, analyze (and an
>>> associated report analysis-report)
>>>
>>> I would like this goal to highlight potential issues with respect to
>>> versions....
>>>
>>> first problem I see is:
>>>
>>> 1. Referencing a reactor project as a plugin or plugin dependency
>>> consumed later in the reactor (since plugins must be class-loaded prior
> to
>>> starting the build life cycle, and the artifacts will not be available
> until
>>> after the package phase at least
>>>
>>> Anyone any other suggestions for possible problems (which are to do with
>>> versions and the reactor)
>>>
>>> 2. Using a dependency which is produced by the reactor, but not using the
>>> version from the reactor (this is more of a warning than a problem as I
> can
>>> see times when you might want to do this)
>>>
>>> Oh, and by the way, these will not fail the build, that's the job of the
>>> enforcer plugin... I want this report to help steer people towards best
>>> practice
>>>
>>> -Stephen
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: versions:analyze
Posted by Mark Hobson <ma...@gmail.com>.
Sounds like a handy goal. A few more checks that would be handy until
we have usable version ranges:
- Warn if an artifact's version resolves to a version lower than one
specified in a transitive pom (i.e. a dependency is being downgraded
because it is nearest)
- As above, but also comparing against transitive dependency
management blocks, since dependency management is not transitive.
Mark
2009/4/6 HUYNH GIANG SON <hu...@gmail.com>:
> Thanks
>
> -----Original Message-----
> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> Sent: Monday, April 06, 2009 4:20 PM
> To: Stephen Connolly
> Cc: Maven Users List; user@mojo.codehaus.org; Maven Developers List;
> dev@mojo.codehaus.org
> Subject: Re: versions:analyze
>
> 5. When locked snapshots are in use ( i.e. 1.0-20090406.102308-2 and not
> 1.0-SNAPSHOT ) (minor warning)
>
> 2009/4/6 Stephen Connolly <st...@gmail.com>
>
>> 3. when the same plugin is specified in multiple projects in the reactor,
>> using different versions (severe warning fir 2.x minor for 3.x)
>>
>> 4. when reporting plugins specify a different version from build plugins
>>
>> Sent from my [rhymes with myPod] ;-)
>>
>>
>> On 4 Apr 2009, at 22:30, Stephen Connolly
> <st...@gmail.com>
>> wrote:
>>
>> Hi,
>>>
>>> ok so I'm working on a new goal for the versions plugin, analyze (and an
>>> associated report analysis-report)
>>>
>>> I would like this goal to highlight potential issues with respect to
>>> versions....
>>>
>>> first problem I see is:
>>>
>>> 1. Referencing a reactor project as a plugin or plugin dependency
>>> consumed later in the reactor (since plugins must be class-loaded prior
> to
>>> starting the build life cycle, and the artifacts will not be available
> until
>>> after the package phase at least
>>>
>>> Anyone any other suggestions for possible problems (which are to do with
>>> versions and the reactor)
>>>
>>> 2. Using a dependency which is produced by the reactor, but not using the
>>> version from the reactor (this is more of a warning than a problem as I
> can
>>> see times when you might want to do this)
>>>
>>> Oh, and by the way, these will not fail the build, that's the job of the
>>> enforcer plugin... I want this report to help steer people towards best
>>> practice
>>>
>>> -Stephen
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: versions:analyze
Posted by HUYNH GIANG SON <hu...@gmail.com>.
Thanks
-----Original Message-----
From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
Sent: Monday, April 06, 2009 4:20 PM
To: Stephen Connolly
Cc: Maven Users List; user@mojo.codehaus.org; Maven Developers List;
dev@mojo.codehaus.org
Subject: Re: versions:analyze
5. When locked snapshots are in use ( i.e. 1.0-20090406.102308-2 and not
1.0-SNAPSHOT ) (minor warning)
2009/4/6 Stephen Connolly <st...@gmail.com>
> 3. when the same plugin is specified in multiple projects in the reactor,
> using different versions (severe warning fir 2.x minor for 3.x)
>
> 4. when reporting plugins specify a different version from build plugins
>
> Sent from my [rhymes with myPod] ;-)
>
>
> On 4 Apr 2009, at 22:30, Stephen Connolly
<st...@gmail.com>
> wrote:
>
> Hi,
>>
>> ok so I'm working on a new goal for the versions plugin, analyze (and an
>> associated report analysis-report)
>>
>> I would like this goal to highlight potential issues with respect to
>> versions....
>>
>> first problem I see is:
>>
>> 1. Referencing a reactor project as a plugin or plugin dependency
>> consumed later in the reactor (since plugins must be class-loaded prior
to
>> starting the build life cycle, and the artifacts will not be available
until
>> after the package phase at least
>>
>> Anyone any other suggestions for possible problems (which are to do with
>> versions and the reactor)
>>
>> 2. Using a dependency which is produced by the reactor, but not using the
>> version from the reactor (this is more of a warning than a problem as I
can
>> see times when you might want to do this)
>>
>> Oh, and by the way, these will not fail the build, that's the job of the
>> enforcer plugin... I want this report to help steer people towards best
>> practice
>>
>> -Stephen
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: versions:analyze
Posted by HUYNH GIANG SON <hu...@gmail.com>.
Thanks
-----Original Message-----
From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
Sent: Monday, April 06, 2009 4:20 PM
To: Stephen Connolly
Cc: Maven Users List; user@mojo.codehaus.org; Maven Developers List;
dev@mojo.codehaus.org
Subject: Re: versions:analyze
5. When locked snapshots are in use ( i.e. 1.0-20090406.102308-2 and not
1.0-SNAPSHOT ) (minor warning)
2009/4/6 Stephen Connolly <st...@gmail.com>
> 3. when the same plugin is specified in multiple projects in the reactor,
> using different versions (severe warning fir 2.x minor for 3.x)
>
> 4. when reporting plugins specify a different version from build plugins
>
> Sent from my [rhymes with myPod] ;-)
>
>
> On 4 Apr 2009, at 22:30, Stephen Connolly
<st...@gmail.com>
> wrote:
>
> Hi,
>>
>> ok so I'm working on a new goal for the versions plugin, analyze (and an
>> associated report analysis-report)
>>
>> I would like this goal to highlight potential issues with respect to
>> versions....
>>
>> first problem I see is:
>>
>> 1. Referencing a reactor project as a plugin or plugin dependency
>> consumed later in the reactor (since plugins must be class-loaded prior
to
>> starting the build life cycle, and the artifacts will not be available
until
>> after the package phase at least
>>
>> Anyone any other suggestions for possible problems (which are to do with
>> versions and the reactor)
>>
>> 2. Using a dependency which is produced by the reactor, but not using the
>> version from the reactor (this is more of a warning than a problem as I
can
>> see times when you might want to do this)
>>
>> Oh, and by the way, these will not fail the build, that's the job of the
>> enforcer plugin... I want this report to help steer people towards best
>> practice
>>
>> -Stephen
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: versions:analyze
Posted by Stephen Connolly <st...@gmail.com>.
5. When locked snapshots are in use ( i.e. 1.0-20090406.102308-2 and not
1.0-SNAPSHOT ) (minor warning)
2009/4/6 Stephen Connolly <st...@gmail.com>
> 3. when the same plugin is specified in multiple projects in the reactor,
> using different versions (severe warning fir 2.x minor for 3.x)
>
> 4. when reporting plugins specify a different version from build plugins
>
> Sent from my [rhymes with myPod] ;-)
>
>
> On 4 Apr 2009, at 22:30, Stephen Connolly <st...@gmail.com>
> wrote:
>
> Hi,
>>
>> ok so I'm working on a new goal for the versions plugin, analyze (and an
>> associated report analysis-report)
>>
>> I would like this goal to highlight potential issues with respect to
>> versions....
>>
>> first problem I see is:
>>
>> 1. Referencing a reactor project as a plugin or plugin dependency
>> consumed later in the reactor (since plugins must be class-loaded prior to
>> starting the build life cycle, and the artifacts will not be available until
>> after the package phase at least
>>
>> Anyone any other suggestions for possible problems (which are to do with
>> versions and the reactor)
>>
>> 2. Using a dependency which is produced by the reactor, but not using the
>> version from the reactor (this is more of a warning than a problem as I can
>> see times when you might want to do this)
>>
>> Oh, and by the way, these will not fail the build, that's the job of the
>> enforcer plugin... I want this report to help steer people towards best
>> practice
>>
>> -Stephen
>>
>
Re: versions:analyze
Posted by Stephen Connolly <st...@gmail.com>.
5. When locked snapshots are in use ( i.e. 1.0-20090406.102308-2 and not
1.0-SNAPSHOT ) (minor warning)
2009/4/6 Stephen Connolly <st...@gmail.com>
> 3. when the same plugin is specified in multiple projects in the reactor,
> using different versions (severe warning fir 2.x minor for 3.x)
>
> 4. when reporting plugins specify a different version from build plugins
>
> Sent from my [rhymes with myPod] ;-)
>
>
> On 4 Apr 2009, at 22:30, Stephen Connolly <st...@gmail.com>
> wrote:
>
> Hi,
>>
>> ok so I'm working on a new goal for the versions plugin, analyze (and an
>> associated report analysis-report)
>>
>> I would like this goal to highlight potential issues with respect to
>> versions....
>>
>> first problem I see is:
>>
>> 1. Referencing a reactor project as a plugin or plugin dependency
>> consumed later in the reactor (since plugins must be class-loaded prior to
>> starting the build life cycle, and the artifacts will not be available until
>> after the package phase at least
>>
>> Anyone any other suggestions for possible problems (which are to do with
>> versions and the reactor)
>>
>> 2. Using a dependency which is produced by the reactor, but not using the
>> version from the reactor (this is more of a warning than a problem as I can
>> see times when you might want to do this)
>>
>> Oh, and by the way, these will not fail the build, that's the job of the
>> enforcer plugin... I want this report to help steer people towards best
>> practice
>>
>> -Stephen
>>
>
Re: versions:analyze
Posted by Stephen Connolly <st...@gmail.com>.
3. when the same plugin is specified in multiple projects in the
reactor, using different versions (severe warning fir 2.x minor for 3.x)
4. when reporting plugins specify a different version from build plugins
Sent from my [rhymes with myPod] ;-)
On 4 Apr 2009, at 22:30, Stephen Connolly <stephen.alan.connolly@gmail.com
> wrote:
> Hi,
>
> ok so I'm working on a new goal for the versions plugin, analyze
> (and an associated report analysis-report)
>
> I would like this goal to highlight potential issues with respect to
> versions....
>
> first problem I see is:
>
> 1. Referencing a reactor project as a plugin or plugin dependency
> consumed later in the reactor (since plugins must be class-loaded
> prior to starting the build life cycle, and the artifacts will not
> be available until after the package phase at least
>
> Anyone any other suggestions for possible problems (which are to do
> with versions and the reactor)
>
> 2. Using a dependency which is produced by the reactor, but not
> using the version from the reactor (this is more of a warning than a
> problem as I can see times when you might want to do this)
>
> Oh, and by the way, these will not fail the build, that's the job of
> the enforcer plugin... I want this report to help steer people
> towards best practice
>
> -Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: versions:analyze
Posted by Stephen Connolly <st...@gmail.com>.
3. when the same plugin is specified in multiple projects in the
reactor, using different versions (severe warning fir 2.x minor for 3.x)
4. when reporting plugins specify a different version from build plugins
Sent from my [rhymes with myPod] ;-)
On 4 Apr 2009, at 22:30, Stephen Connolly <stephen.alan.connolly@gmail.com
> wrote:
> Hi,
>
> ok so I'm working on a new goal for the versions plugin, analyze
> (and an associated report analysis-report)
>
> I would like this goal to highlight potential issues with respect to
> versions....
>
> first problem I see is:
>
> 1. Referencing a reactor project as a plugin or plugin dependency
> consumed later in the reactor (since plugins must be class-loaded
> prior to starting the build life cycle, and the artifacts will not
> be available until after the package phase at least
>
> Anyone any other suggestions for possible problems (which are to do
> with versions and the reactor)
>
> 2. Using a dependency which is produced by the reactor, but not
> using the version from the reactor (this is more of a warning than a
> problem as I can see times when you might want to do this)
>
> Oh, and by the way, these will not fail the build, that's the job of
> the enforcer plugin... I want this report to help steer people
> towards best practice
>
> -Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org