5

Last week our project stopped working because maven-ant-task seems to be calling maven central with http instead of https and now it's enforced, so it returns a 501.

We saw that Apache released a new library Maven Artifact Resolver Ant Tasks, so we're trying to migrate.

This is our old file, used to call our in-house jaxb library to generate java classes. The dependency is dome-jaxb and we were resolving it with maven-ant-tasks.

<project name="Main" basedir="../../" xmlns:artifact="antlib:org.apache.maven.artifact.ant">

   <!-- ==================== Execution Classpath =========================== -->
   <artifact:dependencies filesetId="dependency.fileset" useScope="runtime">
      <dependency groupId="com.dome" artifactId="dome-jaxb" version="LATEST"/>
   </artifact:dependencies>

   <path id="Execute.classpath">
      <fileset refid="dependency.fileset"/>
      <pathelement path="target/classes"/>
   </path>

   <!-- ==================== Type Target ===================================== -->
   <target name="Types" description="Generate type">
      <java classname="dome.util.xml.converter.GenerateClassFromXMLConfig" fork="yes">
         <sysproperty key="file.encoding" value="UTF-8"/>
         <arg value="${basedir}"/>
         <arg value="${xmlConfig}"/>
         <arg value="${moduleId}"/>
         <classpath refid="Execute.classpath"/>
      </java>
   </target>
</project>

I downloaded the project, generated the uber jar (after that I found out that you can also download it here), and added it to my ant/lib (where the maven-ant-task.jar is located).

The new configuration file I managed to put together is this one:

<project name="Main" basedir="../../" xmlns:resolver="antlib:org.apache.maven.resolver.ant">

   <!-- ==================== Execution Classpath =========================== -->
   <taskdef uri="antlib:org.apache.maven.resolver.ant" resource="org/apache/maven/resolver/ant/antlib.xml">
      <classpath>
         <fileset dir="target" includes="maven-resolver-ant-tasks-*uber.jar"/>
      </classpath>
   </taskdef>

   <path id="Execute.classpath">
      <pathelement path="target/classes"/>
   </path>

   <resolver:resolve>
      <dependencies>
         <dependency
            groupId="com.dome"
            artifactId="dome-jaxb"
            version="LATEST"
            scope="runtime"
         />
      </dependencies>      
      <path refid="Execute.classpath" classpath="runtime"/>
   </resolver:resolve>

   <!-- ==================== Type Target ===================================== -->
   <target name="Types" description="Generate type">
      <java classname="dome.util.xml.converter.GenerateClassFromXMLConfig" fork="yes">
         <sysproperty key="file.encoding" value="UTF-8"/>
         <arg value="${basedir}"/>
         <arg value="${xmlConfig}"/>
         <arg value="${moduleId}"/>
         <classpath refid="Execute.classpath"/>
      </java>
   </target>

</project>

This seems to work, but it looks like it's not using my settings.xml which is located in ~/.m2/ (the default location, which reading the documentation should be used), because we have a nexus repository with our local libraries, but it seems that it's only checking the maven central repository since the error is:

Could not find artifact com.dome:dome:jar:4.23.0 in central (https://repo1.maven.org/maven2/)

I've seen in the documentation that you can manually set your settings.xml location, but there's no example or indication as where to put that configuration, so I couldn't get it working.

If anyone has any idea / suggestion, it would be greatly appreciated.

Leo Lozes
  • 1,358
  • 1
  • 15
  • 33
  • it seems that defining the repository manually it works, but if it's defined in my settings.xml, shouldn't it be unnecessary to do this? – Leo Lozes Jun 15 '20 at 09:58
  • In Maven Artifact Resolver Ant Tasks the task is missing. What did you do to replace it in your migrated code? – Zsolt Nov 17 '20 at 19:57

2 Answers2

1

I have observed the same and I think it is a bug in maven-resolver org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(). I'm able to avoid the issue as long as there is a maven-metadata.xml for each artifact I need to resolve. So, my workaround is to:

  1. Copy our deployment repository to ~/.m2/repository to set the baseline

  2. Use mvn -DupdateReleaseInfo=true for any local install

  3. Use mvn dependency:go-offline and mvn dependency:get -Dartifact=... to resolve any other dependencies before running Ant

Lii
  • 11,553
  • 8
  • 64
  • 88
Allen D. Ball
  • 1,916
  • 1
  • 9
  • 16
1

You are likely affected by https://issues.apache.org/jira/browse/MRESOLVER-66. I haven't looked at it, but will happily accept patches.

Michael-O
  • 18,123
  • 6
  • 55
  • 121