Extract service implementations into seperate sub-projects that are plain maven projects

[laeubi]

Currently Equinox is a big bunch of different things (osgi framework implementation, osgi service implementations, eclipse "core" things ...), and it is quite hard for new contributors to get into this world and start, especially if a subpart is to be modified. Also currently there is only all or nothing release cycle.

At last for some parts this is not really required, this is especially for the service implementations e.g.

• https://github.com/eclipse-equinox/equinox/tree/master/bundles/org.eclipse.equinox.cm
• https://github.com/eclipse-equinox/equinox/tree/master/bundles/org.eclipse.equinox.coordinator
• ...

These are actually not equinox/eclipse specific, they just implement a standard service using standard OSGi API and therefore can be developed and released completely independent.

My idea is therefore, to split those into an own repository, e.g.

• https://github.com/eclipse-equinox/equinox-configurationadmin
• https://github.com/eclipse-equinox/equinox-coordinator
• ...

These can the become plain maven projects, which are deployed whenever it seems reasonable, the current equinox/platform then can consume these as any other third party dependency, as it is already done for the felix-scr for example

[maho7791]

I agree with that.

In addition I would like to suggest to unravel the org.eclipse.core.runtime split package stuff in org.eclipse.equinox.common and org.eclipse.core.runtime. It would be great to have a clear separation of the eclipse core API in a way, that we can redistribute this API with the Equinox OSGi Implementation (org.eclipse.osgi-Jar). But also having a separate jar, that contains the all basic stuff that is needed for fullfilling the eclipse specific dependencies. We already have the supplement bundle, but if I am not wrong, this is just for using the equinox.registry with other frameworks than equinox. I would go a step further in that sense.

This would be related to the equinox repositories and eclipse platform.

As mentioned, we are willing to do some work, with some guidance.

[HannesWell]

In addition I would like to suggest to unravel the org.eclipse.core.runtime split package stuff in org.eclipse.equinox.common and org.eclipse.core.runtime. It would be great to have a clear separation of the eclipse core API in a way, that we can redistribute this API with the Equinox OSGi Implementation (org.eclipse.osgi-Jar). But also having a separate jar, that contains the all basic stuff that is needed for fullfilling the eclipse specific dependencies.

IIRC @tjwatson mentioned that the split of o.e.core.runtime and o.e.equinox.common never fulfilled it's promise and that he contemplated to merge them again?

[tjwatson]

Right, I'm not sure what the goal is to "unravel" the org.eclipse.core.runtime split package stuff. I have always had (perhaps the misconception) that nobody used org.eclipse.equinox.common, org.eclipse.equinox.registry without the org.eclipse.core.runtime bundle. But if I am correct, then it would perhaps be more simple if everything got merged back into the org.eclipse.core.runtime and moved back to platform.

From other discussions about making org.eclipse.equinox.common work on other framework implementations I am guessing it must be used by someone without the org.eclipse.core.runtime bundle. I say that because I never thought the org.eclipse.core.runtime could ever work on other frameworks.

[HannesWell]

Separating concerns better is definitely good, but I'm not convinced we should do that by introducing new git-repos.
But I want to mention that currently much work is done to merge git-repos to have less of them, so it seems a bit odd to me, to create new ones now.
So if necessary I think it is better to improve the separation on project/Plugin level. Since it there is not much development work happening in that area (AFAICT) I therefore don't see a great need to have independent and faster release cycle.

[laeubi]

The merging is because the codes are closely related (and can't released independently) while here it is the other way round, just take a look how it is done at felix for example if there is a bug in the felix-scr or bundle plugin it can be fixed, build and released independent from other sub-projects

Also it is very unlikely that we will changing build structure / tools /releases for the whole equinox while for such sub-projects it can easily be evaluated without influence others.

And that these do not change (much) yet is actually good because it does not require heavy development yet, but might also be a sign of people not able to easily contribute, or they are simply feature-complete in wich case its a bit of waste to build/release them every day :-)