Changing the name from "Eclipse UI" to "eclipseui" to avoid space in path names

[elsazac]

Refs: #1460

Changing the path name from "Eclipse UI" to "eclipseui" and "Eclipse UI Editor Support" to "eclipseuieditorsupport" ,
to avoid space in path names and to make it UNIX friendly.

Files changed belongs to : org.eclipse.ui.workbench

[elsazac]

This is the first bundle created as suggested in #1460 (comment), and even though it's a draft PR, it's open for review. However, please don't land it until all the bundles are covered.

[akurtakov]

@elsazac For each such change you have to make sure that the full agregator build still works - e.g. this will break javadoc build and https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/b61229494d094a01678b663371379fce580df2d7/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/pom.xml#L594 have to be changed. Please prep a corresponding PR.
Also I believe it's best to handle bundle by bundle fully and land the changes in so build issues like the one pointed can be handled easier instead of landing multiple bundles at once and thus making it harder to fix things after that.

[github-actions]

Test Results

 1 821 files  ±0   1 821 suites  ±0   1h 52m 20s ⏱️ - 2m 6s
 7 725 tests ±0   7 496 ✅  - 1  228 💤 ±0  1 ❌ +1 
24 336 runs  ±0  23 588 ✅  - 1  747 💤 ±0  1 ❌ +1 

For more details on these failures, see this check.

Results for commit 796786a. ± Comparison against base commit 560db2a.

♻️ This comment has been updated with latest results.

[elsazac]

@elsazac For each such change you have to make sure that the full agregator build still works - e.g. this will break javadoc build and https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/b61229494d094a01678b663371379fce580df2d7/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/pom.xml#L594 have to be changed. Please prep a corresponding PR.

@akurtakov - thanks, I thought about that, and hence I kept this PR in draft. I will bring up the releng-aggregator PR before undrafting this PR.

[elsazac]

Also I believe it's best to handle bundle by bundle fully and land the changes in so build issues like the one pointed can be handled easier instead of landing multiple bundles at once and thus making it harder to fix things after that.

my original plan was to make multiple PRs for as many bundles for Eclipse UI subfolders, and un-draft all at once when everything is ready. But reading your comment and thinking about it further - I think a better approach would be to :

• prepare the releng-aggregator PR for this change (ie, add a new sourcepath ( ie, (eclipseui) ) for the new bundle )
• Also at the same time retain the original Eclipse UI version in the sourcepath
• retain the original classpathentry and source in bundles/org.eclipse.ui.workbench/.classpath and bundles/org.eclipse.ui.workbench/build.properties while adding a new one (ie, eclipseui) for the new bundle
• land this PR, and fix any potential issues thereon
• repeat this for all the bundles
• finally remove the original entries (ie Eclipse UI) from pom.xml, build.properties and .classpath, that points to the old folder which is now unused.

What do you think?

[akurtakov]

This sounds overly complicated to me. Smth like:

• grep in aggregator to find where "Eclipse UI" is used
• do all the changes locally
• verify it builds locally
• land all PRs at once

[HannesWell]

In order to very this change in an aggregator build in advance you could also create a temporary/draft PR against https://github.com/eclipse-platform/eclipse.platform.releng.aggregator, where you modify the .gitmodules file to include this PR's branch.
I.e. you have to change
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/b61229494d094a01678b663371379fce580df2d7/.gitmodules#L26-L28
to

[submodule "eclipse.platform.ui"]
  path = eclipse.platform.ui
  url = https://github.com/elsazac/eclipse.platform.ui.git
  branch = bundle2

[elsazac]

This sounds overly complicated to me. Smth like:

• grep in aggregator to find where "Eclipse UI" is used
• do all the changes locally
• verify it builds locally
• land all PRs at once

Sure, I will proceed accordingly.

[elsazac]

In order to very this change in an aggregator build in advance you could also create a temporary/draft PR against https://github.com/eclipse-platform/eclipse.platform.releng.aggregator, where you modify the .gitmodules file to include this PR's branch.

@HannesWell Thank you for the suggestion. I’ll incorporate this.

[laeubi]

https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/?tab=readme-ov-file#how-to-build-the-eclipse-sdk shows how one can build aggregator locally, it takes a while but might be more efficient than waiting for the Jenkins, you can for example simply remove the checked out submodule and replace it with a link to your forked repository.

[sravanlakkimsetti]

Possibly you may use https://ci.eclipse.org/platform/job/eclipse-aggregator-master/ modify this job according to your needs

[elsazac]

@akurtakov This is ready for review

This has been tested locally and the following changes are required.

Changes in a nutshell :

• 11 files moved to new folder eclipseui
• Made entry in .classpath and build.properties for the new path.
• Retain the old entries (for the sake of other files, will be removed after this exercise)
• Adjusted releng aggregator to accommodate this change.

[akurtakov]

So in #1460 (comment) you said that you will do one PR per bundle, what happened ?

[elsazac]

Made changes in org.eclipse.ui.workbench bundle. Will make a corresponding change in releng aggregator as well.

[elsazac]

@akurtakov This is ready now.

Could you review and let me know of any changes?

[akurtakov]

Looks good to me. Please merge (together with aggregator PR) and start I-build immediately after that when you can monitor the build for breakage.

[elsazac]

Merging this now and will initiate an I-Build to check for any potential failures.