[jira] Commented: (MRM-658) org.apache.maven.archiva.repository.content.FilenameParser is unable to determine unique snapshot versions with specific version names

["Napoleon Esmundo C. Ramirez (JIRA)" <ji...@codehaus.org>]

    [ http://jira.codehaus.org/browse/MRM-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137186#action_137186 ] 

Napoleon Esmundo C. Ramirez commented on MRM-658:
-------------------------------------------------

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/

> org.apache.maven.archiva.repository.content.FilenameParser is unable to determine unique snapshot versions with specific version names
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: MRM-658
>                 URL: http://jira.codehaus.org/browse/MRM-658
>             Project: Archiva
>          Issue Type: Bug
>    Affects Versions: 1.0
>         Environment: windows, maven2
>            Reporter: Markus Nolte
>            Assignee: Maria Odea Ching
>             Fix For: 1.1
>
>         Attachments: unit_test.snippet
>
>
> 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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira