Hi Adrian, clarification never hurts :) Read below.
On 8/7/06, Adrian Shum <[EMAIL PROTECTED]> wrote:
for 1): That means, whenever I know two repos are having chance to contain same artifact, I should put them into two separate group?
Not quite. Whenever you know that having one "non-snapshot" (eg. central) and "snapshot" repo for previous (eg. apache.snapshots) that CONTAIN some artifacts on the SAME path, you SHOULD put them in the same group. And wait for Proximity to be fixed for merged metadata hash calculaction (Proximity currently merges propely the metadata, but the hash that returns belongs to one of the two merged metadatas - hence it is WRONG! It is a known bug.) :) This situation stands only if you use "edge" (snapshot) and "release" Maven artifacts (especially plugins) together. This is typical for Maven developers, for a "common user" it is not a probable situation. The rule: if two different proxied repo is in same group, their maven metadata (IF found on the same path) WILL BE MERGED, otherwise "spoofed" (the one that is first found will be returned "hiding" the second one). Both cases (merging vs spoofing) can be useful in certain cases, but these "features" can be DANGEROUS if the man does not know what are they doing. So the answer: the best thing would be to 1.) place EVERY repo in separate group (eg. groupId = repoId), 2.) turn on (currently nonexistent!) proximity.emergeGroups feature (that causes to publish every repo on separate URL since their groupIds are also repoIds). And leave to Maven to do what it should (merging metadatas taken from different repos hosted/proxied on Proximity). There have been a discussion about this on Maven Developers List. for 2):
I bet the new release will still enable us to access artifacts thru http://hostname/px-webapp/repsitory/artifact-group/artifcact right?
Yep. It would simply allow to publish every repo on different URL. Consider this: you have 2-3 reposes configured, and ALL of their contents appears on the same http://localhost:8080/px-webapp/repository. Think about this (pseudocode :)) - for the sake of brewity, all reposes are "non-snapshots". POM: repoA : http://localhost:8080/px-webapp/repository repoB : http://localhost:8080/px-webapp/repository repoC : http://localhost:8080/px-webapp/repository This means, that mvn cannot distinguish between artifacts originating reposes (even if Proximity itself DOES, mvn will lack the info). If mvn during execution needs "a.jar", it starts to search it by iterating over reposes. It requests "a.jar" from repoA. Proximity executes the request and finds it in repoC and returns it. So, mvn is completely "fooled" by saying that repoA contains "a.jar" while it is in repoC. This is the reason why Proximity "factory" config comes with central only, which should be 90% suffficient for "common" user. The "spoofing and grouping" should be left to "maven powerusers", the default proximity config from RC4 will be (repoId = groupId && emergeGroups = true). Also, can I ask one related question on how Maven2 handle snapshot
artifacts? Which of the following is the correct way? A) maven search thru repositories. If maven enountered a 'snapshot- enabled' repo, it will retrieve snapshot artifacts. Artifacts retrieved from 'snapshot-enabled' repo is assumed to be snapshot and will be checked for update in subsequent accesses; or B) maven search thru repositories. If maven enountered a 'snapshot- enabled' repo, it will retrieve snapshot artifacts. Repository or maven can tell this specific artifact is a snapshot , and only snapshot artifact from snapshot-enabled repo will be checked for update in subsequent accesses Which of the above case is correct? I am just thinking on whether there are ways to eliminate multiple repository proxies (no matter multiple Proximity instance or URL prefix) to serve for release and snapshot.
This question is a complicated one, I will pass on this, but i'm also interested in clarified answer :) AFAIK, repositories only "grows", never "shrinks". Once deployed artifact (even a broken one) should be left in it forever. True, there are examples of "misbehaved" repositories (especially snapshot reposes), but it is not a typical case. But: maven should be configured to enable snapshots, otherwise it will never touch them. I _would_ vote B) Have fun, ~t~
