|
|
|
|
|
|
| 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 #1693927 is a reply to message #1693906] |
Wed, 29 April 2015 10:34 |
Darren Hurt
Messages: 32
Registered: July 2009 |
Member |
|
|
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 #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 |
Darren Hurt
Messages: 32
Registered: July 2009 |
Member |
|
|
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.07293 seconds
] 
Search
Help
Register
Login
Home
