search

eclipse-nattable / nattable

High performance SWT data grid
https://eclipse.dev/nattable/
Eclipse Public License 2.0
15 stars 6 forks source link

Provide an Oomph setup and update dependencies to the latest versions #96

Closed merks closed 2 months ago

merks commented 3 months ago

https://github.com/eclipse-nattable/nattable/issues/95

merks commented 3 months ago

FYI, this bundle is the replacement for all those bundles that I removed (and are needed by batik):

image

But all too often features are over-specified because the requirements of the bundles will be satisfied even if the bundles are listed in a feature.

merks commented 3 months ago

I notice that none of those feature includes affect the update site content which is like this for the 2.4.0 release:

image

And it looks like this for the locally-built repo:

image

So indeed I do think you have gone overboard on the includes in the features used by the product...

fipro78 commented 3 months ago

So indeed I do think you have gone overboard on the includes in the features used by the product...

Not sure what you mean by that. The dependencies of NatTable as a widget are what they are. I actually do not see a big difference in the screenshots you provided. Have I missed something?

The features used in the product are intended to build the examples app product only. They are not published in other ways. And those E4 product features are only intended to keep the product as small as possible.

merks commented 3 months ago

So indeed I do think you have gone overboard on the includes in the features used by the product...

Not sure what you mean by that. The dependencies of NatTable as a widget are what they are. I actually do not see a big difference in the screenshots you provided. Have I missed something?

Yes, the screen shots are about the contents of the update site which are not affected by these plug-in includes.

The features used in the product are intended to build the examples app product only. They are not published in other ways. And those E4 product features are only intended to keep the product as small as possible.

Yes, that's the point. And there such things are not required at all because a product will always include all dependencies without the features doing the includes. As I showed for the Platform: no feature include batik but batik is installed in the SDK product. So you would be more flexible and better off prune down the includes so it doesn't matter which bundle is providing the java.inject package, or com.ibm.icu, if that's even needed which appears not to be the case.

fipro78 commented 3 months ago

And there such things are not required at all because a product will always include all dependencies without the features doing the includes.

That was not the case in the past. And it would also not happen if you uncheck the option the product definition. ;) Anyhow, I got your point and will try to improve the product build further.

merks commented 3 months ago

FYI, I experimented with removing a whole whack of 3rd party bundle includes from features and removing some produce start configuration stuff that I think matters not for your simple product:

image

The product still launches in this case.

We can try to make further simplifications. It's kind of bad news to have to list so many bundles in product feature because if something changes in the Platform it could be a problem. Probably there was a good reason not to just reuse existing platform features like the rcp feature...

fipro78 commented 3 months ago

Probably there was a good reason not to just reuse existing platform features like the rcp feature...

Yes, size concerns with com.ibm.icu. Actually the nattable.examples.e4.rcp.feature is a copy of the platform rcp feature with minimal modifications. Maybe it is possible to drop it now and use the platform rcp feature. 10MB are today much less than it was 10 years ago.

merks commented 3 months ago

I can help experiment with further produce simplification and to make sure it works with both older and new target platforms.. The simpler everything is, the easier it is to maintain. 😀

fipro78 commented 3 months ago

One thing I noticed, the pom.xml file dependencies are not updated. These exist because we publish NatTable on Maven Central and want to ensure that the dependencies are resolved the Maven way too. That was at least necessary in the past. Is there now a more comfortable way to have the correct dependencies in the pom.xml for the Maven Central deployment, or do we still need to maintain this manually?

merks commented 3 months ago

That's a good question. The Platform and EMF use the CBI aggregator. I'm not sure that's more comfortable, though maintaining Maven dependencies is also not exactly comfortable either. Tricky problems like mapping package imports to maven coordinates is handled by the CBI aggregator. But there's a bunch of scripting involved.

In any case, I don't there is much of anything to change. I think only this one affects a bundle for which you've specified dependencies:

            <groupId>org.apache.poi</groupId>
            <artifactId>poi</artifactId>
            <version>4.1.1</version>