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
>
>
