Community
Participate
Working Groups
Build Identifier: I20100608-0911 The problem arises when the plugin id is different from the project name. Follow the steps to reproduce: the path to file generate.emtl on the file system uses the project name (/something/org.eclipse.acceleo.module.sample/something/generate.emtl). Debugging the exception, the function resolveBundle() of BundleURLConverter class fails to find the bundle org.eclipse.acceleo.module.sample, extracted from the file path. In fact, the bundle name is now different because of step 3. Reproducible: Always Steps to Reproduce: 1. Create Acceleo project, using default settings 2. Add an invoke call in generate.mtl main template (example: [invoke('java.lang.String', 'toUpperCase()', Sequence{'foo'})/]) 3. Change plugin ID from org.eclipse.acceleo.module.sample to something else (change Bundle-SymbolicName in MANIFEST.MF) 4. Create Acceleo UI Launcher project for the previous project, using default settings 5. Change dependency to reflect the ID change of referenced project (change Require-Bundle in MANIFEST.MF, using the new ID given at 3.) 6. Run the UI as Eclipse application, create an ECore model with at least a class, right click on it, Acceleo Model to Text popup menu -> Generate Sample 7. NPE
Created attachment 173759 [details] Stack trace
Similarly, Acceleo fails if the invoke refers to a not-exported package. It would be helpful if Acceleo provided edit-time warnings of the validity of the invoke call.
Ed, could you raise a separate enhancement request for a warning on "non exported class invocation" ? We'll try and add all "warning" enhancements at once and this one might be lost :).
I think there are two sides to the same bug. In the absence of an edit-time warning you get the reported run-time error (that could be handled more elegantly.) The attached stacktrace is way down stream from the original error; the console log can be quite substantial.
Ed, Adding a warning for invokes on non exported classes is necessary, even when we fix the originally reported NPE. Thus I believe we need two bugs for this. Moreover, the originally reported NPE (or rather, the path to get to it) is extremelly tedious to solve; I have more than one point in the code with a "FIXME assume that bundle id is the same as the bundle name" since the Eclipse platform doesn't provide an easy lookup for bundles from their name. Not one that I know of at least. Adding the warning you mention is orders of magnitude easier and will be made earlier than the NPE fix.
Request for warning migrated to Bug 321525.
This has been fixed when we refactored the way service registration worked, and is functional in 3.6.4.
