Hi, I thought the artifact_aliases.properties is designed for this purpose (if it supports the jar module as well as the car module), but that may just be my wishful thinking. ;)

Lin

Vamsavardhana Reddy wrote:
I have encountered some unexpected things while trying to install a plug-in when SNAPSHOT versions are specified as dependencies. Here are some examples: 1. A query for "foo/bar/1.0-SNAPSHOT/jar" of an artifact from a remote repository returned result "foo/bar/1.0-beta1/jar". The plug-in installer downloaded 1.0-beta1 and installed in server's repository. Plug-in startup failed since 1.0-SNAPSHOT is not available in server's repository. 2. A second attempt to install the same plug-in (after uninstalling the one installed but not started in (1) above), goes through the same steps for downloading "foo/bar/1.0-SNAPSHOT/jar" and downloads "foo/bar/1.0-beta1/jar". But this time it failed with an error unable to copy dependency since it is already in the server's repository!! (downloaded 3. A query for "1.0-incubating-SNAPSHOT" version of a tuscany artifact had resulted in "0.91-incubating". I do not remember the exact artifactId.

Problem in (2) can be addressed by checking to see if result version is already in server's repository and avoid downloading it. It has been fixed in rev 563782 (branches\2.0) and 563785 (trunk).

Regarding problem in (1), I had a discussion with Paul McMahan on IRC and we decided that if a query for a version of artifact results in a different version, then we will indeed copy the downloaded result into server's repository under query version. (In our example, though we download "foo/bar/1.0-beta1/jar", we will copy it as "foo/bar/1.0-SNAPSHOT/jar ". This way we will avoid plug-in startup failure.) Since we copy the artifact under a SNAPSHOT version, there is no harm as two artifacts named "foo/bar/1.0-SNAPSHOT/jar" need not compare. When I discussed this solution on IRC with Matt, he suggested that it may be better to address this problem by changing how the dependency resolution works for SNAPSHOT versions instead of copying the downloaded version of artifact under a different name. In other words, changed the dependency resolution such a dependency on 1.0-SNAPSHOT is resolved to 1.0-SNAPSHOT or any released version of 1.0 available in the server's repository. It may be alright if just "SNAPSHOT" is specified as dependency (which is as good as omitting the version in dependency, or is it not?) as opposed to " 1.0-SNAPSHOT". I don't think this will address the situation in (3).

Any suggestions on how (1) and (3) from above could be handled?

--vamsi

Reply via email to