Ant script fails during XSLT task when called from Eclipse

[kwin]

When executing Ant from within Eclipse with target -antunit-fake-pom it fails with

-antunit-fake-pom:
     [xslt] Processing /Users/konradwindszus/git/policeman-tools/forbidden-apis/src/test/antunit/dummy.xml to /Users/konradwindszus/git/policeman-tools/forbidden-apis/build/test-maven/fake-pom.xml
     [xslt] Loading stylesheet pom-generator.xsl
     [xslt] : Error! Use of the extension function 'http://exslt.org/strings:split' is not allowed when the secure processing feature is set to true.
     [xslt] Failed to process /Users/konradwindszus/git/policeman-tools/forbidden-apis/src/test/antunit/dummy.xml

BUILD FAILED
/Users/konradwindszus/git/policeman-tools/forbidden-apis/build.xml:600: javax.xml.transform.TransformerException: java.lang.RuntimeException: Use of the extension function 'http://exslt.org/strings:split' is not allowed when the secure processing feature is set to true.

Eclipse requires to explicitly parametrize the underlying factory with

<factory>
     <feature name="http://www.oracle.com/xml/jaxp/properties/enableExtensionFunctions" value="true"/>
</factory>

to make it work.
Further information in https://bugs.eclipse.org/bugs/show_bug.cgi?id=520437.

The workaround which kicks in during Ant CLI build does not work when called from Eclipse: https://bz.apache.org/bugzilla/show_bug.cgi?id=61389

[uschindler]

I merged the PR. Thanks!

[uschindler]

The PR broke the build with Java 7/8 and the minimum supported Ant version.

I reverted it for now. To me this is an Eclipse issue and could be fixed with adapting the command line to undo the added command line options that cause this to fail.

[uschindler]

Hi,
Let me check another time if the extension functions are really needed here. Often it can be done more verbose without. I also have to check other XSL templates used to build Maven deployment/build descriptors.
So there might gut be a better solution. I don't fully remember, but this XSL possibly uses some EXSLT Set/Tokenizer functions to split string parameters to nodes.

[uschindler]

It is as expected. It gets a classpath like structure of jar files as string with separator and builds maven dependency XML from it after splitting it into its parts.

Is it possible to pass a plain classpath to maven as a single dependency?

This is what happens:

forbidden-apis/src/test/antunit/pom-generator.xsl

Line 75 in 6019f14

<xsl:for-each select="str:split($jarfiles,'|')">

If you could pass the string as a classpath or lib directory to Maven as a "fake dependency" it would be easier. Gradle supports this.

[kwin]

Usually one uses a Maven property for the version and a dedicated local repository (compare with https://maven.apache.org/plugins/maven-invoker-plugin/install-mojo.html). Using system path is considered an anti-pattern (even for integration test)...

[uschindler]

Usually one uses a Maven property for the version and a dedicated local repository (compare with https://maven.apache.org/plugins/maven-invoker-plugin/install-mojo.html). Using system path is considered an anti-pattern (even for integration test)...

That's impossible to do here. The artifacts are in no repository (and creating a local one without control in users home dir or similar is an anti pattern, too). There's also no easy way to create a Maven repository from Ant. The jar files related here have no maven coordinates yet.

With Gradle this is all a no-brainer, but this is one reason why I try to avoid Maven.

P.S. if I have done time I will migrate the build from the legacy Ant to Gradle. I had a PR hor this already but because of classpath pollution with outdated Asm or Ant versions I left this on the to do list. Now that Gradle has fixed this, the build system is best fit for forbidden apis. In that case you could instruct Gradle to create an isolated Maven repo.

In short: is it possible to give maven a system dependency with a classical class path (which may contain arbitrary class files, too)? It does not matter if it is deprecated or (German) "unschick", it should work with Maven 3. The integration tests use Maven 3 only, so I don't care about religious aversion against some test setup. I don't care.