ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maarten Coene <>
Subject Re: [antlibs] Break Backwards Compatibility of Ivy Coordinates?
Date Wed, 31 May 2017 20:57:09 GMT
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.

      Van: Stefan Bodewig <>
 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

2017-05-31 16:40 GMT+02:00 Stefan Bodewig <>:

> 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

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

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?


To unsubscribe, e-mail:
For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message