I have some basic questions in eclipse plugin development, can anyone give clarification of the following questions,
When should we have to add features in our plugin development ?
What is the difference between feature and plugin.xml ?
Regards
Mathan
As mentioned in this thread:
A plugin is the eclipse "unit of work". An OSGi bundle that supplies a classpath and can contribute to eclipse through extensions.
A fragment points to a host plugin, and anything it provides (classpath, extensions, etc) are "sucked" into the host plugin. A fragment is also a more specialized OSGi bundle.
A feature represents a versioned collection of plugins, and is used for configuration management in eclipse. They can be deployed manually or through the update manager. If you want to deploy through the update manager, then you need to use features to represent your plugins.
So if you want to manage your plugin or plugins through the update manager, a feature is in order.
You can find more in the Eclipse Help:
Feature
Features do not contain any code.
They merely describe a set of plug-ins that provide the function for the feature and information about how to update it.
Features are packaged in a feature archive file and described using a feature manifest file, feature.xml.
Plugin
While features are organized for the purposes of distributing and updating products, plug-ins are organized to facilitate the development of the product function among the product team. The development team determines when to carve up program function into a separate plug-in.
Plug-ins are packaged in a plug-in archive file and described using a plug-in manifest file, plugin.xml.
Related
I am developing several little plugins for Eclipse. Each one having it's own name, view and icon.
I am now having them in separate projects and as I am reviewing my code, package structure etc. I asked myself: Is it possible to bundle them all in one project called (for example) Plugins or does each one has to have a separate project because of plugin.xml, manifest.mf etc.
I know, each plugin needs to have these files, but can there be more then one plugin in them?
Technically it is possible using bnd-tools way of plugin creation but not via PDE. But if you want you can migrate PDE plugins to bnd. If you are interested check http://bndtools.org/
I'm just starting to develop a new eclipse plugin where I want a web application server running in Eclipse. I found a nice blog, OSGi as a Web Application Server, that describes how to do this. The author suggests creating a target environment for my bundle requirements, and some of those bundles get pulled in from the Equinox Project SDK (now called Equinox Target Components in Juno). I notice that the tutorial project runs fine when my target platform is the platform I created in the tutorial, but fails to start when it is the default platform. So, now for my question...
If I need bundles that are not part of the default, how will my plugin project get access to those bundles? Will I need to deploy them along with my plugin? How would I know if the user's eclipse does or does not already have those required bundles?
You was not much clear about what kind of application you are developing. Running a web server in an Eclipse IDE as a plugin don't make any sense to me. This kind of server application is best just running on top of Equinox.
Anyway, the right path is to create a "Product Configuration" file and add categories that contains the needed bundles (go to File/Plug-in Development/Product Configuration).
With this file you can run an instance of the product (inside the IDE) and can export it (create a zip containing all needed bundles)
And if you want to able your user to install plugin inside his IDE you must create a P2 repository (using a Target Definition File) and expose the exported directory within a Http server. You could research about Tycho to build this kind of components in a maven style.
Well, I'm not sure if re-inventing the wheel again is really sufficient.
You might take a look at Pax-Web for inspiration on how to do it, or take a look Apache Karaf as a OSGi-Container (using Pax-Web). Or even better start contributing to one of the two :-)
IBM has this big 200+ Mb Eclipse plugin where I'm given access to everything and all functionality of Eclipse.
Is there a smaller more lightweight Eclipse plugin available that just gives access to the information a developer needs. Basically just a list of the workitems assigned to me or my team.
Yes, I can configure the big existing IBM plugin to just display that info, but then I'd still have this massive behemoth installed in my Eclipse.
I am aware of Tasktop Dev that allows me to import the workitems into my mylyn tasklist, but I'm looking for something cheaper.
No, because that plugin would have to manage work items and change sets (the list of versioned files), that is the planning and the source control part.
Plus you would need the EMF - GMF dependencies, part of the 200+ MB bundle, as described in "Tip: Installing the Rational Team Concert client into Eclipse 3.5.x".
Which is basically 75% of what the RTC plugin is (the rest being a link to the JBE: Jazz Build Engine).
I have an Eclipse Feature that I'm building that contains a few plugins. One of the plugins uses the import package statement to declare a dependency on another plugin.
The other plugin has platform specific code and exists in another feature that I'm building. I have two plugins in this feature that have the platform specific code. One for os=win32 arch=x86 and the other for os=win32 arch=x86_64
Both features are being built and using Tycho and they both have p2 repositories that are successfully available.
So, I made a composite repository that points to both of these repositories, and then I use the "Install New Software..." command in my RCP app and point to the composite repository to install the first feature I mentioned.
The issue is that when the installation is done, the plugin that has the platform specific code has failed to install correctly. Specifically, the plugin for the x86 system shows up on my 64bit machine.
In your feature.xml, choose the plugin with platform specific code and add a platform filter. the filters are available on the right side (once you select the plugin). You can choose filters such as:
OS
WS
Language
Architecture
When your feature is published, p2 will generate the appropriate filters.
I found the answer.
I needed a p2.inf file sitting next to my feature.xml file in the first feature I mentioned in the question.
And in that p2.inf file, I needed this text...
requires.1.namespace=org.eclipse.equinox.p2.iu
requires.1.name=com.myplatform.specfic.bundle.win32.x86
requires.1.filter=(&(osgi.os=win32) (osgi.arch=x86))
requires.1.namespace=org.eclipse.equinox.p2.iu
requires.1.name=com.myplatform.specfic.bundle.win32.x86_64
requires.1.filter=(&(osgi.os=win32) (osgi.arch=x86_64))
I added this file to the build.properties as well to make sure it was included in the deployed feature
Then when I deployed the p2 repository and performed the install into my RCP application, the correct plugin was placed onto my 64 bit machine.
UPDATE: I was wrong here. This is NOT the correct answer. The incorrect plugin still gets installed on some machines.
I have a plugin for an RCP app that uses BIRT. I have a target for building my app which contains only the plugins/features that are required. I recently updated the BIRT plugin versions in my IDE, which created an incompatibility in the design files with previous versions of BIRT. I have the old version of BIRT in my target and need to update to the newer plugins.
In the past I have manually updated plugin jars in the target, but BIRT is a complicated platform with dependencies out the wazoo. Is there any utility or way of organizing my target differently that will make this easier to control in the future?
I would recommend to keep all components separately and not copy them into a single folder. You can use Target Definition editor (see File / New / Other... / Target Definition). So, after downloading all the pieces, you can unpack them locally and assemble your Target Platform using Target Definition editor.
You can also do the same using Window / Preferences / Plugin Development / Target Platform preference page. There you can select previously created target definition or specify base Eclipse install and then use "Add..." button to add additional components from local folders or remote sites.
Also, as far as I know the PDE team is currently working on expanding Target platform support in Eclipse 3.5. I think they are planning to allow to select Target Definition per-launch configuration and per-project.
Im not sure if i understand you right, so please let me know if not.
When i use third party libraries, i create a plugin for every single one.
Example:
xstream library:
Import the jars (also the source code)
Add the jars to the MANIFEST
Bundle-ClassPath
Add all xtream packages to the
MANIFEST Export-Package
When a plugin needs the code of the xstream library it has to depend on the xtream plugin. Because the packages are public, every plugin can use the source code of it.
When a new version of xtream is comming, you only have to update the jars and not the dependend plugins. Sometimes you have to update the export packages of the third party plugin.
All depended plugins you dont have to change.