Community
Participate
Working Groups
The metadata repository does not preserve the format of the target repository. For example if my target repo is in jar form, the repo resulting of the mirroring application will be non-jar'ed.
I think that the bug applies to both mirroring app. I believe that the same issue is being dealt with by the metadata generator. Ben could you please investigate?
It is not clear that the act of mirroring includes the format of the repo index itself. For example, I might be mirroring into a completely different repo impl for which JAR'd is not relevant. Similarly for the source repo. In the event that the destination repo does not exist the app creates a Simple*Repo for you. It may be relevant to spec whether you want an autocreated destination formated as a JAR in a way similar to the MetadataGeneratorApplication.
I agree with what you say, but this is not the problem I'm talking about. Apparently my message was not clear. The problem is the following: - I have a repo that I will use as a target. It is a compressed simple artifact repo (e.g. d:/foo/content.jar) - I have a source repo for which the format is irrelevant After the mirroring the source into the target, the target repo is no longer in compressed form.
Ah, I was thrown of by "the repo resulting..." and thinking this was a new repo. In any even, isn't this this a flaw in the repo infrastructure somewhere? If I create a repo and set its compression (any property/characteristic really) and then shut down. They startup again, load the repo and write to it, the repos infrastructure itself should be taking care of this no? Why would an application have to worry about or even be exposed to the internal format details of a repo? I vaguely recall a bug about this but cannot find it.
I assume this won't happen for 3.4.1. Moving back to inbox because Ben is no longer active.
Could this have been fixed in Bug 248441?
Andrew, please check if this works and adds a test case for this if we don't have one. Thx.
I just tried to mirror some of my test data into a backup of the 3.4 repo that has a content.jar and I can't replicate it. I'm not sure how I'd automate this test since I'd have the verify the content.jar still exists but that a content.xml does not.
Start with a repo in a given format, mirror into it another repo in another format and check that the file name of the resulting repo has not changed.
Created attachment 116205 [details] Adds tests to ensure compressed properties are honoured
Created attachment 116206 [details] Required test data for test cases Unzip into the testData/mirror folder.
Changing the target milestone as we are not contributing to M3. However please make sure these bugs are addressed early in M4 or tomorrow Testing Thursday for the test related ones.
Thx, test case slightly modified and released.
