Community
Participate
Working Groups
The OnTheFlyCompiler in the xbase core that depends on jdt types but there is no client in that bundle for the compiler itself. We should consider to move the OnTheFlyCompiler to xbase.ui. Otherwise we may introduce other deps to jdt by accident (see bug 364077)
It's a runtime thingy so UI doesn't fit well.
Yeah I know. xbase.ui is a bad name but it's the bundle were we create functionality that _depends_ on e.g. eclipse workspaces and the like. The compiler does not work without eclipse.resources
The standalone compiler should be usable without the need for xbase.ui (or mylangauge.ui). Today we added org.eclipse.xtext.xtend2.standalone which is the runtime compilation story for Xtend. But in fact we should support something like this for every base language. So maybe we should add a similar project for Xbase? The OnTheFlyCompiler could go into ~.xbase.tests for now.
that should have been "for every Xbase language"
(In reply to comment #3) > The OnTheFlyCompiler could go into ~.xbase.tests for now. +1 even though others already seem to use it. For 2.3 we should really try to find a more reasonable split for runtime/equinox/ui (ui as in needs a display)
I moved it to base.junit and removed the JDT sep from org.eclipse.xtext.xbase
(In reply to comment #5) > (In reply to comment #3) > > The OnTheFlyCompiler could go into ~.xbase.tests for now. > > +1 even though others already seem to use it. > > For 2.3 we should really try to find a more reasonable split for > runtime/equinox/ui (ui as in needs a display) +2 for splitting in runtime/headless(equinox)/ui
*** Bug 412368 has been marked as a duplicate of this bug. ***
See bug 364082
(In reply to comment #9) > See bug 364082 I see :) You mean bug 412368 ?
Yep.
If we only use string constants, they will be inlined by the compiler anyway and the dependency can be marked as optional.
Keeping the optional dependency bears the risk that we silently use more JDT functionality in the long run. If we skipped the dependency we could write a test making sure it is not reintroduced.
I confirm that only constants are used so we can make this dependency optional.
I've copied 7 constants from JavaCore class. So the jdt.core dependency is completely removed now.
Requested via bug 522520. -M.