Where can I find a p2 repository containing org.eclipse.test?
The test bundles and framework are included in our repos as of 3.7M2 (Sept 2010). See https://bugs.eclipse.org/bugs/show_bug.cgi?id=318514 for more details.
I don't think there is a p2 update site for ETF (Eclipse Testing Framework)
ETF itself doesn't recognize test bundles in p2 repo: "JUnit4 and the Eclipse Test Framework: Success!":
ETF was created before p2. So you just dropped your test bundles into the "plugins" folder of the SDK, launched the SDK specifying the ETF application and test bundle / test class, and off you go.
And ETF looks quite old, with plan to move to JUnit4 only recently achieved.
It doesn't seem to benefit from the same p2 compliant packaging than the other Eclipse projects.
You can create p2 repositories from features and plugins yourself. See the section "Features and Bundles Publisher" in this link.
Related
I am building a RCP Application which is having 5-6 features and I am using tycho to build this application.
Another team develops and deploy 25+ plugins to p2 repository(i.e. URL = http:\oragnaizaion.com\RCP-Application\plugins).
So when tycho builds my application I need to download the application and after launch I need to install these plugins manually from the given p2 repo URL.
So here I am looking for a solution in which I can automatically install these 25+ plugins by providing URL during tycho build of the RCP application. anyone can please help me on this.
Background
In my RCP application, I have a project that consists of a plugin and a feature, the setup is like this:
my.plugin/
META-INF/MANIFEST.MF
plugin.xml
src/
my.feature/
feature.xml
The plugin contains unversioned dependencies towards other bundles (in other features). The feature contains versioned dependencies towards other features.
In the end, I will build a RCP application as a feature-based product.
All feature dependencies can be found in a p2 repo hosted by a Nexus server (over HTTP).
Problem
The above can be built fine using Tycho and the manifest-first approach. Tycho picks up the correct target platform based on the versioned feature dependencies.
When developing, I would like to create a target platform given the specified features by reading the feature versions, so that I know that development is being done against a target platform that is compatible with the specified set of features.
What is a good way to create a target platform based on this feature dependency specification? Ideally, I think I would just like to generate the target platform automatically using the latest compatible versions, just like Tycho does.
I've used the Google Guava library for a half year now inside some small Eclipse RCP applications. Until now it's worked well with the older versions of Guava 11/12 provided inside the Eclipse Orbit p2 repositories.
In a new project I need to use Base64 encoding, but this feature only exists in Guava since version 14, which is not available inside Eclipse orbit.
I know that there is an alternative within the Apache commons, but I want to have minimal dependencies to other bundles.
I also know the bundle itself is OSGi compatible, but the classic RCP build based on features and it is a good practice to define a feature based target platform.
So does somebody know an (official) p2 repository that includes the latest guava version, or do I need to build my own feature based on the library?
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
So we have the following scenario
We have projects using maven with Intellij in a non osgi enviorenment and then we have projects using eclipse in an osgi environment. The eclipse projects are developing RCP-applications and is therefore using the plugin architecture (OSGI).
So we have:
Projects A – maven organized project in a non Osgi-enviroment
Projects B – maven tycho for creating application, but using eclipse project structure with target platform and so on.
Projects C – maven organized projects with maven-dependencies that should work in both projects A and B.
We also have installed Nexus with the p2-plugin so that maven-tycho can work.
The big problem we have is that we can’t figure out how to construct Projects C so that it works without problems for both projects A and B. In projects A we want that maven should work as usual and pulls down the dependencies as needed. But we also want that functionality in projects B (maybe with the combination Nexus+Tycho??).
How should we solve this problem. I haven’t found a good solution for how to do this. I have tried apache felix bundle plugin in maven, but can't get it to work as I want. Is that the right solution?
I think that your best bet is to use the Nexus P2 Repository Plugin.
You can develop and deploy standard OSGi bundles for the Project C using the maven-bundle-plugin, those bundles are directly usable by Project A via maven builds.
Then, by using the Nexus P2 Repository Plugin, you can also expose those OSGi bundles as a standard P2 repository, that can be consumed by Project B via tycho builds.