Community
Participate
Working Groups
I am trying to use NLSPropertyFileModifier as part of a headless tool and the fact that this is needlessly in JDT UI forces the full inclusion of planet earth. Most of the JDT UI internals should be extracted to be usable without any UI dependencies. Trying to even create a stand-alone plugin to work around this issue exhibits dependencies where that stand-along plugin might have to include large part of the refactoring packages since they seem to have been extracted but within the rest of the JDT UI plugin have a hard dependency on self-hosting.
Is this somehow connected to the jdt.ls project? If not, you may want to join forces with them, see https://projects.eclipse.org/projects/eclipse.jdt.ls There approach is to address a few classes at a time, which appears to be a feasible approach, whereas "Most of the JDT UI internals should ..." sounds (to me) like an effort too large for anybody to be able to deliver.
No it is not related, although I did see a comment about similar stuff during my search. I now have a bundle that compiles and should work to do what I want w/o any UI dependencies and will provide a link to it once tested.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
(In reply to Alain Picard from comment #2) > No it is not related, although I did see a comment about similar stuff > during my search. > > I now have a bundle that compiles and should work to do what I want w/o any > UI dependencies and will provide a link to it once tested. Hi Alain, do you have any updates for this bug (specific classes)? Otherwise, I think it would be best to close this bug and open new bugs for specific classes or groups of classes that can have gerrit patches. Stephan is correct that opening such a bug isn't feasible for anyone to fix.
