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 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.
-
|
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.
-
|
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.
-
|
@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.
-
|
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.
-
|
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.
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