ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gintautas Grigelionis <g.grigelio...@gmail.com>
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?

Gintas

2018-02-27 14:26 GMT+01:00 Jaikiran Pai <jai.forums2013@gmail.com>:

>
>     - https://github.com/apache/ant-ivy/pull/67 (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: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>

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