ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <nicolas.lale...@anyware-tech.com>
Subject Re: Parsing module descriptor VS ivy.resolve()
Date Mon, 26 Nov 2007 14:03:41 GMT
Le lundi 26 novembre 2007, Xavier Hanin a écrit :
> On Nov 26, 2007 2:21 PM, Nicolas Lalevée <nicolas.lalevee@anyware-tech.com>
>
> wrote:
> > Le lundi 26 novembre 2007, Xavier Hanin a écrit:
> > > On Nov 26, 2007 10:49 AM, Nicolas Lalevée
> > > <nicolas.lalevee@anyware-tech.com>
> > >
> > > wrote:
> > > > Hi,
> > > >
> > > > I did an ivy plugin for Hudson, so Hudson will be able to trigger the
> > > > build
> > > > regarding of the dependencies declared in the ivy.xml.
> > > >
> > > > I did an implementation that does the similar to the ivy:buildlist
> > > > ant task.
> > > > Then I saw IVYDE-43 [1], which will quite do a similar job. And the
> > > > solution
> > > > exposed over there is to use a custom resolver.
> > > >
> > > > With the ModuleDescriptorParser, there are some "resolving", as we
> > > > can get the
> > > > full dependency graph. Ivy has to search for the ivy.xml the
> > > > dependencies.
> > > >
> > > > I am quite confused by the API, there is simply no javadoc...
> > > >
> > > > So what should I use ?
> > >
> > > I think using something similar to how the buildlist works is fine.
> > > With the ModuleDescriptorParser there is no resolving, ie no access to
> > > a repository, it's only parsing a file to get the metadata. Then you
> > > can
> >
> > ask
> >
> > > if a module is depending on another one based on the metadata, but it
> >
> > works
> >
> > > only for direct dependencies, not transitive ones. With a custom
> >
> > resolver
> >
> > > you can be aware whenever a resolution occurs and change the resolution
> > > process, which is useful in IVYDE-43 case to replace the dependency on
> >
> > the
> >
> > > module jar(s) by a project dependency in Eclipse. But for what you do
> > > in hudson using the parser is enough and simpler.
> >
> > ok. Thank you very much for the explanation !
> >
> > > BTW, I will try to add some javadoc to some classes to help about that
> >
> > in
> >
> > > the future, could you tell me which classes/methods you looked at which
> > > where the most confusing?
> >
> > For this particular issue, I was looking at ModuleDescriptorParser. But I
> > did
> > already looked at other parts of ivy. And what was disapointing me is
> > that there were no javadoc on the Java interfaces.
>
> Indeed, Ivy code is not a very good example of how things should be done,
> especially in the javadoc area. This is entirely my fault, when I started
> writing Ivy in 2004 I was in a hurry and Ivy was just an internal tool for
> my company... But this bad practice tends to follow the project for a long
> time, we all learn with experience! Fortunately we are trying to add
> javadoc when we maintain the code so it's slowly getting cleaner and
> better.
>
> I wrote some javadoc from my
>
> > investigation, but unfortunatly I accidently removed my checkouted svn.
>
> Too sad, did you try restoring it with a disk rescue utility?

nope. My contribution was too poor (3 or 4 interfaces) and most probably not 
exact to take time to retreive it. But the next time will look into ivy code, 
I will repopulate what I found incomplete ;)

Nicolas

Mime
View raw message