Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow signatures to be loaded as Maven artifacts #13

Closed
GoogleCodeExporter opened this issue Mar 14, 2015 · 16 comments
Closed

Allow signatures to be loaded as Maven artifacts #13

GoogleCodeExporter opened this issue Mar 14, 2015 · 16 comments
Assignees
Milestone

Comments

@GoogleCodeExporter
Copy link

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
Copy link
Member

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

veithen commented May 25, 2015

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
Copy link
Member

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

@uschindler
Copy link
Member

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
Copy link
Member

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.

uschindler added a commit that referenced this issue Sep 29, 2015
Issue #13: Implement signatures artifacts, downloaded from Maven repos
@uschindler uschindler added this to the 2.0 milestone Sep 29, 2015
@uschindler
Copy link
Member

This feature was committed to master: bbc5418

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants