You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jörg Schaible <Jo...@Elsag-Solutions.com> on 2007/11/23 09:30:22 UTC
How are the multiproject artifacts resolved in release:prepare?
Hi folks,
can someone shed some light onto the release:prepare mechanism?
We use since long ago an own plugin, that accesses a secondary artifact of a dependency. This worked like charm ... until now. We have now the new situation, that the secondary artifact is build in the same multi project build by one subproject and it is used in another one. However, release:prepare fails now, since the subproject that makes usage of the secondary artifact always tries to access the final-but-not-yet-release version.
The Mojo does runs through the list of direct dependencies and searches for the configured artifact (groupId and artifactId have been configured, only one definition possible), creates the Artifact instance for the secondary one and resolves it (using the same version as the one of the direct artifact):
public void execute() throws MojoExecutionException, MojoFailureException
{
Artifact descriptors = null;
final Set dependencies = project.getArtifacts();
if (dependencies != null && !dependencies.isEmpty()) {
for (final Iterator iter = dependencies.iterator(); iter.hasNext();) {
final Artifact artifact = (Artifact) iter.next();
if (artifact.getGroupId().equals(groupId) && artifact.getArtifactId().equals(artifactId)) {
descriptors = artifact;
break;
}
}
}
if (descriptors == null) {
throw new MojoFailureException("There is no dependency of with '" + groupId + ':' + artifactId + "'");
}
descriptors = factory.createArtifactWithClassifier(groupId, artifactId, descriptors.getVersion(), "ejb-descriptors", "descriptors");
try {
resolver.resolve(descriptors, remoteRepos, local);
} catch (ArtifactResolutionException e) {
throw new MojoExecutionException("Unable to resolve artifact.", e);
} catch (ArtifactNotFoundException e) {
throw new MojoExecutionException("Unable to find artifact.", e);
}
...
}
So, why is the "normal" dependency mechanism able to access the artifacts with the final release numbers in the target directory during release proparation and the code snippet from above fails to find them? How "injects" the release plugin those not yet installed artifacts? What do I have to do different?
Any help/insight highly welcome.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: How are the multiproject artifacts resolved in release:prepare?
Posted by Graham Leggett <mi...@sharp.fm>.
On Fri, November 23, 2007 3:35 pm, Jörg Schaible wrote:
> I know why my plugin fails, but I don't know why other maven plugins can
> handle the situation. I did now a bad hack and will look for the attached
> artifact at the same location as the main artifact is located and only if
> I cannot find it locally I will use the ArtifactResolver. Nevertheless I
> am interested in the "proper" solution.
Artificts should only ever be found in one of two locations: the current
project, or the local repository (after possibly downloading it fronm a
central repository, if appropriate).
> This is dangerous and highly discouraged. We have quite a lot of artifacts
> and if the release manager simply performs "release:prepare", but fails to
> perform the release itself, the build will at least fail for the next
> artifact that is dependend on the new release.
This makes no sense - why would the build fail because an artifact is
present? The build should only fail if the artifact is absent, which it
will be if default release:prepare behaviour is followed.
If the concern is that possible unreleased jars end up in the local
repository, then the real problem is that release:prepare is trying to run
a build *after* the change of version number from SNAPSHOT to released,
instead of before.
> With your variant the
> prepared, but not yet released artifact is found in the release manager's
> local repository and he will never recognize that the final artifact has
> neither been build nor deployed.
In our case the person performing a release is responsible for running
both release:prepare and release:perform, making this largely a non issue.
The underlying problem is that maven supports a single common local repo
to look for all artifacts, and I personally believe that it should work
this way. The release:prepare tests should be ideally be done using
SNAPSHOT version numbers, and this problem can be worked around.
Regards,
Graham
--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: How are the multiproject artifacts resolved in release:prepare?
Posted by Jörg Schaible <Jo...@Elsag-Solutions.com>.
Graham Leggett wrote:
> On Fri, November 23, 2007 10:30 am, Jörg Schaible wrote:
>
>> We use since long ago an own plugin, that accesses a secondary
>> artifact of a dependency. This worked like charm ... until now. We
>> have now the new situation, that the secondary artifact is build in
>> the same multi project build by one subproject and it is used in
>> another one. However, release:prepare fails now, since the
>> subproject that makes usage of the secondary artifact always tries
>> to access the final-but-not-yet-release version.
>
> This looks suspiciously like a problem we encountered, caused by the
> assumption of the release plugin that elements within a multi-module
> project won't depend on other elements in the same
> multi-module project,
> and where the entire multi-module project has a common version number.
>
> The cause is because the goal that is used to test the build
> of the code,
> doesn't go as far as deploying the artifacts under test into the local
> repository, and so module+1 doesn't see the artifacts just
> generated by
> module or module-1.
I know why my plugin fails, but I don't know why other maven plugins can handle the situation. I did now a bad hack and will look for the attached artifact at the same location as the main artifact is located and only if I cannot find it locally I will use the ArtifactResolver. Nevertheless I am interested in the "proper" solution.
> The workaround is to override this goal to be "clean
> install", which does
> deploy the artifacts into the repo, like this in your root pom:
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-release-plugin</artifactId>
> <version>2.0-beta-6</version>
> <configuration>
> <preparationGoals>clean install</preparationGoals>
> </configuration>
> </plugin>
This is dangerous and highly discouraged. We have quite a lot of artifacts and if the release manager simply performs "release:prepare", but fails to perform the release itself, the build will at least fail for the next artifact that is dependend on the new release. With your variant the prepared, but not yet released artifact is found in the release manager's local repository and he will never recognize that the final artifact has neither been build nor deployed.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How are the multiproject artifacts resolved in release:prepare?
Posted by Graham Leggett <mi...@sharp.fm>.
On Fri, November 23, 2007 10:30 am, Jörg Schaible wrote:
> We use since long ago an own plugin, that accesses a secondary artifact of
> a dependency. This worked like charm ... until now. We have now the new
> situation, that the secondary artifact is build in the same multi project
> build by one subproject and it is used in another one. However,
> release:prepare fails now, since the subproject that makes usage of the
> secondary artifact always tries to access the final-but-not-yet-release
> version.
This looks suspiciously like a problem we encountered, caused by the
assumption of the release plugin that elements within a multi-module
project won't depend on other elements in the same multi-module project,
and where the entire multi-module project has a common version number.
The cause is because the goal that is used to test the build of the code,
doesn't go as far as deploying the artifacts under test into the local
repository, and so module+1 doesn't see the artifacts just generated by
module or module-1.
The workaround is to override this goal to be "clean install", which does
deploy the artifacts into the repo, like this in your root pom:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.0-beta-6</version>
<configuration>
<preparationGoals>clean install</preparationGoals>
</configuration>
</plugin>
Regards,
Graham
--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org