Archiva

mda5 and sha are not generated for snapshot jars

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.2.2
  • Fix Version/s: 1.3.1
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    1

Description

I found a way to reproduce our problems that we have with uploading
SNAPSHOT versions via the web-interface.

We tried with the following files
cocoon-chaperon-impl-1.0.0-SNAPSHOT.pom
cocoon-chaperon-impl-1.0.0-SNAPSHOT.jar

For the version we put in the web form 1.0.0-SNAPSHOT.

The result is that archiva creates the mda5 and sha for the pom but not
for the jar.

As soon we change the name of the version to 1.0.0-SNAPSHOTS. It works
fine.

It seems that the version *-SNAPSHOT is not working. What is the best
approach to debug to find out what is going on and why archiva is not
creating the mda5 and sha file.

It sounds that the following threas may be releated to this issue:
http://archiva.markmail.org/search/?q=Strange%20deploy%20problem#query:Strange%20deploy%20problem+page:1+mid:55mubbiv5khgk4qu+state:results

On Mon, 2010-01-18 at 19:00 +0800, Deng Ching wrote:
The problem seems to be in the create-missing-checksums consumer. The
> consumer is looking for a jar with a -SNAPSHOT in the filename but the
> actual file has a unique (timestamp + build number) snapshot version so a
> "no such file or directory" error occurs. It works if the version is
> -SNAPSHOTS because it was not identified as a SNAPSHOT (from the extra 'S'
> at the end) and therefore the version wasn't converted to a unique version
> format.
>

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Thorsten Scherler added a comment - - edited

A related observation is when using

mvn deploy:deploy-file -Durl=http://archiva.sadesi.es/repository/snapshots-SADESI \
-DrepositoryId=snapshots-SADESI \
-Dfile=/home/thorsten/.m2/repository/org/apache/cocoon/cocoon-chaperon-impl/1.0.0-SNAPSHOT/cocoon-chaperon-impl-1.0.0-SNAPSHOT.jar \
-DpomFile=/home/thorsten/.m2/repository/org/apache/cocoon/cocoon-chaperon-impl/1.0.0-SNAPSHOT/cocoon-chaperon-impl-1.0.0-SNAPSHOT.pom \
-DgroupId=org.apache.cocoon \
-DartifactId=cocoon -Dversion=1.0.0-SNAPSHOT

the actual file has a unique (timestamp + build number) snapshot version but does not have a file with a -SNAPSHOT in the filename. This way it cannot be resolved later on when resolving the dependencies in our project.

Seems that the "create-missing-checksums consumer" should read the meta information of the artifact and use the latest time stamped version

Show
Thorsten Scherler added a comment - - edited A related observation is when using mvn deploy:deploy-file -Durl=http://archiva.sadesi.es/repository/snapshots-SADESI \ -DrepositoryId=snapshots-SADESI \ -Dfile=/home/thorsten/.m2/repository/org/apache/cocoon/cocoon-chaperon-impl/1.0.0-SNAPSHOT/cocoon-chaperon-impl-1.0.0-SNAPSHOT.jar \ -DpomFile=/home/thorsten/.m2/repository/org/apache/cocoon/cocoon-chaperon-impl/1.0.0-SNAPSHOT/cocoon-chaperon-impl-1.0.0-SNAPSHOT.pom \ -DgroupId=org.apache.cocoon \ -DartifactId=cocoon -Dversion=1.0.0-SNAPSHOT the actual file has a unique (timestamp + build number) snapshot version but does not have a file with a -SNAPSHOT in the filename. This way it cannot be resolved later on when resolving the dependencies in our project. Seems that the "create-missing-checksums consumer" should read the meta information of the artifact and use the latest time stamped version
Hide
Permalink
Maria Catherine Tan added a comment -

Added a patch for this fix with unit test.

Use the actual file, which has a timestamp + build number version, when creating a repository task for a snapshot artifact.

Show
Maria Catherine Tan added a comment - Added a patch for this fix with unit test. Use the actual file, which has a timestamp + build number version, when creating a repository task for a snapshot artifact.
Hide
Permalink
Thorsten Scherler added a comment -

Hi Maria,
thank you very much for your patch. We did a quick check and it seems to close this issue. ATM we cannot make all test case that we planed but we will do this Monday. As soon we have the result I will update the ticket again. Thanks agin Maria.

Show
Thorsten Scherler added a comment - Hi Maria, thank you very much for your patch. We did a quick check and it seems to close this issue. ATM we cannot make all test case that we planed but we will do this Monday. As soon we have the result I will update the ticket again. Thanks agin Maria.
Hide
Permalink
Thorsten Scherler added a comment -

Ok we tested and the upload issue is fixed but the problem is to download the snapshots. It stores a file with the timestamp but returns a 404 for the snapshot.

Show
Thorsten Scherler added a comment - Ok we tested and the upload issue is fixed but the problem is to download the snapshots. It stores a file with the timestamp but returns a 404 for the snapshot.
Hide
Permalink
Maria Odea Ching added a comment -

Filed a separate issue for the problem in downloading the snapshots from artifact info page, see MRM-1349. Thanks!

Show
Maria Odea Ching added a comment - Filed a separate issue for the problem in downloading the snapshots from artifact info page, see MRM-1349. Thanks!
Hide
Permalink
Maria Odea Ching added a comment -

Thanks for the patch Marica! Patch applied to 1.3.x branch -r916197 and merged to trunk in -r916217. I updated the timestamp variable name to avoid conflict when I merged this to trunk.

Show
Maria Odea Ching added a comment - Thanks for the patch Marica! Patch applied to 1.3.x branch -r916197 and merged to trunk in -r916217. I updated the timestamp variable name to avoid conflict when I merged this to trunk.

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.