> 2012/4/6 Sascha Vogt <sascha.vogt@...>:
>> Am 05.04.12 11:46, schrieb Olivier Lamy:
>>> 2012/4/5 Sascha Vogt <sascha.vogt@...>:
>>>> It seems that the purge deleted the snapshot -javadoc.jar but left the
>>>> -javadoc.zip and we ended up with several thousand files in one
>>>> directory which slowed down the repository scan to take ages.
>>>> The question is: Can or should Archiva either
>>>> a) refuse deployment if the same classifier is deployed twice with a
>>>> different extension
>>>> b) the purge be enhanced to delete all extensions of a given classifier?
>>> I tend to say b) :-)
>>> Can you load an issue for this feature ?
>>> BTW is **/*.zip recorded as a file pattern in your archiva configuration ?
>> created http://jira.codehaus.org/browse/MRM-1622 and yes **/*.zip is
>> added as a file pattern.
>> I'll try to have a look next week and provide a patch.
> Cool let us know if any questions :-)
I do ;)
I tracked the issue down a little bit further. It seems to be an issue
relating to the type <-> extension mapping.
The purge consumer gets a list of related artifacts
(repository.getRelatedArtifacts()) which contains ArtifactReferences to
the files to be purged. An ArtifactReference has no file extension, but
only a type. So if you use a "wrong" extension for a given type (e.g. as
in our case zip for javadocs) the conversion back to an actual file will
then produce a file, which is not existing...
Frankly I have NO idea how to fix that with an easy patch :) Maybe
extend the ArtifactReference with an optional extension and use that
when converting between files and references if present?
Or should the ManagedRepositoryContent be extended by a method which
directly returns files instead of references (omitting the conversion
from path to reference and back to a path)?