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

You are right in that it is an install time problem as well - i think
from a p2 point of view tp-resolution & install a fairly equal - i think
it is the same p2-API-call!

The problem at runtime is:
a) javafx is not part of any EE so if you have a package import of
   javafx OSGi will not wire your bundle because nobody at runtime
   exposes a javafx-package, for javax the EE does that

b) javafx is part of the ExtClasspath but Equinox does NOT look up
   classes from there so in case you think you can get away with out
   doing any package impports, Equinox will tell you that no javafx
   classes are available

So why fixing the runtime and tp/install problem differently (if you can
find a solution) if one - the current one - fixes all of them?

Tom

On 21.08.14 22:20, Ed Merks wrote:
> Tom,
> 
> It is my impression that this is also an install time resolution issue,
> not just a TP resolution issue.  Of course there is also the runtime
> resolution issue: at that time there is a real JRE that must provide
> resolutions to be able to load actual classes.  So yes, that's
> definitely a third and fundamental  issue not to be mixed up with the
> other two.  At install time, you don't really know which JRE will be
> available, so some fake units are (apparently) needed. When resolving
> the TP, one ought to know which JRE is available, because there are JREs
> registered with JDT that have such information (and there's even a
> default), but (apparently) fake JREs are needed for that too.  In any
> case, at runtime, it better all just work with classpath magic because
> there is definitely exactly one JRE available and it better be able to
> load real classes that really work.  Indeed it's easy to mix all these
> things up, because each of these things better work in some consistent
> and coherent sensible way.  After all, if it works at runtime, but you
> can't install the unit, or can't provision a target platform to develop
> it, you'll never get to the stage of actually running it...
> 
> Cheers,
> Ed
> 
> On 21/08/2014 9:43 PM, Tom Schindl wrote:
>> Hi,
>>
>> You guys are mixing things!
>>
>> What Ed describes is only there for p2 so that it can resolve target
>> platforms who are NOT mapped against a JRE but can only be used when a
>> final EE (e.g. JavaSE-1.7 EE) exposes the package at runtime - this is
>> true for javax stuff which is part of the Boot-Classpath & JSRed and so
>> exported by the System bundle!
>>
>> For javafx this is NOT the case:
>> a) it is not part of an EE defined by OSGi because it is not JSRed
>> b) it is not found on the Boot-Classpath hence it will never by loaded
>>     by Equinox in a default config
>>
>> The bundles provided by e(fx)clipse satisfies both p2 & runtime OSGi if
>> someone thinks there's a better solution which fixes all the problem of
>> integrating JavaFX in Equinox-OSGi (without causing trouble for any
>> other bundle) I'm happy to learn.
>>
>> So please don't mix target-platform dev time resolution and runtime
>> resolution in Equinox and even resolving does not help you still have
>> the classpath problem.
>>
>> Tom
>>
>> On 21.08.14 21:08, Alexander Nyßen wrote:
>>> Hi Ed,
>>>
>>> I was not aware of the existence of such a mechanism. Actually, the
>>> org.eclipse.javafx bundle provided by e(fx)clipse is nothing more than
>>> such a fake bundle, which provides exactly the javafx packages (so
>>> others can resolve against it).
>>>
>>> While I do not want to deny e(fx)clipse any responsibility, maybe it
>>> would be a good idea to think about how we could handle these kind of
>>> things in a more common way.
>>>   Cheers
>>> Alexander
>>>
>>> Am 21.08.2014 um 18:49 schrieb Ed Merks <ed.merks@xxxxxxxxx
>>> <mailto:ed.merks@xxxxxxxxx>>:
>>>
>>>> Guys,
>>>>
>>>> Isn't it a fundamental problem that the fake "a.jre" and "a.jre.se
>>>> <http://a.jre.se>" units in the repo are only for Java 1.6?  I.e.,
>>>> should there be units for 1.7 and 1.8?  After all, how do javax
>>>> packages new to 1.7 or 1.8 (if there are any) become visible for
>>>> package imports in bundles?
>>>>
>>>> I've never understood where these fake units come from and in which
>>>> repos they should exist.  For example, in
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=431259 it's clear that
>>>> orbit doesn't contain these units so you can't provision a target
>>>> platform purely from the Orbit repo even if you only need things form
>>>> Orbit in your TP.
>>>>
>>>> If you're curious, look in
>>>> download.eclipse.org/releases/luna/201406250900/content.jar
>>>> <http://download.eclipse.org/releases/luna/201406250900/content.jar>
>>>> and search for "<unit id='a.jre" where you'll see how it defines all
>>>> the javax packages.
>>>>
>>>> Perhaps the problem is even more complex and that even with such fake
>>>> units, the packages still wouldn't be available on the classpath, but
>>>> I don't understand how this is supposed to work unless there is a fake
>>>> "a.jre" unit that explicitly lists "javafx"...
>>>>
>>>> Regards,
>>>> Ed
>>>>
>>>> On 21/08/2014 6:03 PM, Tom Schindl wrote:
>>>>> a) Does it Help
>>>>> ---------------
>>>>> Yes it does help IMHO.
>>>>>
>>>>> Take for example the GEF4 people they have never ever thought about
>>>>> how
>>>>> JavaFX gets on the classpath they just use it like they use any other
>>>>> thing that is part of the JDK, with the small difference that they
>>>>> import javafx-packages in their MANIFEST.MF.
>>>>>
>>>>> And there's more to JavaFX-SWT embedding than just getting FXCanvas on
>>>>> the classpath? e.g. I guess most people embedding JavaFX into SWT with
>>>>> the help of e(fx)clipse don't know that they need to call
>>>>> Platform.setImplicitExit(false)
>>>>>
>>>>> b) Can an EPP package use JavaFX
>>>>> --------------------------------
>>>>> Sure it can. I'm building an EPP like distro at
>>>>> http://efxclipse.bestsolution.at/install.html using the p2-director to
>>>>> install e(fx)clipse into a plain Eclipse SDK (+some WST, m2e, ...), p2
>>>>> is clever enough to understand that there's an AdapterHook bundle is
>>>>> about to be installed and corrects the config.ini.
>>>>>
>>>>> c) On repackaging + Equinox classloader loading ext
>>>>> ---------------------------------------------------
>>>>> It is a bad idea to rebundle anything from JDK because e.g. FXCanvas
>>>>> calls out to *internal* JavaFX APIs so while your application will
>>>>> work
>>>>> with JDK8u20 nobody on the world guarantees that it will still work
>>>>> with
>>>>> JDK8u40 unless you use the the jar that resides in your JDK.
>>>>>
>>>>> You can do that with Equinox-Specific MANIFEST-Entries but that still
>>>>> leaves you with the heavy change of modifying the Equinox Classloader
>>>>> Hierarchy - I hoped Tom Watson fixes that Equinox specific thing with
>>>>> the Equinox rewrite but apparently it was not done.
>>>>>
>>>>> Tom
>>>>>
>>>>> On 21.08.14 16:11, Doug Schaefer wrote:
>>>>>> I guess this raises another question. What about the other way.
>>>>>> e(fx)clipse doesn't get in the way, but does it help either? i.e.
>>>>>> With e(fx)clipse on the release train, would it be possible to have
>>>>>> an Eclipse EPP package use JavaFX?
>>>>>>
>>>>>> All the magic required to get this actually running really confirms
>>>>>> what many people are telling me, that JavaFX is ready for prime
>>>>>> time. I love the direction, but there are a lot of hurdles to
>>>>>> actually use it in product. In our testing at QNX we did change the
>>>>>> classloader hierarchy to include ext, and we bundle-ified the
>>>>>> swt-javafx jar. Worked but not sure we can do that in the Eclipse
>>>>>> context.
>>>>>>
>>>>>> Thanks,
>>>>>> Doug.
>>>>>> ________________________________________
>>>>>> From: cross-project-issues-dev-bounces@xxxxxxxxxxx
>>>>>> <mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx>
>>>>>> [cross-project-issues-dev-bounces@xxxxxxxxxxx
>>>>>> <mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx>] on behalf of
>>>>>> Tom Schindl [tom.schindl@xxxxxxxxxxxxxxx
>>>>>> <mailto:tom.schindl@xxxxxxxxxxxxxxx>]
>>>>>> Sent: Thursday, August 21, 2014 3:37 AM
>>>>>> To: cross-project-issues-dev@xxxxxxxxxxx
>>>>>> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
>>>>>> Subject: 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.
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>> 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
>>>>>>> http://about.me/maxandersen
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>>>> _______________________________________________
>>>>>> cross-project-issues-dev mailing list
>>>>>> cross-project-issues-dev@xxxxxxxxxxx
>>>>>> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
>>>>>> To change your delivery options, retrieve your password, or
>>>>>> unsubscribe from this list, visit
>>>>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>>>> _______________________________________________
>>>>>> 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
>>>>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>>>>
>>>>> _______________________________________________
>>>>> cross-project-issues-dev mailing list
>>>>> cross-project-issues-dev@xxxxxxxxxxx
>>>>> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
>>>>> To change your delivery options, retrieve your password, or
>>>>> unsubscribe from this list, visit
>>>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>> _______________________________________________
>>>> cross-project-issues-dev mailing list
>>>> cross-project-issues-dev@xxxxxxxxxxx
>>>> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
>>>> To change your delivery options, retrieve your password, or
>>>> unsubscribe from this list, visit
>>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>> -- 
>>> Dr. Alexander Nyßen
>>> Dipl.-Inform.
>>> Software-Engineer
>>>
>>> Telefon: +49 (0) 231 / 98 60-210
>>> Telefax: +49 (0) 231 / 98 60-211
>>> Mobil: +49 (0) 151 /  17396743
>>>
>>> http://www.itemis.de
>>> alexander.nyssen@xxxxxxxxx <mailto:alexander.nyssen@xxxxxxxxx>
>>>
>>> itemis AG
>>> Am Brambusch 15-24
>>> 44536 Lünen
>>>
>>> Rechtlicher Hinweis:
>>>
>>> Amtsgericht Dortmund, HRB 20621
>>>
>>> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek,
>>> Jens Trompeter, Sebastian Neus
>>>
>>> Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael
>>> Neuhaus
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>
>> _______________________________________________
>> 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
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> 
> _______________________________________________
> 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
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



Back to the top