Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 1 commit into from
Apr 22, 2022

Conversation

HannesWell
Copy link
Member

@HannesWell HannesWell commented Apr 19, 2022

As suggested in eclipse-equinox/equinox#18 this PR deletes the following plug-ins that are not build for a while:

  • org.eclipse.equinox.io
  • org.eclipse.equinox.ip
  • org.eclipse.equinox.util
  • org.eclipse.equinox.wireadmin

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

@HannesWell
Copy link
Member Author

HannesWell commented Apr 19, 2022

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
Copy link
Contributor

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 HannesWell force-pushed the deleteAbandonedPlugin branch 2 times, most recently from ee077d6 to 763d33d Compare April 20, 2022 16:54
@HannesWell
Copy link
Member Author

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
Copy link
Contributor

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
Copy link
Member Author

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

  • bundles/org.eclipse.equinox.compendium.tests
  • bundles/org.eclipse.equinox.http.jetty.starter

So the full list of removed projects is:

  • bundles/org.eclipse.equinox.io
  • bundles/org.eclipse.equinox.ip
  • bundles/org.eclipse.equinox.util
  • bundles/org.eclipse.equinox.wireadmin
  • bundles/org.eclipse.equinox.servletbridge.extensionbundle
  • bundles/org.eclipse.equinox.servletbridge.template
  • bundles/org.eclipse.equinox.compendium.tests
  • bundles/org.eclipse.equinox.http.jetty.starter
  • features/org.eclipse.equinox.server.servletbridge

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
Copy link
Member Author

@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
Copy link
Member Author

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

@tjwatson
Copy link
Contributor

tjwatson commented Apr 22, 2022

@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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Member

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

@tjwatson
Copy link
Contributor

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
Copy link
Member Author

@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 eclipse-equinox/equinox#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
Copy link
Member Author

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.

Delete the following projects that are abandoned (and not build) for a
while:

Part 1 (background https://bugs.eclipse.org/bugs/show_bug.cgi?id=533801)
- bundles/org.eclipse.equinox.io
- bundles/org.eclipse.equinox.ip
- bundles/org.eclipse.equinox.util
- bundles/org.eclipse.equinox.wireadmin

Part 2 (background https://bugs.eclipse.org/bugs/show_bug.cgi?id=348045)
- bundles/org.eclipse.equinox.servletbridge.extensionbundle
- features/org.eclipse.equinox.server.servletbridge
- bundles/org.eclipse.equinox.servletbridge.template

Part 3:
- bundles/org.eclipse.equinox.http.jetty.starter

Signed-off-by: Hannes Wellmann <[email protected]>
@tjwatson
Copy link
Contributor

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.

@tjwatson tjwatson self-requested a review April 22, 2022 18:01
@HannesWell
Copy link
Member Author

Great! Thanks Tom for the review.

@HannesWell HannesWell merged commit a369f79 into eclipse-equinox:master Apr 22, 2022
@HannesWell HannesWell deleted the deleteAbandonedPlugin branch April 22, 2022 18:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants