[MRM-703] Artifacts with extensions longer than fours characters breaks repository scanning.

• Type: Bug
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 1.0.1
• Fix Version/s: 1.0.2
• Component/s: repository scanning
• Environment: linux (RHEL5), standalone archiva
• Flags: Patch
• Assignee: Brett Porter
• Reporter: Jason Jackson
• Created: 18/Feb/08 21:16
• Updated: 05/Apr/15 14:54
• Resolved: 19/Feb/08 02:33

Description

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