Sorry to top reply, but my summarised response is:

- there are valid use cases for plugins in more than one repository
- Maven should always be using the repository with the newest version available. If it's not, then it's a bug.

If you are using a version > the last release, and > the snapshot version then it should work out just fine (though I also recommend not using snapshot plugin repositories at all in this case).

The gotcha might be that 1.2-INTERNAL is evaluated as < 1.2 (and 1.2- SNAPSHOT) - is that the issue?

What about hardcoding the plugin version in your POM?

- Brett

On 16/12/2006, at 8:31 AM, Barrie Treloar wrote:

On 12/16/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote:

Thanks Kenney,

- colleagues will automatically get the snapshot version of the plugin, but due to a a bug in maven 2.0.4 they could end up with the wrong plugin in the reactor. For instance: mvn o.a.m.p:maven-assembly-plugin:2.3-SNAPSHOT:directory will first list the 2.3 version, and
     in the lifecycle fork maven will resolve to 2.2.
[del]
So, basically: do NOT specify the maven plugin snapshot repo anywhere, but only an internal one, and manually manage what snapshot plugins are hosted there. It serves as an override of the non-snapshot
central repo.


We are finding that this approach isn't working when our colleagues do
not have the new artifact.  This is because maven loops through all
repositories to merge the metadata from pluginRepository company.repo
and central to correctly find the new version but then also updates
the metadata to use the current repository in the loop, so it sets the
repo to company.repo and then central, so when the wagon attempts to
get the artifact it tries to contact central which of course does not
have this artifact.

This is the problem we are attempting to resolve, at least two other
people have the same problem.

When I wrote the wiki guide I never noticed this problem because I
have mvnproxy in the way and mvnproxy was aggregating both
company.repo and central, so even though maven was contacting central,
mvnproxy would be returning the artifact from company.repo for me.

The use of a snapshot repository does not affect this feature of maven.

I'm fairly confident that what I am describing is correct as I've step
debugged through artifact resolution to replicate what others were
seeing once I turned off mvnproxy.

I'm think this is working for you at your site because
1) you are using snapshot versions and not releases
2) you do not include any  external snapshot repositories and hence
there is only ever one repository that mathces your artifact and thus
never hit this problem.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to