On 5/3/07, Stefan Arentz <[EMAIL PROTECTED]> wrote:
On 5/3/07, Xavier Hanin <[EMAIL PROTECTED]> wrote: > On 5/3/07, Stefan Arentz <[EMAIL PROTECTED]> wrote: > > Actually, I'm still there! :-) > > > > I am trying to use Ivy 2.0.0a1 to download snapshot artifacts from a > > M2 repository. I'm doing this from my own application, directly > > talking to the Ivy API. Like this: > > > > public static void main(String[] args) throws Exception > > { > > IvySettings settings = new IvySettings(); > > > > ResolveEngine engine = new ResolveEngine(settings, new > > EventManager(), new SortEngine(settings)); > > > > File cache = new File("build/cache"); > > cache.mkdirs(); > > > > ResolveData data = new ResolveData(engine, new > > ResolveOptions().setCache(CacheManager.getInstance(settings, cache))); > > > > settings.setDefaultCache(cache); > > > > String ibiblioRoot = "http://snapshots.repository.codehaus.org";; > > > > IBiblioResolver resolver = new IBiblioResolver(); > > resolver.setRoot(ibiblioRoot); > > resolver.setName("test"); > > resolver.setSettings(settings); > > resolver.setM2compatible(true); > > > > ModuleRevisionId mrid = > > ModuleRevisionId.newInstance("org.mortbay.jetty", "cometd-demo", > > "6.1-SNAPSHOT"); > > ResolvedModuleRevision rmr = resolver.getDependency(new > > DefaultDependencyDescriptor(mrid, false), data); > > > > DefaultArtifact artifact = new DefaultArtifact(mrid, > > rmr.getPublicationDate(), "cometd-demo", "war", "war"); > > DownloadReport report = resolver.download(new Artifact[] > > {artifact}, new DownloadOptions(settings, cache)); > > } > > > > This basically comes out of the IBiblioResolverTest. > > > > This works ok for retrieving artifacts that have a release version in > > the repository, for example commons-fileupload 2.0. But it does not > > work for -SNAPSHOT versions like the above cometd-demo 6.1-SNAPSHOT. > > > > I've browsed through the Ivy code and it looks like it does not touch > > the maven-metadata.xml file in the repository to find the latest > > SNAPSHOT build. > > > > Is this something that Ivy simply does not support yet, or am I not > > using the API in the right way? > To distinct things: > * Ivy do not use maven-metadata.xml files now, and this causes some > problem, with maven proxy for instance, and maybe also perf, there's > an issue planned for 2.0 about the proxy thing at least. But Ivy > supports listing revisions without any specific metadata, so this is > not really the main problem unless you are using a maven proxyNope, no proxy. What do you mean with 'listing revisions'?
you usually have too cases when resolving a dependency: either your dependency declaration specify an exact revision, in which case Ivy can use it as is to find the artifact, OR you can specify a dynamic version, or version constraint, for which Ivy should first list which are the available revisions of the dependency, to then decide which one to take according to your version constraint. In the case of maven SNAPSHOT I should say I still do not understand clearly how they work :-) Sometimes you have a file with SNAPSHOT as revision in your repository, sometime you get a timestamp as revision. If you want to get a timestamp revision, Ivy has to list the available ones to find the latest one. Is it getting clearer?
> * we haven't implemented SNAPSHOT yet, but it should be fairly easy to > get simple case working. Indeed the equivalent in Ivy of SNAPSHOT is a > + (1.3-SNAPSHOT would be written 1.3-+ in Ivy) Supporting them like > that is as easy as adding a new VersionMatcher, on the basis of > SubVersionMatcher. Maybe you could add an issue about that to be sure > we don't forget to deal with that (there maybe already one, I don't > remember). I'll add that issue. But that is just cosmetics right?
Not really, because without that Ivy consider 1.3-SNAPSHOT as an exact revision, and thus only to find the module with that exact revision.
If I understand correctly, the real problem is the maven-metadata.xml. I'll be happy to add that to Ivy 2.0 if you can give me some pointers to where that code belongs.
No, maven-metadata is only a performance problem, a maven-proxy problem, and a problem for some repositories for which we do not support revision listing (ftp url resolver for instance). The idea to fix this maven-metadata.xml problem is to make the whole revision listing pluggable on a resolver. Take a look at RepositoryResolver#findDynamicResourceUsingPattern to get the entry point. For the moment this listing thing is almost pluggable, the only thing is that we delegate to ResolverHelper statically instead of delegating to a class implementing an interface. Once we have a cleaner delegation, we should see how to use maven-metadata instead of URLLister to get metadata about which revisions are available. At least this is how I see it now, but I haven't delve into maven-metadata too much for the moment. Xavier
> BTW, your code makes a direct use of a resolver, which is fine to get > only one dependency. If you want a more complete dependency > resolution solution, you should better use Ivy class, which is a > facade for all Ivy services. Feel free to ask for help if you want to > go this way. No this is good enough for me since I will only download .war files which are supposed to be deployable without any dependencies. S.
-- Learn Ivy at ApacheCon: http://www.eu.apachecon.com/ Manage your dependencies with Ivy! http://incubator.apache.org/ivy/
