You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Rex Hoffman <re...@e-hoffman.org> on 2010/08/25 21:00:38 UTC
Filling in a few gaps with enforcer rules
So I felt there are few gaps in the maven release process (and
enforcing a project or a reactor project is releasable).
Perceived gaps:
1) Maven should fail a build if it is building a release version
number and any of it's dependencies (including transitive dependencies
on plugins, or inherited, etc...) are snapshot dependencies.
2) Maven should have the option of forcing developers to ensure
dependencies converge rather than relying on the "closest to the top"
rule it uses by default. In large projects this can be problematic.
I have written an enforcer rule that supports this
For my current employers needs I also felt that we should demand all
modules in a reactor build should have the same version number, so I
built a rule for that as well.
I wrote this in my time, have them hosted on my server, have no
encumbrances on this code and would like to contribute it to the
apache project proper. I'd be happy to help maintain them as well,
actively developing and answering questions of anyone who would like
to work on them.
They are tested fully both with src/it tests and in my organization.
I have them hosted here (with some other open source I've written)
http://www.e-hoffman.org/released/
The source is include in the source jar files, but I have also
included them as zips here, so that the project structure and tests
are preserved.
Rex Hoffman
Re: Filling in a few gaps with enforcer rules
Posted by Brian Fox <br...@infinity.nu>.
Yes, these are useful rules, although we have some that sound the
same, but maybe there's a subtle difference?
http://maven.apache.org/enforcer/enforcer-rules/requireReleaseDeps.html
http://maven.apache.org/enforcer/enforcer-rules/requireReleaseVersion.html
On Wed, Aug 25, 2010 at 6:26 PM, Rex Hoffman <re...@e-hoffman.org> wrote:
> Just want to make sure before I do this that there is desire for these
> kinds of enforcer rules in the community.
> Don't want to engage in the extra effort if others dont feel the need
> for rules like these.
> Wont be hard to split the functionality, will just result in a shared
> library or (some) duplicated code.
>
> Rex
>
> On Wed, Aug 25, 2010 at 3:01 PM, Stephen Connolly
> <st...@gmail.com> wrote:
>> IMHO, if you can separate the rules by function and file enhancement JIRAs
>> with the appropriate patches attached to each, that would probably be the
>> best way
>>
>> -Stephen
>>
>> On 25 August 2010 20:00, Rex Hoffman <re...@e-hoffman.org> wrote:
>>
>>> So I felt there are few gaps in the maven release process (and
>>> enforcing a project or a reactor project is releasable).
>>>
>>> Perceived gaps:
>>>
>>> 1) Maven should fail a build if it is building a release version
>>> number and any of it's dependencies (including transitive dependencies
>>> on plugins, or inherited, etc...) are snapshot dependencies.
>>>
>>> 2) Maven should have the option of forcing developers to ensure
>>> dependencies converge rather than relying on the "closest to the top"
>>> rule it uses by default. In large projects this can be problematic.
>>>
>>> I have written an enforcer rule that supports this
>>>
>>> For my current employers needs I also felt that we should demand all
>>> modules in a reactor build should have the same version number, so I
>>> built a rule for that as well.
>>>
>>> I wrote this in my time, have them hosted on my server, have no
>>> encumbrances on this code and would like to contribute it to the
>>> apache project proper. I'd be happy to help maintain them as well,
>>> actively developing and answering questions of anyone who would like
>>> to work on them.
>>>
>>> They are tested fully both with src/it tests and in my organization.
>>>
>>> I have them hosted here (with some other open source I've written)
>>> http://www.e-hoffman.org/released/
>>>
>>> The source is include in the source jar files, but I have also
>>> included them as zips here, so that the project structure and tests
>>> are preserved.
>>>
>>> Rex Hoffman
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Filling in a few gaps with enforcer rules
Posted by Rex Hoffman <re...@e-hoffman.org>.
Just want to make sure before I do this that there is desire for these
kinds of enforcer rules in the community.
Don't want to engage in the extra effort if others dont feel the need
for rules like these.
Wont be hard to split the functionality, will just result in a shared
library or (some) duplicated code.
Rex
On Wed, Aug 25, 2010 at 3:01 PM, Stephen Connolly
<st...@gmail.com> wrote:
> IMHO, if you can separate the rules by function and file enhancement JIRAs
> with the appropriate patches attached to each, that would probably be the
> best way
>
> -Stephen
>
> On 25 August 2010 20:00, Rex Hoffman <re...@e-hoffman.org> wrote:
>
>> So I felt there are few gaps in the maven release process (and
>> enforcing a project or a reactor project is releasable).
>>
>> Perceived gaps:
>>
>> 1) Maven should fail a build if it is building a release version
>> number and any of it's dependencies (including transitive dependencies
>> on plugins, or inherited, etc...) are snapshot dependencies.
>>
>> 2) Maven should have the option of forcing developers to ensure
>> dependencies converge rather than relying on the "closest to the top"
>> rule it uses by default. In large projects this can be problematic.
>>
>> I have written an enforcer rule that supports this
>>
>> For my current employers needs I also felt that we should demand all
>> modules in a reactor build should have the same version number, so I
>> built a rule for that as well.
>>
>> I wrote this in my time, have them hosted on my server, have no
>> encumbrances on this code and would like to contribute it to the
>> apache project proper. I'd be happy to help maintain them as well,
>> actively developing and answering questions of anyone who would like
>> to work on them.
>>
>> They are tested fully both with src/it tests and in my organization.
>>
>> I have them hosted here (with some other open source I've written)
>> http://www.e-hoffman.org/released/
>>
>> The source is include in the source jar files, but I have also
>> included them as zips here, so that the project structure and tests
>> are preserved.
>>
>> Rex Hoffman
>>
>>
>> ---------------------------------------------------------------------
>> 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: Filling in a few gaps with enforcer rules
Posted by Stephen Connolly <st...@gmail.com>.
IMHO, if you can separate the rules by function and file enhancement JIRAs
with the appropriate patches attached to each, that would probably be the
best way
-Stephen
On 25 August 2010 20:00, Rex Hoffman <re...@e-hoffman.org> wrote:
> So I felt there are few gaps in the maven release process (and
> enforcing a project or a reactor project is releasable).
>
> Perceived gaps:
>
> 1) Maven should fail a build if it is building a release version
> number and any of it's dependencies (including transitive dependencies
> on plugins, or inherited, etc...) are snapshot dependencies.
>
> 2) Maven should have the option of forcing developers to ensure
> dependencies converge rather than relying on the "closest to the top"
> rule it uses by default. In large projects this can be problematic.
>
> I have written an enforcer rule that supports this
>
> For my current employers needs I also felt that we should demand all
> modules in a reactor build should have the same version number, so I
> built a rule for that as well.
>
> I wrote this in my time, have them hosted on my server, have no
> encumbrances on this code and would like to contribute it to the
> apache project proper. I'd be happy to help maintain them as well,
> actively developing and answering questions of anyone who would like
> to work on them.
>
> They are tested fully both with src/it tests and in my organization.
>
> I have them hosted here (with some other open source I've written)
> http://www.e-hoffman.org/released/
>
> The source is include in the source jar files, but I have also
> included them as zips here, so that the project structure and tests
> are preserved.
>
> Rex Hoffman
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Re: Filling in a few gaps with enforcer rules
Posted by Mark Hobson <ma...@gmail.com>.
Great, thanks Rex.
Mark
On 13 September 2010 18:45, Rex Hoffman <re...@e-hoffman.org> wrote:
> Hey Mark,
>
> A little later than I promised but here it is:
>
> http://jira.codehaus.org/browse/MENFORCER-107
>
> Rex
>
>
> On Wed, Sep 8, 2010 at 1:16 PM, Mark Hobson <ma...@gmail.com> wrote:
>> Great, no real rush thanks, I just wondered if anything was happening.
>> If you could post the issues to this thread when they're raised then
>> I'll track it from there.
>>
>> Thanks and happy time off!
>>
>> Mark
>>
>> On 8 September 2010 18:41, Rex Hoffman <re...@e-hoffman.org> wrote:
>>> I haven't opened it yet as I still have to separate out functionality,
>>> and write up some info for the site report. Already have the
>>> integration test done.
>>>
>>> I just quit my job and have two weeks off until I start my next, last
>>> day, yay! So really good news for you!
>>>
>>> I expect to have this split out and the site info done this week.
>>>
>>> If you can't wait I released it for my (old) companies use on my
>>> website ( http://www.e-hoffman.org/released/repo )
>>> Sites are under repo as well
>>>
>>> Not heavily documented but, if you include that location and add this
>>> to your pom, you get the goodness.
>>>
>>> <plugin>
>>> <groupId>org.apache.maven.plugins</groupId>
>>> <artifactId>maven-enforcer-plugin</artifactId>
>>> <version>1.0-beta-1</version>
>>> <dependencies>
>>> <dependency>
>>> <groupId>org.apache.maven.enforcer.rules</groupId>
>>> <artifactId>maven-enforce-releasability</artifactId>
>>> <version>1.0.0</version>
>>> </dependency>
>>> </dependencies>
>>> <executions>
>>> <execution>
>>> <id>enforce</id>
>>> <configuration>
>>> <rules>
>>> <myCustomRule
>>> implementation="org.apache.maven.enforcer.rule.DependencyRule">
>>>
>>> <enforceNoSnapshotsOnRelease>false</enforceNoSnapshotsOnRelease>
>>>
>>> <enforceDependencyConvergence>true</enforceDependencyConvergence>
>>> </myCustomRule>
>>> </rules>
>>> </configuration>
>>> <goals>
>>> <goal>enforce</goal>
>>> </goals>
>>> </execution>
>>> </executions>
>>> </plugin>
>>>
>>>
>>> Or you can wait on me, and then a dev with commit rights to get in to
>>> maven proper.
>>>
>>> Cheers,
>>>
>>> Rex
>>>
>>> On Wed, Sep 8, 2010 at 4:26 AM, Mark Hobson <ma...@gmail.com> wrote:
>>>> Were any issues raised to track the progress of these new rules? I'm
>>>> particularly interested in this one:
>>>>
>>>>> 2) Maven should have the option of forcing developers to ensure
>>>>> dependencies converge rather than relying on the "closest to the top"
>>>>> rule it uses by default. In large projects this can be problematic.
>>>>
>>>> Cheers,
>>>>
>>>> Mark
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Filling in a few gaps with enforcer rules
Posted by Rex Hoffman <re...@e-hoffman.org>.
Hey Mark,
A little later than I promised but here it is:
http://jira.codehaus.org/browse/MENFORCER-107
Rex
On Wed, Sep 8, 2010 at 1:16 PM, Mark Hobson <ma...@gmail.com> wrote:
> Great, no real rush thanks, I just wondered if anything was happening.
> If you could post the issues to this thread when they're raised then
> I'll track it from there.
>
> Thanks and happy time off!
>
> Mark
>
> On 8 September 2010 18:41, Rex Hoffman <re...@e-hoffman.org> wrote:
>> I haven't opened it yet as I still have to separate out functionality,
>> and write up some info for the site report. Already have the
>> integration test done.
>>
>> I just quit my job and have two weeks off until I start my next, last
>> day, yay! So really good news for you!
>>
>> I expect to have this split out and the site info done this week.
>>
>> If you can't wait I released it for my (old) companies use on my
>> website ( http://www.e-hoffman.org/released/repo )
>> Sites are under repo as well
>>
>> Not heavily documented but, if you include that location and add this
>> to your pom, you get the goodness.
>>
>> <plugin>
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-enforcer-plugin</artifactId>
>> <version>1.0-beta-1</version>
>> <dependencies>
>> <dependency>
>> <groupId>org.apache.maven.enforcer.rules</groupId>
>> <artifactId>maven-enforce-releasability</artifactId>
>> <version>1.0.0</version>
>> </dependency>
>> </dependencies>
>> <executions>
>> <execution>
>> <id>enforce</id>
>> <configuration>
>> <rules>
>> <myCustomRule
>> implementation="org.apache.maven.enforcer.rule.DependencyRule">
>>
>> <enforceNoSnapshotsOnRelease>false</enforceNoSnapshotsOnRelease>
>>
>> <enforceDependencyConvergence>true</enforceDependencyConvergence>
>> </myCustomRule>
>> </rules>
>> </configuration>
>> <goals>
>> <goal>enforce</goal>
>> </goals>
>> </execution>
>> </executions>
>> </plugin>
>>
>>
>> Or you can wait on me, and then a dev with commit rights to get in to
>> maven proper.
>>
>> Cheers,
>>
>> Rex
>>
>> On Wed, Sep 8, 2010 at 4:26 AM, Mark Hobson <ma...@gmail.com> wrote:
>>> Were any issues raised to track the progress of these new rules? I'm
>>> particularly interested in this one:
>>>
>>>> 2) Maven should have the option of forcing developers to ensure
>>>> dependencies converge rather than relying on the "closest to the top"
>>>> rule it uses by default. In large projects this can be problematic.
>>>
>>> Cheers,
>>>
>>> Mark
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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: Filling in a few gaps with enforcer rules
Posted by Mark Hobson <ma...@gmail.com>.
Great, no real rush thanks, I just wondered if anything was happening.
If you could post the issues to this thread when they're raised then
I'll track it from there.
Thanks and happy time off!
Mark
On 8 September 2010 18:41, Rex Hoffman <re...@e-hoffman.org> wrote:
> I haven't opened it yet as I still have to separate out functionality,
> and write up some info for the site report. Already have the
> integration test done.
>
> I just quit my job and have two weeks off until I start my next, last
> day, yay! So really good news for you!
>
> I expect to have this split out and the site info done this week.
>
> If you can't wait I released it for my (old) companies use on my
> website ( http://www.e-hoffman.org/released/repo )
> Sites are under repo as well
>
> Not heavily documented but, if you include that location and add this
> to your pom, you get the goodness.
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-enforcer-plugin</artifactId>
> <version>1.0-beta-1</version>
> <dependencies>
> <dependency>
> <groupId>org.apache.maven.enforcer.rules</groupId>
> <artifactId>maven-enforce-releasability</artifactId>
> <version>1.0.0</version>
> </dependency>
> </dependencies>
> <executions>
> <execution>
> <id>enforce</id>
> <configuration>
> <rules>
> <myCustomRule
> implementation="org.apache.maven.enforcer.rule.DependencyRule">
>
> <enforceNoSnapshotsOnRelease>false</enforceNoSnapshotsOnRelease>
>
> <enforceDependencyConvergence>true</enforceDependencyConvergence>
> </myCustomRule>
> </rules>
> </configuration>
> <goals>
> <goal>enforce</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
>
>
> Or you can wait on me, and then a dev with commit rights to get in to
> maven proper.
>
> Cheers,
>
> Rex
>
> On Wed, Sep 8, 2010 at 4:26 AM, Mark Hobson <ma...@gmail.com> wrote:
>> Were any issues raised to track the progress of these new rules? I'm
>> particularly interested in this one:
>>
>>> 2) Maven should have the option of forcing developers to ensure
>>> dependencies converge rather than relying on the "closest to the top"
>>> rule it uses by default. In large projects this can be problematic.
>>
>> Cheers,
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Filling in a few gaps with enforcer rules
Posted by Rex Hoffman <re...@e-hoffman.org>.
I haven't opened it yet as I still have to separate out functionality,
and write up some info for the site report. Already have the
integration test done.
I just quit my job and have two weeks off until I start my next, last
day, yay! So really good news for you!
I expect to have this split out and the site info done this week.
If you can't wait I released it for my (old) companies use on my
website ( http://www.e-hoffman.org/released/repo )
Sites are under repo as well
Not heavily documented but, if you include that location and add this
to your pom, you get the goodness.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.0-beta-1</version>
<dependencies>
<dependency>
<groupId>org.apache.maven.enforcer.rules</groupId>
<artifactId>maven-enforce-releasability</artifactId>
<version>1.0.0</version>
</dependency>
</dependencies>
<executions>
<execution>
<id>enforce</id>
<configuration>
<rules>
<myCustomRule
implementation="org.apache.maven.enforcer.rule.DependencyRule">
<enforceNoSnapshotsOnRelease>false</enforceNoSnapshotsOnRelease>
<enforceDependencyConvergence>true</enforceDependencyConvergence>
</myCustomRule>
</rules>
</configuration>
<goals>
<goal>enforce</goal>
</goals>
</execution>
</executions>
</plugin>
Or you can wait on me, and then a dev with commit rights to get in to
maven proper.
Cheers,
Rex
On Wed, Sep 8, 2010 at 4:26 AM, Mark Hobson <ma...@gmail.com> wrote:
> Were any issues raised to track the progress of these new rules? I'm
> particularly interested in this one:
>
>> 2) Maven should have the option of forcing developers to ensure
>> dependencies converge rather than relying on the "closest to the top"
>> rule it uses by default. In large projects this can be problematic.
>
> Cheers,
>
> Mark
>
> ---------------------------------------------------------------------
> 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: Filling in a few gaps with enforcer rules
Posted by Mark Hobson <ma...@gmail.com>.
Were any issues raised to track the progress of these new rules? I'm
particularly interested in this one:
> 2) Maven should have the option of forcing developers to ensure
> dependencies converge rather than relying on the "closest to the top"
> rule it uses by default. In large projects this can be problematic.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Filling in a few gaps with enforcer rules
Posted by Brian Fox <br...@infinity.nu>.
On Thu, Aug 26, 2010 at 12:39 PM, Rex Hoffman <re...@e-hoffman.org> wrote:
> Baptiste:
>
> I work in a large organization, where there are differing degrees of
> familiarity with maven.
> Most devs shy away from the release plugin for several reasons. One
> is the use of hudson and nexus.
>
I actually wrote those rules because we had a client that couldn't use
the release plugin for various reasons, but we wanted to encapsulate
the best practices contained in the plugin, so this is totally in line
with that.
> Brian:
>
> 1) The snapshot detection rules are similar rules, I'll look at them
> fully to see what differences exist. I wanted the error messages
> given to the user to be the path to each transitive dependency that
> was a snapshot (if the artifact was building a release), rather than
> suppling one.
>
Sure, maybe you can just patch the existing rule to your needs and we
can apply it.
> 2) One of my rules forces every module of a reactor build to have the
> same version number as the parent. Rather than only demanding that is
> a snapshot or not.
> (http://maven.apache.org/enforcer/enforcer-rules/requireReleaseVersion.html)
>
> 3) There is an extra rule coupled into the first (which it looks like
> I should decouple incase the rest of the rule shouldn't make it in
> because it is view as being too similar to
> http://maven.apache.org/enforcer/enforcer-rules/requireReleaseDeps.html)
> which forces developers to resolve transitive dependency version
> number conflicts at build rather than letting maven do it.
> All transitive dependency conflicts are displayed when the rules
> detects that it has been violated.
>
> Seems like 2 and 3 are unique enough to make it in as rules?
>
Yes
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Filling in a few gaps with enforcer rules
Posted by Rex Hoffman <re...@e-hoffman.org>.
Baptiste:
I work in a large organization, where there are differing degrees of
familiarity with maven.
Most devs shy away from the release plugin for several reasons. One
is the use of hudson and nexus.
Developers are not allowed to cut releases on their machines. Simply
checking in updated version numbers into hudson will alter the
behavior of the deploy step when hudson is run.
The artifact will be pushed to the releases directory in our nexus
instance, instead of the usual snapshot location, if the version
number of the artifact being built is a release.
We follow the apache versioning standard and have a branch structure
that is built to mirror that standard. Bug fix releases, for instance
are always cut off of a branch labeled 1.0.X, 1.1.X, etc...
So often devs don't cut branches for bug fix releases, eliminating a
lot of the usefulness of the release plugin.
Brian:
1) The snapshot detection rules are similar rules, I'll look at them
fully to see what differences exist. I wanted the error messages
given to the user to be the path to each transitive dependency that
was a snapshot (if the artifact was building a release), rather than
suppling one.
2) One of my rules forces every module of a reactor build to have the
same version number as the parent. Rather than only demanding that is
a snapshot or not.
(http://maven.apache.org/enforcer/enforcer-rules/requireReleaseVersion.html)
3) There is an extra rule coupled into the first (which it looks like
I should decouple incase the rest of the rule shouldn't make it in
because it is view as being too similar to
http://maven.apache.org/enforcer/enforcer-rules/requireReleaseDeps.html)
which forces developers to resolve transitive dependency version
number conflicts at build rather than letting maven do it.
All transitive dependency conflicts are displayed when the rules
detects that it has been violated.
Seems like 2 and 3 are unique enough to make it in as rules?
Rex
On Thu, Aug 26, 2010 at 12:52 AM, Baptiste MATHUS <ml...@batmat.net> wrote:
> 2010/8/25 Rex Hoffman <re...@e-hoffman.org>
>
>> So I felt there are few gaps in the maven release process (and
>> enforcing a project or a reactor project is releasable).
>>
>> Perceived gaps:
>>
>> 1) Maven should fail a build if it is building a release version
>> number and any of it's dependencies (including transitive dependencies
>> on plugins, or inherited, etc...) are snapshot dependencies.
>>
>
> Not sure to understand. Normally, the maven release (via the release plugin)
> already does it. You can release a version if you don't replace all
> snapshots with release versions. What doesn't work for you?
>
> Cheers
>
> --
> Baptiste <Batmat> MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
> nbsp;!
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Filling in a few gaps with enforcer rules
Posted by Baptiste MATHUS <ml...@batmat.net>.
2010/8/25 Rex Hoffman <re...@e-hoffman.org>
> So I felt there are few gaps in the maven release process (and
> enforcing a project or a reactor project is releasable).
>
> Perceived gaps:
>
> 1) Maven should fail a build if it is building a release version
> number and any of it's dependencies (including transitive dependencies
> on plugins, or inherited, etc...) are snapshot dependencies.
>
Not sure to understand. Normally, the maven release (via the release plugin)
already does it. You can release a version if you don't replace all
snapshots with release versions. What doesn't work for you?
Cheers
--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
nbsp;!