Hi, the issue is fxed and released. Please try it!
The current release relies on the following solution: Repositories are divided into groups (String repo.getGroupId()). Repositories IN the same groups are merged, otherwise they are spoofed (as before). The ordering of reposes are still important, but beside repositoryOrder (list of all reposes configured independent of groupId) we have "subchains" by groups with same order of members. The algorithm: if we have request for non "mergeable" item, use "who serves first -- wins" by repositoryOrder. if we have request for "mergable" item, use "who serves first -- wins" to get initial copy. Then, iterate over the found item's originating repo group, and merge the result (resultlist). Thus, using current Px RC2 a solution to Barrie's inital problem would be: repo A: group A repo B: group B repo C: group C or even more sophisticated: A: group One B: group Two C: group Two So, A may be used to spoof (inhouse), but B and C (if A does not serve what it needs) will be merging metadatas. RC2 has a "factory" configuration as this: inhouse, group: private extFree, group: private extNonFree, group: private central, group: public All four reposes shares same repository logic, so they share newly implemented snapshot policies too: serveSnapshots=false, serverReleases=true (release is something that is not snapshot in Px vocabulary). Question: what should happen with maven-metadata.xml checksum (sha1, md5) after merge? Thanx in advance, ~t~ On 7/26/06, Trygve Laugstøl <[EMAIL PROTECTED]> wrote:
Tamás Cservenák wrote: > Hi, > > On 7/26/06, Trygve Laugstøl <[EMAIL PROTECTED]> wrote: > >> That is not the problem, the problem is that the metadata from all the >> repositories has to be _merged_ and dispatched properly by proximity. >> That is why any plain http proxy will fail acting as a repository for >> Maven. >> > > Ah, I see. My knowledge was here faulty a little bit, sorry. > > At a first glance, it is easily implentable at proximityBean level (it > has the list of repos), using some similar pattern as repositoryBean > does for retrieval logic. Actually, externalize the current "first > serves wins" serving algorithm to some customizable form. > > And this issue is only for aggregated reposes. Does anything else > needs merging through reposes? Not that I can think of right now. > I will create an issue for that. > >> How can Maven solve this problem? Maven will properly merge the metadata >> from the different repositories but Proximity is effectively stopping >> half of the data coming through. >> > > sorry, i meant to say: solution could be to not "aggregate" > repositories, you could use different base URLs for them (in POM or > settings.xml). It is what Barrie suggested on the top of the thread. > And it is (will be) solvable with the "repo relocation" i was talking > about. Proximity will serve metadata properly then, no? Sounds like it. -- Trygve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
