Community
Participate
Working Groups
Need to separate dependency on org.eclipse.core.runtime bundle such that core Sapphire components do not depend on it.
Previous to any work on this bug, I could do something like this in one of my entities: @Image(path = PortletUIPlugin.PLUGIN_ID + "/icons/e16/finder_column_16x16.gif") public interface IFinderColumn .... Now these are throwing these exceptions: ERROR : error java.lang.IllegalArgumentException at org.eclipse.sapphire.modeling.ImageData.createFromClassLoader(ImageData.java:104) I guess there is a new way to support this, any tips on correcting? Do all images need to be in source folders and no longer in top level directories in the plugins?
> I guess there is a new way to support this, any tips on correcting? Do > all images need to be in source folders and no longer in top level directories > in the plugins? Images must now be found in the classloader that loaded the model element interface. Same thing in sdef file. You can no longer reference stuff from another bundle unless you do it the OSGi way via manifest. For quickest resolution, copy your icons directory into your src directory. If you wish to keep images separate, you can create a second source directory to hold them. As I've been working on this, I am starting to move away from the traditional structure of having a separate images directory in favor of placing images in the package structure along with Java code. The reason that co-location is beneficial is that images ride the same OSGi package import mechanics as classes, so that you can gain access to images defined in other bundles in the same way that you gain access to their classes. Same consideration for sdef files when re-using definitions across files. I used to prefer a top-level sdef folder in the bundle. No more.
I am splitting this work into two parts. The second part is Bug 345046 and is targeted to the 0.4 release. In short, the dependency has been separated from the modeling plugin, but the UI plugin needs more work. More info on changes... Three new bundles: org.eclipse.sapphire.osgi - OSGi specific API, such as BundleResourceStore. org.eclipse.sapphire.osgi.fragment - Enables discovery of Sapphire extensions in an OSGi environment. It scans bundles for META-INF/sapphire-extension.xml files. The default implementation looks for extensions in the class loader that Sapphire is loaded in. org.eclipse.sapphire.platform - Some API to make it easier to use Sapphire for building features for the Eclipse IDE. Most of the changes were related to breaking dependency on IStatus, IPath, IProgressMonitor and NLS classes from the Eclipse platform. Sapphire now has replacement classes in the modeling plugin for all of these. With exception of IStatus, the replacement classes are forked from Eclipse with minimal changes. They will likely evolve further in the future to better suit Sapphire needs, but they are largely unchanged from Eclipse versions at this point. For Status, I took the opportunity to completely re-think the API to make it simpler to use. StatusBridge, PathBridge and ProgressMonitorBridge classes allow back-n-forth conversion between Sapphire and Eclipse versions of these classes. The bridge classes are located in the org.eclipse.sapphire.platform plugin. I re-wrote Sapphire extension discovery logic to eliminate dependency on Eclipse extension system (plugin.xml). This allowed most of the Sapphire bundles to loose singleton requirements. In sdef files, the import directives had a dependency on OSGi. You specified which bundle to import before specifying packages and definitions. I changed the semantics of sdef imports to only import from the class loader that the sdef file is loaded from. In an OSGi environment, to import packages and definitions from another bundle, first import that package using standard OSGi facilities in MANIFES.MF. The sdef file can only see what the bundle sees. The above has an implication that images and sdef files must be on bundle classpath. It is no longer sufficient to binary-include these resources via build.properties file. As a further improvement, when referencing images in sdef file, the imported packages are consulted so that it is not necessary to specify full path from the root of the class loader. A similar change was necessary in the @Image annotation. Previously, the path attribute required bundle id as the first segment. That form is no longer supported. The path is treated as resource name resolvable in the annotated type's class loader. Similarly to the sdef file, it is possible to specify just the file name if the image is located in the same package as the annotated type. I updated the samples and other Sapphire plugins to align with the new recommended practice of placing images and sdef files alongside Java code in package tree. Updated the what's new document and the migration guide (see the section on modularity).
Verified the new bundles, samples and docs.
