Improve the aggregator's maven publishing to support resolving package requirements

[merks]

I'm testing using the platform's *.aggr which I've modified to add more rules for completeness of the mapping, including correctness for all dependencies:

The above selected maven mapping specifies to map any bundle to $key$ where key must be present as a property in the p2 metadata of the installable unit for the rule to be applicable. This normal default rule kicks in when that's not the case.

A new tab in the Analyzer editor presents the information about the POM induced for each installable unit. Here we see that package imports are resolved to one or more installable units (two in the case selected below) and those are also mapped to dependencies:

The Analyzer editor analyzes each generated POM to ensure that the group/artifact information can be resolved to its maven metadata either remotely or locally, e.g.,

https://repo1.maven.org/maven2/org/eclipse/jdt/org.eclipse.jdt.apt.pluggable.core/maven-metadata.xml

It also tests that each dependency's version range resolves to an existing artifact version.

It's not clear whether adding support for java.package requirements will result in bogus or undesirable dependencies. In the example above. I think the dependency on ecg is undesirable (and definitely unnecessary), but I don't know if it's problematic. If you look at the most recent published version you can see that the dependencies for package imports were not present previously:

https://repo1.maven.org/maven2/org/eclipse/jdt/org.eclipse.jdt.apt.pluggable.core/1.3.0/org.eclipse.jdt.apt.pluggable.core-1.3.0.pom

In other cases duplicates seem correct, e.g., as in this case involving split packages:

My sense though is that we need some general mechanism to control this new behavior or even to turn off this new behavior...

[merks]

I added support for MavenDependencyMapping and use it like this for the platform SDK aggregator:

1. Specifies to ignore all requirements of all IUs that don't start with org.eclipse and also exclude org.eclipse.emf, org.eclipse.ecf, and org.eclipse.jetty given that these are not published by the platform project; the value of ! for the group and artifact ids specifies to omit matching dependencies.
2. Ensure that the matching package requirements map to the bundles and not also to the ecj bundle.
3. Similarly.
4. Specifies that all java.package dependencies (of all remaining IUs), map to */* which results in the requirement being resolved to one or more IUs and the MavenMappings for those IUs being used to produce the dependencies.

This above fixes this to produce the proper dependency:

[merks]

Provide improved support for specifying version ranges for package requirements. In particular, provide support for extracting the version components from the bundle(s) that provide(s) the capability that satisfies the requirement.

For example, this syntax is supported:

Here the Version Range Template value major.minor.micro will expand to the full version of the resolved requirement. The expansion/evaluation process trims trailing segment separators so the javax.inject package requirement which resolves to version 1 evaluates to 1 instead of 1..:

Also supported are simple expressions, e.g.,

where the [major.minor.micro,major+1) produces this dependency range: