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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
