Community
Participate
Working Groups
com.google.gwtorm doesn't have any dependency on com.google.protobuf and causes a failure at runtime because of that. Steps to reproduce: 1. In Preferences->Plug-in Development->Target Platform->Edit->Locations, add new location Orbit - http://download.eclipse.org/tools/orbit/downloads/drops/S20140917154621/repository/ 2. In the Orbit location, include ORM for Google Web Toolkit (GWT) 1.1.4.v201112241444 and click OK 3. Import the attached project from Comment 1 4. Open plugin.xml and in Overview->Testing click Launch an Eclipse Application 5. In the running Eclipse Application, click Window->Show View->Error Log 6. In the running Eclipse Application, press CTRL-6 or click the additional button on the tool-bar 7. An unhandled event loop exception is logged Tested with Eclipse SDK Version: Mars (4.5) Build id: N20141012-2000
Created attachment 247913 [details] Test Project
Created attachment 247930 [details] Smaller test case for org.antlr.runtime Here's a test case for a similar issue, this time in org.antlr.runtime. Same steps, except in step 2 include ANTLR Runtime 3.2.0.v201101311130 instead of ORM for GWT. Maybe I'm misunderstanding something about the nature of OSGi bundles and public APIs..?
Just to clarify, comment 2 is an issue with a completely different bundle? Is there a connection to original bug I don't see? If it is just a case that two bundles don't have complete "dependencies" specified, then it should be two bugs. That said, java 8 has a nice tool "jdeps" I think it's named, that with correct options, will show you packages required. (Previously, there are other open source tools do do such dependency analysis on "binary" code ... but ... just handy that it's "built in" to Java 8.). I mention this tool since, if I was going to debug, that'd be the first thing I would do, is to use that tool to see what else might be missing ... so if you have time ... it would help if you did that analysis. [In fact, just looked up a bug where I previously used it, see bug 426382 comment 26.] AND THEN, I've not looked, but one "key" to fixing is if the missing dependency is in Orbit already, or not. Such as is com.google.protobuf already in Orbit? If not, someone will need to open a CQ for it (first for project, then for Orbit) and then someone will need to add it. If is in Orbit, should be an easy fix? Can you attach a patch for MANIFEST.MF? Thanks for opening,
Chris, I see your named listed next to com.google.gwtorm ... and, com.google.protobuf ... so am assigning to you. If you can no longer be "contact/maintainer", Chris, please say so, and see if you can find someone else to be? Otherwise we'll assign to "nobody@eclipse.org" and ask for volunteers (either existing committers, or someone new -- who has a vested interest -- to become a committer). Thanks,
(In reply to comment #3) > Just to clarify, comment 2 is an issue with a completely different bundle? Is > there a connection to original bug I don't see? If it is just a case that two > bundles don't have complete "dependencies" specified, then it should be two > bugs. You're right, these should probably be separate bugs. I encountered the second one soon after the first and they are both similar so I wasn't sure I wasn't missing something. But I think the fixes for these are different: com.google.gwtorm should require com.google.protobuf but org.antlr.runtime should not contain the offending class DOTTreeGenerator. > That said, java 8 has a nice tool "jdeps" I think it's named, that with correct > options, will show you packages required. (Previously, there are other open > source tools do do such dependency analysis on "binary" code ... but ... just > handy that it's "built in" to Java 8.). I mention this tool since, if I was > going to debug, that'd be the first thing I would do, is to use that tool to see > what else might be missing ... so if you have time ... it would help if you did > that analysis. [In fact, just looked up a bug where I previously used it, see > bug 426382 comment 26.] I'm actually building these bundles from the latest source code using the Orbit bundles as models to imitate, so I first noticed these as compile-time errors. It was only later that I confirmed them as runtime issues with the original bundles as well.
