Artifacts with extensions longer than fours characters breaks repository
scanning.
----------------------------------------------------------------------------------
Key: MRM-703
URL: http://jira.codehaus.org/browse/MRM-703
Project: Archiva
Issue Type: Bug
Components: repository scanning
Affects Versions: 1.0.1
Environment: linux (RHEL5), standalone archiva
Reporter: Jim Jackson
Priority: Minor
Attachments: archiva-artifact-extension.patch
We store Mac OS X jnilib artifacts in our unmanaged maven repository. During
our transition to a standalone archiva 1.0.1 instance running on linux (RHEL5),
I was able to deploy our jnilib artifacts, but I was not able to download them
as a dependency in a different project. I received the dependency not found in
any repository error. When running the repository scan, the log file showed
this:
3076623 [pool-2-thread-1] ERROR
org.apache.maven.archiva.repository.scanner.RepositoryScanner:default -
Consumer [metadata-updater] had an error when processing file
[/var/www/html/managed-maven2/fobs4jmf/macosx/i386/libfobs4jmf/0.4.1.4-SNAPSHOT/libfobs4jmf-0.4.1.4-20080217.211715-4.jnilib]:
Unable to convert to artifact reference:
fobs4jmf/macosx/i386/libfobs4jmf/0.4.1.4-SNAPSHOT/libfobs4jmf-0.4.1.4-20080217.211715-4.jnilib
org.apache.maven.archiva.consumers.ConsumerException: Unable to convert to
artifact reference:
fobs4jmf/macosx/i386/libfobs4jmf/0.4.1.4-SNAPSHOT/libfobs4jmf-0.4.1.4-20080217.211715-4.jnilib
at
org.apache.maven.archiva.consumers.core.MetadataUpdaterConsumer.processFile(MetadataUpdaterConsumer.java:167)
at
org.apache.maven.archiva.repository.scanner.functors.ConsumerProcessFileClosure.execute(ConsumerProcessFileClosure.java:57)
at
org.apache.commons.collections.functors.IfClosure.execute(IfClosure.java:117)
at
org.apache.commons.collections.CollectionUtils.forAllDo(CollectionUtils.java:388)
at
org.apache.maven.archiva.repository.scanner.RepositoryScannerInstance.directoryWalkStep(RepositoryScannerInstance.java:138)
at
org.codehaus.plexus.util.DirectoryWalker.fireStep(DirectoryWalker.java:173)
at
org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:391)
at
org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:385)
...
Caused by: org.apache.maven.archiva.repository.layout.LayoutException: Invalid
path to Artifact: filename format is invalid,expected timestamp format in
filename.
at
org.apache.maven.archiva.repository.content.DefaultPathParser.toArtifactReference(DefaultPathParser.java:131)
at
org.apache.maven.archiva.repository.content.AbstractDefaultRepositoryContent.toArtifactReference(AbstractDefaultRepositoryContent.java:54)
at
org.apache.maven.archiva.repository.content.ManagedDefaultRepositoryContent.toArtifactReference(ManagedDefaultRepositoryContent.java:330)
at
org.apache.maven.archiva.consumers.core.MetadataUpdaterConsumer.processFile(MetadataUpdaterConsumer.java:161)
I narrowed down the issue to a regex in
org.apache.maven.archiva.repository.content.FilenameParser. The artifact
filename extension is limited to four characters and the version was coming
back with '0.4.1.4-20080217.211715-4.j'. By changing the extension length to
six characters, the issue was resolved.
The attached patch sets no length on an artifact extension enabling support for
.dylib and .jnilib files for mac os x.
org.apache.maven.archiva.repository.content.FilenameParser
43c43
< private static final Pattern extensionPattern = Pattern.compile(
"(.tar.gz$)|(.tar.bz2$)|(.[a-z0-9]{1,4}$)",
---
> private static final Pattern extensionPattern = Pattern.compile(
> "(.tar.gz$)|(.tar.bz2$)|(.[a-z0-9]*$)",
Jim Jackson
--
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
