[antlibs] Break Backwards Compatibility of Ivy Coordinates?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[antlibs] Break Backwards Compatibility of Ivy Coordinates?

Stefan Bodewig
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 <[hidden email]>:

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [antlibs] Break Backwards Compatibility of Ivy Coordinates?

Gintautas Grigelionis
Hi,

can't you just publish new ivy.xml?

Gintas

2017-05-31 17:34 GMT+02:00 Stefan Bodewig <[hidden email]>:

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

Re: [antlibs] Break Backwards Compatibility of Ivy Coordinates?

Stefan Bodewig
On 2017-05-31, Gintautas Grigelionis wrote:

> can't you just publish new ivy.xml?

we can't overwrite existing files in Maven Central.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [antlibs] Break Backwards Compatibility of Ivy Coordinates?

Gintautas Grigelionis
Then option 2 is a given: errare humanum est sed in errare perseverare
diabolicum :-)

Gintas

2017-05-31 18:11 GMT+02:00 Stefan Bodewig <[hidden email]>:

> On 2017-05-31, Gintautas Grigelionis wrote:
>
> > can't you just publish new ivy.xml?
>
> we can't overwrite existing files in Maven Central.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [antlibs] Break Backwards Compatibility of Ivy Coordinates?

Maarten Coene-2
In reply to this post by Stefan Bodewig
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 <[hidden email]>
 Aan: [hidden email]
 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 <[hidden email]>:

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



   
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [antlibs] Break Backwards Compatibility of Ivy Coordinates?

Jaikiran Pai
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 <[hidden email]> 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 <[hidden email]>
Aan: [hidden email]
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 <[hidden email]>:

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





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [antlibs] Break Backwards Compatibility of Ivy Coordinates?

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

> 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 <[hidden email]>
> 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 <[hidden email]>
> Aan: [hidden email]
> 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 <[hidden email]>:
>
> > 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [antlibs] Break Backwards Compatibility of Ivy Coordinates?

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

> 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 <[hidden email]>:
>
>> 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 <[hidden email]>
>> 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 <[hidden email]>
>> Aan: [hidden email]
>> 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 <[hidden email]>:
>>
>> > 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
Loading...