Move as subproject of JDT (instead of subproject of JDT.LS) ? #1881
Replies: 7 comments 15 replies
-
|
I'm fine with that, if the move is supported by the Eclipse JDT Core community |
Beta Was this translation helpful? Give feedback.
-
|
I've asked at https://www.eclipse.org/lists/jdt-dev/msg02724.html |
Beta Was this translation helpful? Give feedback.
-
|
I think feedback from the JDT team itself is required in order to push this forward. Part of that decision is likely to be a demonstration that we have users, contributors, or interest outside of jdt-ls. If (for example) all of our consumers and interest are only using us via jdt-ls, then it would likely not be a compelling argument to ask jdt to "adopt" us. However, if we start having consumers that are substantially independent of jdt-ls, then it would be a good idea. So, do we have consumers that are expressing interest outside of the jdt-ls context? |
Beta Was this translation helpful? Give feedback.
-
Yes, but I suspect similar arguments as for JDT-LS can work there, so I'm not so worried on that part.
Good question and I think the answer is no at the moment; but the goal is not to satisfy the current (few) customers but more to try building a wider community of customers. |
Beta Was this translation helpful? Give feedback.
-
|
I think it would be a good idea as well to move the jdt-javac work to a new repo under the jdt core organization, if the JDT core team is okay with that. If not, it might be interesting to give this project it's own organization. eclipse.jdt.ls is still tightly coupled to this repo. eclipse.jdt.ls uses the JDT Core components generated by the build job in jdt core incubator: https://github.com/eclipse-jdtls/eclipse.jdt.ls/blob/main/org.eclipse.jdt.ls.target/org.eclipse.jdt.ls.tp.target#L36. This effectively means that jdt core incubator is being used to control which version of jdt.core is being used, since new features for jdt.core won't be added until the jdt-javac work is rebased on the latest upstream jdt.core commits. What should be done about that? Also, if we're moving to a new repo, should we remove the JDT core code and leave just the javac fragment and the javac test fragment? I think we can do this fairly safely since we aren't making as many changes directly in the existing JDT core code. The changes that we do need to make have been upstreamed into JDT core fairly fast. Being a fork of JDT core means we need to manually rebase regularly in order to keep up. Sometimes we forget for a while. Is the goal to be a friendly fork of jdt core forever, or to eventually have just the fragment code in the repo? |
Beta Was this translation helpful? Give feedback.
-
|
Note that the proposal is to create a new project for jdt.javac, as a child of jdt, as a sibling of eclipse.jdt.core or eclipse.jdt.ls (would probably be eclipse.jdt.javac), I don't think we want the repo to move to eclipse.jdt.core (yet) as both components have different constraints and lifecycles.
Probably get rid of it: consume jdt.core from upstream, and jdt.javac from the javac repo. But I don't think it's so related to the current discussion about creating a standalone project.
Ideally yes, but we still have some cases where we want to test ahead of time a change in org.eclipse.jdt.core and we do have modified (improved) many tests in ways that we haven't tried to contribute back.
Sometimes yet, sometimes not. For example one of my current changes that is very important for Javac seems stuck until next M1, for 1 month...
Fortunately, it's often useless as we don't rebuild JDT.core bits but just consume them. The forked bits are more there as "development assistance", not things we intend to ship.
Ideally, just a fragment; realistically, we'll at least probably forever need to keep the forked tests... |
Beta Was this translation helpful? Give feedback.
-
Well, jdt.ls is shipping them from my understanding. |
Beta Was this translation helpful? Give feedback.
-
That's the choice of jdt.ls at the moment, not a requirement (usually, the fragment is compatible with a wide range of org.eclipse.jdt.core). |
Beta Was this translation helpful? Give feedback.
-
|
https://github.com/eclipse-jdtls/eclipse.jdt.ls/blob/c183fdab28fe18c2acc576f55aabbebf1cc46e08/org.eclipse.jdt.ls.target/org.eclipse.jdt.ls.tp.target#L31-L37 . Does this imply the forked bits are identical to upstream JDT Core ? We can pretty easily just take from upstream. As long as jdt.core.javac supports latest I-build it should be fine. The old approach just guaranteed there wouldn't be any incompatibilities (at the cost of slower updates). |
Beta Was this translation helpful? Give feedback.
-
|
I think moving it to jdt (core) is the right thing. Having (just another) subproject is something I would question here, JDT is already a mess to build as all the "subprojects" are actually heavily dependent and can not be use standalone anyways, so my personal preference would be more to merge subproject repositories than to making more... |
Beta Was this translation helpful? Give feedback.
-
|
The proposal (AFAIU) is to change the project not to create new or remove existing git repository. So purely marketing and not technical change. |
Beta Was this translation helpful? Give feedback.
-
|
@mickaelistria There is no project (in the EF meaning of it) for javac - see https://projects.eclipse.org/projects/eclipse.jdt.ls, it's just one repository of jdt.ls. There are few possible paths forward:
|
Beta Was this translation helpful? Give feedback.
-
|
The proposal I'm suggesting is the 1st bullet |
Beta Was this translation helpful? Give feedback.
-
|
In that case, You need approval from Project PLs of the project you aim to be subproject of. https://www.eclipse.org/projects/handbook/#starting contains quite detailed information and steps to follow. |
Beta Was this translation helpful? Give feedback.
-
|
For those who are not on jdt mailing list, I've answered: https://www.eclipse.org/lists/jdt-dev/msg02725.html Answering to the latest question from Mickael, I personally see "forking" as worst thing in the current proposal and I would be against any "new & independent" JDT project that would be a fork of JDT, independently how the project would be created at Eclipse.org. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks Andrey. I'll look at reorganizing the project so that it doesn't look like a fork (removing some bundles, renaming others, clearly not re-ship upstream bits) to make the independance more visible. |
Beta Was this translation helpful? Give feedback.
-
|
#1889 |
Beta Was this translation helpful? Give feedback.
-
|
See https://github.com/eclipse-jdtls/eclipse.jdt.javac is no more a fork (but a "companion" fork is still used for tests, but it's a separate repository that doesn't produce any artifact). |
Beta Was this translation helpful? Give feedback.
-
|
This may a bit of an orthogonal point but if the goal is to get more people outside of JDT-LS on board, I would suggest adapting the README (or similar) to include information on how to use javac-based JDT in a normal Eclipse installation/where to get bundles from if possible (if an update site exists). Maybe there are some people interested in using it and maybe reporting bugs or even contributing code but it's easier to get started when you have an easy way to test it. |
Beta Was this translation helpful? Give feedback.
-
|
That's indeed good proposal. |
Beta Was this translation helpful? Give feedback.
-
|
And now that a dedicated repo exists, here is a dedicated README: https://github.com/eclipse-jdtls/eclipse.jdt.javac/blob/main/README.md ! |
Beta Was this translation helpful? Give feedback.
-
You may of course try to attract more people to your project, but please don't do this with negative statements about ECJ which are not true presently, notably this:
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
At the moment, JDT-Javac is a subprojects of JDT-LS. However, this component is viable for other cases that are not related to JDT.LS.
Having it in JDT-LS had for initial advantage that
Having it in JDT-LS had the initial disadvantages
So having it part of JDT-Core, as a sibling project of JDT-LS but with its own project management would resolve the 3 disadvantages, and would not challenge the initial advantage.
JDT-Javac is currently mature enough to "level up" as a standalone project.
@robstryker @datho7561 What do you think? Do you support this idea?
@eclipse-jdtls/eclipse-jdt-ls-project-leads Would you support the request for such migration?
Beta Was this translation helpful? Give feedback.
All reactions