Merge Mylyn repositories

[ruspl-afed]

Currently we have a number of git repositories for Mylyn components

• commons
• tasks
• contexts
• versions
• builds
• reviews

Do we really need to have them all separated?

• In fact, they are not independent and have circular dependencies
• More repositories require much more releng effort
• Code changes require extra work to be aligned accross several repositories

How about merging them all to one? Of cause, after resolving #1

[BeckerFrank]

Maybe org.eclipse.mylyn.commons is an exception.
org.eclipse.mylyn.docs use direct or indirect

• org.eclipse.mylyn.commons.context
• org.eclipse.mylyn.commons.core
• org.eclipse.mylyn.commons.screenshots
• org.eclipse.mylyn.commons.ui
• org.eclipse.mylyn.commons.workbench
• org.eclipse.mylyn.monitor.core
• org.eclipse.mylyn.monitor.ui

so it can make sense to have these in an separate repository.

[BeckerFrank]

Frank, this use case is handled by having a dedicated feature published to Mylyn p2 repository, it does not require to have dedicated GitHub repository.

sure, but having a separate repository can make it easier for maintaining from both sides.
We can start with a dedicated feature and if it is needed we can create a new repository later.

[wimjongman]

Maybe @akurtakov can chime in?

[akurtakov]

From releng POV having these multiple repositories is a total nightmare. Esp. considering the circular dependencies and how not test suite can reliably test these. Thus Eclipse Platform is merging 1-2 repos together for each release - this had no negative effect so far even the verification builds are not slower.
Regarding Mylyn Docs - nothing from mylyn commons is used anymore in the last releases, the code is there but it's not compiled and not part of the release.

[akurtakov]

IIRC this was the only way to continue releasing when Mylyn was removed from Simrel and no one complained since then about the lack of task-focused editing for wiki files so right now there are no plans to bring this functionality back even when Mylyn is back in simrel.

[wimjongman]

Regarding Mylyn Docs - nothing from mylyn commons is used anymore

Cheers! So no block to merge commons in as well.

lack of task-focused editing for wiki files so right now there are no plans to bring this functionality back even when Mylyn is back in simrel

Sounds totally valid. We will see if there is community interest in that once Mylyn is back on track.

[wimjongman]

What will the repo structure be?

commons
tasks
etc..??

or one flat repo?

[ruspl-afed]

Pesonally I would prefer one flat, but do not see problems having subfolders

[wimjongman]

The problem with subfolders is that you cannot go tycho pomless (AFAIK)
The advantage of subfolders is that we have some organization

[ruspl-afed]

is that you cannot go tycho pomless

I think we can, but with a bit more extra manifests. However,

I thought you will offer a "simplicity" of merging as a reason to have subfolders.

[wimjongman]

Yes, there is that too. And the irresistible human urge to categorize. ;)

[BeckerFrank]

Yes, there is that too. And the irresistible human urge to categorize. ;)

Somtimes categorize can help but we can do this with the Oomph *.setup and Working Sets. At some point we maybe want to know what Eclipse Project was in a specific Repository.

[wimjongman]

Guys, I have merged the repositories into the org.eclipse.mylyn repo retaining all history. I have created a new branch main, which I suggest we use going forward.

Please take a look at https://github.com/eclipse-mylyn/org.eclipse.mylyn/tree/main

I have created a bash script (attached) that I assembled from this SO answer. This means that I can replay it if something is missing/wrong.

Let me know if you miss something

mylyn.sh.txt

[ruspl-afed]

Use it in the build and see if it works.

Do you want me to fix the build right in the main branch of https://github.com/eclipse-mylyn/org.eclipse.mylyn/, Wim?
I'm asking again, just to avoid misunderstandings.

[BeckerFrank]

The Mylyn.setup and the CONTRIBUTING.md are now changed the the use main instead of master.

I think the next steps are.

• Request to change the Default Branch from master to main for repository org.eclipse.mylyn
• If we want to have a review for every change we also should request that the main Branch of org.eclipse.mylyn is protected
• Request archive for the following repositories.
  • org.eclipse.mylyn.commons
  • org.eclipse.mylyn.builds
  • org.eclipse.mylyn.context
  • org.eclipse.mylyn.tasks
  • org.eclipse.mylyn.reviews
  • org.eclipse.mylyn.versions
  • org.eclipse.mylyn.all
  • org.eclipse.mylyn.incubator
  • org.eclipse.mylyn.reviews.ui
  • org.eclipse.mylyn.context.mft

Thougths?

[ruspl-afed]

+1
Let's also archive

• org.eclipse.mylyn.all

[BeckerFrank]

+1 Let's also archive

• org.eclipse.mylyn.all

I add some more!

[BeckerFrank]

I create https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/2445 for the change from master to main
and
https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/2446 for Retirement of the repositories.