Ivy release this month?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Ivy release this month?

Jaikiran Pai
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Ivy release this month?

Gintautas Grigelionis
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 <[hidden email]>:

> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Ivy release this month?

Stefan Bodewig
[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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Ivy release this month?

Gintautas Grigelionis
2018-02-18 20:30 GMT+01:00 Stefan Bodewig <[hidden email]>:

> [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
Reply | Threaded
Open this post in threaded view
|

Re: Ivy release this month?

Stefan Bodewig
On 2018-02-18, Gintautas Grigelionis wrote:

> 2018-02-18 20:30 GMT+01:00 Stefan Bodewig <[hidden email]>:

>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Ivy release this month?

Jaikiran Pai

>>>>     - 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Ivy release this month?

Gintautas Grigelionis
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 <[hidden email]>:

>
>     - 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Ivy release this month?

Gintautas Grigelionis
In reply to this post by Stefan Bodewig
2018-02-19 7:35 GMT+01:00 Stefan Bodewig <[hidden email]>:

> On 2018-02-18, Gintautas Grigelionis wrote:
>
> > 2018-02-18 20:30 GMT+01:00 Stefan Bodewig <[hidden email]>:
>
> >> 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
Reply | Threaded
Open this post in threaded view
|

Re: Ivy release this month?

Gintautas Grigelionis
In reply to this post by Stefan Bodewig
2018-02-18 20:30 GMT+01:00 Stefan Bodewig <[hidden email]>:

> [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
Reply | Threaded
Open this post in threaded view
|

Re: Ivy release this month?

Gintautas Grigelionis
The ugly thing

2018-02-27 22:40 GMT+01:00 Gintautas Grigelionis <[hidden email]>:

> 2018-02-18 20:30 GMT+01:00 Stefan Bodewig <[hidden email]>:
>
>> [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