You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Stefan Arentz <st...@gmail.com> on 2007/05/03 15:02:03 UTC
Writing some code after ApacheConEU - Retrieving SNAPSHOT Artifacts
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?
S.
Re: Writing some code after ApacheConEU - Retrieving SNAPSHOT Artifacts
Posted by Xavier Hanin <xa...@gmail.com>.
On 5/3/07, Stefan Arentz <st...@gmail.com> wrote:
> On 5/3/07, Xavier Hanin <xa...@gmail.com> wrote:
>
> > > 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?
>
> Almost :-)
>
> How does the listing work in practice? Do you assume that the
> repositories provide a directory listing that you can parse?
Exactly, we rely on the directory listing from the web server, in case
of a web server. Obviously for a filesystem repository it's much
easier :-)
The problem is that in Ivy almost anything can be a repository, and
layout are configurable, so using metadata like maven is not flexible
enough for Ivy. But in case there is some present, in the case of
ibiblio resolver, it make sense to use it (and solve maven-proxy
problem).
>
> I'm also confused about the naming conventions though .. I've see both
> -SNAPSHOT.ext and -<timestamp>.ext names. Maybe the first was a Maven
> 1.0 convention?
I don't think so, I've seen both with maven 2 produced snapshots.
Maybe asking on the maven mailing list could be a good idea.
> I'll try to figure that one out :-)
Great!
Xavier
>
> S.
>
--
Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/
Re: Writing some code after ApacheConEU - Retrieving SNAPSHOT Artifacts
Posted by Stefan Arentz <st...@gmail.com>.
On 5/3/07, Xavier Hanin <xa...@gmail.com> wrote:
> > 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?
Almost :-)
How does the listing work in practice? Do you assume that the
repositories provide a directory listing that you can parse?
I'm also confused about the naming conventions though .. I've see both
-SNAPSHOT.ext and -<timestamp>.ext names. Maybe the first was a Maven
1.0 convention? I'll try to figure that one out :-)
S.
Re: Writing some code after ApacheConEU - Retrieving SNAPSHOT Artifacts
Posted by Xavier Hanin <xa...@gmail.com>.
On 5/3/07, Stefan Arentz <st...@gmail.com> wrote:
> On 5/3/07, Xavier Hanin <xa...@gmail.com> wrote:
> > On 5/3/07, Stefan Arentz <st...@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/
RE: Writing some code after ApacheConEU - Retrieving SNAPSHOT Artifacts
Posted by Gilles Scokart <gs...@gmail.com>.
> -----Original Message-----
> From: Stefan Arentz [mailto:stefan.arentz@gmail.com]
> Sent: jeudi 3 mai 2007 15:39
> To: ivy-user@incubator.apache.org
> Subject: Re: Writing some code after ApacheConEU - Retrieving SNAPSHOT
> Artifacts
>
> On 5/3/07, Xavier Hanin <xa...@gmail.com> wrote:
> > 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'?
>
When you don't specify a specific revision, ivy must 'list' all available
revision before selecting the right one. That's what it means. Ivy can do
this by scanning directories in the repository.
> > * 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? 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.
>
I guess Xavier can give more precise info, but starts by looking at the
VersionMatchers, its subclass and its 'caller'.
Gilles
Re: Writing some code after ApacheConEU - Retrieving SNAPSHOT Artifacts
Posted by Stefan Arentz <st...@gmail.com>.
On 5/3/07, Xavier Hanin <xa...@gmail.com> wrote:
> On 5/3/07, Stefan Arentz <st...@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'?
> * 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? 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.
> 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.
Re: Writing some code after ApacheConEU - Retrieving SNAPSHOT Artifacts
Posted by Xavier Hanin <xa...@gmail.com>.
On 5/3/07, Stefan Arentz <st...@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
* 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).
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.
Xavier
>
> S.
>
--
Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/