You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by "Jan Matèrne (jhm)" <ap...@materne.de> on 2018/01/08 14:48:44 UTC
Ivy-2.5.0
I took my old TODO list for Ivy-2.5.0.
Most of them are still open, how to deal with that?
In my opinion we should try to get a release out and postpone these to a
2.5.1 (means reducing stopper->later).
We have lots of changes we could deliver in this way. We also show a sign of
life in that way.
Jan
- https://issues.apache.org/jira/browse/IVY-1485
Incorrect revision of dependencies put in to delivered Ivy files
Status:
11.09.2017: Jaikiran wanted to focus on that
prio: stopper ("but it was IVY-1485 which reanimated the community")
- SVG-graphics
Status:
08.01.2018: unknown
prio: should be included, as it seems to be nearly finished (for me)
- https://github.com/apache/ant-ivy/pull/60
use Unicode glyphs or SVG data URLs instead of bitmaps
Status:
11.09.2017: review required
08.01.2018: not sure what to do or what impact this have
prio: should be included (as part of the "svg-bulk")
- https://github.com/apache/ant-ivy/pull/57
fix the last inconsistencies in generics
Status:
11.09.2017: This includes a change which breaks BC
08.01.2018: no consense on the API change
prio: solve that or delay (this PR should not delay the new version in my
opinion)
- https://github.com/apache/ant-ivy/pull/55
use the vectorised logo
Status:
11.09.2017: nearly finished (missing header)
08.01.2018: no changes (license header missing)
prio: include that as is nearly finished
- https://issues.apache.org/jira/browse/IVY-1420
defaultconfmapping on <configurations/> element is not written to
delivered ivy file
Status:
11.09.2017: "I need about a week"
08.01.2018: done (27.09.2017)
prio: should be included
- upgrading BouncyCastle
Status: done
- IVY-1420/IVY-1437, defaultconf/defaultconfmapping/confmappingoverride
attributes
"according to ivy.xsd, all three attributes can be used on both
dependencies and configurations.
So, it's the documentation that must be adjusted accordingly"
Status:
11.09.2017: open
08.01.2018: done
prio: maybe delay (and open a Jira ticket)
Re: Ivy-2.5.0
Posted by Jaikiran Pai <ja...@gmail.com>.
I think it's time to start moving this release process further. My work
on IVY-1485 isn't complete nor is it in a state where I'm confident that
it won't break/regress other things. So I think it's safe to move it out
of this release and try and get it into some next release. We have a
good amount of bug fixes that have been done since 2.4.0 and I think we
should start looking at what it takes to do the release formalities.
-Jaikiran
On 09/01/18 12:29 PM, Jaikiran Pai wrote:
> Hi Jan,
>
> My efforts to resolve IVY-1485 have taken longer than I expected,
> mainly due to not finding enough time to sort it out. A few weekends I
> tried to focus on this, with my local WIP changes, I ran into merge
> issues with the latest upstream changes. I resolved them then and
> continued with the WIP changes. But a few weeks down the line I ran
> into the merge conflicts again. I haven't yet been able to find time
> to resolve them locally and spend time on the real fix (I do admit
> that I lost a bit of focus/interest with the merges).
>
> I'll try again this weekend and see how far I can get this working.
> Either way, I don't want to block the release anymore. If I can't get
> IVY-1485 solved by this weekend, I propose to have it marked as a
> known issue for this release and I will try and get it out in the next
> release after that.
>
> As you note, we do have good number of fixes in this release and it's
> time that we have them available to the general public.
>
> -Jaikiran
>
>
> On 08/01/18 8:18 PM, Jan Matèrne (jhm) wrote:
>> I took my old TODO list for Ivy-2.5.0.
>>
>> Most of them are still open, how to deal with that?
>>
>> In my opinion we should try to get a release out and postpone these to a
>> 2.5.1 (means reducing stopper->later).
>>
>> We have lots of changes we could deliver in this way. We also show a
>> sign of
>> life in that way.
>>
>>
>>
>> Jan
>>
>>
>>
>>
>> - https://issues.apache.org/jira/browse/IVY-1485
>>
>> Incorrect revision of dependencies put in to delivered Ivy files
>>
>> Status:
>>
>> 11.09.2017: Jaikiran wanted to focus on that
>>
>> prio: stopper ("but it was IVY-1485 which reanimated the community")
>>
>>
>> - SVG-graphics
>>
>> Status:
>>
>> 08.01.2018: unknown
>>
>> prio: should be included, as it seems to be nearly finished (for me)
>>
>>
>> - https://github.com/apache/ant-ivy/pull/60
>>
>> use Unicode glyphs or SVG data URLs instead of bitmaps
>>
>> Status:
>>
>> 11.09.2017: review required
>>
>> 08.01.2018: not sure what to do or what impact this have
>>
>> prio: should be included (as part of the "svg-bulk")
>>
>>
>> - https://github.com/apache/ant-ivy/pull/57
>>
>> fix the last inconsistencies in generics
>>
>> Status:
>>
>> 11.09.2017: This includes a change which breaks BC
>>
>> 08.01.2018: no consense on the API change
>>
>> prio: solve that or delay (this PR should not delay the new
>> version in my
>> opinion)
>>
>>
>> - https://github.com/apache/ant-ivy/pull/55
>>
>> use the vectorised logo
>>
>> Status:
>>
>> 11.09.2017: nearly finished (missing header)
>>
>> 08.01.2018: no changes (license header missing)
>>
>> prio: include that as is nearly finished
>>
>>
>> - https://issues.apache.org/jira/browse/IVY-1420
>>
>> defaultconfmapping on <configurations/> element is not written to
>> delivered ivy file
>>
>> Status:
>>
>> 11.09.2017: "I need about a week"
>>
>> 08.01.2018: done (27.09.2017)
>>
>> prio: should be included
>>
>>
>> - upgrading BouncyCastle
>>
>> Status: done
>>
>>
>> - IVY-1420/IVY-1437, defaultconf/defaultconfmapping/confmappingoverride
>> attributes
>>
>> "according to ivy.xsd, all three attributes can be used on both
>> dependencies and configurations.
>>
>> So, it's the documentation that must be adjusted accordingly"
>>
>> Status:
>>
>> 11.09.2017: open
>>
>> 08.01.2018: done
>>
>> prio: maybe delay (and open a Jira ticket)
>>
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Ivy-2.5.0
Posted by Jaikiran Pai <ja...@gmail.com>.
Hi Jan,
My efforts to resolve IVY-1485 have taken longer than I expected, mainly
due to not finding enough time to sort it out. A few weekends I tried to
focus on this, with my local WIP changes, I ran into merge issues with
the latest upstream changes. I resolved them then and continued with the
WIP changes. But a few weeks down the line I ran into the merge
conflicts again. I haven't yet been able to find time to resolve them
locally and spend time on the real fix (I do admit that I lost a bit of
focus/interest with the merges).
I'll try again this weekend and see how far I can get this working.
Either way, I don't want to block the release anymore. If I can't get
IVY-1485 solved by this weekend, I propose to have it marked as a known
issue for this release and I will try and get it out in the next release
after that.
As you note, we do have good number of fixes in this release and it's
time that we have them available to the general public.
-Jaikiran
On 08/01/18 8:18 PM, Jan Matèrne (jhm) wrote:
> I took my old TODO list for Ivy-2.5.0.
>
> Most of them are still open, how to deal with that?
>
> In my opinion we should try to get a release out and postpone these to a
> 2.5.1 (means reducing stopper->later).
>
> We have lots of changes we could deliver in this way. We also show a sign of
> life in that way.
>
>
>
>
>
> Jan
>
>
>
>
>
>
>
> - https://issues.apache.org/jira/browse/IVY-1485
>
> Incorrect revision of dependencies put in to delivered Ivy files
>
> Status:
>
> 11.09.2017: Jaikiran wanted to focus on that
>
> prio: stopper ("but it was IVY-1485 which reanimated the community")
>
>
>
> - SVG-graphics
>
> Status:
>
> 08.01.2018: unknown
>
> prio: should be included, as it seems to be nearly finished (for me)
>
>
>
> - https://github.com/apache/ant-ivy/pull/60
>
> use Unicode glyphs or SVG data URLs instead of bitmaps
>
> Status:
>
> 11.09.2017: review required
>
> 08.01.2018: not sure what to do or what impact this have
>
> prio: should be included (as part of the "svg-bulk")
>
>
>
> - https://github.com/apache/ant-ivy/pull/57
>
> fix the last inconsistencies in generics
>
> Status:
>
> 11.09.2017: This includes a change which breaks BC
>
> 08.01.2018: no consense on the API change
>
> prio: solve that or delay (this PR should not delay the new version in my
> opinion)
>
>
>
> - https://github.com/apache/ant-ivy/pull/55
>
> use the vectorised logo
>
> Status:
>
> 11.09.2017: nearly finished (missing header)
>
> 08.01.2018: no changes (license header missing)
>
> prio: include that as is nearly finished
>
>
>
> - https://issues.apache.org/jira/browse/IVY-1420
>
> defaultconfmapping on <configurations/> element is not written to
> delivered ivy file
>
> Status:
>
> 11.09.2017: "I need about a week"
>
> 08.01.2018: done (27.09.2017)
>
> prio: should be included
>
>
>
> - upgrading BouncyCastle
>
> Status: done
>
>
>
> - IVY-1420/IVY-1437, defaultconf/defaultconfmapping/confmappingoverride
> attributes
>
> "according to ivy.xsd, all three attributes can be used on both
> dependencies and configurations.
>
> So, it's the documentation that must be adjusted accordingly"
>
> Status:
>
> 11.09.2017: open
>
> 08.01.2018: done
>
> prio: maybe delay (and open a Jira ticket)
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Ivy-2.5.0
Posted by Gintautas Grigelionis <g....@gmail.com>.
Interesting, japicmp does not mark URLHandler as backwards incompatible,
even though it has a bunch of new methods :-S
On the other hand, IvyDEA has some old components: Commons VFS 1.0, JSch
0.1.31... BTW, JSch is a part of IntelliJ distribution?
Gintas
2018-01-09 15:40 GMT+01:00 Gintautas Grigelionis <g....@gmail.com>:
> You can use PR-61 for that 😉
>
> Gintas
>
>
> Den 9 jan. 2018 14:53 skrev "Jaikiran Pai" <ja...@gmail.com>:
>
> Thanks Maarten, I'll look this.
>
> -Jaikiran
>
>
>
> On 09/01/18 5:53 PM, Maarten Coene wrote:
>
>> The change to the URLHandler class (TimoutConstraint) is also backwards
>> incompatible.The IvyIdea plugin (IntelliJ) breaks on this which contains an
>> extension of AbstractURLHandler.
>> I didn't look into it yet, maybe it can be changed to be more backwards
>> compatible?
>>
>> kind regards,Maarten
>>
>> Van: Gintautas Grigelionis <g....@gmail.com>
>> Aan: Ant Developers List <de...@ant.apache.org>
>> Verzonden: dinsdag 9 januari 9:45 2018
>> Onderwerp: Re: Ivy-2.5.0
>> 2018-01-09 7:12 GMT+00:00 Jan Matèrne (jhm) <ap...@materne.de>:
>>
>> What must be done to complete the work on SVG (IVY-922/IVY-450 or resp
>>>> PR-55/PR-60)? If you fine with merging (eventually adjusting the
>>>> contents of SVG), let's do it.
>>>>
>>> I added a comment on the PR.
>>> For short:
>>> - license header is missed on two files
>>> - improve two JavaDocs
>>> - test: does the fresh built Ivy use the SVG graphics?
>>>
>>> I hope I addressed all points now.
>>
>>
>> Changes to alleviate IVY-1315/IVY-1419/IVY-1420/IVY-1437 should be
>>>> evaluated by reporters, but nobody responded because the issues are so
>>>> old.
>>>> I would rather close the issues and a open a new issue if needed. I
>>>>
>>> No. It's just a matter of prioritization by us.
>>>
>>>
>>>
>>> added test cases for every issue highlighting the specific parts of the
>>>> problem and I can write up separately on the design problem with
>>>> permitting the same attributes on different elements with recursive
>>>> inheritance or using the same attribute name with different semantics
>>>> depending on the element (perhaps in Confluence? or Github wiki?).
>>>>
>>> Can't understand the problem (haven't that knowledge of Ivy).
>>> IVY-1315 "is related to" IVY-1420, which is resolved.
>>> Is IVY-1315 also resolved? Then just close that issue.
>>>
>>> The problem is that the same set of attributes is allowed on both
>> configurations and dependencies. However, it is the attrubte values for
>> last element (dependencies) that are definitive -- unless they're absent.
>>
>> Both configurations and dependencies can be inherited ("extended"); on top
>> of that, configurations allow for includes, which I guess predates
>> extension, and includes can have the attributes, too.
>>
>> So the problem is: while ivy.xml is updated, the values of attributes may
>> change. Because ivy.xml is written in chunks, configurations (processed
>> early) may end up with different attribute values than dependencies (which
>> are definitive). That makes no difference when processed ivy.xml is
>> resolved, but might mess up subsequent extends.
>>
>> Because the whole mechanism is underspecified, I tend to leave it as is
>> (put the final values of attributes on dependencies) rather than cache
>> configurations and publications until attributes on dependencies are
>> processed in order to guarantee that attributes have identical values for
>> both configurations and dependencies (or that configurations get the final
>> values if no attributes were present on dependencies).
>>
>> I will close all issues pertaining to the attributes. When we agree on
>> specification, we can open a new one if needed.
>>
>>
>> My opinion on PR-57 is that it addresses another design problem in a
>>>> similarly good-enough fashion. We can handle this like Ant and have a
>>>> Java
>>>> 7 branch (2.5.x) and a Java 8+ branch with further API changes (2.6.x).
>>>> The question is, whether that makes 2.5.x more interesting and is worth
>>>> the extra work?
>>>>
>>> I wouldn't create an extra branch just for that.
>>> I am more a fan of moving to a newer Java version after that release.
>>>
>>> I recap the PR-57:
>>> - multiple changes array->collection
>>> - all are fine expect one
>>> - one central public interface added one new method
>>> -- no changes in semantics, but only in method declaration
>>> (array->collection, generics)
>>> -- technically one new method and deprecating the old
>>> - this means breaking backwards compatibility
>>> - proposal is adding a 2nd interface extending the original interface and
>>> adding that new method
>>> (could be 'inlined' in later Ivy version).
>>>
>>> I followed the mail thread https://www.mail-archive.com/
>>> dev@ant.apache.org/msg46002.html and found another problem
>>> - ModuleRules breaks BWC due the same reason (as you pointed it out).
>>>
>>> Maybe we should not include this PR into an Ivy-2.5.0 release but instead
>>> move Ivy-2.6.0 to Java8 and change these parts in a (IMO) right but
>>> backwards incompatible way.
>>>
>>> PR-57 is narrowed down specificaly to the method addition in
>> DependencyResolver. That affects every resolver implementation; however, a
>> default method implementation is provided in AbstractResolver and all
>> known
>> third party implementations use it.
>>
>> We can kick the can down the road, but the important point is that Java
>> permits no arrays of generics and we must fix that.
>>
>> Gintas
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
>
Re: Facing problem using xslt and Java 9
Posted by Stefan Bodewig <bo...@apache.org>.
On 2018-01-12, Sarika Sinha wrote:
> We are trying to use xslt with Java 9 using this -
> <factory name="org.apache.xalan.processor.TransformerFactoryImpl">
> <feature name="
> http://www.oracle.com/xml/jaxp/properties/enableExtensionFunctions"
> value="true"/>
> </factory>
> With Java 9, org.apache.xalan.processor.TransformerFactoryImpl is present
> in java.xml module but the package
> com.sun.org.apache.xalan.internal.xsltc.trax is not exported in the module.
I'm confused. Are you looking for TransformerFactoryImpl in
org.apache.xalan.processor or in
com.sun.org.apache.xalan.internal.xsltc.trax or where? I don't see where
the requirement for com.sun.org.apache.xalan.internal.xsltc.trax comes
from at all.
If you want to enable the feature on the default transformer factory
provided by the java.xml module, you don't need to specify a name for
the factory at all. Something like
<factory>
<feature
name="http://www.oracle.com/xml/jaxp/properties/enableExtensionFunctions"
value="true"/>
</factory>
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Facing problem using xslt and Java 9
Posted by Sarika Sinha <sa...@in.ibm.com>.
Hi,
We are trying to use xslt with Java 9 using this -
<factory name="org.apache.xalan.processor.TransformerFactoryImpl">
<feature name="
http://www.oracle.com/xml/jaxp/properties/enableExtensionFunctions"
value="true"/>
</factory>
With Java 9, org.apache.xalan.processor.TransformerFactoryImpl is present
in java.xml module but the package
com.sun.org.apache.xalan.internal.xsltc.trax is not exported in the module.
we tried using
--add-exports
java.xml/com.sun.org.apache.xalan.internal.xsltc.trax=ALL-UNNAMED but we
get the error as -
[xslt] Failed to load org.apache.xalan.processor.TransformerFactoryImpl
via the configured classpath, will try Ant's classpath instead.
[xslt] Failed to process null
Any help in making this run will be great.
Thanks & Regards,
Sarika Sinha
Eclipse JDT/Ant committer
Re: Ivy-2.5.0
Posted by Gintautas Grigelionis <g....@gmail.com>.
You can use PR-61 for that 😉
Gintas
Den 9 jan. 2018 14:53 skrev "Jaikiran Pai" <ja...@gmail.com>:
Thanks Maarten, I'll look this.
-Jaikiran
On 09/01/18 5:53 PM, Maarten Coene wrote:
> The change to the URLHandler class (TimoutConstraint) is also backwards
> incompatible.The IvyIdea plugin (IntelliJ) breaks on this which contains an
> extension of AbstractURLHandler.
> I didn't look into it yet, maybe it can be changed to be more backwards
> compatible?
>
> kind regards,Maarten
>
> Van: Gintautas Grigelionis <g....@gmail.com>
> Aan: Ant Developers List <de...@ant.apache.org>
> Verzonden: dinsdag 9 januari 9:45 2018
> Onderwerp: Re: Ivy-2.5.0
> 2018-01-09 7:12 GMT+00:00 Jan Matèrne (jhm) <ap...@materne.de>:
>
> What must be done to complete the work on SVG (IVY-922/IVY-450 or resp
>>> PR-55/PR-60)? If you fine with merging (eventually adjusting the
>>> contents of SVG), let's do it.
>>>
>> I added a comment on the PR.
>> For short:
>> - license header is missed on two files
>> - improve two JavaDocs
>> - test: does the fresh built Ivy use the SVG graphics?
>>
>> I hope I addressed all points now.
>
>
> Changes to alleviate IVY-1315/IVY-1419/IVY-1420/IVY-1437 should be
>>> evaluated by reporters, but nobody responded because the issues are so
>>> old.
>>> I would rather close the issues and a open a new issue if needed. I
>>>
>> No. It's just a matter of prioritization by us.
>>
>>
>>
>> added test cases for every issue highlighting the specific parts of the
>>> problem and I can write up separately on the design problem with
>>> permitting the same attributes on different elements with recursive
>>> inheritance or using the same attribute name with different semantics
>>> depending on the element (perhaps in Confluence? or Github wiki?).
>>>
>> Can't understand the problem (haven't that knowledge of Ivy).
>> IVY-1315 "is related to" IVY-1420, which is resolved.
>> Is IVY-1315 also resolved? Then just close that issue.
>>
>> The problem is that the same set of attributes is allowed on both
> configurations and dependencies. However, it is the attrubte values for
> last element (dependencies) that are definitive -- unless they're absent.
>
> Both configurations and dependencies can be inherited ("extended"); on top
> of that, configurations allow for includes, which I guess predates
> extension, and includes can have the attributes, too.
>
> So the problem is: while ivy.xml is updated, the values of attributes may
> change. Because ivy.xml is written in chunks, configurations (processed
> early) may end up with different attribute values than dependencies (which
> are definitive). That makes no difference when processed ivy.xml is
> resolved, but might mess up subsequent extends.
>
> Because the whole mechanism is underspecified, I tend to leave it as is
> (put the final values of attributes on dependencies) rather than cache
> configurations and publications until attributes on dependencies are
> processed in order to guarantee that attributes have identical values for
> both configurations and dependencies (or that configurations get the final
> values if no attributes were present on dependencies).
>
> I will close all issues pertaining to the attributes. When we agree on
> specification, we can open a new one if needed.
>
>
> My opinion on PR-57 is that it addresses another design problem in a
>>> similarly good-enough fashion. We can handle this like Ant and have a
>>> Java
>>> 7 branch (2.5.x) and a Java 8+ branch with further API changes (2.6.x).
>>> The question is, whether that makes 2.5.x more interesting and is worth
>>> the extra work?
>>>
>> I wouldn't create an extra branch just for that.
>> I am more a fan of moving to a newer Java version after that release.
>>
>> I recap the PR-57:
>> - multiple changes array->collection
>> - all are fine expect one
>> - one central public interface added one new method
>> -- no changes in semantics, but only in method declaration
>> (array->collection, generics)
>> -- technically one new method and deprecating the old
>> - this means breaking backwards compatibility
>> - proposal is adding a 2nd interface extending the original interface and
>> adding that new method
>> (could be 'inlined' in later Ivy version).
>>
>> I followed the mail thread https://www.mail-archive.com/
>> dev@ant.apache.org/msg46002.html and found another problem
>> - ModuleRules breaks BWC due the same reason (as you pointed it out).
>>
>> Maybe we should not include this PR into an Ivy-2.5.0 release but instead
>> move Ivy-2.6.0 to Java8 and change these parts in a (IMO) right but
>> backwards incompatible way.
>>
>> PR-57 is narrowed down specificaly to the method addition in
> DependencyResolver. That affects every resolver implementation; however, a
> default method implementation is provided in AbstractResolver and all known
> third party implementations use it.
>
> We can kick the can down the road, but the important point is that Java
> permits no arrays of generics and we must fix that.
>
> Gintas
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Ivy-2.5.0
Posted by Jaikiran Pai <ja...@gmail.com>.
Thanks Maarten, I'll look this.
-Jaikiran
On 09/01/18 5:53 PM, Maarten Coene wrote:
> The change to the URLHandler class (TimoutConstraint) is also backwards incompatible.The IvyIdea plugin (IntelliJ) breaks on this which contains an extension of AbstractURLHandler.
> I didn't look into it yet, maybe it can be changed to be more backwards compatible?
>
> kind regards,Maarten
>
> Van: Gintautas Grigelionis <g....@gmail.com>
> Aan: Ant Developers List <de...@ant.apache.org>
> Verzonden: dinsdag 9 januari 9:45 2018
> Onderwerp: Re: Ivy-2.5.0
>
> 2018-01-09 7:12 GMT+00:00 Jan Matèrne (jhm) <ap...@materne.de>:
>
>>> What must be done to complete the work on SVG (IVY-922/IVY-450 or resp
>>> PR-55/PR-60)? If you fine with merging (eventually adjusting the
>>> contents of SVG), let's do it.
>> I added a comment on the PR.
>> For short:
>> - license header is missed on two files
>> - improve two JavaDocs
>> - test: does the fresh built Ivy use the SVG graphics?
>>
> I hope I addressed all points now.
>
>
>>> Changes to alleviate IVY-1315/IVY-1419/IVY-1420/IVY-1437 should be
>>> evaluated by reporters, but nobody responded because the issues are so
>>> old.
>>> I would rather close the issues and a open a new issue if needed. I
>> No. It's just a matter of prioritization by us.
>>
>>
>>
>>> added test cases for every issue highlighting the specific parts of the
>>> problem and I can write up separately on the design problem with
>>> permitting the same attributes on different elements with recursive
>>> inheritance or using the same attribute name with different semantics
>>> depending on the element (perhaps in Confluence? or Github wiki?).
>> Can't understand the problem (haven't that knowledge of Ivy).
>> IVY-1315 "is related to" IVY-1420, which is resolved.
>> Is IVY-1315 also resolved? Then just close that issue.
>>
> The problem is that the same set of attributes is allowed on both
> configurations and dependencies. However, it is the attrubte values for
> last element (dependencies) that are definitive -- unless they're absent.
>
> Both configurations and dependencies can be inherited ("extended"); on top
> of that, configurations allow for includes, which I guess predates
> extension, and includes can have the attributes, too.
>
> So the problem is: while ivy.xml is updated, the values of attributes may
> change. Because ivy.xml is written in chunks, configurations (processed
> early) may end up with different attribute values than dependencies (which
> are definitive). That makes no difference when processed ivy.xml is
> resolved, but might mess up subsequent extends.
>
> Because the whole mechanism is underspecified, I tend to leave it as is
> (put the final values of attributes on dependencies) rather than cache
> configurations and publications until attributes on dependencies are
> processed in order to guarantee that attributes have identical values for
> both configurations and dependencies (or that configurations get the final
> values if no attributes were present on dependencies).
>
> I will close all issues pertaining to the attributes. When we agree on
> specification, we can open a new one if needed.
>
>
>>> My opinion on PR-57 is that it addresses another design problem in a
>>> similarly good-enough fashion. We can handle this like Ant and have a
>>> Java
>>> 7 branch (2.5.x) and a Java 8+ branch with further API changes (2.6.x).
>>> The question is, whether that makes 2.5.x more interesting and is worth
>>> the extra work?
>> I wouldn't create an extra branch just for that.
>> I am more a fan of moving to a newer Java version after that release.
>>
>> I recap the PR-57:
>> - multiple changes array->collection
>> - all are fine expect one
>> - one central public interface added one new method
>> -- no changes in semantics, but only in method declaration
>> (array->collection, generics)
>> -- technically one new method and deprecating the old
>> - this means breaking backwards compatibility
>> - proposal is adding a 2nd interface extending the original interface and
>> adding that new method
>> (could be 'inlined' in later Ivy version).
>>
>> I followed the mail thread https://www.mail-archive.com/
>> dev@ant.apache.org/msg46002.html and found another problem
>> - ModuleRules breaks BWC due the same reason (as you pointed it out).
>>
>> Maybe we should not include this PR into an Ivy-2.5.0 release but instead
>> move Ivy-2.6.0 to Java8 and change these parts in a (IMO) right but
>> backwards incompatible way.
>>
> PR-57 is narrowed down specificaly to the method addition in
> DependencyResolver. That affects every resolver implementation; however, a
> default method implementation is provided in AbstractResolver and all known
> third party implementations use it.
>
> We can kick the can down the road, but the important point is that Java
> permits no arrays of generics and we must fix that.
>
> Gintas
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Ivy-2.5.0
Posted by Jaikiran Pai <ja...@gmail.com>.
Maarten, I just pushed a change to Ivy upstream to not force existing
implementations of this URLHandler to understand timeout constraints and
yet have the feature available for other implementations. When you get a
chance, can you please try the IvyIdea plugin build/test with the latest
Ivy and see if it solves the issue?
-Jaikiran
On 09/01/18 5:53 PM, Maarten Coene wrote:
> The change to the URLHandler class (TimoutConstraint) is also backwards incompatible.The IvyIdea plugin (IntelliJ) breaks on this which contains an extension of AbstractURLHandler.
> I didn't look into it yet, maybe it can be changed to be more backwards compatible?
>
> kind regards,Maarten
>
> Van: Gintautas Grigelionis <g....@gmail.com>
> Aan: Ant Developers List <de...@ant.apache.org>
> Verzonden: dinsdag 9 januari 9:45 2018
> Onderwerp: Re: Ivy-2.5.0
>
> 2018-01-09 7:12 GMT+00:00 Jan Matèrne (jhm) <ap...@materne.de>:
>
>>> What must be done to complete the work on SVG (IVY-922/IVY-450 or resp
>>> PR-55/PR-60)? If you fine with merging (eventually adjusting the
>>> contents of SVG), let's do it.
>> I added a comment on the PR.
>> For short:
>> - license header is missed on two files
>> - improve two JavaDocs
>> - test: does the fresh built Ivy use the SVG graphics?
>>
> I hope I addressed all points now.
>
>
>>> Changes to alleviate IVY-1315/IVY-1419/IVY-1420/IVY-1437 should be
>>> evaluated by reporters, but nobody responded because the issues are so
>>> old.
>>> I would rather close the issues and a open a new issue if needed. I
>> No. It's just a matter of prioritization by us.
>>
>>
>>
>>> added test cases for every issue highlighting the specific parts of the
>>> problem and I can write up separately on the design problem with
>>> permitting the same attributes on different elements with recursive
>>> inheritance or using the same attribute name with different semantics
>>> depending on the element (perhaps in Confluence? or Github wiki?).
>> Can't understand the problem (haven't that knowledge of Ivy).
>> IVY-1315 "is related to" IVY-1420, which is resolved.
>> Is IVY-1315 also resolved? Then just close that issue.
>>
> The problem is that the same set of attributes is allowed on both
> configurations and dependencies. However, it is the attrubte values for
> last element (dependencies) that are definitive -- unless they're absent.
>
> Both configurations and dependencies can be inherited ("extended"); on top
> of that, configurations allow for includes, which I guess predates
> extension, and includes can have the attributes, too.
>
> So the problem is: while ivy.xml is updated, the values of attributes may
> change. Because ivy.xml is written in chunks, configurations (processed
> early) may end up with different attribute values than dependencies (which
> are definitive). That makes no difference when processed ivy.xml is
> resolved, but might mess up subsequent extends.
>
> Because the whole mechanism is underspecified, I tend to leave it as is
> (put the final values of attributes on dependencies) rather than cache
> configurations and publications until attributes on dependencies are
> processed in order to guarantee that attributes have identical values for
> both configurations and dependencies (or that configurations get the final
> values if no attributes were present on dependencies).
>
> I will close all issues pertaining to the attributes. When we agree on
> specification, we can open a new one if needed.
>
>
>>> My opinion on PR-57 is that it addresses another design problem in a
>>> similarly good-enough fashion. We can handle this like Ant and have a
>>> Java
>>> 7 branch (2.5.x) and a Java 8+ branch with further API changes (2.6.x).
>>> The question is, whether that makes 2.5.x more interesting and is worth
>>> the extra work?
>> I wouldn't create an extra branch just for that.
>> I am more a fan of moving to a newer Java version after that release.
>>
>> I recap the PR-57:
>> - multiple changes array->collection
>> - all are fine expect one
>> - one central public interface added one new method
>> -- no changes in semantics, but only in method declaration
>> (array->collection, generics)
>> -- technically one new method and deprecating the old
>> - this means breaking backwards compatibility
>> - proposal is adding a 2nd interface extending the original interface and
>> adding that new method
>> (could be 'inlined' in later Ivy version).
>>
>> I followed the mail thread https://www.mail-archive.com/
>> dev@ant.apache.org/msg46002.html and found another problem
>> - ModuleRules breaks BWC due the same reason (as you pointed it out).
>>
>> Maybe we should not include this PR into an Ivy-2.5.0 release but instead
>> move Ivy-2.6.0 to Java8 and change these parts in a (IMO) right but
>> backwards incompatible way.
>>
> PR-57 is narrowed down specificaly to the method addition in
> DependencyResolver. That affects every resolver implementation; however, a
> default method implementation is provided in AbstractResolver and all known
> third party implementations use it.
>
> We can kick the can down the road, but the important point is that Java
> permits no arrays of generics and we must fix that.
>
> Gintas
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Ivy-2.5.0
Posted by Maarten Coene <ma...@yahoo.com.INVALID>.
The change to the URLHandler class (TimoutConstraint) is also backwards incompatible.The IvyIdea plugin (IntelliJ) breaks on this which contains an extension of AbstractURLHandler.
I didn't look into it yet, maybe it can be changed to be more backwards compatible?
kind regards,Maarten
Van: Gintautas Grigelionis <g....@gmail.com>
Aan: Ant Developers List <de...@ant.apache.org>
Verzonden: dinsdag 9 januari 9:45 2018
Onderwerp: Re: Ivy-2.5.0
2018-01-09 7:12 GMT+00:00 Jan Matèrne (jhm) <ap...@materne.de>:
> > What must be done to complete the work on SVG (IVY-922/IVY-450 or resp
> > PR-55/PR-60)? If you fine with merging (eventually adjusting the
> > contents of SVG), let's do it.
>
> I added a comment on the PR.
> For short:
> - license header is missed on two files
> - improve two JavaDocs
> - test: does the fresh built Ivy use the SVG graphics?
>
I hope I addressed all points now.
>
> > Changes to alleviate IVY-1315/IVY-1419/IVY-1420/IVY-1437 should be
> > evaluated by reporters, but nobody responded because the issues are so
> > old.
> > I would rather close the issues and a open a new issue if needed. I
>
> No. It's just a matter of prioritization by us.
>
>
>
> > added test cases for every issue highlighting the specific parts of the
> > problem and I can write up separately on the design problem with
> > permitting the same attributes on different elements with recursive
> > inheritance or using the same attribute name with different semantics
> > depending on the element (perhaps in Confluence? or Github wiki?).
>
> Can't understand the problem (haven't that knowledge of Ivy).
> IVY-1315 "is related to" IVY-1420, which is resolved.
> Is IVY-1315 also resolved? Then just close that issue.
>
The problem is that the same set of attributes is allowed on both
configurations and dependencies. However, it is the attrubte values for
last element (dependencies) that are definitive -- unless they're absent.
Both configurations and dependencies can be inherited ("extended"); on top
of that, configurations allow for includes, which I guess predates
extension, and includes can have the attributes, too.
So the problem is: while ivy.xml is updated, the values of attributes may
change. Because ivy.xml is written in chunks, configurations (processed
early) may end up with different attribute values than dependencies (which
are definitive). That makes no difference when processed ivy.xml is
resolved, but might mess up subsequent extends.
Because the whole mechanism is underspecified, I tend to leave it as is
(put the final values of attributes on dependencies) rather than cache
configurations and publications until attributes on dependencies are
processed in order to guarantee that attributes have identical values for
both configurations and dependencies (or that configurations get the final
values if no attributes were present on dependencies).
I will close all issues pertaining to the attributes. When we agree on
specification, we can open a new one if needed.
> > My opinion on PR-57 is that it addresses another design problem in a
> > similarly good-enough fashion. We can handle this like Ant and have a
> > Java
> > 7 branch (2.5.x) and a Java 8+ branch with further API changes (2.6.x).
> > The question is, whether that makes 2.5.x more interesting and is worth
> > the extra work?
>
> I wouldn't create an extra branch just for that.
> I am more a fan of moving to a newer Java version after that release.
>
> I recap the PR-57:
> - multiple changes array->collection
> - all are fine expect one
> - one central public interface added one new method
> -- no changes in semantics, but only in method declaration
> (array->collection, generics)
> -- technically one new method and deprecating the old
> - this means breaking backwards compatibility
> - proposal is adding a 2nd interface extending the original interface and
> adding that new method
> (could be 'inlined' in later Ivy version).
>
> I followed the mail thread https://www.mail-archive.com/
> dev@ant.apache.org/msg46002.html and found another problem
> - ModuleRules breaks BWC due the same reason (as you pointed it out).
>
> Maybe we should not include this PR into an Ivy-2.5.0 release but instead
> move Ivy-2.6.0 to Java8 and change these parts in a (IMO) right but
> backwards incompatible way.
>
PR-57 is narrowed down specificaly to the method addition in
DependencyResolver. That affects every resolver implementation; however, a
default method implementation is provided in AbstractResolver and all known
third party implementations use it.
We can kick the can down the road, but the important point is that Java
permits no arrays of generics and we must fix that.
Gintas
Re: Ivy-2.5.0
Posted by Gintautas Grigelionis <g....@gmail.com>.
2018-01-09 7:12 GMT+00:00 Jan Matèrne (jhm) <ap...@materne.de>:
> > What must be done to complete the work on SVG (IVY-922/IVY-450 or resp
> > PR-55/PR-60)? If you fine with merging (eventually adjusting the
> > contents of SVG), let's do it.
>
> I added a comment on the PR.
> For short:
> - license header is missed on two files
> - improve two JavaDocs
> - test: does the fresh built Ivy use the SVG graphics?
>
I hope I addressed all points now.
>
> > Changes to alleviate IVY-1315/IVY-1419/IVY-1420/IVY-1437 should be
> > evaluated by reporters, but nobody responded because the issues are so
> > old.
> > I would rather close the issues and a open a new issue if needed. I
>
> No. It's just a matter of prioritization by us.
>
>
>
> > added test cases for every issue highlighting the specific parts of the
> > problem and I can write up separately on the design problem with
> > permitting the same attributes on different elements with recursive
> > inheritance or using the same attribute name with different semantics
> > depending on the element (perhaps in Confluence? or Github wiki?).
>
> Can't understand the problem (haven't that knowledge of Ivy).
> IVY-1315 "is related to" IVY-1420, which is resolved.
> Is IVY-1315 also resolved? Then just close that issue.
>
The problem is that the same set of attributes is allowed on both
configurations and dependencies. However, it is the attrubte values for
last element (dependencies) that are definitive -- unless they're absent.
Both configurations and dependencies can be inherited ("extended"); on top
of that, configurations allow for includes, which I guess predates
extension, and includes can have the attributes, too.
So the problem is: while ivy.xml is updated, the values of attributes may
change. Because ivy.xml is written in chunks, configurations (processed
early) may end up with different attribute values than dependencies (which
are definitive). That makes no difference when processed ivy.xml is
resolved, but might mess up subsequent extends.
Because the whole mechanism is underspecified, I tend to leave it as is
(put the final values of attributes on dependencies) rather than cache
configurations and publications until attributes on dependencies are
processed in order to guarantee that attributes have identical values for
both configurations and dependencies (or that configurations get the final
values if no attributes were present on dependencies).
I will close all issues pertaining to the attributes. When we agree on
specification, we can open a new one if needed.
> > My opinion on PR-57 is that it addresses another design problem in a
> > similarly good-enough fashion. We can handle this like Ant and have a
> > Java
> > 7 branch (2.5.x) and a Java 8+ branch with further API changes (2.6.x).
> > The question is, whether that makes 2.5.x more interesting and is worth
> > the extra work?
>
> I wouldn't create an extra branch just for that.
> I am more a fan of moving to a newer Java version after that release.
>
> I recap the PR-57:
> - multiple changes array->collection
> - all are fine expect one
> - one central public interface added one new method
> -- no changes in semantics, but only in method declaration
> (array->collection, generics)
> -- technically one new method and deprecating the old
> - this means breaking backwards compatibility
> - proposal is adding a 2nd interface extending the original interface and
> adding that new method
> (could be 'inlined' in later Ivy version).
>
> I followed the mail thread https://www.mail-archive.com/
> dev@ant.apache.org/msg46002.html and found another problem
> - ModuleRules breaks BWC due the same reason (as you pointed it out).
>
> Maybe we should not include this PR into an Ivy-2.5.0 release but instead
> move Ivy-2.6.0 to Java8 and change these parts in a (IMO) right but
> backwards incompatible way.
>
PR-57 is narrowed down specificaly to the method addition in
DependencyResolver. That affects every resolver implementation; however, a
default method implementation is provided in AbstractResolver and all known
third party implementations use it.
We can kick the can down the road, but the important point is that Java
permits no arrays of generics and we must fix that.
Gintas
AW: Ivy-2.5.0
Posted by "Jan Matèrne (jhm)" <ap...@materne.de>.
> What must be done to complete the work on SVG (IVY-922/IVY-450 or resp
> PR-55/PR-60)? If you fine with merging (eventually adjusting the
> contents of SVG), let's do it.
I added a comment on the PR.
For short:
- license header is missed on two files
- improve two JavaDocs
- test: does the fresh built Ivy use the SVG graphics?
> Changes to alleviate IVY-1315/IVY-1419/IVY-1420/IVY-1437 should be
> evaluated by reporters, but nobody responded because the issues are so
> old.
> I would rather close the issues and a open a new issue if needed. I
No. It's just a matter of prioritization by us.
> added test cases for every issue highlighting the specific parts of the
> problem and I can write up separately on the design problem with
> permitting the same attributes on different elements with recursive
> inheritance or using the same attribute name with different semantics
> depending on the element (perhaps in Confluence? or Github wiki?).
Can't understand the problem (haven't that knowledge of Ivy).
IVY-1315 "is related to" IVY-1420, which is resolved.
Is IVY-1315 also resolved? Then just close that issue.
> My opinion on PR-57 is that it addresses another design problem in a
> similarly good-enough fashion. We can handle this like Ant and have a
> Java
> 7 branch (2.5.x) and a Java 8+ branch with further API changes (2.6.x).
> The question is, whether that makes 2.5.x more interesting and is worth
> the extra work?
I wouldn't create an extra branch just for that.
I am more a fan of moving to a newer Java version after that release.
I recap the PR-57:
- multiple changes array->collection
- all are fine expect one
- one central public interface added one new method
-- no changes in semantics, but only in method declaration (array->collection, generics)
-- technically one new method and deprecating the old
- this means breaking backwards compatibility
- proposal is adding a 2nd interface extending the original interface and adding that new method
(could be 'inlined' in later Ivy version).
I followed the mail thread https://www.mail-archive.com/dev@ant.apache.org/msg46002.html and found another problem
- ModuleRules breaks BWC due the same reason (as you pointed it out).
Maybe we should not include this PR into an Ivy-2.5.0 release but instead move Ivy-2.6.0 to Java8 and change these parts in a (IMO) right but backwards incompatible way.
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Ivy-2.5.0
Posted by Gintautas Grigelionis <g....@gmail.com>.
What must be done to complete the work on SVG (IVY-922/IVY-450 or resp
PR-55/PR-60)? If you fine with merging (eventually adjusting the contents
of SVG), let's do it.
Changes to alleviate IVY-1315/IVY-1419/IVY-1420/IVY-1437 should be
evaluated by reporters, but nobody responded because the issues are so old.
I would rather close the issues and a open a new issue if needed. I added
test cases for every issue highlighting the specific parts of the problem
and I can write up separately on the design problem with permitting the
same attributes on different elements with recursive inheritance or using
the same attribute name with different semantics depending on the element
(perhaps in Confluence? or Github wiki?).
My opinion on PR-57 is that it addresses another design problem in a
similarly good-enough fashion. We can handle this like Ant and have a Java
7 branch (2.5.x) and a Java 8+ branch with further API changes (2.6.x). The
question is, whether that makes 2.5.x more interesting and is worth the
extra work?
Gintas
2018-01-08 14:48 GMT+00:00 Jan Matèrne (jhm) <ap...@materne.de>:
> I took my old TODO list for Ivy-2.5.0.
>
> Most of them are still open, how to deal with that?
>
> In my opinion we should try to get a release out and postpone these to a
> 2.5.1 (means reducing stopper->later).
>
> We have lots of changes we could deliver in this way. We also show a sign
> of
> life in that way.
>
>
>
>
>
> Jan
>
>
>
>
>
>
>
> - https://issues.apache.org/jira/browse/IVY-1485
>
> Incorrect revision of dependencies put in to delivered Ivy files
>
> Status:
>
> 11.09.2017: Jaikiran wanted to focus on that
>
> prio: stopper ("but it was IVY-1485 which reanimated the community")
>
>
>
> - SVG-graphics
>
> Status:
>
> 08.01.2018: unknown
>
> prio: should be included, as it seems to be nearly finished (for me)
>
>
>
> - https://github.com/apache/ant-ivy/pull/60
>
> use Unicode glyphs or SVG data URLs instead of bitmaps
>
> Status:
>
> 11.09.2017: review required
>
> 08.01.2018: not sure what to do or what impact this have
>
> prio: should be included (as part of the "svg-bulk")
>
>
>
> - https://github.com/apache/ant-ivy/pull/57
>
> fix the last inconsistencies in generics
>
> Status:
>
> 11.09.2017: This includes a change which breaks BC
>
> 08.01.2018: no consense on the API change
>
> prio: solve that or delay (this PR should not delay the new version in my
> opinion)
>
>
>
> - https://github.com/apache/ant-ivy/pull/55
>
> use the vectorised logo
>
> Status:
>
> 11.09.2017: nearly finished (missing header)
>
> 08.01.2018: no changes (license header missing)
>
> prio: include that as is nearly finished
>
>
>
> - https://issues.apache.org/jira/browse/IVY-1420
>
> defaultconfmapping on <configurations/> element is not written to
> delivered ivy file
>
> Status:
>
> 11.09.2017: "I need about a week"
>
> 08.01.2018: done (27.09.2017)
>
> prio: should be included
>
>
>
> - upgrading BouncyCastle
>
> Status: done
>
>
>
> - IVY-1420/IVY-1437, defaultconf/defaultconfmapping/confmappingoverride
> attributes
>
> "according to ivy.xsd, all three attributes can be used on both
> dependencies and configurations.
>
> So, it's the documentation that must be adjusted accordingly"
>
> Status:
>
> 11.09.2017: open
>
> 08.01.2018: done
>
> prio: maybe delay (and open a Jira ticket)
>
>
>
>
>
>