I am looking for extensions that implement a specific extension point, and am using the following acceptable method to do this:
IExtensionRegistry extensionRegistry = Platform.getExtensionRegistry();
if (extensionRegistry == null) {
return TEMPLATES;
}
IConfigurationElement[] config = extensionRegistry.getConfigurationElementsFor("com.ibm.im.launchpoint.templates.template");
I then would like to get the version of the defining bundle. I would use the following API, but the API for PluginVersionIdentifier is deprecated:
for (IConfigurationElement e : config) {
BlueprintTemplate template = new BlueprintTemplate();
IExtension declaringExtension = e.getDeclaringExtension();
PluginVersionIdentifier versionIdentifier = declaringExtension.getDeclaringPluginDescriptor().getVersionIdentifier();
I could not find an alternative in the new API - i.e. from a IConfigurationElement, how do I get the version id descriptor of the bundle. Obviously, from the Bundle I can get the version using the Bundle.getHeaders(), getting the Bundle-Version value - but how do I get the Bundle in the first place??? Platform.getBundle(bundleId) is not enough since I might have multiple versions of same bundle installed, and I need to know who I am. At the moment I have a chicken & egg situation, and the only solution I have is the above deprecated API.
All this information is based on Eclipse 3.6:
Your IContributor will be an instance of RegistryContributor if you are in the osgi environment which of course you are or you wouldn't be having this issue.
RegistryContributor gives you two methods: getID() and getActualID(). getID() may return the host bundle if this was loaded from a fragment. getActualID() always loads the id of the fragment/bundle the contributor represents. You can use this id in your BundleContext.getBundle(long id) method. Here is a snippet:
Bundle bundle;
if (contributor instanceof RegistryContributor) {
long id = Long.parseLong(((RegistryContributor) contributor).getActualId());
Bundle thisBundle = FrameworkUtil.getBundle(getClass());
bundle = thisBundle.getBundleContext().getBundle(id);
} else {
bundle = Platform.getBundle(contributor.getName());
}
I use a fall through method that will degrade gracefully to a non-version aware solution if IContributor gets a new default implementation in the future. The bundle id is unique to an instance of OSGi so it will load the correct version of the bundle.
I suggest browsing a bit the Javadoc deprecation descriptions, the replacement is documented. I found the following code, but did not test it.
String contributor = e.getDeclaringExtension().getContributor().getName();
Bundle bundle = Platform.getBundle(contributor);
Version versionInfo = bundle.getVersion();
Out of curiosity: why do you need to get the version of the extending plug-in? As far as I know, the goal of the extension point mechanism is to detach specific information about the extender, and only the information described in the extension (plugin.xml) or the referenced code is needed.
Related
ViewsPlugin.class is missing in this org.eclipse.ui.views_3.9.0.v20170226-1833.jar plugin.
Anyone know, Please give the suggest me. Any alternate option.
That class was internal, so it shouldn't have been used in other plugins in the first place.
It was removed in Bug 478242. See the Gerrit change there for details.
If you need the PLUGIN_ID (for whatever reason), you can use
FrameworkUtil.getBundle(ContentOutline.class).getBundleId();
// or use any other class from that bundle instead of `ContentOutline`
If you need the getAdapter utility method which was there earlier, use
Adapters.getAdapter(object, adapter, true);
as noted in Bug 478333.
If you need the replacement for getViewImageDescriptor, then use
private ImageDescriptor createImageDescriptor(String relativeIconPath)
{
String ICONS_PATH = "$nl$/icons/full/";//$NON-NLS-1$
Bundle bundle = FrameworkUtil.getBundle(ContentOutline.class);
ImageDescriptor imageDescriptor = AbstractUIPlugin.imageDescriptorFromPlugin(
String.valueOf(bundle.getBundleId()),
ICONS_PATH + relativeIconPath);
return imageDescriptor;
}
(taken from this changeset)
I'm in the midst of implementing Birt 4.6.0 into my gwt application. Unfortunately whenever I run a specific section of the program, I get the following error:
org.eclipse.birt.core.exception.BirtException:
error.CannotStartupOSGIPlatform at
org.eclipse.birt.core.framework.Platform.startup(Platform.java:81)
I've done some searching and one thread mentioned a permissions error but I am not sure what that entails. What does this mean?
EDIT Just read another article that suggests that it may be an issue with my classpath but I already added all the jar files from ReportEngine/lib to my buildpath. Anyone know what jar files I am supposed to include?
the offending code:
public static synchronized IReportEngine getBirtEngine(ServletContext sc) {
if (birtEngine == null) {
EngineConfig config = new EngineConfig();
java.util.HashMap map = config.getAppContext();;
map.put(EngineConstants.APPCONTEXT_CLASSLOADER_KEY, SegnalazioniDbManager.class.getClassLoader());
config.setAppContext(map);
IPlatformContext context = new PlatformServletContext(sc);
config.setPlatformContext(context);
try {
Platform.startup(config); //problem begins here
.....
}
[1]: http://developer.actuate.com/community/forum/index.php?/topic/20933-errorcannotstartuposgiplatform/
Yes it is indeed a permission error.
The relevant file is:
WEB-INF/platform/configuration/org.eclipse.osgi/.manager/.fileTableLock
You need to give access to the Birt user.
The SpringApplicationContextLoader assumes that the application is either using 100% XML or 100% Java config. This is because #ContextConfiguration allows either a list of classes or locations/value, not both. If any is specified, SpringApplicationContextLoader ignores the Application class that creates and starts the SpringApplication.
Trying to make Boot work with a 100% Groovy/no-XML pet project, I ran across the above issue. My Application class has #EnableAutoConfiguration and #ComponentScan annotations on it, the former required by Boot to set up a Web server. The later I had to keep because of SPR-11627. On the other hand, if I omitted the locations/value on #ContextConfiguration, dependencies weren't set up (duh!).
I give the code below along with a patch that I locally made to SpringApplicationContextLoader. If there's a better way, please let me know.
MovieDatabaseRESTClientIntegrationTest.groovy
RunWith(SpringJUnit4ClassRunner)
#ContextConfiguration(value = ['classpath:client-config.groovy', 'classpath:integ-test-config.groovy'],
loader = PatchedSpringApplicationContextLoader)
#SpringApplicationConfiguration(classes = MovieDatabaseApplication)
#WebAppConfiguration
#IntegrationTest
class MovieDatabaseRESTClientIntegrationTest {
MovieDatabaseApplication.groovy
#EnableAutoConfiguration
#ComponentScan
class MovieDatabaseApplication {
SpringApplicationContextLoader.java fix
private Set<Object> getSources(MergedContextConfiguration mergedConfig) {
Set<Object> sources = new LinkedHashSet<Object>();
sources.addAll(Arrays.asList(mergedConfig.getClasses()));
sources.addAll(Arrays.asList(mergedConfig.getLocations()));
/* The Spring application class may have annotations on it too. If such a class is declared on the test class,
* add it as a source too. */
SpringApplicationConfiguration springAppConfig = AnnotationUtils.findAnnotation(mergedConfig.getTestClass(),
SpringApplicationConfiguration.class);
if (springAppConfig != null) {
sources.addAll(Arrays.asList(springAppConfig.classes()));
}
if (sources.isEmpty()) {
throw new IllegalStateException(
"No configuration classes or locations found in #SpringApplicationConfiguration. "
+ "For default configuration detection to work you need Spring 4.0.3 or better (found "
+ SpringVersion.getVersion() + ").");
}
return sources;
}
Also posted on Spring forum.
I could be wrong but I don't think there is any support for beans{} configuration in #ContextConfiguration and #SpringContextConfiguration is just an extension of that. A feature request in JIRA would be appropriate. Also there has never been any support for mixed configuration format (as the entry point at least) - you always have to choose either XML or #Configuration, or else supply your own ContextLoader. You also shouldn't have both #ContextConfiguration and #SpringContextConfiguration on the same class (the behaviour is undefined).
In my RCP app, I would like to point a property (osgi.java.profile) to a file, and would prefer using paths relative to my installation and config dir.
Is there a definitive spec on what kind of variables are supported in config.ini?
#config.dir seems to be supported, there are references in the builtin, and it's always mentioned as typical example (e.g this SO answer )
However, looking at docs like Eclipse help/Runtime Options, it mentions a few "symbolic locations" like #user.home; however that seems fairly limited and doesn't include #config.dir.
Have even dug into org.eclipse.osgi sources as well, and found no references to this (I did find LocationManager and its hard coded variable substitutions for #user.dir & co).
Can I refer to arbitrary system properties there in some way?
Is this #config.dir a special case, only handled by P2? UPDATE: this seems to be the case.. looking at Eclipse SDK, About .. Configuration dialog shows #config.dir unresolved, probably taken literally by the Equinox..
Thanks for any hints.
I'm late to the party, but hopefully this will help others in the future.
Starting with Eclipse 3.8/4.2 (June 2012), you can substitute Java properties and environment variables into your config.ini file (Eclipse Bug 241192). The Equinox launcher does not support substitution in the eclipse.ini launcher file. The syntax uses dollar signs ($VARIABLE$) to indicate variable substitution:
osgi.configuration.area=$APPDATA$/MyCompany/MyProgram/configuration
osgi.user.area=$APPDATA$/MyCompany/MyProgram/user
osgi.instance.area=$APPDATA$/MyCompany/MyProgram/instance
I imagine you could use something like this for your purposes:
osgi.java.profile=$osgi.install.area$/path/to/profile.txt
You can use a platform URL (Platform URI scheme) to achieve this, i.e.
osgi.java.profile = platform:/config/java_profile.txt
in config.ini, would point to the file java_profile.txt in the current configuration directory.
You might also use existing system properties in config.ini:
osgi.java.profile = ${osgi.configuration.area}/java_profile.txt
From org.eclipse.core.runtime.adaptor.LocationManager, here are the special tokens:
// Data mode constants for user, configuration and data locations.
private static final String NONE = "#none"; //$NON-NLS-1$
private static final String NO_DEFAULT = "#noDefault"; //$NON-NLS-1$
private static final String USER_HOME = "#user.home"; //$NON-NLS-1$
private static final String USER_DIR = "#user.dir"; //$NON-NLS-1$
Why not use two system property variables?
One is named -Dmy.relativepath=filename, which is processed by your code of relative path of eclipse installation folder(workspace or anywhere), another is called -Dmy.path=absolutepath.
The system property is passed to the jvm, you need some tricky(translate the variable in runtime) in the native launcher(like eclipse.exe) if you wants to use variable in its value.
Look how osgi.java.profile is resolved in org.eclipse.osgi.framework.internal.core.Framework:
// check for the java profile property for a url
String propJavaProfile = FrameworkProperties.getProperty(Constants.OSGI_JAVA_PROFILE);
if (propJavaProfile != null)
try {
// we assume a URL
url = new URL(propJavaProfile);
} catch (MalformedURLException e1) {
// try using a relative path in the system bundle
url = findInSystemBundle(propJavaProfile);
}
That means osgi.java.profile must point either to a fully qualified URL, or to a relative path in system bundle (org.eclipse.osgi). This makes impossible usage of installation directory relative path without patching Eclipse.
I want to use the default XML editor (org.eclipse.wst.xml.ui) of Eclipse in an RCP application. I need to read the DOM of the xml file currently open. The plugin doesn't offer any extension point, so I'm trying to access the internal classes. I am aware that the I should not access the internal classes, but I don't have another option.
My approach is to create a fragment and an extension point to be able to read data from the plugin. I'm trying not to recompile the plugin, that's why I thought that a fragment was necessary. I just want to load it and extract the data at runtime.
So, my question is: is there another way to access the classes of a plugin? if yes, how?
Any tutorial, doc page or useful link for any of the methods is welcome.
Since nobody answered my question and I found the answer after long searches, I will post the answer for others to use if they bump into this problem.
To access a plugin at runtime you must create and extension point and an extension attached to it into the plugin that you are trying to access.
Adding classes to a plugin using a fragment is not recommended if you want to access those classes from outside of the plugin.
So, the best solution for this is to get the plugin source from the CVS Repository and make the modifications directly into the source of the plugin. Add extension points, extensions and the code for functionality.
Tutorials:
Getting the plugin from the CVS Repository:
http://www.eclipse.org/webtools/community/tutorials/DevelopingWTP/DevelopingWTP.html
Creating extensions and extension points and accessing them:
http://www.vogella.de/articles/EclipseExtensionPoint/article.html
http://www.eclipsezone.com/eclipse/forums/t97608.rhtml
I ended up extending XMLMultiPageEditorPart like this:
public class MultiPageEditor extends XMLMultiPageEditorPart implements
IResourceChangeListener {
#Override
public void resourceChanged(IResourceChangeEvent event) {
// TODO Auto-generated method stub
setActivePage(3);
}
public Document getDOM() {
int activePageIndex = getActivePage();
setActivePage(1);
StructuredTextEditor fTextEditor = (StructuredTextEditor) getSelectedPage();
IDocument document = fTextEditor.getDocumentProvider().getDocument(
fTextEditor.getEditorInput());
IStructuredModel model = StructuredModelManager.getModelManager()
.getExistingModelForRead(document);
Document modelDocument = null;
try {
if (model instanceof IDOMModel) {
// cast the structured model to a DOM Model
modelDocument = (Document) (((IDOMModel) model).getDocument());
}
} finally {
if (model != null) {
model.releaseFromRead();
}
}
setActivePage(activePageIndex);
return modelDocument;
}
}
This is not a clean implementation, but it gets the job done.