Re: [equinox-dev] Equinox, PDE and packages from the ExtensionClasspath (e.g. JavaFX)
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..."? I think the dilema is that anything that requires a "fix" will make adoption harder because people won't be able to use released versions (eg., Juno) for JavaFX development. Is that correct? -Gunnar -- Gunnar Wagenknecht gun...@wagenknecht.org http://wagenknecht.org/ ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] IP CQs waiting on your team
equinox-dev, IPZilla records show that one or more of the projects on which you are developer are in need of attention. The following CQs have been in the 'awaiting_project' status for over 3 weeks and need your team to take action. rt.equinox: 6484 Apache Felix Resolver -- checkintocvs, nonepl, sourceandbinary, unmodified, 6 months ago https://dev.eclipse.org/ipzilla/show_bug.cgi?id=6484 If you have any questions, please do not hesitate to contact your project lead, PMC member, or the EMO ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox, PDE and packages from the ExtensionClasspath (e.g. JavaFX)
I agree with BJ that it would be better to use an Equinox-specific directive for this Equinox-specific functionality. I believe that Felix should work fine today with the following: Fragment-Host: system.bundle;x-appclasspath:=ext because it would ignore the unknown directive, and would provide visibility of the JavaFX classes via the framework's application classpath. The same would be true of Equinox sans the slightly strange Eclipse launcher. There are implementation challenges with this approach, because the instruction to use the extension loader needs to be passed out of the framework to the launcher. The framework shouldn't actually know what classloader it has been started in, only the launcher knows that. Therefore in order to obey the above directive, the framework would need to actually find the extension loader, which will a "sibling" of its own classloader. The Java classloader API doesn't provide methods for navigating up and down the tree in this fashion, AFAIK. 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. On Tue, Nov 13, 2012 at 10:57 PM, Tom Schindl wrote: > Am 13.11.12 23:42, schrieb BJ Hargrave: > >> > Fragment-Host: system.bundle; extension:=extclasspath > >> > >> Would this extension:=extclasspath cause problems to other > >> OSGi-Implementations like e.g. felix? > > > > A compliant framework should reject this manifest since the standard > > directive does not specify a valid value. > > > > If you are thinking of having a non-standard, Equinox-specific value for > > a standard directive, why not just add an Equinox-specific manifest > > header or Equinox-specific directive? > > > > Because Equinox already supports it this way and if the change is coming > with Java7u something we need to use what is already in the framework. > > > Fragment-Host: system.bundle; x-appclasspath:=ext > > > > I'm all for having such a framework specific option, if I got Neil and > Tom right only equinox has this strange setting that it does not consult > the extension classpath and has to be forced in this direction. So if > equinox is willing to implement it, I'll happily use it but if I have > the choice of: > a) can't run at all on equinox > b) only work on equinox > > I'll go for b). Users of other frameworks would have to create their own > fragment, not the prefered solution but well. > > > This does not sound like it would work in general anyway. What happens > > when the framework is launched from code whose classpath does not > > include ext? I assume the option here is either use the bootclasscloader > > for the parent of the classloader used to load the framework or use the > > current classloader for the parent of the classloader used to load the > > framework. > > > > I let Tom Watson comment on this. > > Tom > > -- > B e s t S o l u t i o n . a tEDV 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 > ___ > equinox-dev mailing list > equinox-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/equinox-dev > ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox, PDE and packages from the ExtensionClasspath (e.g. JavaFX)
Am 13.11.12 23:42, schrieb BJ Hargrave: >> > Fragment-Host: system.bundle; extension:=extclasspath >> >> Would this extension:=extclasspath cause problems to other >> OSGi-Implementations like e.g. felix? > > A compliant framework should reject this manifest since the standard > directive does not specify a valid value. > > If you are thinking of having a non-standard, Equinox-specific value for > a standard directive, why not just add an Equinox-specific manifest > header or Equinox-specific directive? > Because Equinox already supports it this way and if the change is coming with Java7u something we need to use what is already in the framework. > Fragment-Host: system.bundle; x-appclasspath:=ext > I'm all for having such a framework specific option, if I got Neil and Tom right only equinox has this strange setting that it does not consult the extension classpath and has to be forced in this direction. So if equinox is willing to implement it, I'll happily use it but if I have the choice of: a) can't run at all on equinox b) only work on equinox I'll go for b). Users of other frameworks would have to create their own fragment, not the prefered solution but well. > This does not sound like it would work in general anyway. What happens > when the framework is launched from code whose classpath does not > include ext? I assume the option here is either use the bootclasscloader > for the parent of the classloader used to load the framework or use the > current classloader for the parent of the classloader used to load the > framework. > I let Tom Watson comment on this. Tom -- B e s t S o l u t i o n . a tEDV 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 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox, PDE and packages from the ExtensionClasspath (e.g. JavaFX)
> > Fragment-Host: system.bundle; extension:=extclasspath > > Would this extension:=extclasspath cause problems to other > OSGi-Implementations like e.g. felix? A compliant framework should reject this manifest since the standard directive does not specify a valid value. If you are thinking of having a non-standard, Equinox-specific value for a standard directive, why not just add an Equinox-specific manifest header or Equinox-specific directive? Fragment-Host: system.bundle; x-appclasspath:=ext This does not sound like it would work in general anyway. What happens when the framework is launched from code whose classpath does not include ext? I assume the option here is either use the bootclasscloader for the parent of the classloader used to load the framework or use the current classloader for the parent of the classloader used to load the framework. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox, PDE and packages from the ExtensionClasspath (e.g. JavaFX)
Hi, Following up my last mail on all this stuff. I had a meeting on IRC with Tom Watson, discussing how one could make use of none public packages. Normally I'd say to anyone that they should not use them because they are an implementation detail of your JRE. The problem as it looks like today is that JavaFX is not JSRed and hence not part of a EE-profile. The current thinking is that it will endup in the ext/lib directory in Java8 (and maybe one of the Java7-Updates) and so if people want to use it in OSGi-Envs they need to get access to it. There are 2 sides of the problem: a) Runtime: How can we provide people access to javafx-Classes b) Tooling: How can people make use of javafx-Classes inside their IDE (Bnd, PDE) Runtime: Tom Watson and myself came to the conclusion that the best solution to provide people access to the none-public packages is to provide a fragment to the system.bundle who itself has no source but exports the javafx-packages, so that developers can use them in their app bundles. An equinox specific problem in this regard is that equinox normally only consults the bootclassloader for classes because of history reasons so the fragment we'll have to provide has some equinox specific setting: > Manifest-Version: 1.0 > Bundle-ManifestVersion: 2 > Bundle-Name: Myext > Bundle-SymbolicName: javafx.bundle > Bundle-Version: 8.0.0.qualifier > Fragment-Host: system.bundle; extension:=extclasspath > Bundle-RequiredExecutionEnvironment: JavaSE-1.6 > Export-Package: javafx Would this extension:=extclasspath cause problems to other OSGi-Implementations like e.g. felix? The final question is which of the packages of javafx we'll export. JavaFX is quite young and sometimes people have to reside to internal APIs to implement things, so I think we need to be pragmatic and export also none-public packages but mark them as x-internal:=true. Any objections? (Eclipse)Tooling: - BND-Tools: -- Neil told me that BND-Tools already picked up stuff from the system.bundle fragments and so I hope it simply works but I have not tested. PDE: PDE does not pick up the stuff but consults the EE when createing the JRE Classpath Container and setting up the accessible rules for it. In reality this stuff is not done by PDE but JDT-Launch where all this stuff is handled. That's the bad news. The good one is that JDT-Launching has an extension point allowing us to contribute to the access rules and so we can provide a plugin which adds access rules for javafx-packages when we detect a Java8 EE (not sure yet how this Compact1, ... is going to be handled). Summary: We have a plan, a working prototype how we can integrate ext/lib or more generally none public JRE-packages into the runtime. The tooling already as of Eclipse 3.3 provides the needed hooks we need to provide the tooling integration. Tom -- B e s t S o l u t i o n . a tEDV 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 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
