Replies: 6 comments 8 replies
-
|
I don't think we want merge them nkw, considering that there are efforts to make compiler work more independent from the rest of the IDE code. |
Beta Was this translation helpful? Give feedback.
-
|
But just because the code resides in the same git repository do not mean it is more coupled/dependent ... |
Beta Was this translation helpful? Give feedback.
-
|
Let's not fix something that ain't broken. Yes, jdt.debug does use jdt.core, but via well defined APIs. In the example you cited, you added an API in core and used that in one of the clients. Are you saying, this is good enough reason to merge them both? |
Beta Was this translation helpful? Give feedback.
-
|
Depends on how you define "broken", in terms of releng such thing is broken, also in terms of usability this is broken and also in terms of build verification this is broken. Because as a matter of fact eclipse.jdt.debug is not just "one client" it is more a satellite project that is fully managed by the life-cycle of jdt.core. |
Beta Was this translation helpful? Give feedback.
-
OK, let's see what you really meant by that. |
Beta Was this translation helpful? Give feedback.
-
|
e.g. m2e is a true client of PDE, any change in the PDE API do not change the m2e build (unless we upgrade to the next release and can then adjust the code). That means m2e is always one release behind. But for jdt.debug If I push the debug changes the verification build will obviously fail, if I push the core changes, the build will NOT fail (as it does not build debug in the same verification build), but probably once it is merged the ibuild will fail (unless I just merge the other changes just without verification) So there is no way to have a consistent change across repositories, because debug uses the current release, while a true client would use the previous release... so I always need two (non atomic) changes. Thats more from a dev perspective. So this is not a complain its more an observation ... also each releng change (e.g. upgrade to next release, adjustment of java versions, ...) need to performed multiple times, because debug is not really an independent project with independent project management or release cycles. So merging such close related thing into the same source repository can improve the overall project management (e.g. consistent atomic branches and/or tags). e.g. platform is currently also merging some of its sub-repositories, because there is actually no (or just too less) benefit from having them separated for historic reasons. SO @akurtakov can probably better explain the major pain points from platform-releng perspective. Over all I think jdt can benefit from such simplifications as well (less repositories, less releng work, less duplication e.g. what issue should go where and so on), therefore I opened this discussion :-) |
Beta Was this translation helpful? Give feedback.
-
|
Releng simplifications are not felt by many people so the pain in this area will only be well understood only after more people start to feel it is my latest POV. |
Beta Was this translation helpful? Give feedback.
-
|
@iloveeclipse @jarthana @akurtakov I just noticed this today that we successfully have reduced the number of repos already for platform with much success and little to no hassle, so could this maybe considered for JDT as well? Especially if the goal is to move things from UI > CORE in the jdt-ls case this would allow these moves without loosing all history and with one verification build and one dedicated commit. |
Beta Was this translation helpful? Give feedback.
-
|
AFAIK JDT committers want to keep jdt.core to be compiler only repo (not even jdt.core.manipulation is in jdt.core repo but in jdt.ui one) much like SWT is kept separate one as it requires some extra care. |
Beta Was this translation helpful? Give feedback.
-
|
Should then not https://github.com/eclipse-jdt/eclipse.jdt.core/tree/master/org.eclipse.jdt.core.compiler.batch be a separate repository instead but maybe I miss what all includes "compiler" and to biased from Tycho? |
Beta Was this translation helpful? Give feedback.
-
That will be trouble. Rest of the jdt (i.e. org.eclipse.jdt.core) uses internal stuff from the comiler.batch. Ideally, no other bundle, other than org.eclipse.jdt.core should have access to the internals of the compiler. |
Beta Was this translation helpful? Give feedback.
-
|
But this does not mean it could not be "the" separate repository and everything else (i.e. org.eclipse.jdt.core / debug / ui) could be in one repository (with probably subfolders to make clear some boundaries e.g. UI / MODEL / ...), if the reason really is "the compiler should be independent" (what it currently is not) as stated by @akurtakov in fact it would be great if (batch) compiler could be released independently from JDT(core) / SimRel and then is just consumed by JDT(core) like SWT is consumed by platform-ui (for example). But in general all of this (release independent, stay independent) is not a property of a github repository I can host different code / assets in one repository and still release / develop / build these parts independently. |
Beta Was this translation helpful? Give feedback.
-
|
I think eclipse.jdt.debug, which is used for integration in the IDE and not at all for the compiler, would make more sense being merged in eclipse.jdt.ui than in eclipse.jdt.core. |
Beta Was this translation helpful? Give feedback.
-
|
Imho the modularization approach currently used to split jdt into its modules has lots of issues. Just look how complex the configuration is if you want to create jdt ui plugins with the same or better support for junit, codecoverage and so on while still maintaining a kind of compatibility so that you can copy your code with minimal steps into jdt ui as contribution. |
Beta Was this translation helpful? Give feedback.
-
I would like to propose to merge
I think they are close related enough and it would allow to make changes that are crossing boundaries more easier and consistent, for example #614 and eclipse-jdt/eclipse.jdt.debug#169 are elated but has to be handled differently.
Beta Was this translation helpful? Give feedback.
All reactions