When I start installing a plug-in, I will expect that the plugin installer will download only those dependencies that could not be resolved currently. I guess the artifact_aliases.properties file will be used at this resolution step. Once it is past that, it either downloads the dependency or fails saying it can not download the dependency. In exmple (1), it is downloading a different version of the depedency, still assumes it has downloaded the required one, proceeds to download further dependencies and fails at starting the plugin!!
--vamsi On 8/9/07, Lin Sun <[EMAIL PROTECTED]> wrote: > > 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 > >
