You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Jaikiran Pai <ja...@gmail.com> on 2018/02/18 12:06:57 UTC

Ivy release this month?

Hello everyone,

Is there anything I can help with to start off and complete the Ivy
release, hopefully this month? As I noted in the dev list mail, I don't
plan to include the fix for
https://issues.apache.org/jira/browse/IVY-1485 in this release and
instead try and tackle it after that. There are few PRs open, but except
for this one https://github.com/apache/ant-ivy/pull/62 I don't plan to
merge the rest given the nature of the changes. There's no release
instructions that I could find, so I am not sure what's going to be
involved in the actual release process.


-Jaikiran


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: Ivy release this month?

Posted by Gintautas Grigelionis <g....@gmail.com>.
2018-02-19 7:35 GMT+01:00 Stefan Bodewig <bo...@apache.org>:

> On 2018-02-18, Gintautas Grigelionis wrote:
>
> > 2018-02-18 20:30 GMT+01:00 Stefan Bodewig <bo...@apache.org>:
>
> >> On 2018-02-18, Gintautas Grigelionis wrote:
>
> >>>    - https://github.com/apache/ant-ivy/pull/63 (has to do with choice
> of
> >>>    generics, with are not set in stone yet);
>
> >> changes the generic type of an argument of a public method inside a
> >> public class.
>
> > That's obvious. Any suggestions?
>
> I'm not familiar with the Ivy code base so all I can suggest is along
> general lines of "think about a different approach" and "document the
> break of backwards compatibility if unavoidable".
>
> This case is specifically tricky as you will only run into problems at
> runtime (unless you recompile your code) thanks to type erasure.
> Existing compiled code that invokes doesCallersExclude with a Stack of
> ModuleRevisionIds will be allowed to call the method.
>

Hmmm, I may use (Array)Deque and provide Stack for backwards compatibility,
how about that?

Gintas

Re: Ivy release this month?

Posted by Gintautas Grigelionis <g....@gmail.com>.
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 <ja...@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
>
>

Re: Ivy release this month?

Posted by Jaikiran Pai <ja...@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


Re: Ivy release this month?

Posted by Stefan Bodewig <bo...@apache.org>.
On 2018-02-18, Gintautas Grigelionis wrote:

> 2018-02-18 20:30 GMT+01:00 Stefan Bodewig <bo...@apache.org>:

>> On 2018-02-18, Gintautas Grigelionis wrote:

>>>    - https://github.com/apache/ant-ivy/pull/63 (has to do with choice of
>>>    generics, with are not set in stone yet);

>> changes the generic type of an argument of a public method inside a
>> public class.

> That's obvious. Any suggestions?

I'm not familiar with the Ivy code base so all I can suggest is along
general lines of "think about a different approach" and "document the
break of backwards compatibility if unavoidable".

This case is specifically tricky as you will only run into problems at
runtime (unless you recompile your code) thanks to type erasure.
Existing compiled code that invokes doesCallersExclude with a Stack of
ModuleRevisionIds will be allowed to call the method.

>>    - https://github.com/apache/ant-ivy/pull/64 (in production at TomTom;
>>>    should we look for a more general solution, or just document that
>>>    preemptive authentication restricts to basic scheme?);

>> adds a new method to a public interface (URLHandler).

> Java 8, then.

Not my call.

>>>    - 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?

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: Ivy release this month?

Posted by Gintautas Grigelionis <g....@gmail.com>.
2018-02-18 20:30 GMT+01:00 Stefan Bodewig <bo...@apache.org>:

> [Personally I prefer discussion by email over discussion in github
> issues.]
>
> On 2018-02-18, Gintautas Grigelionis wrote:
>
> >    - https://github.com/apache/ant-ivy/pull/63 (has to do with choice of
> >    generics, with are not set in stone yet);
>
> changes the generic type of an argument of a public method inside a
> public class.
>

That's obvious. Any suggestions?

>    - https://github.com/apache/ant-ivy/pull/64 (in production at TomTom;
> >    should we look for a more general solution, or just document that
> >    preemptive authentication restricts to basic scheme?);
>
> adds a new method to a public interface (URLHandler).
>

Java 8, then.


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

Gintas

Re: Ivy release this month?

Posted by Gintautas Grigelionis <g....@gmail.com>.
The ugly thing

2018-02-27 22:40 GMT+01:00 Gintautas Grigelionis <g....@gmail.com>:

> 2018-02-18 20:30 GMT+01:00 Stefan Bodewig <bo...@apache.org>:
>
>> [Personally I prefer discussion by email over discussion in github
>> issues.]
>>
>
> The beauty is that GitHub comments are echoed in mailing list, and, in
> case of PR mentioning JIRA issues, in JIRA as well.
>
> Gintas
>

The ugliness is that comments on commits get subject "[GitHub] ant-ivy pull
request #:" in mailing list rather than the original Git comment.
Do we have control over that of is it something to report to infra?

Gintas

Re: Ivy release this month?

Posted by Gintautas Grigelionis <g....@gmail.com>.
2018-02-18 20:30 GMT+01:00 Stefan Bodewig <bo...@apache.org>:

> [Personally I prefer discussion by email over discussion in github
> issues.]
>

The beauty is that GitHub comments are echoed in mailing list, and, in case
of PR mentioning JIRA issues, in JIRA as well.

Gintas

Re: Ivy release this month?

Posted by Stefan Bodewig <bo...@apache.org>.
[Personally I prefer discussion by email over discussion in github
issues.]

On 2018-02-18, Gintautas Grigelionis wrote:

>    - https://github.com/apache/ant-ivy/pull/63 (has to do with choice of
>    generics, with are not set in stone yet);

changes the generic type of an argument of a public method inside a
public class.

>    - https://github.com/apache/ant-ivy/pull/64 (in production at TomTom;
>    should we look for a more general solution, or just document that
>    preemptive authentication restricts to basic scheme?);

adds a new method to a public interface (URLHandler).

>    - 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?

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: Ivy release this month?

Posted by Gintautas Grigelionis <g....@gmail.com>.
I suggested previously how some of the contentious issues could be dealt
with (no response AFAICS).

In the meantime, I added the following PRs asking for some discussion

   - https://github.com/apache/ant-ivy/pull/63 (has to do with choice of
   generics, with are not set in stone yet);
   - https://github.com/apache/ant-ivy/pull/64 (in production at TomTom;
   should we look for a more general solution, or just document that
   preemptive authentication restricts to basic scheme?);
   - https://github.com/apache/ant-ivy/pull/67 (a one-liner; anybody sees
   some side effects?)

Thanks,
Gintas

2018-02-18 13:06 GMT+01:00 Jaikiran Pai <ja...@gmail.com>:

> Hello everyone,
>
> Is there anything I can help with to start off and complete the Ivy
> release, hopefully this month? As I noted in the dev list mail, I don't
> plan to include the fix for
> https://issues.apache.org/jira/browse/IVY-1485 in this release and
> instead try and tackle it after that. There are few PRs open, but except
> for this one https://github.com/apache/ant-ivy/pull/62 I don't plan to
> merge the rest given the nature of the changes. There's no release
> instructions that I could find, so I am not sure what's going to be
> involved in the actual release process.
>
>
> -Jaikiran
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>