Am 06.04.2012 11:35, schrieb Olivier Lamy: > 2012/4/6 Sascha Vogt <[email protected]>: >> Hi, >> >> Am 05.04.12 11:46, schrieb Olivier Lamy: >>> 2012/4/5 Sascha Vogt <[email protected]>: >>>> 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 >>>> or >>>> 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)? Any input is welcome! Greetings -Sascha-
