Allow signatures to be loaded as Maven artifacts

[GoogleCodeExporter]

In issue #10 it was shown that its possible to release "signature" artifacts as 
Maven packages. You could then add a dependency to the Maven plugin section of 
your POM and load the signaures JAR file into the plugin's classpath. Those 
signatures would then be available by the "bundled-signatures" config setting.

The only problem is the package name: All those Maven artifacts need to have 
the signatures in the de.thetaphi.forbiddenapis package, which violates general 
Maven bundling, which should have package names named by the released product 
(see also OSGI).

Instead the signatures should be moved into the META-INF/ folder of the JAR, so 
its universal. An addon signature artifact would then be a JAR file with only a 
META-INF/ resource folder.

Original issue reported on code.google.com by uwe.h.schindler on 11 Oct 2013 at 3:53

[uschindler]

One other soulution would be to allow <signatureResources>. This would load signatures from plugin's classpath. Not fixed to META-INF or other subfolder, just by giving a resource URI:

<signatureResources>
  <resource>my/own/package/signatures.txt</resource>
</signatureResources>

This would execute getClass().getClassloader().getResourceAsStream(...)

In any case, defining real maven dependencies would be the more flexible use case, but harder to do.

[veithen]

Simply loading signatures from the plugin's classpath isn't a good solution because this implies that the Maven artifacts are added as plugin dependencies, but this won't work because plugin dependencies are loaded from the wrong repositories (see my first comment above).

[uschindler]

Ah, you are right. But the possibility to do this could also be availabe or does it make no sense at all?

[uschindler]

I started to work on this, want this to be ready for release of v. 2.0. Maven is at the moment the only plugin left that does not support signatures files from Maven central.

Gradle supports it out of box:

• create configuration (e.g., "forbiddenSignatures") and add the artifacts as dependencies. You are free to use any type, just Maven coordinates are important
• Assign the configuration (which implements FileCollection) to the signaturesFiles property of the task

Ant also supports it (since a few cleanups on weekend):

• Moved the signatures to a separate XML element named <signatures>...</signatures>. This element can contain several resource types (all of Ant like files, filesets, ivy:cachefilesets, strings, and also a special type added by forbidden called <bundled name=.../>).
• By this its possible to collect signatures files from any resource (also IVY or simply give an URL, string,...)

I like Ant's solution best, because you have full flexibility. You also can pick single files from JARs or whatever. Really everything is possible.

As always, maven will be most restricted. Adding a new dependency type is impossible.

The PR #79 implements a new configuration parameter signaturesArtifacts that is implemented by several strings for groupId, artifactId, version and type/packaging (+ other coordinate parts like qualifiers). This is very limited but should fit the needs. If you want to have it inside JAR artficats, the coordinates also optionally may supply a resource name (resolved against the JAR file). This is not yet implemented, but want to get basic setup working.

[uschindler]

This is now how it looks like:

Possibility (a):

<signaturesArtifact>
  <groupId>org.apache.foobar</groupId>
  <artifactId>example</artifactId>
  <version>1.0</version>
  <classifier>signatures</classifier>
  <type>txt</type>
</signaturesArtifact>

(this relies on a separate .txt file artifact in Maven Central)

The alternative (b) is to refer to a TXT file inside a jar/war/zip/ear/... artifact using the "additional coordinate" named "path":

<signaturesArtifact>
  <groupId>org.apache.foobar</groupId>
  <artifactId>example</artifactId>
  <version>1.0</version>
  <type>jar</type>
  <path>path/inside/jar/file/signatures.txt</path>
</signaturesArtifact>

So practically, an alternative way to specify bundled signatures via Maven is:

<signaturesArtifact>
  <groupId>de.thetaphi</groupId>
  <artifactId>forbiddenapis</artifactId>
  <version>2.0-SNAPSHOT</version>
  <type>jar</type>
  <path>de/thetaphi/forbiddenapis/signatures/jdk-deprecated-1.6.txt</path>
</signaturesArtifact>

For both cases, the artifact declarations have to be wrapped inside an outer, additional <signaturesArtifacts>...</signaturesArtifacts> outer element.

PR #79 is almost ready, just a test for Maven 2 and Maven 3 is missing.