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: [antlibs] Break Backwards Compatibility of Ivy Coordinates?
Date Thu, 01 Jun 2017 14:16:35 GMT
I believe this comment
<https://github.com/ceylon/ceylon-herd/issues/262#issuecomment-194440002>
provides
a pretty good argument why coordinates must be consistent.

Gintas

2017-06-01 14:57 GMT+02:00 Gintautas Grigelionis <g.grigelionis@gmail.com>:

> It's not a "should", it's a MUST. Ideally, pom.xml should be generated
> from ivy.xml or the other way around; at the very least, maven-ant-tasks
> should check the consistence between them, like this
>
>   <target name="check-pom" description="o Verify pom.xml properties">
>     <typedef resource="org/apache/maven/artifact/ant/antlib.xml"
>              uri="antlib:org.apache.maven.artifact.ant"
>              classpath="${libdir}/maven-ant-tasks-2.1.3.jar"/>
>     <artifact:pom id="ivy.pom" file="pom.xml"/>
>     <echo>The pom version is ${ivy.pom.version}</echo>
>     <fail message="maven-compiler-plugin must be first in build plugin
> list!">
>       <condition>
>         <not>
>           <equals arg1="maven-compiler-plugin"
> arg2="${ivy.pom.build.plugins[0].artifactId}"/>
>         </not>
>       </condition>
>     </fail>
>     <xmlproperty keeproot="false" prefix="grand.pom.build">
>       <string value="${ivy.pom.build.plugins[0].configuration}"/>
>     </xmlproperty>
>     <echoproperties prefix="ivy.pom"/>
>     <fail message="Inconsistent Ant and Maven properties!">
>       <condition>
>         <not>
>           <and>
>             <equals arg1="${ivy.pom.version}" arg2="${project.version}"
> forcestring="true"/>
>             <equals arg1="${ivy.pom.build.source}" arg2="${java.target}"
> forcestring="true"/>
>             <equals arg1="${ivy.pom.build.target}" arg2="${java.target}"
> forcestring="true"/>
>           </and>
>         </not>
>       </condition>
>     </fail>
>   </target>
>
> Gintas
>
> 2017-06-01 13:56 GMT+02:00 J Pai <jai.forums2013@gmail.com>:
>
>> The new organization being proposed “org.apache.ant” instead of
>> “org/apache” is the right way to go IMO. It’s not just Ivy and applies to
>> Maven co-ordinates (via pom.xml) as well. Ideally, they should match with
>> each other. Using the org.apache.ant would make it fit with the groupId (in
>> Maven land) and the organization naming schemes that I have seen for all
>> the other projects out there.
>>
>> -Jaikiran
>> On 01-Jun-2017, at 2:27 AM, Maarten Coene <maarten_coene@yahoo.com.INVALID>
>> wrote:
>>
>> I don't see how Ivy could resolve the old ant-compress ivy.xml files
>> without using very special artifact patterns.So my guess is that Ivy users
>> of ant-compress just use the pom.xml file.
>>
>> So I'd say we should fix the ivy.xml.
>> Maarten
>>
>>      Van: Stefan Bodewig <bodewig@apache.org>
>> Aan: dev@ant.apache.org
>> Verzonden: woensdag 31 mei 17:34 2017
>> Onderwerp: [antlibs] Break Backwards Compatibility of Ivy Coordinates?
>>
>> Hi all
>>
>> this is an excerpt from the cancelled vote thread for the compress
>> antlib.
>>
>> 2017-05-31 16:40 GMT+02:00 Stefan Bodewig <bodewig@apache.org>:
>>
>> > I've just realized that the ivy.xml file I've published to Nexus has
>> > completely different coordinates from the one used in earlier
>> > releases. It used to be
>> >
>> >     <info organisation="org/apache"
>> >           module="ant" ...>
>> >         <artifact name="ant-compress" ...
>> >
>> > for 1.5 RC1 it is
>> >
>> >     <info organisation="Apache Ant"
>> >           module="ant-compress" ...>
>> >         <artifact name="ant-compress" ...
>> >
>> > and the current master branch would create
>> >
>> >     <info organisation="org.apache.ant"
>> >           module="ant-compress"
>> >           <artifact name="ant-compress" ...
>>
>> and as Gintas points out, master is the only one that is using Ivy
>> coordinates the way they are intended to be.
>>
>> All antlibs builds except for Compress are currently in a state that
>> makes it impossible to release them without making changes and Compress
>> is "correct" after all. So now would be a good time to decide what to
>> do.
>>
>> We could violate Ivy's concepts and go back to what we've done before -
>> the first example above. This is what the two releases of Dotnet, the
>> four releases of AntUnit ant the five releases of Compress have done so
>> far.
>>
>> The other option is to fix all Antlibs to be in line with Ivy's concepts
>> (as Compress is inside master right now). This runs the risk of breaking
>> things for people who use Ivy to retrieve the Antlibs (or maybe not, if
>> they pick them up via their POMs as those have been correct) with all
>> future releases of the three Antlibs that have had releases.
>>
>> I tend to go with the second option and list it as a backwards
>> incompatible change.
>>
>> Any preferences?
>>
>> Stefan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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