ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gintautas Grigelionis <>
Subject Re: Ivy release this month?
Date Tue, 27 Feb 2018 16:45:57 GMT
Frankly, I was doubtful about the classloader change.

But, what use cases are there for java -jar ivy.jar -main  <main-class>?
As I understand it, it's about resolving an artifact and lauching whatever
main class would be there in it.
So, why not bootstrapping an Ivy build in a fancy way?

But, the new classloader created as a child of Ivy's classloader has all
Ivy classes creating conflicts.
By taking a parent of Ivy classloader (that is, system classloader) the
conflicts are avoided.
What is exactly the problem? Is there a use case that MUST have Ivy classes
on the classloader automagically?


2018-02-27 14:26 GMT+01:00 Jaikiran Pai <>:

>     - (a one-liner; anybody
>>>>>     sees some side effects?)
>>>> I don't understand the issue. Is this a documented way of using Ivy or
>>>> why would anybody expect it to be possible to invoke Ant via the Ivy
>>>> jar?
>>> Somebody was interested enough to open a JIRA issue. And the case is
>>> around
>>> the use which is definitely documented.
>> Let me rephrase. Is this a use-case the Ivy developers want to support?
> I am nervous about this change for multiple reasons:
>     - I read that JIRA and I don't understand why Ivy jar is being used to
> call into Ant's Main class.
>     - The JIRA doesn't provide any context nor did I find (in my limited
> search) that we support that use case.
>     - The change being proposed involves a classloader (hierarchy) change
> which is what makes me nervous, since without knowing more on what we are
> trying to achieve here and why, it's difficult to say whatelse it might
> impact.
>     - It also brings in additional deps and again comes back to the
> original question about what use case we are trying to support.
> IMO, this is something that we can avoid changing.
> -Jaikiran
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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