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 12:57:41 GMT
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