Update versions of dependencies

[fipro78]

With this PR the following changes are intended:

• Update the versions of the NatTable dependencies
• Handle the changes needed for the Eclipse Collections update
• Change the features to not include the third-party dependencies anymore

@merks and @laeubi

Are these the changes we discussed in the Eclipse Collections PR? Or should I change something to make NatTable better consumeable and integrateable?

[laeubi]

Suggested change

	<import plugin="org.eclipse.collections.api"/>
	<import plugin="org.eclipse.collections.impl"/>
	<import plugin="org.eclipse.collections.impl"/>

I assume the API is already referenced somehow and does not needs to be listed explicitly?

[merks]

Yes, I think one doesn't generally need to specify such things in the feature.xml if some bundle already has such a dependency anyway and if both these things are needed then the bundle should require both...

[fipro78]

Typically the impl bundle is not referenced directly but only the api bundle. In the older versions of Eclipse Collections the factory.primitive bundle was not available in the api bundle, which is why there is such a dependency to impl in NatTable. But it seems that was fixed with 11.1.0 already. So I will change that now too.

[laeubi]

Typically the impl bundle is not referenced directly but only the api bundle

From OSGi point of view it would be good to have a require capability and corresponding provided capability then, e.g. like we did for SWT here:

• https://github.com/eclipse-platform/eclipse.platform.swt/blob/a413b4b7a52571c311aa333e4d7394b66f6b9a76/bundles/org.eclipse.swt.svg/META-INF/MANIFEST.MF#L15
• https://github.com/eclipse-platform/eclipse.platform.ui/blob/f7d94e22f91c78aaec56663452d49199cfdd5cc8/bundles/org.eclipse.jface.text/META-INF/MANIFEST.MF#L43
  then if someone uses the API it will get at least one implementation.

[fipro78]

They have pretty extensive capability headers.

Require-Capability: osgi.extender;filter:="(&(osgi.extender=osgi.service
 loader.processor)(version>=1.0.0)(!(version>=2.0.0)))",osgi.serviceload
 er;filter:="(osgi.serviceloader=org.eclipse.collections.api.factory.bag
 .ImmutableBagFactory)";...

Provide-Capability: osgi.service;objectClass:List<String>="org.eclipse.c
 ollections.api.factory.bag.ImmutableBagFactory";effective:=active,...

That was actually my main contribution to Eclipse Collections. Using bndtools to generate the manifest files for correct SPI headers.

Does that mean I can also remove the IMPL dependency?

[laeubi]

It seems to be the case ...

[laeubi]

Suggested change

	<requires>
	<import plugin="ca.odell.glazedlists"/>
	<import plugin="org.apache.commons.commons-codec"/>
	</requires>
	<requires>
	<import plugin="ca.odell.glazedlists"/>
	<import plugin="org.apache.commons.commons-codec"/>
	</requires>

I would assume both are anyways required by some import-package/require bundle so no need to list them here.

[laeubi]

Suggested change

	<requires>
	<import plugin="org.apache.commons.lang3"/>
	<import plugin="org.apache.commons.text"/>
	<import plugin="org.eclipse.nebula.cwt"/>
	<import plugin="org.eclipse.nebula.widgets.cdatetime"/>
	<import plugin="org.eclipse.nebula.widgets.richtext"/>
	</requires>

These are also likely not independently required?

[merks]

Yes, less is more.

[laeubi]

At least some here seem not needed as they are already transitively required.

[merks]

Move all such 3rd party things to a feature not consumed by end users.

[fipro78]

Does it need to be a feature, or can those dependencies also be added as bundles in a new category?

[laeubi]

Should these really be consumed from nat table or are these more dependencies of this project and can be added e.g. as maven coordinates or consumed from the original update sites directly?

[fipro78]

For the 12.0.0 version there is no original update site. Seems that was missed and is only available for the 13.0.0. But of course I can use the maven coordinates.

[merks]

I see no changes to the category.xml so I doubt very much your repository will contain all the necessary 3rd party (non-project) dependencies that are needed by nattable. It's of course fine not to include things from the Platform, but you really need to ensure that folks can install or create a target platform from nattable and all the transitive dependencies.

[fipro78]

@laeubi
I have adapted the PR according to your suggestions. Would you say it is ok now?

@merks
I have added the third-party dependencies to a new category, but without a new feature. With the automatic resolving of a target platform, I get the things resolved and can build a product in a clean environment. But of course it will resolve the Eclipse Collections 11.1.0 from the SimRel currently if I do not explicitly include the 12.0.0 in my target. I suppose this gets solved once Eclipse Collections is removed from the SimRel repo, correct?

Is the state of this PR now fine, or should I modify something? In the past I would have added something like "third-party-dependency-features", but if I understand correctly, this is not really necessary anymore, right?

[laeubi]

@fipro78 just in case instead of adding a handcrafted set of dependencies to a category.xml (and therefore duplicating content, increasing the load on the storage server and so on) I would these days recommend the following:

1. Enable includeAllDependencies to make P2 consider all transitive of dependencies of your plugins
2. Enable includeAllSources if you want to be nice and distribute all available sources
3. Enable addIUTargetRepositoryReferences to reference what you have consumed
4. Enable filterProvided to remove everything already provided by other update sites

That way you will end up with a minimal update site where user can install whatever is required transitively (if not already there) optionally including the sources.

[fipro78]

@laeubi

If I change the packaging to p2-maven-repository and add this plugin configuration in the update-site pom.xml

<plugin>
    <groupId>org.eclipse.tycho</groupId>
    <artifactId>tycho-p2-repository-plugin</artifactId>
    <version>${tycho-version}</version>
    <configuration>
        <includeAllDependencies>true</includeAllDependencies>
        <includeAllSources>true</includeAllSources>
        <addIUTargetRepositoryReferences>true</addIUTargetRepositoryReferences>
        <filterProvided>true</filterProvided>
        <categoryName>NatTable</categoryName>
    </configuration>
</plugin>

I get an almost empty update site. I only see the DataSet category and there are only the artifacts.xml and the content.xml file. So probably I am doing things wrong. Any hints?

[laeubi]

If I change the packaging to p2-maven-repository

This mostly is to be used for plain maven builds (well it should also work for Tycho builds ...), just keep everything as before (e.g. category.xml and packing) and just remove any third party stuff :-)

[fipro78]

@laeubi
I have updated the PR according to your suggestions. Looks ok to me. Now the NatTable repository only contains the NatTable artifacts. If I use it in a new project, the dependencies are resolved automatically. Well, of course only if the automatic dependency resolution is enabled. But IMHO this should give users the same convenient experience as before (especially with the same automation feature in the .product file), but provides the ability to customize in case different versions of the dependencies should be used.

@merks
What do you think?