ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: Writing some code after ApacheConEU - Retrieving SNAPSHOT Artifacts
Date Thu, 03 May 2007 13:56:00 GMT
On 5/3/07, Stefan Arentz <stefan.arentz@gmail.com> wrote:
> On 5/3/07, Xavier Hanin <xavier.hanin@gmail.com> wrote:
> > On 5/3/07, Stefan Arentz <stefan.arentz@gmail.com> 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 proxy
>
> Nope, 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/

Mime
View raw message