search

eclipse-equinox / equinox.bundles

Eclipse Public License 2.0
8 stars 16 forks source link

Delete code of abandoned equinox-io, -ip, -util and -wireadmin plug-ins #17

Closed HannesWell closed 2 years ago

HannesWell commented 2 years ago

As suggested in https://github.com/eclipse-equinox/equinox/issues/18 this PR deletes the following plug-ins that are not build for a while:

Some background why they have been abandoned can be found here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=533801

HannesWell commented 2 years ago

From the from the equinox.bundles/pom.xml I derived that there are one more bundle and feature that are not build and not published anymore:

Could they be deleted too?

tjwatson commented 2 years ago

From the from the equinox.bundles/pom.xml I derived that there are one more bundle and feature that are not build and not published anymore:

Could they be deleted too?

Yes, I see no reason to leave stuff we don't build here.

HannesWell commented 2 years ago

Could they be deleted too?

Yes, I see no reason to leave stuff we don't build here.

Great!

Besides the mentioned ones I think bundles/org.eclipse.equinox.servletbridge.template should removed as well. In contrast to the others it is build at the moment, but it was not published. And since it only consists of a product template that uses plug-ins and features that are finally removed with this PR I think it can/should go as well.

Removing the servletbridge.extension bundl also allowed to simplify the poms of some test plugins.

Furthermore the method deployExtensionBundle(File) in org.eclipse.equinox.servletbridge.FrameworkLauncher could be simplified since we now know that org.eclipse.equinox.servletbridge.extensionbundle can never be found. But I think this should go into a dedicated issue.

tjwatson commented 2 years ago

Furthermore the method deployExtensionBundle(File) in org.eclipse.equinox.servletbridge.FrameworkLauncher could be simplified since we now know that org.eclipse.equinox.servletbridge.extensionbundle can never be found. But I think this should go into a dedicated issue.

Yes, separate issue. Not sure we should do that though because one can always have packaged their own JAR with that name in their WAR.

HannesWell commented 2 years ago

After systematically going through all projects I found two more abandoned projects:

So the full list of removed projects is:

Where only org.eclipse.equinox.servletbridge.template is build but not published at the moment but as mentioned above I think it is obsolete.

HannesWell commented 2 years ago

@tjwatson are you fine with removing them all?

Furthermore the method deployExtensionBundle(File) in org.eclipse.equinox.servletbridge.FrameworkLauncher could be simplified since we now know that org.eclipse.equinox.servletbridge.extensionbundle can never be found. But I think this should go into a dedicated issue.

Yes, separate issue. Not sure we should do that though because one can always have packaged their own JAR with that name in their WAR.

OK. Then lest leave it as it is. Less work to do. :)

HannesWell commented 2 years ago

@tjwatson are you fine with this PR as it is now? If yes I would like to submit it.

tjwatson commented 2 years ago

@tjwatson are you fine with this PR as it is now? If yes I would like to submit it.

Can we Do not delete the two test projects.? The compendium.tests don't exist anywhere else and I use them to test locally (although I would like to get them enabled in the build also for testing things like metatype impl). The ds.tests is questionable to keep but I have used that to verify that our updates to felix SCR versions are working correctly within the project.

tjwatson commented 2 years ago

For the record, I will state that the OSGi WG currently uses the Equinox wireadmin implementation as the compatible implementation. But the wireadmin specification has not seen an update in since its very first 1.0 version release. I argue the OSGi WG can continue to use the currently released versions of Equinox wireadmin for a compatible implementation.

I've literally not heard a single thing from when we stopped building the wireadmin implementation over two years ago. (https://bugs.eclipse.org/bugs/show_bug.cgi?id=533801). That makes me think nobody uses our implementation of wireadmin except the OSGi WG as the compatible implementation to release the wireadmin specification.

tjwatson commented 2 years ago

I forgot to mention that the ds.tests are currently executed during our I-Builds. So deleting them may require other releng work first.

akurtakov commented 2 years ago

ds.tests are executed and I kind of assumed they are testing felix.scr integration on our side, is this not the case?

tjwatson commented 2 years ago

ds.tests are executed and I kind of assumed they are testing felix.scr integration on our side, is this not the case?

Yes, that is the case and why I think we should not delete them at this time.

HannesWell commented 2 years ago

@tjwatson are you fine with this PR as it is now? If yes I would like to submit it.

~Can we~ Do not delete the two test projects.~?~ The compendium.tests don't exist anywhere else and I use them to test locally (although I would like to get them enabled in the build also for testing things like metatype impl). The ds.tests is questionable to keep but I have used that to verify that our updates to felix SCR versions are working correctly within the project.

The project ds.tests was never deleted. It was only modified to remove the reference to org.eclipse.equinox.util that is about to be removed with this PR. But I reverted the modifications to remove non-Java references to the removed plugin and will submit them in a separate PR so that this is a clean delete only PR.

I also reverted the remove of compendium.tests. The reason I collected all projects that are not build and not only the one you mentioned in https://github.com/eclipse-equinox/equinox/issues/18 is that I would like to enabled and fully leverage Tycho-pomless for this repo later. I created a separate PR to include compendium.tests.

This avoids the need to list each plugin to build in the root pom but instead just build everything in the bundles and features directory...

But while typing those lines I start to question if Tycho can also generate the aggregator pom's in the aggregator build? @akurtakov can we Tycho's automatic aggregator-pom generation for projects that are part of the aggregator build? It will work when I 'build-individual-bundles' but will it also work in an I-build?

HannesWell commented 2 years ago

For the record, I will state that the OSGi WG currently uses the Equinox wireadmin implementation as the compatible implementation. But the wireadmin specification has not seen an update in since its very first 1.0 version release. I argue the OSGi WG can continue to use the currently released versions of Equinox wireadmin for a compatible implementation.

I've literally not heard a single thing from when we stopped building the wireadmin implementation over two years ago. (https://bugs.eclipse.org/bugs/show_bug.cgi?id=533801). That makes me think nobody uses our implementation of wireadmin except the OSGi WG as the compatible implementation to release the wireadmin specification.

So could when then keep it as well? If yes I suggest to start building it again.

tjwatson commented 2 years ago

So could when then keep it as well? If yes I suggest to start building it again.

No, I am for removing that source code for the wireadmin impl. If the OSGi WG chooses to progress the wireadmin specification then there should be someone with interest to actually implement it also. At that time we can re-evaluate getting the source backup and running if the interest is to implement at Equinox.

The project ds.tests was never deleted.

Ah, sorry I didn't notice that. OK, I see that it has some benign code that tries to find the org.eclipse.equinox.util bundle in the test. I guess we can leave that there and remove the reference later.

HannesWell commented 2 years ago

Great! Thanks Tom for the review.