Several teams in our company use internal framework to build an Eclipse UI. This framework is composed of set of Eclipse plugins.
Our team is responsible for the develpment of this framework and we're looking for some tools that would check API breakage in the further versions of our framework.
For example, we have the following class:
package com.foo.A;
class A {
public void doSmth() {}
}
Currently in MANIFEST we and users of our plugins do not specify any versions of plugin's dependencies (always complining with the latest version).
We'd like to have some warnings from Eclipse if we change something in this class, e.g. change method signature or something else. We'd like Eclipse to suggest us to rise plugin's version in such cases.
I've read the following information about API tooling in Eclipse:
https://wiki.eclipse.org/PDE/API_Tools/User_Guide
But it seems to me that this tooling works only with Eclipse native plugins, but not with our custom developed ones.
If I'm mistaken, could anyone be so kind to explain me how to setup API tooling for our plugins?
the Eclipse API tooling works also with user bundles. What you should do is take your released framework and define it as baseline. A quick solution is to copy all your build and released to the public bundles in a folder and set the folder as Baseline:
Window - Preferences - Plug-in Development - API Baselines - [Add Baseline...]
You can have multiple Baselines if you have to patch older release versions of the framework for example. Be sure to set your API Errors/Warnings as you reqire them.
Edit: Of course you should enable API Tooling in all your bundles as described in "Configure Bundles for API Tooling" in the web page you linked!
Related
My ultimate goal is Invoking Eclipse plugin from Java. I see that an Eclipse plugin registers a class as Bundle-Activator in MANIFEST.MF. The start(BundleContext context) method will be called on this class. Where does this call come from?
Eclipse is made up of many repos that are mostly mirrored on GitHub. Some are deprecated and point to other repos. And it's a programming IDE and an OSGi framework at the same time? I find it hard to find the code for this core part of the framework that handles plugin loading. Where is it?
The project to interact with OSGi bundles is Eclipse Equinox. It is an implementation of the OSGi framework. You start equinox and load the bundle jar from there instead of putting them into the regular classpath.
Here you find some information how to do this in general:
http://njbartlett.github.io/2011/07/03/embedding-osgi.html
You can then interact with the bundles from you plain java application. This is not an easy thing though.
What makes things even more complex is that Eclipse is not plain OSGi. Eclipse predates OSGi and many of the concepts are still not fully adapted to plain OSGi.
So using eclipse plugins from a plain java application may be very hard.
I recommend to ask on the mailing list of the plugin you want to use if there is experience with using it outside eclipse.
I am following hello world application of Amazon Web Services Simple Workflow Service. According to description #Activities annotation should have been able to generate two classes GreeterActivitiesClient and GreeterActivitiesClientImpl. But these classes has not been generated.
I have Enable annotation processing in project properties. I am using Eclipse Mars with Jdk 1.8. I have also installed AWS toolkit for eclipse, aspectj.
Can someone see where the problem is?
Some versions of Eclipse, (notably Mars and Neon), may fail to fetch the latest artifacts due to a bug in old versions of the Oomph plugin. To work around this issue:
Make sure that you’re using https://aws.amazon.com/eclipse/site.xml as the AWS Toolkit for Eclipse update site.
Delete the ~/.eclipse/org.eclipse.oomph.p2/cache/ directory to remove cached content.
Install the latest version of Oomph (Eclipse Installer).
Reference: Set up the Toolkit
I've been beating my head against a wall for about 6 months now and have not found a concise way of understanding the mechanism for developing an eclipse plugin with third-party resources.
We are attempting to develop an Eclipse ODA to ride on top of in-house Spring-based code that accesses a REST based info set.
In broad strokes - this is what I feel that we need to be able to do:
Augment our maven artifacts with Eclipse bundle information using tycho or a the felix bundle plugin.
Set up a plugin project through Eclipse for the ODA Implementation & UI.
Have Tycho generate the poms etc for the plugin.
Now here's where I get muddy. I understand that there are two approaches
Manifest-First - which is the standard mechanism for defining a plugin's dependencies
POM-First - which provides dependencies via Maven's resolution mechanisms.
I'm not entirely sure where to begin trying to start doing this as I've never worked on developing an eclipse plugin.
One of the other questions I have is, how does a developer of an eclipse plugin (maven aside) leverage already existing third-party code (i.e. Apache HttpClient 4.x)? Do they have to download the jars, dump them into a directory within the project, add to classpath, then go from there or is there a "repository" mechanism similar to what is used with ivy, maven, gradle?
Thanks in advance and I apologize if I was rambling a bit with that.
Disclaimer: Your question is very broad, so it is impossible to answer it completely. Still, I can give you some hints so that you know what to search for.
In the Eclipse universe, the primary source for libraries (in the sense of binary dependencies) are p2 repositories. However, since p2 repositories are rarely used outside of the Eclipse context, you won't e.g. find a p2 repository on the Apache HTTP Client project's download page.
To account for this problem, there is the Eclipse Orbit Project which provides libraries used by Eclipse projects in p2 repositories.
If you can't find the library or library version in the Eclipse Orbit, you may also be able to use the libraries from Maven repositories. This is for example supported by Tycho via the pomDependencies=consider mechanism.
Note however that Eclipse plug-ins can only depend on libraries which are OSGi bundles. So if the library in the Maven repository is not yet an OSGi bundle, you need to convert it to an OSGi bundle first, e.g. with the maven-bundle-plugin and the Embed-Dependency mechanism.
The best way for an Eclipse plugin to consume libraries is as OSGi bundles. You just install those bundles into your target platform and reference them in the same way as eclipse.org plugins. Some of the library providers already offer their libraries as OSGi bundles. Absent that, you can typically turn a plain library jar into an OSGi bundle simply by adding a few manifest entries.
Depending on the build system you use and whether the libraries you need are available as OSGi bundles packaged into an online p2 repository, you can reference the URL and rely on your build to download and install the bundle.
If question of choosing a build system for Eclipse plugins with dependencies is still relevant:
Today I released new gradle plugin: Wuff version 0.0.1, which (I think) completely solves the problem. It allows to build Eclipse bundles and applications as they would be "normal" Gradle projects. All OSGi woodoo is auto-generated (although customizable). All dependencies are usual maven dependencies - regardless of whether dependency is OSGi or "normal" library.
Sources and doc: https://github.com/akhikhl/wuff
Pro edition of Nexus shows the dependencies for an artifact...
Want to do the same in the Community edition. Doesn't look like the standard REST API:
https://repository.sonatype.org/nexus-core-documentation-plugin/core/docs/data_ns0.html
supplies a service for dependencies. Have googled for examples on creating plugins (not too charged about the Nexus documentation on plugins right now) and toying with the idea of creating a plugin (a REST based) that pulls out dependencies per artifact. Ideas?
From what I know Nexus basically downloads the pom.xml of the project you are interested and runs the list or tree goals of the maven dependency plugin and then just displays the results nicely.
You could of course do the same in your own custom plugin. You can also use the Aether API and others directly to do the dependency resolution in your plugin and not call the plugin externally and then show the results.. in fact Nexus might just be doing that.
Realistically writing this yourself that sounds like reinventing the wheel and I would just get a Pro license. Beyond that minimal feature, there are a LOT of other benefits to pro. Just give it a try.
Look at this "headless" plugin (plugin that offers services to other plugins, not having any functionality or UI on its own):
https://github.com/sonatype/nexus/tree/master/nexus/nexus-core-plugins/nexus-maven-bridge-plugin
Nexus uses pure Aether, not (whole) Maven - as Manfred says - to calculate the tree of dependencies.... again, just take a peek at that plugin above, it's there ;)
I have an existing, fully functional Spring web application based on Spring 2.5.6 - developed using SpringSource Tool Suite 2.1.0.SR1.
Because I'd like to use REST I decided to upgrade to Spring 3.0.0.M4. After editing the dependencies in pom.xml and changing my code to reflect the API changes in Spring 3.0 I tried to publish my web app to a local server (SpringSource tc - a Tomcat derivate).
The result is an almost empty web app folder and therefore a non-functional app. The app's folder only contains WEB-INF/lib with all libraries required by the Maven dependencies.
After realising that something's broken, I created a new Spring MVC project (based on the default 2.5.6) and published it to the same server. No problems. I tried to adapt my project's files (.settings/*, .project, .classpath, .springBeans), but this didn't change anything.
I'm pretty lost right now. My guess is that STS doesn't handle 3.0 apps correctly. Any suggestions?
PS: I don't want to revert to 2.5 if it's not absolutely necessary. I don't need STS and tc so I don't have a problem using other tools, but it worked fine so far.
I run into this all the time using Eclipse Galileo and m2eclipse 0.9.8 and Tomcat with WTP. I think it is m2eclipse that is the culprit. The problem seems worse after switching from Ganymede. The work around is to run mvn to create the war and then copy the war contents from "target" to WTP's "wtpwebapps" directory. You can conveniently find this horribly long path by double clicking the server in the Servers view, and choosing "Open Launch Configuration" from there click on Arguments(?) tab I think and copy the catalina.home java property that is defined as an argument there.
The problem vanished with newer versions of STS. Additionally my development environment changed a bit since I posted this question, so I can't really tell what caused the problem.
For me, it looked like a weird hiccup inside STS.
Spring Tool Suite 2.1.0 claims partial support for Spring 3.0, though not for the REST features. According to the release, future releases will add full support. From the release statement:
Features
Support for milestones of Spring 3.0 including XML editing and validation, support for #Configuration and #Bean annotations
Future
Complete Spring 3.0 support including tools for developing RESTful web applications
Try deploying your app to embedded jetty. 'mvn jetty:run' with help you confirm if that there's nothing wrong with your build (that all the right manifests and deps are in place)