| Summary: | [xbase] Remove dependency to JDT from xbase core bundle | ||
|---|---|---|---|
| Product: | [Modeling] TMF | Reporter: | Sebastian Zarnekow <sebastian.zarnekow> |
| Component: | Xtext | Assignee: | Dennis Huebner <dennis.huebner> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | dennis.huebner, info, jan, sven.efftinge |
| Version: | 2.1.0 | Flags: | sebastian.zarnekow:
juno+
|
| Target Milestone: | M4 | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | v2.4.3 | ||
|
Description
Sebastian Zarnekow
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. Requested via bug 522520. -M. |