Hi, I add a look and something puzzle me here. I cannot reproduce the problem. Note I have added unit test in this commit [1] Did I miss something with your use case ?
Thanks -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy [1] http://svn.apache.org/viewvc?view=revision&revision=1325558 2012/4/10 Sascha Vogt <[email protected]>: > 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-
