You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Barrie Treloar <ba...@gmail.com> on 2006/12/15 01:27:38 UTC
[m2] Dev help needed: Should multiple repositories be able to host an artifact, potentially with different versions
See http://www.nabble.com/forum/ViewPost.jtp?post=7884079&framed=y&skin=177
for full discussion.
The problem is that a plugin contains defects that have not yet been
resolved in a release.
The defect may be fixed in a snapshot version or there may be an
unapplied patch available.
The releases of your companies artifacts can't use snapshot versions
and internally patched versions of the plugins needs to be made
available to all developers.
My original stab at providing process guidance around this is at
http://docs.codehaus.org/display/MAVENUSER/Patching+Maven+Plugins.
Other people have attempted to follow this and have found shortcomings
because the repository for all versions of an artifact is based on
that last repository that had metadata for the artifact. e.g.
internal_plugins and central both have metadata for plugin X, the
repository is set to internal_plugins, which also contains the latest
version, and then the repository reset to central. At this point the
build process fails because central does not contain the specified
version.
I can't find any decent use cases for why you want an artifact to be
available from multiple repositories. The two I can think of are
1) an artifact moves to another repository, e.g. codehaus to maven.
In this case the artifiact id usuallu changes too from a form of
<name>-maven-plugin to maven-<name>-plugin. So this problem would
never have been noticed before.
2) you are creating an internal patch repository.
The current work around is to change the artifactId as part of the
plugin patching process.
I would like the opinion of some maven-devs on this and whether it
makes sense to support this better in maven, or to continue with the
workarounds available.
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Dev help needed: Should multiple repositories be able to host an artifact, potentially with different versions
Posted by Barrie Treloar <ba...@gmail.com>.
On 12/18/06, Brett Porter <br...@apache.org> wrote:
> 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?
The gotcha is that the metadata merging of multiple repositories is
when the artifact's repository value is set. In the next step when
version resolution occurs the incorrect artifact repository value is
used.
Therefore Metadata merging must include the repository in the
versioning information.
I think I can patch it to do so, but its a large enough change that I
am uncomfortable with the potential changes this will cause.
If I can
1) work out a way to have multiple versions of maven installed on my
machine so I can switch between them for independent development that
would be tops. I need separate mvn binaries and repositories (I
assume maven devs have this exact problem, how do they solve it?)
2) work out how to create appropriate unit tests to expose the problem
prior to development. This may be more difficult due to the component
nature of how this gets resolved.
However, since I have a workaround using mvnproxy, this is going down
my priority list.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Dev help needed: Should multiple repositories be able to host an artifact, potentially with different versions
Posted by Brett Porter <br...@apache.org>.
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 <ke...@apache.org> 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: 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: [m2] Dev help needed: Should multiple repositories be able to host an artifact, potentially with different versions
Posted by Barrie Treloar <ba...@gmail.com>.
On 12/16/06, Kenney Westerhof <ke...@apache.org> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Dev help needed: Should multiple repositories be able to host
an artifact, potentially with different versions
Posted by Kenney Westerhof <ke...@apache.org>.
Hi,
I'm following this setup/process:
- We have the following repository definitions in the root pom of the projects:
* repository central - inherited, for normal non-snapshot artifacts
* pluginRepository central - inherited, for normal non-snapshot plugins
* repository company.repo for releases of normal artifacts
* repository company.snapshot.repo for snapshots of normal artifacts
* pluginRepository company.repo for releases of plugins (company local plugins)
* pluginRepository company.snapshot.repo for snapshots of plugins
(both company local and official maven/mojo plugins)
- By default, there are only company local plugins present in the company.* repositories.
No snapshot versions of maven/mojo plugins are used.
- When I fix a bug in a maven plugin, and I don't deploy it to the people.apache snapshot repo,
I mvn install it locally and then manually copy the plugin dir (with only my version)
to the pluginRepository company.snapshot.repo.
The filename contains -SNAPSHOT so you will overwrite previous versions. Maven should pick up on
this but it might not.
It's safer to do this:
mvn deploy -DaltDeploymentRepository=company.snapshot.repo:default:scp://repo.company.com/path/
- 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.
To overcome this, I specify the version for the bugfixed-plugins in pluginManagement in the root pom.
This way you're sure that your fixed version is used.
If you require non-snapshot versions of plugins because you need to release, you can follow
the process described at the wiki page you listed, to change the version to -INTERNAL.
Another solution (not tested) is to specify the timestamped version instead of using the SNAPSHOT
keyword - I'm hoping here that the release plugin will not complain then.
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.
This approach works quite well for me.
-- Kenney
Barrie Treloar wrote:
> See http://www.nabble.com/forum/ViewPost.jtp?post=7884079&framed=y&skin=177
> for full discussion.
>
> The problem is that a plugin contains defects that have not yet been
> resolved in a release.
> The defect may be fixed in a snapshot version or there may be an
> unapplied patch available.
>
> The releases of your companies artifacts can't use snapshot versions
> and internally patched versions of the plugins needs to be made
> available to all developers.
>
> My original stab at providing process guidance around this is at
> http://docs.codehaus.org/display/MAVENUSER/Patching+Maven+Plugins.
> Other people have attempted to follow this and have found shortcomings
> because the repository for all versions of an artifact is based on
> that last repository that had metadata for the artifact. e.g.
> internal_plugins and central both have metadata for plugin X, the
> repository is set to internal_plugins, which also contains the latest
> version, and then the repository reset to central. At this point the
> build process fails because central does not contain the specified
> version.
>
> I can't find any decent use cases for why you want an artifact to be
> available from multiple repositories. The two I can think of are
>
> 1) an artifact moves to another repository, e.g. codehaus to maven.
> In this case the artifiact id usuallu changes too from a form of
> <name>-maven-plugin to maven-<name>-plugin. So this problem would
> never have been noticed before.
>
> 2) you are creating an internal patch repository.
>
> The current work around is to change the artifactId as part of the
> plugin patching process.
>
> I would like the opinion of some maven-devs on this and whether it
> makes sense to support this better in maven, or to continue with the
> workarounds available.
>
> Thanks.
>
> ---------------------------------------------------------------------
> 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: [m2] Dev help needed: Should multiple repositories be able to host an
artifact, potentially with different versions
Posted by Aa...@Globus.ch.
Hello,
> The releases of your companies artifacts can't use snapshot versions
> and internally patched versions of the plugins needs to be made
> available to all developers.
I solved these issues by writing my own proxy which can rewrite URLs (so
even if someone configures Maven to download something from Xyz.com, it
will still go to Sateh, no matter what). Plus I can "blind" maven (return
404 for any URL I like).
This way, I can make a beta of the site plugin (which contains vital bug
fixes for me) available to all developers but maven will not be able to
download the snapshots of the source or compiler plugin.
As a last resort, the proxy will look into a "patches" tree for files. The
search order is: patches, allow/deny rules, rewrite rules.
This allows me to fix any bugs by using my own patches, let maven see what
it should (and nothing else) and force all external connections to one
single maven repository.
Regards,
--
Aaron Digulla
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org