- 浏览: 329101 次
- 性别:
- 来自: 北京
最新评论
-
sjzcmlt:
谢谢,学习了!
mysql中GROUP BY结合GROUP_CONCAT的使用 -
Einsdan:
看了这篇文章豁然开朗,谢谢分享!
struts2采用convention-plugin实现零配置 -
hachorse:
楼主,请问有没有什么办法可以在Activator中获取你第二步 ...
RCP中采用actionSet配置菜单的方法总结 -
l4d_fire:
动态方法貌似只能用!不能使用其他的么
struts2采用convention-plugin实现零配置 -
morigin:
拜谢!~
struts2启动报错com/opensymphony/xwork2/spring/SpringObjectFactory.java:220:-1
problem
The key can be found in the message: '!MESSAGE Missing required bundle com.dawnatech.misc_0.0.0.' -- note the version number of 0.0.0.
answer
This is due to the fact that your 'misc' plugin is not defined in your quick launch configuration. These are tricky to get right..... I always define a specific quick launch configuration for all of my RCP apps.
I found that merely selecting the 'Launch an Eclipse application' link on the plug-in editor page usually doesn't set up the application and required plug-ins correctly at run time.
This also explains why you think it worked earlier but not later. This has happened to me, as well......
Go to Run | Run... page, create a new run configuration (and name it).
Then, set the Workspace Location to something appropriate for your machine, set the Program to run (product or application).
Then, go to the Plug-ins page and select the 'Choose plug-ins and fragments to launch....'. Deselect all, then select the two plugins in your product/application, and then select 'Add required plugins'.
Every now and again, questions like "Why doesn't eclipse start?" are posted on the newsgroups, or "The application cannot be found". How do you go about debugging these scenarios? This isn't an exhaustive list, but may be a good place to start.
First, some background knowledge. Eclipse uses two writable areas for storing data; a configuration directory (which actually doesn't contain that much other than a config.ini and a few .dlls that have been extracted from bundles) and a workspace , which is usually in ~/workspace on Unix and c:\Documents and Settings\User\workspace on Windows. The workspace has two purposes; to act as a default place for any projects you create, and to have a .metadata directory for storing transient files, as well as anything you've configured in the Eclipse preferences, run-time caches, and a bunch of other stuff.
The config area is usually pretty harmless; if you delete it, it will get re-created on startup. Once created, it isn't usually changed. There's not usually much benefit in deleting the configuration directory, but there's not usually much harm in it either. A default install from unzipping the distribution from Eclipse doesn't have any configuration directory.
When Eclipse starts, it reads two files; eclipse.ini and configuration/config.ini . The former is a list of arguments that get passed to the JVM, whilst the latter is a list of name-value pairs that are set as system properties. If you want to run an Eclipse with an environment value set, you can put it in config.ini as org.example=foo or eclipse.ini as -Dorg.example=foo (after the 'vmargs' flag; if not present, you'll need to add it as an extra arg). Arguments are serparated by newline characters, so you can't put them on the same line. You can also supply these args on the command-line; eclipse -vmargs -Dorg.example=foo .
Eclipse logs all its messages to workspace/.metadata/.log. If you're in Unix, these are usually hidden, but they'll be there. Sometimes, when Eclipse isn't starting, it can help to delete this file first so that you're sure that any problems in starting the environment are not just random messages left over from before.
There's a secondary log, generated when Eclipse doesn't even get as far as starting. For example, if you specify a non-existent VM, then it won't get as far as running any Java code. In these cases, you can often find a configuration/123456.log which contains something useful. If Eclipse isn't starting and not generating a workspace/.metadata/.log file, check the configuration directory for anything suspicious.
The most likely scenario is one where the Eclipse VM starts, but then fails to find out what it's supposed to be doing and shuts down again. What to do then?
Well, clearly, the log may have some answers. Always a good place to look first, rather than guessing. If you do look and don't understand the output, generally posting the entire stacktrace to the newsgroup isn't the best way of finding out. You can generally find out what's going on just by reading the exception messages; and since Java's nested exception handling prints out the full stacktrace of each, you generally just want to scan down for the 'caused by' message at the top of each nested exception. In most cases, the answer is staring you in the face :-)
A good comand to run is:
egrep -A 2 "Caused by:|Exception:" workspace/.metadata/.log
If you're on a primitive OS without 'egrep' installed by default, use Cygwin to install that and other useful tools. Other variants of grep will work as well, but you might have to do two separate greps or miss out on the -A 2 (which prints out the two lines After as well).
It's 'normal' for there to be some errors in the log that are unrelated, so don't take it as read that that's the cause of the problem. Deleting the log before running will give you an idea of what's new, at least.
Some common messages:
NullPointerException ...
Oh joy. Nothing much to say here other than the code needs to be more defensive. Still, it's better than segfaulting, huh?
The bundle could not be resolved. Reason: Missing Constraint ...
Generally, you've got a newer version of a plug-in without its dependencies. For example, you had org.foo.lib-1.0.0 and org.foo.app-1.0.0 , and now that you've installed org.foo.app-1.0.1 it's stopped working. Chances are, org.foo.app-1.0.1 depends on org.foo.lib-1.0.1 or greater, and you've not got that installed. Using a kosher update site like Eclipse Europa discovery site shouldn't have these problems, but always something to be aware of.
java.lang.IllegalStateException: Workbench has not been created yet
This usually comes when someone tries to run a Java application against an OSGi bundle with java -classpath .... . It really means that the workbench plug-in hasn't started yet, and so calls to getWorkbench() fail. This is essentially a race condition, and can be solved by either expressing an explicit dependency on that bundle or bumping up that bundle to a higher start level than the workbench. Generally not seen, but if it is, that's what's happening.
Application "foobar" cannot be found in the registry. The applications available are:...
Either (a) you've mistyped the application ID, or more likely (b) the bundle that contributed the application can't be started. See below.
One or more bundles are not resolved because the following root constraints are not resolved:
Again, a problem with dependencies.
So, now that we know Eclipse is firing up a JVM, but not able to do anything else, where do we go? Well, time to drop into an OSGi console to find out more, or even look at what's going on in the log. Eclipse has a bunch of runtime options , and here are some of the most important ones:
-consoleLog
When starting, dump the messages to the console as well as the .metadata/.log file. Can be quite useful for quickly figuring out what's going on, especially if you don't know where the .metadata/.log file is being written (or assume that it's not being writable)
-noExit
Almost as useful as the last. Basically, even if the application can't be found or there's another problem, don't quit the JVM or OSGi engine. Can make the window hang around rather than disappearing on a Windows system.
-console or -console 1234
Start up an OSGi console interactively, or via a network socket 1234 (to which you can 'telnet localhost 1234' to gain access). Very useful if you're running on a remote machine or don't have access to the console from where Eclipse is being launched. Can do all manner of commands; see below for more.
-data /tmp/newplace or -data c:\temp\newplace
Run Eclipse, but with a workspace that's not the default location. Quite often, if this works but running without doesn't, indicates a problem with the workspace area.
-clean
Used to flush out some (but not all) entries in the workspace metadata area. A good thing to try, and generally safe, but doesn't always have the results intended. If you've not got any preferences, it's sometimes better just deleting the workspace/.metadata directly. If you have got prefs, either export them from the Window -> Preferences beforehand, or save *.prefs from the .metadata/.plugins/org.eclipse.core.runtime/.settings directories. Note that there's a bunch of stuff (like CVS repositories) that probably won't get saved like this; but you did take a backup first, right?
Windows users might also like to know about eclipsec , which isn't a compiler but rather a version of Eclipse that fires up a console window instead of hiding it away. Most of the time, running these with eclipsec is a good way of figuring out what's going on. Unix users can just use the eclipse one. For Mac users, there's a eclipse command you can access through Terminal instead of double-clicking the Eclipse.app .
So, you're through to the OSGi console. When it starts up, it will print out:
osgi>
From here, you can start to figure out what's going wrong. Typing '?' or 'help' will give you a list of available commands; if they scroll off the screen, type 'more' and you'll get paginated output.
Typing 'ss' (for ShortStatus) brings up a list of bundles that are available; they'll be in ACTIVE (running), RESOLVED (ready to run), STARTING (usually indicates a deadlock or stuck thread if you see that for any length of time) or INSTALLED. The last one is the one to look for; it means that the OSGi environment has found the bundle, but one or more of its dependencies haven't been met.
If you find a bundle in the INSTALLED state, you can use 'diag' (for DIAGnostics) to find out what's missing:
osgi> ss
Framework is launched.
id State Bundle
0 ACTIVE org.eclipse.osgi_3.3.0.v20070530
1 ACTIVE org.eclipse.equinox.common_3.3.0.v20070426
...
123 INSTALLED org.example.foo_1.0.0
...
osgi> diag 123
update@plugins/org.example.foo_1.0.0.jar [123]
Missing imported package org.example.bar_0.0.0.
Missing required bundle org.example.bar.core_0.0.0.
Quite often, if you've got an application that's not starting, it's because 'org.example.foo' defines the application; but the bundle can't start because it's got missing dependencies. The solution is therefore to resolve those dependencies (by installing a missing bundle or a bundle which exports the given package, and you should be away.
You can do this by restarting, or by dynamically adding it in via the console:
osgi> install http://www.eclipsezone.com/files/jsig/bundles/HelloWorld.jar
Bundle id is 456
osgi> start 456
Hello OSGi
You can also stop and start other bundles; once you've brought your dependencies in, you can restart the ones that failed before (e.g. start 123).
Occasionally, if the bundle is RESOLVED (i.e. all dependencies are met) but it still can't start (doing start 123 leads to an exception), then it implies the Bundle Activator's start() method has thrown an exception. That's basically either a programming or configuration error, outside the scope of this post. It's not always an error; for example, a plug-in that connects to a DB might (reasonably) be expected to have the property set via a command line property (e.g. -Ddatabase=foo) otherwise it won't work.
You can find out if there's a setting using 'getprop' in the console:
osgi> getprop osgi.nl
osgi.nl=en_UK
and even set it if it doesn't exist:
osgi> setprop database=foo
osgi> getprop database
database=foo
Of course, you can then do 'start 456' to see if the activator now works.
There's a bunch of other things you can do in the console; for example, if you wanted to see what application extension points were being contributed, you can do:
osgi> pt org.eclipse.core.runtime.applications
osgi> pt org.eclipse.core.runtime.applications
Extension point: org.eclipse.core.runtime.applications [from org.eclipse.equinox.app]
Extension(s):
-------------------
org.eclipse.ant.core.antRunner [from org.eclipse.ant.core]
...
org.eclipse.help.base.helpApplication [from org.eclipse.help.base]
...
You can also find out what extension points are contributed by a bundle:
osgi> ns org.eclipse.help
Extension point(s):
-------------------
org.eclipse.help.contentExtension [from org.eclipse.help]
org.eclipse.help.contentProducer [from org.eclipse.help]
org.eclipse.help.contexts [from org.eclipse.help]
org.eclipse.help.index [from org.eclipse.help]
org.eclipse.help.toc [from org.eclipse.help]
At least doing this will give you confidence that any extension points you've used will be contributed in the list somewhere. If not (or you have something like 'org.example.foo.org.example.foo.FooApp') then at least you can start debugging somewhere.
The last kind of error is more subtle to fix. If you see a message in the log like
The activator org.example.FooActivator for bundle org.example.foo is invalid , then this usually means there has been a ClassNotFoundException trying to load the class in the first place, before it's even got to the start() method.
CNFE is the bane of debugging; the only thing I can say is that it gets easier with practice. A key thing to understand is that if you have a class Foo, and that class references Bar as any kind of method parameter, return type or field type, then in order to load Foo, Bar must also be loaded. This is transitive, so if Bar needs to be loaded, then so does Flubber, and so on. Unfortuantely, when you hit a missing class, the actual class that can't be found is lost in the message and you just get back "Class Foo cannot be found", when clearly it can. Very often, the PDE will give you warnings when you're running into these problems at development time, but sometimes they can make their way past you and into a runtime bundle. Unfortunately, you have to go back to the code to figure it out.
In a bunch of cases, this has been caused by a developer adding a Jar to a Project's Java Build Path and not the OSGi Manifest dependencies. If you have (say) JUnit.jar added onto the build path, then the project will compile, but at run-time your activator will only consult the Bundle-ClassPath to find code. If it can't find JUnit.jar on that path, it will give up and give you the CNFE. The other possibility is that the Bundle-ClassPath either doesn't contain '.' (for classes in the bundle) or it does contain '.,JUnit.jar' but when exporting, the JUnit.jar is missing from the bundle itself. If it's the latter, check the entries in build.properties, and ensure that 'bin.includes=JUnit.jar' is in there. Very often, exporting the bundle and then opening it in WinZip will give you a clue as to what you expected to be in there (but wasn't) and/or consulting what the Bundle-ClassPath is in relation to the contents of the bundle itself.
So, whilst I don't think this will prevent any more questions being posted to the newsgroups in the future, at least it will be somewhere to point people to when they get stuck for reference. If you're experienced at debugging Eclipse startup problems and have any ideas that I've missed, please add comments to the below for the benefit of others. And if you find any glaring errors I've made, please add a comment so I can fix it :-)
I hope you've found this useful. Until next time
The key can be found in the message: '!MESSAGE Missing required bundle com.dawnatech.misc_0.0.0.' -- note the version number of 0.0.0.
answer
This is due to the fact that your 'misc' plugin is not defined in your quick launch configuration. These are tricky to get right..... I always define a specific quick launch configuration for all of my RCP apps.
I found that merely selecting the 'Launch an Eclipse application' link on the plug-in editor page usually doesn't set up the application and required plug-ins correctly at run time.
This also explains why you think it worked earlier but not later. This has happened to me, as well......
Go to Run | Run... page, create a new run configuration (and name it).
Then, set the Workspace Location to something appropriate for your machine, set the Program to run (product or application).
Then, go to the Plug-ins page and select the 'Choose plug-ins and fragments to launch....'. Deselect all, then select the two plugins in your product/application, and then select 'Add required plugins'.
Debugging a failed Eclipse launch
Every now and again, questions like "Why doesn't eclipse start?" are posted on the newsgroups, or "The application cannot be found". How do you go about debugging these scenarios? This isn't an exhaustive list, but may be a good place to start.
First, some background knowledge. Eclipse uses two writable areas for storing data; a configuration directory (which actually doesn't contain that much other than a config.ini and a few .dlls that have been extracted from bundles) and a workspace , which is usually in ~/workspace on Unix and c:\Documents and Settings\User\workspace on Windows. The workspace has two purposes; to act as a default place for any projects you create, and to have a .metadata directory for storing transient files, as well as anything you've configured in the Eclipse preferences, run-time caches, and a bunch of other stuff.
The config area is usually pretty harmless; if you delete it, it will get re-created on startup. Once created, it isn't usually changed. There's not usually much benefit in deleting the configuration directory, but there's not usually much harm in it either. A default install from unzipping the distribution from Eclipse doesn't have any configuration directory.
When Eclipse starts, it reads two files; eclipse.ini and configuration/config.ini . The former is a list of arguments that get passed to the JVM, whilst the latter is a list of name-value pairs that are set as system properties. If you want to run an Eclipse with an environment value set, you can put it in config.ini as org.example=foo or eclipse.ini as -Dorg.example=foo (after the 'vmargs' flag; if not present, you'll need to add it as an extra arg). Arguments are serparated by newline characters, so you can't put them on the same line. You can also supply these args on the command-line; eclipse -vmargs -Dorg.example=foo .
Eclipse logs all its messages to workspace/.metadata/.log. If you're in Unix, these are usually hidden, but they'll be there. Sometimes, when Eclipse isn't starting, it can help to delete this file first so that you're sure that any problems in starting the environment are not just random messages left over from before.
There's a secondary log, generated when Eclipse doesn't even get as far as starting. For example, if you specify a non-existent VM, then it won't get as far as running any Java code. In these cases, you can often find a configuration/123456.log which contains something useful. If Eclipse isn't starting and not generating a workspace/.metadata/.log file, check the configuration directory for anything suspicious.
The most likely scenario is one where the Eclipse VM starts, but then fails to find out what it's supposed to be doing and shuts down again. What to do then?
Well, clearly, the log may have some answers. Always a good place to look first, rather than guessing. If you do look and don't understand the output, generally posting the entire stacktrace to the newsgroup isn't the best way of finding out. You can generally find out what's going on just by reading the exception messages; and since Java's nested exception handling prints out the full stacktrace of each, you generally just want to scan down for the 'caused by' message at the top of each nested exception. In most cases, the answer is staring you in the face :-)
A good comand to run is:
egrep -A 2 "Caused by:|Exception:" workspace/.metadata/.log
If you're on a primitive OS without 'egrep' installed by default, use Cygwin to install that and other useful tools. Other variants of grep will work as well, but you might have to do two separate greps or miss out on the -A 2 (which prints out the two lines After as well).
It's 'normal' for there to be some errors in the log that are unrelated, so don't take it as read that that's the cause of the problem. Deleting the log before running will give you an idea of what's new, at least.
Some common messages:
NullPointerException ...
Oh joy. Nothing much to say here other than the code needs to be more defensive. Still, it's better than segfaulting, huh?
The bundle could not be resolved. Reason: Missing Constraint ...
Generally, you've got a newer version of a plug-in without its dependencies. For example, you had org.foo.lib-1.0.0 and org.foo.app-1.0.0 , and now that you've installed org.foo.app-1.0.1 it's stopped working. Chances are, org.foo.app-1.0.1 depends on org.foo.lib-1.0.1 or greater, and you've not got that installed. Using a kosher update site like Eclipse Europa discovery site shouldn't have these problems, but always something to be aware of.
java.lang.IllegalStateException: Workbench has not been created yet
This usually comes when someone tries to run a Java application against an OSGi bundle with java -classpath .... . It really means that the workbench plug-in hasn't started yet, and so calls to getWorkbench() fail. This is essentially a race condition, and can be solved by either expressing an explicit dependency on that bundle or bumping up that bundle to a higher start level than the workbench. Generally not seen, but if it is, that's what's happening.
Application "foobar" cannot be found in the registry. The applications available are:...
Either (a) you've mistyped the application ID, or more likely (b) the bundle that contributed the application can't be started. See below.
One or more bundles are not resolved because the following root constraints are not resolved:
Again, a problem with dependencies.
So, now that we know Eclipse is firing up a JVM, but not able to do anything else, where do we go? Well, time to drop into an OSGi console to find out more, or even look at what's going on in the log. Eclipse has a bunch of runtime options , and here are some of the most important ones:
-consoleLog
When starting, dump the messages to the console as well as the .metadata/.log file. Can be quite useful for quickly figuring out what's going on, especially if you don't know where the .metadata/.log file is being written (or assume that it's not being writable)
-noExit
Almost as useful as the last. Basically, even if the application can't be found or there's another problem, don't quit the JVM or OSGi engine. Can make the window hang around rather than disappearing on a Windows system.
-console or -console 1234
Start up an OSGi console interactively, or via a network socket 1234 (to which you can 'telnet localhost 1234' to gain access). Very useful if you're running on a remote machine or don't have access to the console from where Eclipse is being launched. Can do all manner of commands; see below for more.
-data /tmp/newplace or -data c:\temp\newplace
Run Eclipse, but with a workspace that's not the default location. Quite often, if this works but running without doesn't, indicates a problem with the workspace area.
-clean
Used to flush out some (but not all) entries in the workspace metadata area. A good thing to try, and generally safe, but doesn't always have the results intended. If you've not got any preferences, it's sometimes better just deleting the workspace/.metadata directly. If you have got prefs, either export them from the Window -> Preferences beforehand, or save *.prefs from the .metadata/.plugins/org.eclipse.core.runtime/.settings directories. Note that there's a bunch of stuff (like CVS repositories) that probably won't get saved like this; but you did take a backup first, right?
Windows users might also like to know about eclipsec , which isn't a compiler but rather a version of Eclipse that fires up a console window instead of hiding it away. Most of the time, running these with eclipsec is a good way of figuring out what's going on. Unix users can just use the eclipse one. For Mac users, there's a eclipse command you can access through Terminal instead of double-clicking the Eclipse.app .
So, you're through to the OSGi console. When it starts up, it will print out:
osgi>
From here, you can start to figure out what's going wrong. Typing '?' or 'help' will give you a list of available commands; if they scroll off the screen, type 'more' and you'll get paginated output.
Typing 'ss' (for ShortStatus) brings up a list of bundles that are available; they'll be in ACTIVE (running), RESOLVED (ready to run), STARTING (usually indicates a deadlock or stuck thread if you see that for any length of time) or INSTALLED. The last one is the one to look for; it means that the OSGi environment has found the bundle, but one or more of its dependencies haven't been met.
If you find a bundle in the INSTALLED state, you can use 'diag' (for DIAGnostics) to find out what's missing:
osgi> ss
Framework is launched.
id State Bundle
0 ACTIVE org.eclipse.osgi_3.3.0.v20070530
1 ACTIVE org.eclipse.equinox.common_3.3.0.v20070426
...
123 INSTALLED org.example.foo_1.0.0
...
osgi> diag 123
update@plugins/org.example.foo_1.0.0.jar [123]
Missing imported package org.example.bar_0.0.0.
Missing required bundle org.example.bar.core_0.0.0.
Quite often, if you've got an application that's not starting, it's because 'org.example.foo' defines the application; but the bundle can't start because it's got missing dependencies. The solution is therefore to resolve those dependencies (by installing a missing bundle or a bundle which exports the given package, and you should be away.
You can do this by restarting, or by dynamically adding it in via the console:
osgi> install http://www.eclipsezone.com/files/jsig/bundles/HelloWorld.jar
Bundle id is 456
osgi> start 456
Hello OSGi
You can also stop and start other bundles; once you've brought your dependencies in, you can restart the ones that failed before (e.g. start 123).
Occasionally, if the bundle is RESOLVED (i.e. all dependencies are met) but it still can't start (doing start 123 leads to an exception), then it implies the Bundle Activator's start() method has thrown an exception. That's basically either a programming or configuration error, outside the scope of this post. It's not always an error; for example, a plug-in that connects to a DB might (reasonably) be expected to have the property set via a command line property (e.g. -Ddatabase=foo) otherwise it won't work.
You can find out if there's a setting using 'getprop' in the console:
osgi> getprop osgi.nl
osgi.nl=en_UK
and even set it if it doesn't exist:
osgi> setprop database=foo
osgi> getprop database
database=foo
Of course, you can then do 'start 456' to see if the activator now works.
There's a bunch of other things you can do in the console; for example, if you wanted to see what application extension points were being contributed, you can do:
osgi> pt org.eclipse.core.runtime.applications
osgi> pt org.eclipse.core.runtime.applications
Extension point: org.eclipse.core.runtime.applications [from org.eclipse.equinox.app]
Extension(s):
-------------------
org.eclipse.ant.core.antRunner [from org.eclipse.ant.core]
...
org.eclipse.help.base.helpApplication [from org.eclipse.help.base]
...
You can also find out what extension points are contributed by a bundle:
osgi> ns org.eclipse.help
Extension point(s):
-------------------
org.eclipse.help.contentExtension [from org.eclipse.help]
org.eclipse.help.contentProducer [from org.eclipse.help]
org.eclipse.help.contexts [from org.eclipse.help]
org.eclipse.help.index [from org.eclipse.help]
org.eclipse.help.toc [from org.eclipse.help]
At least doing this will give you confidence that any extension points you've used will be contributed in the list somewhere. If not (or you have something like 'org.example.foo.org.example.foo.FooApp') then at least you can start debugging somewhere.
The last kind of error is more subtle to fix. If you see a message in the log like
The activator org.example.FooActivator for bundle org.example.foo is invalid , then this usually means there has been a ClassNotFoundException trying to load the class in the first place, before it's even got to the start() method.
CNFE is the bane of debugging; the only thing I can say is that it gets easier with practice. A key thing to understand is that if you have a class Foo, and that class references Bar as any kind of method parameter, return type or field type, then in order to load Foo, Bar must also be loaded. This is transitive, so if Bar needs to be loaded, then so does Flubber, and so on. Unfortuantely, when you hit a missing class, the actual class that can't be found is lost in the message and you just get back "Class Foo cannot be found", when clearly it can. Very often, the PDE will give you warnings when you're running into these problems at development time, but sometimes they can make their way past you and into a runtime bundle. Unfortunately, you have to go back to the code to figure it out.
In a bunch of cases, this has been caused by a developer adding a Jar to a Project's Java Build Path and not the OSGi Manifest dependencies. If you have (say) JUnit.jar added onto the build path, then the project will compile, but at run-time your activator will only consult the Bundle-ClassPath to find code. If it can't find JUnit.jar on that path, it will give up and give you the CNFE. The other possibility is that the Bundle-ClassPath either doesn't contain '.' (for classes in the bundle) or it does contain '.,JUnit.jar' but when exporting, the JUnit.jar is missing from the bundle itself. If it's the latter, check the entries in build.properties, and ensure that 'bin.includes=JUnit.jar' is in there. Very often, exporting the bundle and then opening it in WinZip will give you a clue as to what you expected to be in there (but wasn't) and/or consulting what the Bundle-ClassPath is in relation to the contents of the bundle itself.
So, whilst I don't think this will prevent any more questions being posted to the newsgroups in the future, at least it will be somewhere to point people to when they get stuck for reference. If you're experienced at debugging Eclipse startup problems and have any ideas that I've missed, please add comments to the below for the benefit of others. And if you find any glaring errors I've made, please add a comment so I can fix it :-)
I hope you've found this useful. Until next time
发表评论
-
RCP启动遇到org.osgi.framework.BundleException: The activator for bundle s invalid
2010-10-29 11:03 8543错误: !ENTRY org.eclipse.osgi 2 ... -
RCP中视图间的交互机制探讨
2009-11-23 11:12 2837来源:http://www.blogjava.net/ecli ... -
RCP中如何获取页面状态(最大/最小/restore)
2009-03-16 17:01 1770如下代码: IWorkbenchPage ipa ... -
在不用扩展点的情况下,RCP中设置view属性的方法
2008-12-31 11:21 2791在RCP中,想perspective新添一个view时,如果没 ... -
RCP中设置view和editor的tilte字体
2008-10-31 10:43 4639[align=left]我们在rcp的项目开发中,view和e ... -
在RCP中修改View的标题title
2008-09-26 11:25 4417在RCP中,用户自己定义的view都继承自org.eclips ... -
RCP中采用actionSet配置菜单的方法总结
2008-09-16 16:20 7920最近学习了下如何通过org.eclipse.ui.action ... -
RCP中的一些技巧 不断更新中……
2008-09-12 14:57 5930如果这些技巧对你们的开发有帮助,大家互相贡献啊 1.最大化窗口 ... -
RCP中采用配置perspectiveExtensions方式配置view的方法介绍
2008-09-12 14:33 5458在RCP中,view是张贴于per ... -
RCP中获得其他view或editor引用的方法
2008-08-22 15:15 3826每个view和editor都有一个ID,正是这个唯一标识他们的 ... -
RCP中view大小的设置
2008-08-20 13:42 5156其实一般情况下,在Perspective 中添加View的时候 ...
相关推荐
Eclipse Rich Client Platform (RCP) 的目标是在各种不是集成开发环境 (IDE) 的最终用户应用程序中使用 Eclipse。随着 Eclipse V3.1 的发布,创建 RCP 应用程序变得容易。本教程将指导您一步步创建自己的 RCP 应用...
将涉及以下内容:创建第一个RCP程序,创建菜单和工具栏,查看,编辑,对话,外部JAR的用法,向一个RCP应用程序产品中添加标志和帮助。每一章都基本独立于其他章节。欢迎访问我的网站——www.xeclipse.com。
利用SWT技术,基于WindowBuilder Eclipse 插件开发 桌面应用小程序详细步骤
eclipse icons,用来开发rcp桌面应用程序
开发你的第一个EclipseRCP应用程序汇编.pdf
内附有一个高校收费分析系统实例源码,用hibernate 与rcp结合使用,对初学者来说很实用的,特别是想了解如何在桌面程序使用jface,swt并与hibernate结合处理数据库使用方面很到位。
The objective of the Eclipse Rich Client Platform (RCP) is to enable Eclipse to be used in a wide range of end-user applications that are not integrated development environments (IDEs). With the ...
Eclipse打包Java应用程序及在Linux系统上的部署运行[归纳].pdf
《Eclipse RCP深入浅出》内容简介:Eclipse不只是一个单纯的流行IDE,其Rich Client Platform(RCP)插件几乎是所有桌面应用程序的坚实基础,从聊天应用程序到前端的企业级应用程序,不一而足。《Eclipse RCP深入浅...
的用法,向一个 RCP应用程序产品中添加标志和帮助。 每一章都基本独立于其他章节。 目录 1 富客户端平台 ......................................................................................................
基于Eclipse RCP的商务信息管理平台中加密模块的设计与实现,金星善,,RCP (Rich Client Platform) 是基于Eclipse开发平台而推出的一套用来开发富客户端程序的应用框架,其主要功能是能够为开发人员提供一个快速�...
所谓RCP,就是RichClientPlatform的缩写,即富客户平台,是Eclipse进化的产物(自3.0版以后出现),是Eclipse组织向用户提供的强大的开放性开发平台,能够使用户方便地创建自己的基于Eclipse的应用程序,并且这些...
Eclipse For RCP and RAP Developers开发包主要针对开发Eclipse插件,Eclipse RCP(富客户端应用程序),RAP(富客户端ajax应用程序)的程序员,还包含CVS、Mylyn和xml...我们使用这个Eclipse开发包来开发应用程序。
注意在过去的两年中,MONKEY WORKS GmbH被并入... 真诚的迈克尔·巴特BuildMonkey 使用gradle构建工件来创建Eclipse RCP应用程序。 您可以通过Gitter与我们联系: : 在此处找到文档: : 子项目Gradle工件部署程序简
2.6 应用程序的PLUGIN ID ................................................................................................................21 3 ACTIONS的用法(菜单栏和工具栏) ..............................
本书全面介绍了SWT、JFace和RCP的相关知识。全书共分5篇,第1篇介绍...本书结构清晰,注重实用,深入浅出,非常适合Eclipse开发人员学习使用,尤其适合SWT/JFace开发人员、Eclipse插件开发人员和RCP应用程序开发人员。
本书全面介绍了SWT、JFace和RCP的相关知识。全书共分5篇,第1篇介绍...本书结构清晰,注重实用,深入浅出,非常适合Eclipse开发人员学习使用,尤其适合SWT/JFace开发人员、Eclipse插件开发人员和RCP应用程序开发人员。
本书全面介绍了SWT、JFace和RCP的相关知识。全书共分5篇,第1篇介绍...本书结构清晰,注重实用,深入浅出,非常适合Eclipse开发人员学习使用,尤其适合SWT/JFace开发人员、Eclipse插件开发人员和RCP应用程序开发人员。
Eclipse RCP的扩展点与扩展机制研究,金星善,库少平,RCP (Rich Client Platform) 是基于Eclipse开发平台而推出的一套用来开发富客户端程序的应用框架。Eclipse的插件机制,使得我们可以通过扩展Ecli
一个用于Eclipse RCP应用程序(例如Virtual Satellite)的Maven Tycho演示项目。 项目状态 状态 用于开发构建。 状态 用于集成构建。 状态 为大师建造。 目的 该项目是使虚拟卫星开源的测试设置。 它有助于将软件...