Merge the eclipse.platform.common into this repository

[laeubi]

Despite its name eclipse.platform.common does not really contains any common code or something that could be shared, it actually aggregates the documentation of many projects.

Even worse, there is no verification builds, so changes can only be merged on best effort basis (e.g. eclipse-platform/eclipse.platform.common#138)

Because of this, I think it would be good to merge this repo into this one to:

1. make clear this is something larger as its pieces and we are aggregating things
2. We can make changes there and get the verification build for that

as the repository is already part of this by using git-submodules, neither buildtime not build scripts will change and we can get rid of another repository.

WDYT @akurtakov @vogella @iloveeclipse ... and probably others!

[gireeshpunathil]

Even worse, there is no verification builds, so changes can only be merged on best effort basis

+1 to that. Even the other open PR eclipse-platform/eclipse.platform.common#131 in the repo is an example of lack of verification at the original PR time, leading to needing to do it on a post-release manner, after being reported by end users.

[BeckerWdf]

eclipse-platform/eclipse.platform.common#131

Agree. I always was asking myself why the documentation e.g. for platform is not in the platform repo...

[iloveeclipse]

+1, makes sense.

[HannesWell]

Sounds good.
What about moving the documentation into the repos of the projects that are documented?
If a non-trivial build set up is required, that could live in a special parent pom located in this platform.releng aggregator repo and could be referred to as parent.

[merks]

It's certainly more logical for PDE and JDT to host their own documentation...

[laeubi]

If any of you think items can be moved elsewhere, please go on ;-)

But if you look at the buildscripts several things currently prevent this as they contain a lot of cross-references and as explained they actually aggregate different stuff.

Nerveless merging the repositories does not prevent this if we see that some itmes might me moved , e.g. org.eclipse.jdt.tips.user and org.eclipse.platform.doc.tips seems like a standalone bundle.

[merks]

Yes, the structure is somehow quite illogical. E.g., p2 defines org.eclipse.equinox.internal.p2.ui.IProvHelpContextIds.TRUST_DIALOG and if I have just p2 in my workspace, I search and cannot find where that is defined. Only in my full SDK workspace can I find it:

So if I want to write documentation and test it, I need another Git repo. Note that Equinox is lumped in Platform, so moving this part to p2's repo is not a trivial exercise that we'd all like done, though preferably done by someone else who has nothing better to do. 😈

So I agree @laeubi that moving this into the aggregator does not prevent any subsequent refactoring in the future nor does it make such refactoring more difficult in the future.

[laeubi]

CC @vogella maybe something for your merge-one-repository-a-release agenda ...

[laeubi]

@vogella do you like to initiate this merge?

[akurtakov]

This has been done.