maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Max Bowsher <m...@mxtelecom.com>
Subject MNG-2456: Maven Archiver creates incorrect Class-Path entry in Manifest for deployed snapshots
Date Fri, 06 Oct 2006 10:49:23 GMT
Hi. I've recently been looking at MNG-2456 and I've reached the point
where I could use some insight from those more familiar with the core code.

In summary:
The Maven-Archiver uses the file part of the artifact's filename to
create the Class-Path entries in the Manifest.
This works fine for released artifacts and non-deployed snapshots. The
problem occurs when using a deployed snapshot as the assembly plugin
will copy the dependency as
${artifactId}-${version}-timestampedversion.jar and the entry in the
Class-Path will be ${artifactId}-${version}-SNAPSHOT.jar
thus use of java -jar <jarfile> will fail because of the differing names.


Investigating the problem led me to maven-artifact-manager's
DefaultArtifactResolver.resolve(), which contains the following code block:


>                 if ( artifact.isSnapshot() && !artifact.getBaseVersion().equals(
artifact.getVersion() ) )
>                 {
>                     String version = artifact.getVersion();
>                     artifact.selectVersion( artifact.getBaseVersion() );
>                     File copy = new File( localRepository.getBasedir(), localRepository.pathOf(
artifact ) );
>                     if ( resolved || !copy.exists() )
>                     {
>                         // recopy file if it was reresolved, or doesn't exist.
>                         try
>                         {
>                             FileUtils.copyFile( destination, copy );
>                         }
>                         catch ( IOException e )
>                         {
>                             throw new ArtifactResolutionException(
>                                 "Unable to copy resolved artifact for local use: " +
e.getMessage(), artifact,
>                                 remoteRepositories, e );
>                         }
>                     }
>                     artifact.setFile( copy );
>                     artifact.selectVersion( version );
>                 }

There are several issues with that, but the most interesting one as far
as MNG-2456 is concerned is: Why does this code deliberately adjust the
artifact's file property from the YYYYMMDD.HHMMSS-N.jar form to the
SNAPSHOT.jar form?
(3rd line from the bottom, "artifact.setFile( copy )")


One question that would help a *lot* in determining what the proper
direction for this bug is, is:

   Why does Maven copy timestamped snapshot artifacts to
   SNAPSHOT artifacts at all?

One possible reason that I can see is as a courtesy to non-Maven tools
making use of the local repository. As an example, take
"mvn eclipse:eclipse" - because of this copying behaviour, it becomes
possible for the generated Eclipse .classpath file to remain valid even
when later snapshots are downloaded to the local repository.

Is this the only reason for this behaviour?

In any case, it looks to me that there's reasonable cause for artifacts
to provide two different File getters, one to get the filename based on
the "version", and one to get the filename based on the "baseVersion".

What do people think about this?

Thanks for reading.

-- 
Max Bowsher <maxb@mxtelecom.com>
http://www.mxtelecom.com


Mime
View raw message