Partitioning the equinox build?

[laeubi]

As previous discussion revealed the initial idea to try moving code around to form some kind of independent "equinox" might not be suitable as to many (maybe competing) goals do not converge to form a good understanding of the result.

Therefore I'd like to came up with a new, probably less disturbing approach that would allow to do more smaller focused changes without loosing the "big picture". Instead of moving code across repositories, we can partitioning the build inside the equinox repository.

How would it work:

• Currently the root pom.xml lists all modules and test of projects in this repository
• Now we can decide what are usable sub-parts, for example I can think about the following:
  • equinox-framework: contains everything that is "The OSGi Framework" and its core services
  • equinox-platform: contains the extension registry and stuff like that
  • maybe more like equinox-security, equninox-ui, ... whatever seems worth to keep together or keep apart
• Now each of the sub-part will get an own pom-file that lists the modules of that part
• The root pom will be changed to only reference the "sub-part-poms"

What is the advantage of this:

1. We do not need to move any code, just reorganize some poms
2. No need to adjust any setups (IDE, aggregator builds, IDE, features, whatever...)
3. After initial setup, its still easy to move one thing from one to the other part, so less risk of "what if ..."
4. This will allow to apply certain things to only a subset of the equinox bundles, e.g. it would be possible to just deploy equinox-framework and let it use org.eclipse.equinox as a group id while retain the rest "as is"
5. One could start to build each part independently (e.g. we can use one step in the Jenkinsfile for each sub-part-pom"
6. If after a while we are happy and want to push this further, e.g. choose different subfolder, move parts away or separate/decouple builds even more e.g equinox-platform part can start only using released equinox-framework and therefore there would be no need to build them in the same reactor and using two distinct build jobs that only trigger for changes in that area.

What do you think?

[akurtakov]

I like that approach a lot!

[rotty3000]

As a lurker and occasional contributor who built his own scripts that did pretty much this, I think it's a great idea. +1

…

On Sat., Oct. 8, 2022, 13:14 Александър Куртаков, ***@***.***> wrote: I like that approach a lot! — Reply to this email directly, view it on GitHub <#136 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABD2TEA73C5MPD76G5JOALWCGTWFANCNFSM6AAAAAARAKAHJ4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[HannesWell]

Sounds good.