jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • Maven 2 & 3
  • MNG-2903

Snapshots are being packaged with datestamps in their filename instead of "SNAPSHOT",

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Critical Critical
  • Resolution: Unresolved
  • Affects Version/s: 2.0.5
  • Fix Version/s: Issues to be reviewed for 3.x
  • Component/s: Artifacts and Repositories
  • Labels:
    None
  • Complexity:
    Intermediate

Description

When I run mvn package on a project, it collects all the correct and most recent
jar files for me in the lib directory, however in the zip file instead
of naming them <project>-3.0-SNAPSHOT.jar (for example) it will name
them <project>-20070318.080720-37.jar.

Meanwhile in the project's own jar file, the manifest will point to
./lib/<project>-3.0-SNAPSHOT.jar. This means the packaged project does
not run.

It doesn't do this for every single dependency snapshot, and I can't
seem to work out a pattern as to which get named correctly and which
don't.

I have two repositories in my pom file:

<repositories>
<repository>
<id>common-repository</id>
<name> Common Repository</name>
<url>http://repository/common-repository</url>
</repository>
<repository>
<id>snapshot-repository</id>
<name>Trovix Snapshot Repository</name>
<url>http://repository/snapshots</url>
<snapshots>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
</snapshots>
</repository>
</repositories>

If I try to disable them manually (and use only the local repository),
the problem persists. However, this is where it gets weird. If I
unplug my network cable - my package file is created perfectly!

However - if I unplug my network cable with the snapshot repository
removed, it creates the package incorrectly once again!

This seems to be the key part of what is making it work (blacklisting
the snapshot-repository):

[INFO] task-segment: [package]
[INFO]
---------------------------------------------------------------------
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] snapshot com:com.benchmark:3.0-SNAPSHOT: checking for updates
from snapshot-repository
[WARNING] repository metadata for: 'snapshot
com:com.benchmark:3.0-SNAPSHOT' could not be retrieved from repository:
snapshot-repository due to an error: Error transferring file
[INFO] Repository 'snapshot-repository' will be blacklisted
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [jar:jar]

I have also run mvn -X package, and the debug log shows that it thinks
it is collecting all the correct SNAPSHOT named jars, even though it
then stores the date-stamped ones.

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
Mario Camou added a comment - 23/Nov/11 5:44 AM

This problem is affecting us, we're using the copy-resources plugin which copies the resource with the -SNAPSHOT name, but the JAR plugin adds the timestamped name to the Manifest. For the moment I've manually added the -SNAPSHOT to the classpath with the manifestEntries/Class-Path tag but it would be excellent to have the plugin work correctly.

Show
Mario Camou added a comment - 23/Nov/11 5:44 AM This problem is affecting us, we're using the copy-resources plugin which copies the resource with the -SNAPSHOT name, but the JAR plugin adds the timestamped name to the Manifest. For the moment I've manually added the -SNAPSHOT to the classpath with the manifestEntries/Class-Path tag but it would be excellent to have the plugin work correctly.
Hide
Permalink
Mario Camou added a comment - 23/Nov/11 5:46 AM

I forgot to indicate that we're using Maven 3.0.3.

Show
Mario Camou added a comment - 23/Nov/11 5:46 AM I forgot to indicate that we're using Maven 3.0.3.
Hide
Permalink
Joerg Schaible added a comment - 23/Nov/11 6:51 AM

The difference is based on the fact, how the snapshot artifact was added to your local repository. If it was downloaded from a remote repository, you get the time stamped version, if it was installed locally, you get the snapshot. And yes - this behavior is very annoying, because it actually breaks applications.

Show
Joerg Schaible added a comment - 23/Nov/11 6:51 AM The difference is based on the fact, how the snapshot artifact was added to your local repository. If it was downloaded from a remote repository, you get the time stamped version, if it was installed locally, you get the snapshot. And yes - this behavior is very annoying, because it actually breaks applications.
Hide
Permalink
Hamster added a comment - 24/Nov/11 4:02 AM

Hi, I am using Maven 3.0.1 and experiencing same issue.

Show
Hamster added a comment - 24/Nov/11 4:02 AM Hi, I am using Maven 3.0.1 and experiencing same issue.

People

  • Assignee:
    Unassigned
    Reporter:
    Tim Cederman
Vote (6)
Watch (4)

Dates

  • Created:
    26/Mar/07 5:24 PM
    Updated:
    24/Nov/11 4:02 AM
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.