[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Equinox, PDE and packages from the ExtensionClasspath (e.g. JavaFX)

Am 14.11.12 12:49, schrieb Neil Bartlett:
> On Wed, Nov 14, 2012 at 11:34 AM, Tom Schindl
> <tom.schindl@xxxxxxxxxxxxxxx <mailto:tom.schindl@xxxxxxxxxxxxxxx>> wrote:
>     Am 14.11.12 08:13, schrieb Gunnar Wagenknecht:
>     > Am 14.11.2012 01:30, schrieb Neil Bartlett:
>     >> I really feel that the problem is in the launcher, so that's where it
>     >> needs to be fixed, i.e. by setting the osgi.parentClassloader=app
>     system
>     >> property.
>     >
>     > I agree. So the wrong property is only used if the Equinox is launched
>     > using the binary executable or also when launched using "java -jar
>     > org.eclipse.osgi..."?
>     >
>     Please note that we can't simply change the launcher to use the
>     ext-classpath because then we'd most likely break other Eclipse plugins!
> I really don't think so. I had a brief chat with Tom W about the reason
> why Eclipse uses the boot loader as its parent. Apparently it dates back
> to Eclipse 2.x (pre-OSGi) and conflicts with the Xerces XML parser that
> was being shipped in Sun JREs around that time. You see the irony, I
> hope.... back then it was necessary to avoid exposing Eclipse to non-JSR
> libraries in the extension loader. Now we WANT to expose Eclipse to
> non-JSR libraries in the extension loader. You can't have your cake and
> eat it.
> Why not try running Eclipse right now with osgi.parentClassLoader=app,
> and find out what happens?

I agree fully with you and see the irony and naturally the best would be
that equinox would switch to the app classloader.

I can try to run my stuff and some other eclipse plugins I'm using and
in my daily work and most certainly they won't break but I'm not the one
who can make the decision that Eclipse IDE (or better Equinox) has to
switch to it by default.

What I'm providing is a plugin for the Eclipse IDE and I'm not in
control of this setting :-(

>     We only change the classpath for a specific fragment. At least this is
>     how I interpreted Tom Watsons suggestion to use the above format.
> I just don't see how it's possible for the framework to change its own
> classpath for different fragments. Maybe Tom has some ideas. However I
> think this solution could come with its own set of plugin breakages, if
> it even works at all.

I'm not sure what is happening when I set this specific header in side
my fragment, only Tom can answer that.

Will it only switch the classloading of packages exported of this
specific fragment? Will it switch the classloader for the complete
system.bundle? I have no idea.


B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
tom schindl                 geschäftsführer/CEO
eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833
http://www.BestSolution.at                      phone    ++43 512 935834