Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release

We are still using OSGi-AdapterHooks but so do others on the release
train as well but we are not modify any classpath nor do we modify the
classloader strategy of Equinox so I can't see how we can affect others
inside the IDE.

As far as I can tell there's no other option than Adapter-Hooks to get
JavaFX embedded in the Eclipse IDE because the swt-javafx bridge is not
on ANY classpath.

For JavaFX8 in OSGi without adapter-hooks you'd have to modify the
Equinox-Classloader hierarchy to include the extension-classpath which
most likely breaks many other things and would still not fix your
swt-javafx embedding.

Other IDEs built on top of Eclipse (e.g. STS) have already adopted our
AdapterHook and so do others like GEF4 and hopefully many others as well.

To sum up, I can't see how having e(fx)clipse on the release train (and
maybe in a download package) can affect others using JavaFX beside
takeing the burden to understand how much such an integration has to
work in every detail.


On 21.08.14 09:23, Max Rydahl Andersen wrote:
> On 20 Aug 2014, at 10:46, Tom Schindl wrote:
>> Hi,
>> e(fx)clipse would like to join the Mars release as a +3 component
>> because we depend on Xtext who is +2.
>> Our current plan is to contribute e(fx)clipse 2.0 because this is the
>> first time we are joining (I need to make myself familiar with the
>> process) I'm not sure we manage to contribute to M1 in time.
> I'm curious - Did you find a way to use javafx without doing tweaks on
> the classpath/eclipse.ini
> that potentially affect others using javafx ?
> /max
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit

Back to the top