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.grigelio...@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.forums2...@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_co...@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 <bode...@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 <bode...@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-unsubscr...@ant.apache.org
>> For additional commands, e-mail: dev-h...@ant.apache.org
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>> For additional commands, e-mail: dev-h...@ant.apache.org
>>
>>
>
