Community
Participate
Working Groups
Committeers builds wtp-M-1.5.1-200608300436.zip (no errors) and wtp-M-1.5.1-200608302118.zip (one failed unit test) do not allow the creation of any WTP project types aside a static web project. No errors in the log, the preferences dialog looks normal (all WTP related items are available).
I just tried with the wtp-sdk-M-1.5.1-200608311445 build... about to pass the smoke test....
Hi Chuck, you used the SDK build, which makes the difference. I just checked again: wtp-M-1.5.1-200608312130.zip (most recent build) => does not work (no errors/warnings) ! wtp-sdk-M-1.5.1-200608311445.zip => Works ! (1 unit test error) So the non-SDK builds are broken.
Created attachment 49244 [details] "New project" wizard from non-sdk-build
CCing you David... do you have any ideas? whats missing?
Beats me ... but perhaps one of us can do a "diff", or your developers test a non-SDK build?
I'm even more confused, because wtp-sdk-M-1.5.1-200608312130.zip does not work either (yes, the SDK build !). To avoid confusion: I always tried it with a blank eclipse installation with a new workspace. Involved files are (all official releases from the final Callisto release) : eclipse-SDK-3.2-win32.zip emf-sdo-runtime-2.2.0.zip GEF-runtime-3.2.zip VE-runtime-1.2.zip xsd-runtime-2.2.0.zip I did probably more than 30 WTP installations over the months (including the 1.5.0 installation with the files above), so I would exclude an error of mine.
That explains it.... We require a new base for these maintensance releases... For instance, the following drivers with this build: # The Eclipse driver used in this build is eclipse-SDK-M20060830-0800-linux-gtk.tar.gz. You can find a suitable driver for your platform at here # The EMF driver used in this build is emf-sdo-xsd-SDK-M200608241248.zip # The GEF driver used in this build is GEF-SDK-3.2.zip # Java EMF Model Runtime driver used in this build is JEM-SDK-M20060825.zip Please reopen if you still see a problem with these versions
OK, this did the trick. I used eclipse-SDK-M20060830-0800-win32.zip. All the other required plugins (EMF, GEF, VE) work with their initial Callisto release versions. Isn't there a kind of "contract" that there should be no API changes beetween eclipse maintenance releases (3.2.0 to 3.2.1), so that WTP 1.5.0 should run with all 3.2.0 releases, and WTP 1.5.1 should run with all 3.2.0 releases ?
Chuck, Wolfgang make a good point that's definitely the goal and ideal. Wolfgang, since we are not purely API clean yet, we may not always be able to achieve this. And, ... while there might be times we could not maintain "workability" with downlevel pre-reqs, there should be enough constraints in place there'd at least be an error message in the log ... Wolfgang, did you check your log for messages ... about unsatisfied constraints?
I completely agree this should be the goal, but we did need to react to a few "internal" api references this release, and we did add this new lower bound constraint - actually I wonder if this is what happened.... the new constraint might have prevented the startup of several bundles.... We added this constraint: org.eclipse.ui.workbench;bundle-version="[3.2.1,4.0.0)" to our org.eclipse.jst.j2ee.ui plugin MANIFEST.
Created attachment 49435 [details] Configuration Details of wtp-M-1.5.1-200608302118 About comment #9: There is no .log file. Attached is the content of the "Configuration Details" dialog. Maybe this helps finding out what went wrong. If I understand comment #10 correctly the next releases will at least provide an error message about a mismatching eclipse version ?
I reopen it because I think that there should be an error message in the log file, or better a message box "Not fulfilled plugin requirements: xyz needs Eclipse 3.2.1, found 3.2.0". This version validation is probably an Eclipse issue ?
I'll send this over to the platform, but there already is a message in the log file for missing bundle entry if the versions don't match, and if you launch the target you can specify "validate plugin dependencies" and a dialog will show, if problems exist....
I don't see what we can do. It seems that you got a message in the log and the configuration detail shows that some bundles are only "installed" whereas they should be "resolved" or "started", which should be enough to help you figure out what is going on.
Nope, there is NO message in the log (even after trying to open the "new project" dialog where the features are missing). Digging around in more than 70KB of plugin configuration info is not the best way to find out that something is missing (especially if there is no hint THAT something is missing). I placed my installed eclipse here: http://helpdesk.hg-online.de/Eclipse31WTP151M.zip Maybe someone wants to try it out with the same files I have. Original files are the same as in comment #6, WTP is "wtp-M-1.5.1-200609110428.zip".
I think I know maybe whats happening in cases like this, and can see why it might lead to trouble and confusion. The unsatisfied constraint error message is printed ... once! but, then not again, unless "-clean" is specified. So, perhaps Wolfgang, in his efforts to get things working may have deleted, or "over ran" is normal workspace log. In which case, no one would see the message again, unless -clean was specified. Not sure what the right answer is ... would be nice if this was "easier to use", but ... not sure we should ~always~ print out missing constraints (would make start up more expensive, I'd guess, to always check everything each time). Perhaps an extra button on configuration dialog/screen to say "recheck constraints" or similar.
And ... two more points ... I am surprised if I go to "help, manage configuration" the tree of features actually looks ok ... no, red X's where I expected them. Guess its just showing features? Not plugins? And, second, Pascal, "...the configuration detail shows that some bundles are only "installed" whereas they should be "resolved" or "started", which should be enough to help you figure out what is going on." I'm not sure even ~I~ could have figured that out ... if you hadn't told me :) [for what that's worth].
For comment #16: I never reuse my workspace (always delete the directory) when I try out a new eclipse installation. So I should have seen something in the log. "eclipse.exe -clean" does not bring up error messages, too. Could anybody try out my eclipse installation (comment #15) and take a look wether any error message is found ? This is probably the easiest way to quickly clear the big confusion ;-). If this brings up the expected error message I will think about doing nasty things to my computer...
(In reply to comment #18) Well, be gentle with that computer :) I did try your test case, and immediately saw the error in the log: !ENTRY org.eclipse.osgi 2 0 2006-09-12 01:44:50.781 !MESSAGE One or more bundles are not resolved because the following root constraints are not resolved: !SUBENTRY 1 org.eclipse.osgi 2 0 2006-09-12 01:44:50.781 !MESSAGE Bundle update@plugins/org.eclipse.jst.j2ee.ui_1.1.0.v200609102340.jar was not resolved. !SUBENTRY 2 org.eclipse.jst.j2ee.ui 2 0 2006-09-12 01:44:50.781 !MESSAGE Missing required bundle org.eclipse.ui.workbench_[3.2.1,4.0.0).
(ten tests later) No more error message. You mean WORKSPACE\.metadata\.log, don't you ? I even tried it at another machine with no recent eclipse and a new workspace, and there was no message, too. Does eclipse write the "first plugin version message shown" information to any directory other than the workspace ? By the way, I uploaded my zipped eclipse from comment #15 one more time because the zip file seems to have gone broken. Did you try it with this file or with a custom installation ? Does the parameter "eclipse.ee.install.verify" from "config.ini" interfer with my problem ? I found that in "Help" - "About Eclipse SDK" - "Configuration Details" this parameter is always "false", even if I start it with "-clean" or with a blank workspace. I switched it to "true" by setting it in config.ini, but this did not bring up any validation errors either.
Debugging resolution problems is always hard. it is very strange that the messages are not being logged. At least the first time. For future reference, running with -console and typing "ss" will show you all known bundles and their state. For any bundle that is not resovled or active, type "diag ##" where ## is the bundle's number. This will tell you why the bundle is not resolved. Follow that trial until you find the actual problem. I wrote a little utility a while ago (it may be on StateHelper or some such) that did this searching for you and basically showed just the dead-ends. Perhaps that should be itegrated into the console. another suggestion here is to have the About -> Configuration Details show any problems wrt unresolved plugins.
Created attachment 50010 [details] Output of "ss" command in console Attached is the output of "ss" command after starting eclipse with "-console". I took it while the workspace selection dialog was waiting for my input. Line 125 is interesting: 124 INSTALLED org.eclipse.jst.j2ee.ui_1.1.0.v200609102340 Installed but not resolved. Are version conflicts checked and logged before or after selecting the workspace ?
Output of "dialog ###": osgi> diag 124 update@plugins/org.eclipse.jst.j2ee.ui_1.1.0.v200609102340.jar [124] Missing required bundle org.eclipse.ui.workbench_[3.2.1,4.0.0).
Jeff, the "diag" command uses the StateHelper methods you mention. We only log unresolved bundles in the following cases: - if you use -debug or -dev and the state timestamp has not changed (-clean forces this) - if an error occurs starting the application. Wolfgang, run with the -debug -clean options to see if the resolution errors are logged. +1 on the recommendation to add the unresolved bundles information to the configuration data. I can provide a patch if someone points me to the code that gathers the information.
(In reply to comment #23) > Output of "dialog ###": > osgi> diag 124 > update@plugins/org.eclipse.jst.j2ee.ui_1.1.0.v200609102340.jar [124] > Missing required bundle org.eclipse.ui.workbench_[3.2.1,4.0.0). Just noticed this message. From you previous posting of the "ss" command you have org.eclipse.ui.workbench_3.2.0.I20060605-1400 installed but org.eclipse.jst.j2ee.ui_1.1.0.v200609102340.jar requires version 3.2.1. Is that correct? It looks like you either did not get 3.2.1 platform installed or we have a version mismatch in org.eclipse.jst.j2ee.ui_1.1.0.v200609102340.jar
I have just tested the following configuration: - WTP-SDK-1.5.1-200609071217 - VE-SDK-M20060825 - XSD-SDK-M200609071016 - EMF-SDO-SDK-M20060609071016 - GEF-SDK-3.2.zip - Eclipse SDK M20060912-1730 and the org.eclipse.jst.j2ee.ui plug-in resolves. I'm closing as the problem was likely caused by range problem.
Created attachment 50033 [details] Logfile of "eclipse.exe -clean -debug"
Sorry to reopen the bug once again, but I feel misunderstood ;-). The original bug report is resolved because I know that a newer Eclipse than 3.2.0 will work. BUT I had no chance to find out why the combination of 3.2.0 and WTP 1.5.1M did not work ! No error message in the log (this was up to now the only place I knew about where problems are reported). How does a eclipse user find out that some plugin cannot be resolved ? He/She will probably not look at the "Help" - "About Eclipse SDK" - "Configuration Details" dialog and scroll through pages of plugin information and he/she will not know that "Installed" does not mean "Resolved". PLEASE log the information about non-resolved plugins at first eclipse startup, because this is a really critical problem (at least if you do not use an update server).
Logging each startup is not the solution here. The SDK is shipped with bundles a required execution environment of J2SE-1.5. These bundles will not be resolved on 1.4 VMs, that is fine it just means some functionality is not available. Logging these resolution messages each startup will fill the log with unwanted information. Seems like the configuration details is the correct place to show this information.
What stands against logging the bundles on first startup and if the "-clean" option is set ? "-clean" seems to be quite well-known commandline switch (even I knew it ;-) ).
Changing summary to make more sense.
*** Bug 163190 has been marked as a duplicate of this bug. ***
Summary: 1). The original problem was fixed. 2). The user would like unresolved bundle messages printed out every time Eclipse starts. This will not happen. We already log the message the first time Eclipse starts as well as when you clean your configuration area (-config) As Tom mentions in comment #29 some of these unresolved messages are ok.
As I wrote in comment #28, there is NO, NO, NO error message on first eclipse startup with a new workspace and a new eclipse "installation" (unzipped) ! So "We already log the message the first time Eclipse starts" in comment #30 is actually wrong. Please verify it with the old eclipe bundle I provide in comment #15. "eclipse -config" does not show an error message either, only "eclipse -debug -clean", which is probably unknown to most users. I think it is not a good solution that even on first eclipse startup there is no log output about unfulfilled constraints ! When you close the bug the next time I will give up about it ;-)
Changing summary to reflect user's real issue. Old Summary: No easy-to-spot warning if minimal bundle constraints not met Talked to Tom about this and there is code in EclipseStarter#startup which does the check. We should reconsider the "only log if in debug or dev mode" option. See also bug 127084 and its duplicates.
*** Bug 174515 has been marked as a duplicate of this bug. ***
There are many legitimate cases where one has bundles installed that do not resolve. In previous times we got beat up by people saying that they didn't want to see all these messages in the log if things were really ok. We have no real way of telling the difference so we turned the messages off unless we could tell that you wanted this kind of info. for exampel if you were running in -debug mode. We feel damned if we do and damned if we don't...
(In reply to comment #37) > There are many legitimate cases where one has bundles installed that do not > resolve. In previous times we got beat up by people saying that they didn't > want to see all these messages in the log if things were really ok. We have no > real way of telling the difference so we turned the messages off unless we > could tell that you wanted this kind of info. for exampel if you were running > in -debug mode. We feel damned if we do and damned if we don't... That is an understandable dilemma. Seems to me like it could be resolved by defining multiple levels of "required" for bundles. In other words, have a "critical" requirement and an "optional" requirement. Log the criticals all the time (actually, I'd say notify the user visibly about them, see Bug 174515) and only the "optionals" during -debug. IS that feasible to implement?
the challenge is that there are whole subgraphs of the dependency graph that may be orphaned and that may or may not be ok. We already have optional and strong (i.e. normal) dependencies. But in a loosely coupled system you may have chunks that are not related by any explicit dependency. One easy example is SWT. It has a set of fragments specific to various platforms. on linux it is reasonable for people to have both GTK and Motif installed since it is in the end a user choice for how to run. In either case one of them is going to be unresolved but that is ok.
Suggestion: -Log optional bundles only if "-clean -debug" is set. -Log required bundles on first startup and on "-clean". Probably the GTK/Motif bundle would need a constraint which says "need one of GTK or Motif", if none is present this would be an error and logged on first startup. If only one is present this would be just a informational message logged with "-clean -debug". Same for the Java dependencies: Java 1.5 is an optional constraint => log unresolved only with "-debug" But any plugin which cannot be resolved and which does not define an "optional" constraint should be logged as "error" on first startup or "-clean". Does this suggestion make sense to you ?
We are not going to make everyone happy here. Jeff sparked my memory in comment 37. There are many cases where it is expected that bundles will not be resolved. The challenge is the framework does not (and cannot) know what is really "optional" for a running product. One simple example is the apt support in jdt when running on JavaSE-1.6. They have three bundles that have a required EE of JavaSE-1.6. When running on JavaSE-1.5 or less these 3 bundles will be unresolved. For the SDK product this is fine, every thing functions fine but some of the extra functionality for apt is not available. If we start logging errors in this case then it will become a problem. The challege is at the framework level we have no idea if these 3 bundles are critical to the functionality of the product. The only time we have any clue is if the application failed to launch. In this case we *do* log unresolved errors without the -debug option because that may have something to do with why the application failed to launch. IMO logging unresolved errors will lead to more invalid bug reports opened against us because we have no idea wheather the unresolved bundle is expected or not.
We cannot automatically log resolution errors to the log because there are too many cases where unresolved bundles are valid and should not cause an error log. Doing so would make many people unhappy. The Equinox team discussed this at length and did not see anything we could do at the log level. We think it could be useful if resolution information was somehow displayed on the plugin details page in the about dialog.
Wolfgang would you be able to provide a patch for the UI part (AboutPluginsDialog in org.eclipse.ui.workbench)? We could help you with the core part to get the diagnostic.
Me ? Sorry, I'm not a eclipse developer, just a user complaining about everything ;-)
*** Bug 177342 has been marked as a duplicate of this bug. ***
(In reply to comment #43) > Wolfgang would you be able to provide a patch for the UI part > (AboutPluginsDialog in org.eclipse.ui.workbench)? We could help you with the > core part to get the diagnostic. > I would be willing to help on this one. If I understand correctly , this is only about displaying the current bundle status in the plugin details dialog ?
Yes. I'm not a UI guy so take my suggestions with a grain of salt. Maybe a new resolution column could be added to show resolution status, similar to the signed column. Then a new button could be added to show resolution info. Or maybe the existing "Show Signing Info" button could be generalized to show both the signing info and resolution info. When a bundle is unresolved you would show the details of the resolver errors that caused it to be unresolved.
Created attachment 63040 [details] patch to display state of installed bundles This is my take at adding a column to the "plugins details..." dialog in order to display the current state of each plugin. also added a button to display non ready plugins as this bug is all about diagnostic. This new button will allow the display of non ready plugins (eg: installed)
Now, I would also like to display why a bundle is not in a ready state (a la -console diag) but to be able to report that, it looks like I need to duplicate some code from org.eclipse.core.runtime.internal.adaptor.EclipseCommandProvider, since everything is in an internal package. which doesn't seem like a particularly good idea. Is there a way to programmatically call the osgi console, launch a diag XXX and get the result back ? Or may be an OSGI service that would provide this kind of information (a la org.eclipse.osgi.service.resolver.PlatformAdmin) ?
Patrick: Thanks for the patch! It looks good but I do have one concern. Elsewhere in the UI (when filtering by activities or in the keys preference page, for instance) when we filter by some criteria we typically add a checkbox that (if enabled) adds the missing content back into the UI rather than a button that toggles two sets of input. If you have time could you update the patch to have that behavior? If you dont have the time I understand - I'll try and get to it early next week myself. Thanks again!
Patrick thank you for your help. There is no way to programmatically invoke the command of the console. The logic would have to be duplicated.
Created attachment 63161 [details] patch to display state of plugins + diagnostic take 2. implemented the checkBox to add the installed plugin (instead of toggling content) as suggested by Kim. As I was at it, I also implemented an almost complete filter on the list of plugin, by provider, name, version and/or id. Quite useful when you have 100+ plugins. I can probably refine the filter with - signed status (but the order by does a fine job at it, since it's a on/off state) - individual status (but do we really care ?) for me the main use case of this screen is when something doesn't work properly, with the provided filter it's very easy to isolate what you are looking for. I also duplicated the logic of the diag command to get a diagnostic as indicated by Pascal. this is displayed in a tray, a la signing info.
reassigning remaining [About] bugs according to 2009 platform-ui triage guidelines
If anybody's interested in updating this patch, I'd be willing to push it into Kepler. PW
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the stalebug whiteboard tag.
Closing this, as it is old and the original issue is probably not reproduceable after 13 years.
