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 Nicolas Lalevée <ni...@anyware-tech.com> on 2007/11/26 10:49:19 UTC
Parsing module descriptor VS ivy.resolve()
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 ?
[1] https://issues.apache.org/jira/browse/IVYDE-43
--
Nicolas LALEVÉE
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com
Re: Parsing module descriptor VS ivy.resolve()
Posted by Nicolas Lalevée <ni...@anyware-tech.com>.
Le lundi 26 novembre 2007, Xavier Hanin a écrit :
> On Nov 26, 2007 2:21 PM, Nicolas Lalevée <ni...@anyware-tech.com>
>
> wrote:
> > Le lundi 26 novembre 2007, Xavier Hanin a écrit:
> > > On Nov 26, 2007 10:49 AM, Nicolas Lalevée
> > > <ni...@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
Re: Parsing module descriptor VS ivy.resolve()
Posted by Xavier Hanin <xa...@gmail.com>.
On Nov 26, 2007 2:21 PM, Nicolas Lalevée <ni...@anyware-tech.com>
wrote:
> Le lundi 26 novembre 2007, Xavier Hanin a écrit:
> > On Nov 26, 2007 10:49 AM, Nicolas Lalevée
> > <ni...@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?
Xavier
>
>
> cheers,
> Nicolas
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: Parsing module descriptor VS ivy.resolve()
Posted by Nicolas Lalevée <ni...@anyware-tech.com>.
Le lundi 26 novembre 2007, Xavier Hanin a écrit :
> On Nov 26, 2007 10:49 AM, Nicolas Lalevée
> <ni...@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. I wrote some javadoc from my
investigation, but unfortunatly I accidently removed my checkouted svn.
cheers,
Nicolas
Re: Parsing module descriptor VS ivy.resolve()
Posted by Xavier Hanin <xa...@gmail.com>.
On Nov 26, 2007 10:49 AM, Nicolas Lalevée <ni...@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.
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?
Xavier
>
>
> [1] https://issues.apache.org/jira/browse/IVYDE-43
>
> --
> Nicolas LALEVÉE
> ANYWARE TECHNOLOGIES
> Tel : +33 (0)5 61 00 52 90
> Fax : +33 (0)5 61 00 51 46
> http://www.anyware-tech.com
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/