Re: problem building Ivy [Was: Using the configuration as part of the artifact pattern]

[Christoffer Soop <li...@soop.se>]

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.

(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...

/Chris

Re: problem building Ivy [Was: Using the configuration as part of the artifact pattern]

[Christoffer Soop <li...@soop.se>]

Xavier Hanin skrev:
> 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?
Not sure which line that would be, cannot find an ivy version number.

I logged a defect, makes it easier to track it. For me it is a 
"blocker", but left the severity to the default "major" pending 
confirmation by somebody else and your judgment.

	https://issues.apache.org/jira/browse/IVY-718

/Chris

Re: problem building Ivy [Was: Using the configuration as part of the artifact pattern]

[Xavier Hanin <xa...@gmail.com>]

On Feb 5, 2008 10:50 PM, Christoffer Soop <li...@soop.se> 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.

Xavier

>
>
> /Chris
>
>
>
>


-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/