|
|
|
|
|
|
Re: jfxswt not on the classpath [message #1403565 is a reply to message #1403561] |
Thu, 24 July 2014 12:39   |
Marcel Austenfeld Messages: 160 Registered: July 2009 |
Senior Member |
|
|
Hello Tom,
i added the org.eclipse.fx.target.rcp.feature and followed the steps 9&10.
However if i add the -D flag then i get the error below:
java.lang.NoClassDefFoundError: org/eclipse/osgi/baseadaptor/HookConfigurator
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:455)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:367)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:259)
at org.eclipse.osgi.internal.hookregistry.HookRegistry.loadConfigurators(HookRegistry.java:185)
at org.eclipse.osgi.internal.hookregistry.HookRegistry.initialize(HookRegistry.java:106)
at org.eclipse.osgi.internal.framework.EquinoxContainer.<init>(EquinoxContainer.java:73)
at org.eclipse.osgi.launch.Equinox.<init>(Equinox.java:31)
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:297)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:232)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
Caused by: java.lang.ClassNotFoundException: org.eclipse.osgi.baseadaptor.HookConfigurator
at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 27 more
Do you have any idea what i'm doing wrong? Without the flag the canvas cannot be loaded.
[Updated on: Thu, 24 July 2014 12:40] Report message to a moderator
|
|
|
|
|
|
|
|
Re: jfxswt not on the classpath [message #1693791 is a reply to message #1403526] |
Tue, 28 April 2015 11:38   |
Eclipse User |
|
|
|
I tried to follow 2 with Eclipse Luna, but
1. I don't see the template you talk about when creating a new plug-in project.
2. No matter what dependencies I add to my project I cannot see FXCanvas from my project.
Any ideas? My needs are simple, and that is to access the contents of 'jfxswt.jar' (particularly FXCanvas) from within my plug-in, which considering that it is distributed with java 8 (albeit optional), should not be too hard. Of course I need it such that my built plug-in also works (not just when running from Eclipse).
Why is this so hard? There seem to be a lot of posts on this, and I think Eclipse should support JavaFX integration out of the box, without all of these extra hoops to jump through!
Thanks,
Darren Hurt
|
|
|
Re: jfxswt not on the classpath [message #1693792 is a reply to message #1403526] |
Tue, 28 April 2015 11:39   |
Eclipse User |
|
|
|
I tried to follow 2 with Eclipse Luna, but
1. I don't see the template you talk about when creating a new plug-in project.
2. No matter what dependencies I add to my project I cannot see FXCanvas from my project.
Any ideas? My needs are simple, and that is to access the contents of 'jfxswt.jar' (particularly FXCanvas) from within my plug-in, which considering that it is distributed with java 8 (albeit optional), should not be too hard. Of course I need it such that my built plug-in also works (not just when running from Eclipse).
Why is this so hard? There seem to be a lot of posts on this, and I think Eclipse should support JavaFX integration out of the box, without all of these extra hoops to jump through!
Thanks,
Darren Hurt
|
|
|
|
|
|
Re: jfxswt not on the classpath [message #1693898 is a reply to message #1693798] |
Wed, 29 April 2015 08:50   |
Eclipse User |
|
|
|
Here is the current set up I'm trying.
I installed the minimal OSGI integration bundle from the update site (tell me if I need anything else), included the system property in the vm arguments (as specified) added the dependency and imported package in the manifest, and updated the class-path of my plug-in via PDE tools. Still can't get it to see FXCanvas. If I look in the org.eclipse.fx.javafx I can find the package, but it contains a dummy.tx and a dummy.class.
Plugin dependencies: 
JRE_DEP: 
Eclipse Ini: 
Installed Features: 
Plug-in Manifest:
|
|
|
|
Re: jfxswt not on the classpath [message #1693927 is a reply to message #1693906] |
Wed, 29 April 2015 10:34   |
Eclipse User |
|
|
|
I am not sure you understand what I am trying to do. let me try and elaborate further.
I am the author of a suite of plug-ins used to develop on a proprietary platform where I cannot include lots of extras stuff that people do not need. The end users (developers of business applications) have no need to be able to work with Java FX in my Eclipse based IDE product that they are using, and hence the extra wizards and capabilities etc. are not something I am willing to add. They use a fixed suite of plug-ins and a fixed set of technologies (that do not include JavaFX).
For example, I certainly don't want to be dragging in XText, Xtend etc. just for the needs of a language for specifying FX screens which they don't even need or use. I just need the ability to use JavaFX screens in my plug-ins. In fact I can use the SWT browser widget instead, but i wanted to compare and see which works best for me (it was WebView I was interested in).
To clarify, no JavaFX capabilities are needed by them, only by me in the plug-ins to display some stuff to them.
In fact they use GWT to create end user screens, and hence the CSS editor provided by Google is what they need, and I do NOT want a JavaFX specific one taking over the .css file association 
The way I work is that I generally prefer to install the plug-ins that will be included in the final product and work against the 'Runtime' target platform. I realise I can use custom target platforms instead, but I prefer not to. It is perfectly valid to use the default 'Runtime' target platform, so I do not understand why you are getting hung up on that point. In fact I tried a custom target platform and got exactly the same result. Either way it is not why it isn't working.
If it is the Eclipse plug-ins development Eclipse that needs to resolve the jfxswt.jar then surely it is that which needs the system property in the eclipse.ini?
Does this make my set-up and goals clearer to you?
|
|
|
Re: jfxswt not on the classpath [message #1693929 is a reply to message #1693927] |
Wed, 29 April 2015 10:46   |
Eclipse User |
|
|
|
In trying just to take the IDE-PDE feature it seems to want to include Xtext, Xtext UI and Xtend. I know about the whole Xtext language infrastructure generation stuff and the Xtend JavaVM language that is an example of it etc. etc., and I certainly don't want or need it for my product. It'd be nice if there was a smaller feature that just included enough to be able to use JavaFX in plug-in development. I am sorry I used the word bloat. that was unfortunate and I can see that might offend. It's just that in my case I do have valid reasons to just want a very limited ability to use JavaFX in plug-ins code, and hence just really want the minimal 'class-path manipulation' part of e(fx)clipse.
|
|
|
Re: jfxswt not on the classpath [message #1693935 is a reply to message #1693927] |
Wed, 29 April 2015 11:44   |
Thomas Schindl Messages: 6651 Registered: July 2009 |
Senior Member |
|
|
On 29.04.15 12:34, Darren Hurt wrote:
> I am not sure you understand what I am trying to do. let me try and
> elaborate further.
>
I very well understand what you are doing
> I am the author of a suite of plug-ins used to develop on a proprietary
> platform where I cannot include lots of extras stuff that people do not
> need. The end users (developers of business applications) have no need
> to be able to work with Java FX in my Eclipse based IDE product that
> they are using, and hence the extra wizards and capabilities etc. are
> not something I am willing to add. They use a fixed suite of plug-ins
> and a fixed set of technologies (that do not include JavaFX).
> For example, I certainly don't want to be dragging in XText, Xtend etc.
> just for the needs of a language for specifying FX screens which they
> don't even need or use. I just need the ability to use JavaFX screens in
> my plug-ins. In fact I can use the SWT browser widget instead, but i
> wanted to compare and see which works best for me (it was WebView I was
> interested in).
So you are the only one who has to install the e(fx)clipse tooling -
your users don't have to, they really only need the minimum feature.
>
> To clarify, no JavaFX capabilities are needed by them, only by me in the
> plug-ins to display some stuff to them.
Right hence they don't need the e(fx)clipse tooling themselves but you
as a developer need it. Similar to maybe other development time tools
like findbugs you use while developing the plug-ins.
>
> In fact they use GWT to create end user screens, and hence the CSS
> editor provided by Google is what they need, and I do NOT want a JavaFX
> specific one taking over the .css file association :)
We are NOT taking over the .css association but only if we detect the
that content is containing javafx stuff but I repeat your users DON'T
HAVE TO HAVE our tooling installed.
>
> The way I work is that I generally prefer to install the plug-ins that
> will be included in the final product and work against the 'Runtime'
> target platform. I realise I can use custom target platforms instead,
> but I prefer not to. It is perfectly valid to use the default 'Runtime'
> target platform, so I do not understand why you are getting hung up on
> that point. In fact I tried a custom target platform and got exactly the
This is going against any advice how do you get a headless build running
then?
> same result. Either way it is not why it isn't working.
>
> If it is the Eclipse plug-ins development Eclipse that needs to resolve
> the jfxswt.jar then surely it is that which needs the system property in
> the eclipse.ini?
No you are not understanding that correctly: The system property only
modifies the RUNTIME classpath and has NOTHING to do with compile time -
you users have to specify this or if you install your features through
p2 into an eclipse install p2 will create an extra entry in config.ini.
Tom
|
|
|
Re: jfxswt not on the classpath [message #1693953 is a reply to message #1693935] |
Wed, 29 April 2015 13:07   |
Eclipse User |
|
|
|
Ok, finally I think I see what I need. It's a while since I changed the build of my product so I'd kind of forgotten that I don't build everything into it, so that's my mistake (sorry about that) .
Still, I don't really want XText, Xtend etc. even there, but I can tolerate it. I still think there's a case for a bit of re-factoring for a more basic product with just the class-loader magic though .
Let's not get into arguments about build methodologies, technology, testing, general software practice. It is utterly pointless.
I probably should set-up a target platform, but not doing so hasn't caused me any grief over the many years I've been working in Eclipse plug-ins. I guess it will clarify the distinction between the contents of the product and the development plug-ins, so I agree that it's worth doing. Not totally necessary though as I specify elsewhere the totality of what goes into the product. It isn't the reason for stuff not working though, but rather that reason is me not installing the bit that does the class-loader magic.
I build with PDE tools within Eclipse, which works just fine for my purposes. I actually don't do headless builds, so I'm sure I offend those who subscribe to standard ways of doing everything (and I do not care about that) . However, I am the sole developer, designer etc., so such formalities are much less important than they are across large teams.
In light of what you've said, I think the following will likely work:
1. I install full tools in my plug-ins Eclipse.
2. I only build the minimal feature (is this the minimal OSGI feature thing?) into my product.
3. My product needs the vm argument in it's .ini file.
Thanks for your help. I will let you know if it works out (or even if not).
|
|
|
|
Powered by
FUDForum. Page generated in 0.06989 seconds