ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: problem building Ivy [Was: Using the configuration as part of the artifact pattern]
Date Wed, 06 Feb 2008 06:40:01 GMT
On Feb 5, 2008 10:50 PM, Christoffer Soop <> wrote:

> Xavier Hanin skrev:
> > I guess you have a version of Ivy in your ant lib, thus this takes
> > precendence over the version of Ivy you are building which should be
> used
> > during Ivy build.
> I doubt this is the case - as far as I can tell the jar files in the ant
> dist there is no ivy there... I would guess you can reproduce the error
> by using a completely clean Ant dist, the Ivy trunk and a cleaned out
> Ivy cache. I haven't used Ant in a while and pulled down the version
> 1.7.0 for the sole purpose of building Ivy.

OK, I'll check that when I'll have a better internet connection. I'd
appreciate if anybody else can check it too. In the mean time, could you
provide some of your logs, especially the line where Ivy tells which version
of Ivy is used?

(Ivy would be the one thing that could make me consider using Ant
> instead of Maven2 for a Java project - here I am using Ivy with NAnt and
> C#/.NET as mentioned previously.)
> > Allright, so I guess the best solution is to use the namespace aware
> > version. About IVY-567,  we haven't applied the patch yet because the
> > solution is not very satisfying, due to the poor support for classpath
> in
> > jar (you have to have the dependencies at the exact right relative
> location,
> > I really dislike this). What would be much more satisfying IMO is to
> remove
> > the dependency on commons-cli, to make Ivy runnable alone. This is more
> work
> > though...
> Another option, which I would guess is not really to your taste, would
> be to actually include the commons-cli in the ivy jar file. Admittedly
> this is not a very elegant solution but why reinvent the wheel when the
> commons-cli is exactly the functionality you need? A point to consider
> is that it is not nearly as much work as roll your own version...

This is not an easy decision. I really don't like projects packaging other
libraries in their jar. It's a source of cumbersome problems very difficult
to debug. On the other hand, I dislike reinventing the wheel... but that's
what we have to do frequently in Ivy to avoid having any dependency for the
core. So that would be consistent with the core philosophy :-) And
implementing argument parsing logic isn't that much a big deal.


> /Chris

Xavier Hanin - Independent Java Consultant

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message