I have working plugin deployed.
Now i need to add catalog contribution to existing plugin for xml validation.
I have created fragment plugin for that.
Now i need to know
How do i publish the fragment?
Will there be two separate jar file generated for the plugin and placed at client side?
Do i need to take care for something important?
Creating a fragment doesn't take much more validation than creating a regular plugin. The only difference I can think of is that you'll have a "fragment.xml" instead of the usual "plugin.xml". A fragment will be deployed as a separate JAR that can be installed (fragments are by nature optional) by the client alongside its "host" plugin.
How the fragment is deployed in your client's Eclipse depends on how you deliver the regular plugin. If you provide them with an update site, you'll have to make sure that your fragment is included in a feature (if you look at the feature.xml, you should have something like this when including a fragment) :
<plugin
id="com.stackoverflow.plugin.id"
download-size="0"
install-size="0"
version="0.0.0"
fragment="true" <!-- this is the line of interest -->
unpack="false"/>
If you deploy the jars, when you select both the plugin and its fragment and use right-click > export > deployable plug-ins and fragments, you'll see that there is a jar for both.
That's it really, the build facilities of Eclipse take care of everything for you, whether you're deploying regular plug-ins or plug-in fragments.
Related
I need to turn Eclipse fragments into plug-ins. Haven't found any wizard to support this.
So I've created a plugin.xml and edited the MANIFEST.MF to look exactly like a plug-in project does. Still, Eclipse somehow detects it's not a plug-in: for example it asks for a Host-plugin.
Also checked .project file, nothing seems to indicate "fragmentness".
Why I need this:
Fragments were used for Unit-testing; but they're rather inconvenient: any modification in them triggers a chain of builds, and they block the exporting of individual plug-ins, unless their project is closed.
Solution
As Greg suggested it was the 'Fragment-Host:' option that did the trick. And as Rüdiger wrote; the project had to be closed/reopened for eclipse to acknowledge the change.
The fragment host is specified in the fragment's MANIFEST.MF:
Fragment-Host: host.plug.in
you will need to remove that.
However many fragments rely on code from their host plugin so it may not be possible to just convert the fragment.
I am working on a set of plugins and fragments on eclipse 4.3 (Kepler) but using the 3.x model.
One plugin contains part of the application model and has a fragment which contributes some model editors. (This seems right to me - tell me if it's unnecessarily complicated)
In the main app these editor contributions are not listed. I changed the fragment to a plugin and the editors became visible.
I could change the fragment to a plugin but this would mean that I have to expose more of the model.
I could move the fragment to the host plugin but this would mean mixing model and view (perhaps not a big deal)
Is it generally not possible to contribute from a fragment or have I done something wrong?
Here is the fragment:
<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.4"?>
<fragment>
<extension
point="org.eclipse.ui.editors">
<editor
class="com.acme.atf.device.ui.editors.NullConfigEditor"
default="false"
id="827299e9-6039-4a76-bfa6-08ef2d7f8724"
name="VariableEditor">
</editor>
<editor
class="com.acme.atf.device.ui.editors.SerialConfigEditor"
default="false"
id="cbaba4b2-8380-4ae5-9896-542cf97ca8cc"
name="SerialEditor">
</editor>
</extension>
Further information
The plugin hierarchy looks like this: (P=plugin, F=fragment)
com.acme.atf.app (P)
com.acme.atf.device (P)
com.acme.atf.device.help (F)
com.acme.atf.device.ui (F)
com.acme.atf.model (P)
com.acme.atf.core.ui (P)
An action in com.acme.atf.app attempts to load an editor (which happens to be in device.ui) which cannot be found. If I change device.uito a plugin then the editor is found.
Just managed to solve very similar problem with Eclipse 4.4.1. Unfortunately, the solution was to use clean workspace (I've imported my projects from Git).
Before that, I tried "playing" with version numbers of host and fragment, singleton flags, recreating fragment project, cleaning all projects and configuration of my RCP app. Also, I used OSGI console trying to get some additional info, but it reported only that:
Host plug-in org.aaa.bbb is in ACTIVE state (with no fragments)
Fragment bundle is in INSTALLED state (reporting "Unresolved requirement: Fragment-Host: org.aaa.bbb")
I think this is a bug and garbaged workspace (launch) configuration may be the cause. Hope this helps someone.
I think about using AspectJ in an existing project.
I have several pure Java Eclipse projects and I like to create an AOP project.
I'm not quite sure about when ajc is needed and when optional. We use Ant (with javac) as our main build and I would like to avoid changing the build.
Is the following possible:
I have a AspectJ enabled Eclipse and create my aspect project. I create a jar from this and include this jar with the aspectj jar in the normal eclipse workspace with the other projects.
The build includes my aspect jar and the aspectj jar as dependency jars with javac.
Is this enough for working with the aspects ?
Or do every project of the application needs to be compiled with ajc ?
The main goal is to keep the current structure of Eclipse setup and build environment as as much as possible as it is now.
Or is this only possible with the annotation style ? (if so can someone link me some information about the weaver and how to do this at runtime ?)
Thank you
If you want to weave your aspect into your codebase, you must use AJC. If you only use javac, even with the annotation, your code won't be weaved by your aspects.
That being said, you don't have to add a lot to your ant build.
something like that should do the job:
<path id="ajclasspath">
<path refid="classpath"/>
<pathelement location="${scm.home}/ant_libs/aspectjrt.jar"/>
</path>
<iajc inpath="${classes.dir}" destDir="${classes.dir}" fork="true" maxmem="${aspectj.maxmem}">
<argfiles refid="aspectj.argfiles.path"/>
<classpath refid="ajclasspath"/>
</iajc>
In fact, you just build like normal and you add a step with the iajc taking your output dir of the javac compile as the inpath and you put the result in the same directory.
You can also take a jar as input to iajc and produce a jar with all your stuff weaved inside.
Edit: Or you can use runtime weaving, if your app is a web application, it is not too bad. If not, i do not recommand runtime weaving, since each time you will start your app, it might be a lot longer to start. I don't have a lot of experience with runtime weaving, but you can check it out. I know you need a aop.xml to define your aspects.
Regards
I have a main plugin project which does not depend on any of Eclipse APIs. But I do want to use Eclipse API's in one of its fragment plug-in. Will it cause any problem for the main plugin?
If you add a dependency (to a plug-in or a package) in a fragment, then you effectively modify the class path of the host project as well. Whether that will cause any changes to the semantics of the host project or any other fragment for the same host project, depends on the specific use in the project.
Having said all that, the normal answer is: no, it should not cause problems, unless you have code that depends on the class path - e.g. if you are using Class.forName(...) or similar...
One final note: when you test this, use -clean argument in the launch configuration to force OSGi to accept the changed dependency. Otherwise, it will be ignored.
I currently have an existing plugin, which references a class from a required plugin. I have replaced this code with a reference to a class which is part of my fragment.
I am facing two issues.
If I import my fragment as a jar file, I am not able to see the changes I have made as the plugin running as an eclipse application results in a ClassNotFoundException
To overcome this, I link an additional source (of fragment) to the existing plugin project. However, the link uses an absolute path, and makes it unfit for deployment.
I want to be able to package the plugin with the code modification and be able to "depend" on my fragment code. Is there a way I can add my fragment as a dependency?
For example:
Plugin Project I am changing : org.eclipse.*.editor
it depends on org.eclipse.*.edit
I have a fragment mydomain.*.edit which has org.eclipse.*.edit as host plugin
I want org.eclipse.*.editor to pick up mydomain.*.edit
instead of org.eclipse.*.edit
ps: I have also tried packaging the jar file for the mydomain.*.edit in the plugins directory and try and pick it up from there, it doesnt show up on the list when I click add required plugins on the dependency tab on the plugin.xml file of the org.eclipse.*.editor
Please let me know if I am not clear enough, I will try and rephrase it.
Thanks in advance!
If I understand correctly what you want to do, I don't think that it's possible. You will have to try some other way.
Plugins have dependencies on other plugins. Fragments don't exist as separate runtime entities, but only as extensions of a plugin. So your plugin can only refer to the 'editor' plugin.
Classes provided by a fragment can't (and shouldn't) be accessed directly. They can be returned by the original plugin (A) if they are implementing an executable extension provided by plugin A.
If you refer to the fragment's code from another plugin (B), the classes will be loaded by plugin B's classloader and be different from the ones that are loaded by plugin A.
What is the purpose of your fragment? Do you want to get access to internal code in plugin A? Do you want to extend an eclipse editor?
If you want to extend functionality that the original plugin is not exposing as extensible, I think the only way is to write a plugin, extend the editor class from the original plugin, register it alongside the original one and use it instead.
[Edit] Maybe this link will explain better: Eclipse FAQ
Hope this helps,
Vlad
Thanks Vlad,
Your explanation was very helpful. Unlike the extension based architecture that is truly intended for fragments, I had to modify a certain component in the editor that was not exposed as part of the extension. This modification referred to an external project I created as an fragment but could have been a normal java project packaged a jar file that I could place in the classpath of the editor.
I was able to resolve the dependency issues by placing the jar file in class path, however when I export the plugins and related plugins as jar files and place it in the dropin directory, it does not install correctly. (Nor does placing the jar files in the plugins directory)
The eclipse editor that I am trying to modify uses the EMF project. I have kept the EMF project in the workspace inorder to resolve dependencies of the editor. However when I replace the EMF jar files bundled with eclipse with the one in the workspace, the files that I want to edit are not correctly recognized.
Is there another way of doing this?