Archiva

org.apache.maven.archiva.repository.content.FilenameParser is unable to determine unique snapshot versions with specific version names

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Cannot Reproduce
  • Affects Version/s: 1.0
  • Fix Version/s: 1.1
  • Component/s: None
  • Labels:
    None
  • Environment:
    windows, maven2
  • Testcase included:
    yes
  • Number of attachments :
    1

Description

After deploying an artifact with version trunk-SNAPSHOT with unique version set to true, I am not able to download the artifact anymore. The reason is the org.apache.maven.archiva.repository.content.DefaultPathParser throwing a LayoutException "filename format is invalid, expected timestamp format in filename".

The problem is the determination of an unique snapshot in the given file path using the FilenameParser.nextVersion method that uses VersionUtil.isVersion to determine if the parsed section of a given filename is part of a version or not.
The VersionUtil uses a VersionMegaPattern to identify version parts in a string, this does not work on any possible version name.

A quick solution for me was to patch the VersionUtil and add 'trunk' to the VersionMegaPattern, but a more stable solution should use the already identified baseVersion (trunk-SNAPSHOT in this case) to determine the version and timestamp parts in a given or to skip path validity checks.

I added an additional unit test snippet for org.apache.maven.archiva.repository.content.DefaultPathParserTest to reproduce the problem

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Maria Odea Ching added a comment - - edited

Hmm, the test case is not failing for me. Could you verify this in trunk (1.1-SNAPSHOT) too?
Thanks!

Show
Maria Odea Ching added a comment - - edited Hmm, the test case is not failing for me. Could you verify this in trunk (1.1-SNAPSHOT) too? Thanks!
Hide
Permalink
Maria Odea Ching added a comment -

I cannot replicate this too when I tried requesting (using Maven) for an artifact with a 1.0-trunk-SNAPSHOT version. I also had the uniqueVersion set to true when I deployed the 1.0-trunk-SNAPSHOT artifact in the Archiva repo.

Could someone verify this as well?
Thanks..

Show
Maria Odea Ching added a comment - I cannot replicate this too when I tried requesting (using Maven) for an artifact with a 1.0-trunk-SNAPSHOT version. I also had the uniqueVersion set to true when I deployed the 1.0-trunk-SNAPSHOT artifact in the Archiva repo. Could someone verify this as well? Thanks..
Hide
Permalink
Nap Ramirez added a comment -

I tried it in 1.0.2 and it seemed fixed to me. I tried it by deploying a an artifact like com.mycompany.app:my-app:1.0-internal-2.0-SNAPSHOT which created the entry in localhost:8080/archiva/repository/snapshots/com/mycompany/app/my-app/1.0-internal-2.0-SNAPSHOT/

Show
Nap Ramirez added a comment - I tried it in 1.0.2 and it seemed fixed to me. I tried it by deploying a an artifact like com.mycompany.app:my-app:1.0-internal-2.0-SNAPSHOT which created the entry in localhost:8080/archiva/repository/snapshots/com/mycompany/app/my-app/1.0-internal-2.0-SNAPSHOT/
Hide
Permalink
Maria Odea Ching added a comment -

Thanks for verifying this Nap!
Closing this as issue as 'Cannot Reproduce'.

Show
Maria Odea Ching added a comment - Thanks for verifying this Nap! Closing this as issue as 'Cannot Reproduce'.

People

Vote (3)
Watch (3)

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.