You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@archiva.apache.org by Jim Jackson <jj...@echostorm.net> on 2008/02/18 16:52:31 UTC

Mac OS X jnilib download issue

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.processF 
ile(MetadataUpdaterConsumer.java:167)
         at  
org.apache.maven.archiva.repository.scanner.functors.ConsumerProcessFile 
Closure.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.di 
rectoryWalkStep(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.toArtifact 
Reference(DefaultPathParser.java:131)
         at  
org.apache.maven.archiva.repository.content.AbstractDefaultRepositoryCon 
tent.toArtifactReference(AbstractDefaultRepositoryContent.java:54)
         at  
org.apache.maven.archiva.repository.content.ManagedDefaultRepositoryCont 
ent.toArtifactReference(ManagedDefaultRepositoryContent.java:330)
         at  
org.apache.maven.archiva.consumers.core.MetadataUpdaterConsumer.processF 
ile(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.

I'd like to offer the following patch to support .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]{1,6}$)",

Cheers,
Jim Jackson


Re: Mac OS X jnilib download issue

Posted by Brett Porter <br...@gmail.com>.
thanks - will apply it now

On 19/02/2008, Jim Jackson <jj...@echostorm.net> wrote:
> Brett,
>
> MRM-703.  The patch drops the maximum length constraint.
>
> Cheers,
> Jim Jackson
>
> On Feb 18, 2008, at 3:23 PM, Brett Porter wrote:
>
> > Thanks Jim!
> >
> > Would you mind putting this in JIRA as an attached patch? Also, I'd
> > suggest just dropping the maximum length constraint altogether - I
> > don't see that it adds anything?
> >
> > Thanks,
> > Brett
> >
> > On 19/02/2008, Jim Jackson <jj...@echostorm.net> wrote:
> >> 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.proce
> >> ssF
> >> ile(MetadataUpdaterConsumer.java:167)
> >>          at
> >> org.apache.maven.archiva.repository.scanner.functors.ConsumerProcessF
> >> ile
> >> Closure.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
> >> .di
> >> rectoryWalkStep(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.toArtif
> >> act
> >> Reference(DefaultPathParser.java:131)
> >>          at
> >> org.apache.maven.archiva.repository.content.AbstractDefaultRepository
> >> Con
> >> tent.toArtifactReference(AbstractDefaultRepositoryContent.java:54)
> >>          at
> >> org.apache.maven.archiva.repository.content.ManagedDefaultRepositoryC
> >> ont
> >> ent.toArtifactReference(ManagedDefaultRepositoryContent.java:330)
> >>          at
> >> org.apache.maven.archiva.consumers.core.MetadataUpdaterConsumer.proce
> >> ssF
> >> ile(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.
> >>
> >> I'd like to offer the following patch to support .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]{1,6}$)",
> >>
> >> Cheers,
> >> Jim Jackson
> >>
> >>
> >
> >
> > --
> > Brett Porter
> > Blog: http://blogs.exist.com/bporter/
> >
>
>


-- 
Brett Porter
Blog: http://blogs.exist.com/bporter/

Re: Mac OS X jnilib download issue

Posted by Jim Jackson <jj...@echostorm.net>.
Brett,

MRM-703.  The patch drops the maximum length constraint.

Cheers,
Jim Jackson

On Feb 18, 2008, at 3:23 PM, Brett Porter wrote:

> Thanks Jim!
>
> Would you mind putting this in JIRA as an attached patch? Also, I'd
> suggest just dropping the maximum length constraint altogether - I
> don't see that it adds anything?
>
> Thanks,
> Brett
>
> On 19/02/2008, Jim Jackson <jj...@echostorm.net> wrote:
>> 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.proce 
>> ssF
>> ile(MetadataUpdaterConsumer.java:167)
>>          at
>> org.apache.maven.archiva.repository.scanner.functors.ConsumerProcessF 
>> ile
>> Closure.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 
>> .di
>> rectoryWalkStep(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.toArtif 
>> act
>> Reference(DefaultPathParser.java:131)
>>          at
>> org.apache.maven.archiva.repository.content.AbstractDefaultRepository 
>> Con
>> tent.toArtifactReference(AbstractDefaultRepositoryContent.java:54)
>>          at
>> org.apache.maven.archiva.repository.content.ManagedDefaultRepositoryC 
>> ont
>> ent.toArtifactReference(ManagedDefaultRepositoryContent.java:330)
>>          at
>> org.apache.maven.archiva.consumers.core.MetadataUpdaterConsumer.proce 
>> ssF
>> ile(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.
>>
>> I'd like to offer the following patch to support .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]{1,6}$)",
>>
>> Cheers,
>> Jim Jackson
>>
>>
>
>
> -- 
> Brett Porter
> Blog: http://blogs.exist.com/bporter/
>


Re: Mac OS X jnilib download issue

Posted by Brett Porter <br...@gmail.com>.
Thanks Jim!

Would you mind putting this in JIRA as an attached patch? Also, I'd
suggest just dropping the maximum length constraint altogether - I
don't see that it adds anything?

Thanks,
Brett

On 19/02/2008, Jim Jackson <jj...@echostorm.net> wrote:
> 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.processF
> ile(MetadataUpdaterConsumer.java:167)
>          at
> org.apache.maven.archiva.repository.scanner.functors.ConsumerProcessFile
> Closure.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.di
> rectoryWalkStep(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.toArtifact
> Reference(DefaultPathParser.java:131)
>          at
> org.apache.maven.archiva.repository.content.AbstractDefaultRepositoryCon
> tent.toArtifactReference(AbstractDefaultRepositoryContent.java:54)
>          at
> org.apache.maven.archiva.repository.content.ManagedDefaultRepositoryCont
> ent.toArtifactReference(ManagedDefaultRepositoryContent.java:330)
>          at
> org.apache.maven.archiva.consumers.core.MetadataUpdaterConsumer.processF
> ile(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.
>
> I'd like to offer the following patch to support .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]{1,6}$)",
>
> Cheers,
> Jim Jackson
>
>


-- 
Brett Porter
Blog: http://blogs.exist.com/bporter/