feat(GH-188): Implement package type providers

[dwalluck]

This uses the Java Service Provider Interface via ServiceLoader to register new types, where each type gets its own class.

[ppkarwasz]

My 2 cents about the API changes:

• The only class that the user needs to see in order to implement a new type is PackageTypeProvider. Since users that implement this interface are service providers, I would put it in a spi package. The package must have an @Export annotation, so it is marked as exported by BND.
• The remaining classes can be in an non-exported package. I would suggest calling it internal, so even non-JPMS users understand that the package is not part of the public API. The ServiceLoader JavaDoc even recommends this:

  It is strongly recommended that the module does not export the package containing the service provider.

• Nit: I find putting each implementation of PackageTypeProvider a little bit verbose. These classes need to be public, but they can be nested classes of a single top level class.
• JPMS and OSGi don't read the META-INF/services files. To declare a class as service, the @ServiceProvider class from biz.aQute.bnd.annotation can be used (see documentation):

  @ServiceProvider(value = PackageTypeProvider.class, resolution = Resolution.MANDATORY)

  This will generate all the necessary JPMS, OSGi and even the META-INF/services file. The current BND goal jar does this, when it creates the JAR, which is too late for unit tests, so we need either keep a manually generated META-INF/services file or switch to the bnd-process goal.
• The class that calls ServiceLoader needs to be annotated with:

  @ServiceConsumer(value = PackageTypeProvider.class, resolution = Resolution.MANDATORY, cardinality = Cardinality.MULTIPLE)

[dwalluck]

@ppkarwasz I made most of the changes you suggested, but I need to know how to update the pom.xml and bnd.bnd files:

[WARNING] bnd.bnd [0:0]: jpms.jarname calculated module names from file name: [org.osgi.resource-1.0.0, org.osgi.service.serviceloader-1.0.0][ERROR] bnd.bnd [0:0]: Requirement osgi.extender resolution not correct[ERROR] bnd.bnd [0:0]: Requirement osgi.serviceloader cardinality not correct[ERROR] bnd.bnd [0:0]: Requirement osgi.serviceloader resolution not correct

[dwalluck]

• biz.aQute.bnd.annotation can be used (see documentation):

@ppkarwasz There seems to be duplicated classes between this and org.osgi.annotation.bundle. I am not sure which to prefer, since I think both dependencies end up being necessary.

[dwalluck]

• This will generate all the necessary JPMS, OSGi and even the META-INF/services file. The current BND goal jar does this, when it creates the JAR, which is too late for unit tests, so we need either keep a manually generated META-INF/services file or switch to the bnd-process goal.

@ppkarwasz I think it's better to auto-generate this file if we can.

[dwalluck]

It bothers me to have the factory class also implementing some type of provider, since it's not actually added to the set of providers.

This is trying to provider the default normalization that needs to happen before all type-specific normalization.

But, maybe there is a better way to do this (add it to the list in the first position?).

[dwalluck]

This is kind of a hack right now.

[dwalluck]

@ppkarwasz I am stuck on the OSGi errors. I don't have experience creating a bnd file manually as opposed to plugins that generate the MANIFEST.MF bundle headers.

[ppkarwasz]

I am stuck on the OSGi errors. I don't have experience creating a bnd file manually as opposed to plugins that generate the MANIFEST.MF bundle headers.

I'll check it out.

[ppkarwasz]

The BND errors are due to the wrong constants being used.

[ppkarwasz]

Suggested change

	importorg.osgi.annotation.bundle.Requirement.Cardinality;
	importorg.osgi.annotation.bundle.Requirement.Resolution;
	importaQute.bnd.annotation.Cardinality;
	importaQute.bnd.annotation.Resolution;

[dwalluck]

Thanks! I was using something from aQute, but it said deprecated use the OSGi ones, but now I can't find it.

[ppkarwasz]

Suggested change

	importorg.osgi.annotation.bundle.Requirement.Resolution;
	importaQute.bnd.annotation.Resolution;

[ppkarwasz]

What bothers me a little with the current proposal is that type-specific normalization and validation only occurs when normalize and canonicalize is called. Looking at the "Tests" section of the spec and in particular:

• parsing the test purl should return the components parsed from the test canonical purl

I deduce that the components should only and always be stored in normalized form (and be valid). So the PackageTypeProvider interface should probably a validate-and-normalize method for each component, so that it can be used in the constructors.

[jeremylong]

I like this approach - each type can implement the type-specific normalization.