Change repository layout to structured layout?

[laeubi]

Currently the repo layout is quite complex as we have:

• apitools
• build
• ui
• ua
• ...

Each containing some mixture of bundles / features (and there is even a features directory in the root).

I therefore like to suggest that we change to the structured build layout this will also save some pom files currently used to connect the different parts and make it easier to find out where stuff is located and whats the purpose.

[HannesWell]

I would be in favour of that restructoring.
It is probably for historic reasons and due to repo merges.
Does anybody has a reason not to do it?

[iloveeclipse]

If it means, git blame will show everything "added" in one commit, clear "no".

Assuming the change will be done without breaking git blame, I'm +- 0 on this, because I don't see why moving everything into one directory would "make it easier to find out where stuff is located and whats the purpose" - the opposite would be the case, as today the code is clearly separated into different PDE domains, after the proposed move there will be only maven related separation, which isn't really helpful to understand code relationship.

[merks]

Of course I too assume that no history would lost. I too would be in favor of such restructuring.

[laeubi]

Usually moving files is handled well by git, so if it works when we merge repos and move stuff around I don't see a reason why it should not work when moving code in the same repo.

This is also not particular about a maven layout, but if I install the Eclipse SDK it is structured like this:

but in the filesystem it is like this:

So while build might be a different domain, at laest ui / ua / ds / apitools seem close enough related to not really separate them and better split this into bundles / test as we already has a root folder features

Also note that for example the platform repo, even it uses "domain folders" has inside the domains the structured layout:

• https://github.com/eclipse-platform/eclipse.platform/tree/master/resources
• https://github.com/eclipse-platform/eclipse.platform/tree/master/runtime
• https://github.com/eclipse-platform/eclipse.platform/tree/master/team

so for sure this is not very important, but having a common layout across platform / pde / ... can help to understand and automate things.

[HannesWell]

Assuming the change will be done without breaking git blame, [...]

Git can detect moves of files, it can even detect moves/renames if you change some content of the moved file if the old and new file are above a certain similarity index. If one renames and changes the file (E/J)Git sometimes is confused about the source and target a file if there are too similar files. But pure moves without changes in the files are usually not a problem.
Nevertheless we can check the result before merging.

[...] the opposite would be the case, as today the code is clearly separated into different PDE domains, after the proposed move there will be only maven related separation, which isn't really helpful to understand code relationship.

It is not really maven related but more project-type related. And as Christoph pointed out, currently we have a mixture of both. Furthermore you can still see which projects are related from their name prefix. Besides that the current domain separation is also not completely correct since the ui folder also contains for example the non-ui pde.core Plugin. This can also lead to confusion.
So since the PDE domains are IMHO not absolutly clear, it seem better to separate for project type, which is clear and also a common repository layout among many Eclipse repos.

[merks]

I totally agree.

Also, the Oomph setup can (and does) create working sets however we like them:

so we don't need that structure reflected in the folder structure...

[vogella]

I would be in favour of that restructoring.

Me too