I discovered that there is one nasty issue with the approach to add a 
dependency to the plugin declaration in the POM. Maven seems to simply add that 
dependency to the dependencies of the plugin (i.e. those declared in the POM of 
the plugin) and then to resolve them all in the same way. In particular, Maven 
will use the repositories declared in the POM of the plugin, and not the 
repositories declared in the POM of the project where the plugin is configured. 
This would still work for bundled signatures available from Maven central or if 
one builds the the JAR with the signatures first, but in all other cases, the 
build may fail with the following kind of error:

[ERROR] Failed to execute goal de.thetaphi:forbiddenapis:1.4-SNAPSHOT:check 
(default) on project synapse-nhttp-transport: Execution default of goal 
de.thetaphi:forbiddenapis:1.4-SNAPSHOT:check failed: Plugin 
de.thetaphi:forbiddenapis:1.4-SNAPSHOT or one of its dependencies could not be 
resolved: Could not find artifact 
org.apache.ws.commons.axiom:forbiddenapi-signatures:jar:1.2.15-SNAPSHOT in 
sonatype-nexus-snapshots 
(https://oss.sonatype.org/content/repositories/snapshots)

In the example shown above, Maven is trying to resolve 
org.apache.ws.commons.axiom:forbiddenapi-signatures:jar:1.2.15-SNAPSHOT from 
oss.sonatype.org because that repository is declared in the POM of the plugin 
(via its parent POM), but the artifact is in the Apache snapshot repository 
(which is properly declared in the POM of the project).

To get the desired feature (i.e. load bundles signatures from a Maven 
artifact), we will need to add a parameter to the plugin that allows to specify 
a list of Maven artifacts and then write the code that resolves these artifacts 
using the correct list of remote repositories.

You think we should add code like in the animal-sniffer plugin?

See this:
https://fisheye.codehaus.org/browse/mojo/tags/animal-sniffer-parent-1.9/animal-s
niffer-maven-plugin/src/main/java/org/codehaus/mojo/animal_sniffer/maven/CheckSi
gnatureMojo.java?r=17664

This is a big change and I have to think about it, but we can make it work. So 
I would for now not move the bundled artifacts and instead we should do this as 
a separate "feature": Load signatures from remote artifacts, given by maven 
coordinates.

> Load signatures from remote artifacts, given by maven coordinates.

This means signatures dont need to be JAR files, you can directly load them 
from Maven as a "signature file" artifact.

> You think we should add code like in the animal-sniffer plugin?

Yes. Another example would be the "copy" goal in the maven-dependency-plugin.

> This means signatures dont need to be JAR files, you can directly load them 
from Maven as a "signature file" artifact.

As a matter of fact, it would not be required to package them as JARs.

I checked around to find the easiest way to do this:

I have 2 ideas:

1) Add another signatures config option, which is a list of Strings, every 
string pointing to an artifact (like the get-Mojo in the maven-dependency 
plugin): http://maven.apache.org/plugins/maven-dependency-plugin/get-mojo.html
Those dependencies would be resolved directly from the configured repos, but 
not transitively.

2) List the artifacts as "standard dependecies" in your pom with a new 
type/scope in the standard dependencies section of your pom. I have no idea if 
this is easy possible:

<dependency>
 <groupId>you.own.group</groupId>
 <artifactId>myforbiddensignatures</artifactId>
 <version>x.x</version>
 <type>TOBEDISCUSSED</type>
 <scope>forbidden-apis</scope>
</dependency>

This would be most elegant, the maven plugin would only ask the resover to 
resolve all scope="forbidden-apis" artifacts (including dependencies, if they 
declare some!). The type would default to something unique for those artifacts. 
This approach would work like with any other dependency, so you can also list 
versions in dependencyManagement or whatever you can do here.

What do you think?

The second approach would also allow to configure the dependencies per 
sub-module like in the standard Maven build scenario, so you would not need to 
disable signatures that don't resolve. The sub-projects would list the 
signatures together with their own JAR dependencies...

Some investigation shows: scope="..." would be not possible. It should be more 
the type of artifact that is used to differentiate between standard deps and 
forbiddens. Like a WAR dependency is never added to compile classpath, although 
listed in scope="compile".

So the thing should look like this:
- add dependency to signatures for scope="compile" or scope="test" or both, 
e.g. runtime
- set type of dependency to "forbidden-apis-signature"

The plugin would then resolve all dependencies for the scope of compilation 
(CheckMojo or TestCheckMojo) and collect all artifacts of the 
"forbidden-apis-signature" type.

I will delay this issue to be implemented after the next release, maybe for 
version 2.0. This requires major changes.

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