Merge repo into eclipse.platform.ui #31
Comments
|
Every single simplification matters and there are way too many obstacles for many to land so if you can do this one - go for it. |
|
Sounds reasonable. |
|
Maybe better target directly eclipse.platform repo? This seems our all-in-one final target anyway. IMHO the best (releng) option is to end up with one repo. |
|
IMHO put it in UI so the two merges can go simultaneosly now :) . We are far from targetting one repo yet so let's aim for best shortterm gain. |
|
Last time it was said that we should aim for
as a first step because of build times and separation. |
I stand behind this 100 % for now. |
|
So the merged repo goes into a "tools" subdirectory in platform.ui as we do for merges in platform? |
|
Sounds good to me. |
|
I'm not sure all these things are tools? The source repo was "ua" for user assistance. It seems to me all these things are mostly framework components, not tools... |
|
Someone named them tools (even bundle names are o.e.e4.tools.*) so even if being general components tools is still good place in the sense of folder with o.e.e4.tools.* components. |
|
I don't have a really strong opinion but at some point "ua" seemed like good name (to some human beings) for some group of things, and perhaps folks looking for things in that group might not be helped by looking in tools. We are talking about these, right?
No sign of tools here. Just saying. 😉 |
|
@merks you commenting on the wrong issue, this is the merge from ui.tools not eclipse-platform/eclipse.platform#324 which you are referring too. |
|
Sorry !!! Now it all makes perfect sense. Sorry sorry. |
|
Happens to me quite often thanks to multitasking :) |
|
Lets see what CI error we get this time eclipse-platform/eclipse.platform.ui#602 |
|
Done |
|
FYI, AFAICS history for the merged files is still available.
|
|
For existing files from platform.ui
|
|
Why were maven natures and filters added to the .project files?
Also, why do we need .polyglot.META-INF? |
|
@merks where do you see .polyglot.META-INF? find . -name ".polyglot.META-INF" does not find anything on my machine. |
|
Probably/maybe m2e is generating them? |
|
These are runtime artifacts of tycho when using pomless builds and they are deleted at end of build. As visible from the screenshots they are ignored by git. |
|
I've never done a Tycho build so I don't know where they came from. An even bigger problem is that all the .project files are missing for the tools projects:
|
|
@merks Thanks for noticing. Fixed via eclipse-platform/eclipse.platform.ui#605 |
|
When the maven nature is enabled, the files are created as part of the project import, so I think the issue is more that the .project files are missing, then they are handled as maven projects and then you get the maven nature and the temp files (of course you can ignore them). I once suggested that git ignored files can be automatically filtered from the view, but I think this was never considered further. |
|
Now I see problems with "dirty" state after these import successfully.
|
|
|
So if one does just |
I also do not see a GH code verification action for PR in the aggregator repo https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/tree/master/.github/workflows |
|
I'll try to take a look at the build issue as soon as I'm finished with some tasks, but probably one want to enable that option for that repo? |
|
JDT templates removed from the build and re-triggered I-build https://ci.eclipse.org/releng/job/Builds/job/I-build-4.27/140/ |
@vogella: If that "JDT templates" thing is supposed to be useful for e4, please create an issue to enable them again. |
|
Now we face xpath issue again: |
|
I think that project got deleted maybe? I'm having trouble finding it and dependencies on it in my workspace resolve to the binary plugins in the target platform not to a workspace project.
|
That happened at very beginning with 708cf228e289b3dd96416ccc6b153c9606cec620 |
|
No jxpath no CVEs :). |
I restorted it with eclipse-platform/eclipse.platform.ui#610, this was unintentially deleted and as the features live in another repo then the plug-ins I did not notice. |
|
Now seriously, this shows how big of an issue our many repositories with many cyclic references repositories is if such an issue happens and the subrepo build tells us all is fine. |
I think you should revert the jdt.templates change too. |
Lets do this after the other issue is solved. |
|
Odd that the test dependency on it didn't fail the build...
|
|
It was satisfied just fine from I-builds repo where the bundle exists so no reason for the test bundle to not resolve. |
|
@akurtakov Ah, now it all make sense! Thanks. |
|
eclipse-platform/eclipse.platform.ui#610 merged, next try. Unfortunately I be away from the laptop soon, so if any work is still requred I can look at it tomorrow. |
|
Would be more effective if the source bundle creation could be after the real compilation.
|
|
After the build repos are not clean so either it would have to be cleaned or even worse repos would have to be cloned again. This raise the question who needs the source tarball anymore? It was added by Red Hat and used for the Fedora/RHEL rpm builds which we no longer use so maybe no one uses them at all. |
|
@akurtakov I created eclipse-platform/eclipse.platform.releng.aggregator#882 to retire the source tarball generation. |
|
Build successful and AFAICS no new test errors ( https://download.eclipse.org/eclipse/downloads/drops4/I20230219-1800/testResults.php) , so lets close this. Please open new issues in in eclipse.platform.ui if you find another issue. Thanks for the help to the involved people. |
|
Would you please revert the jdt.templates removal from feature? |
|
I suggest to merge this one into eclipse.platform.ui. Any objections? cc @laeubi and @akurtakov
The text was updated successfully, but these errors were encountered: