I need to create p2 repositories to add extra software in my application.
for instance I want to externalize all i18n bundle, so I have a set of features with only i18n fragments.
The way I do that is from a complete p2 repository that was build by pde and containt the product and the i18n plugins and features.
I try to use the p2.mirror ant task to create a p2 repository with only the i18n fragments but the problem is that it always embbed the host bundles that those i18n bundle depend on. This makes my p2 repo huge because it has most of my application along with the i18n.
<p2.mirror source="file://${build.repo.path}" destination="file://${i18n.repo.path}">
<iu id="org.talend.i18n.all-feature.feature.group" version="" />
</p2.mirror>
Is there a way to create a p2 repository including only the bundle that are referenced in a given feature and not the ones that host them ?
You need to add so-called "slicing options" and specify that you only want strict version range dependencies:
<p2.mirror ...>
<slicingoptions followStrict="true" />
</p2.mirror>
The inclusion relationship between features and plug-ins is encoded in p2 as strict version range dependency, so with this option you should only get the feature and its included plug-ins.
Note that p2 relies on the publishers to correctly translate the information from the feature.xml. If you use a non-standard publisher or influence the publishing via a p2.inf, the strict version range dependencies may not correspons 1:1 to the inclusions. In this case, it is not possible to achieve what you want. p2 mirroring will only operate on p2 metadata – there is no option to make it look at the feature.xml again.
Related
What is the best way to share a Target Platform?
E.g. together with the source code of some RCP project.
I can define a .target file and fill it with remote p2 sites and share this file. The problem here is first, those sites tend to be very slow and unreliable. From experience, resolving such a Target Platform fails from time to time.
A more reliable and faster (in terms of loading this Target Platform) approach is to define a local directory, that contains all plugins and features.
This directory can either be part of the source repository itself or I can provide a (fast and reliable) remote site from which I can download this target platform anytime.
The difficulty here is, how can I translate a list of p2 sites into a directory, that contains those plugins and features which are provided by the update site?
When I set a specific target platform from within Eclipse, where are those artifacts actually saved? I assume I could just copy this directory.
Despite the sometimes slow Eclipse p2 repositories and despite the crappy target platform editor, I still recommend using .target files. They are easy to share because they can be stored in the source code repository.
While resolving a target platform, PDE caches bundles in the .metadata/.plugins/org.eclipse.pde.core/.bundle_pool directory of the workspace.
Using .target files also allows you to use Tycho as a build tool. Note, however, that Tycho cannot read from local (i.e. file://) repositories.
It is the most common and most accepted way of providing dependencies for RCP/plug-in development.
To mitigate the unreliable performance of Eclipse p2 repositories you may want to mirror these and specify the mirrored sites in your target platform definition.
There is also Target Platform Definition DSL and Generator that you might try as a drop-in replacement for if you are dissatisfied with the reliability of the the PDE target platform editor.
I have the following situation:
an Eclipse plug-in (A) which contains base functionality, grouped in two features
an Eclipse plug-in (B) which contains add-on functionality in one feature and builds on the first plug-in
The two plug-ins have independent lifecycles, but periodically plugin (B) is released and its update site contains contains the latest features from (A) and (B).
What I want to enforce is that a certain feature from plugin (B) is only installable with features from plugin (A) of at least a certain version. So for instance when installing (B) 1.1.0 I should be able to enforce that the features from (A) are at least at version (1.3.0).
I've tried/considered the following:
bump the dependencies in one of manifests from (B). That does not sound right, since the plug-ins work fine together ; this is a distribution issue
in the feature.xml for (B), include the other features, e.g. <includes id="some.feature" version="1.3.0"/> . This creates a hard requirement on that version, but I want an 'at least' constraint
in the feature.xml for (B), include the other features with a version range, e.g. <includes id="some.feature" version="[1.3.0,)"/> . This is illegal in feature.xml files
What options do I have to require a feature with a version range?
You can add a dependency on another feature to your feature.xml, this can specify a matching rule for that dependency. Here you can say 'version greater or equal'.
Something like:
<requires>
<import feature="org.eclipse.e4.rcp" version="1.3.100" match="greaterOrEqual"/>
</requires>
This is configured on the 'Dependencies' tab of the feature.xml editor.
We use eclipse and m2e to work with a tycho-based plugin.
Our problem is the sources of the dependencies are not attached:
Is there any way to make PDE/m2e download sources automatically and attach them to the dependencies?
You can try to install this pde.source.lookup plugin, that will look for matching source bundles in the available p2 repositories of your Eclipse installation, just like m2e does for Maven dependencies.
If the source jar exists in one the p2 repositories and it doesn't work for you (really it should), please open a bug to its issue tracker.
Now, if that doesn't work, i.e. the jar doesn't come from a p2 repository, another alternative is to install JBoss Tools' Maven source lookup feature, which is very similar to m2e's mechanism, but a bit more robust and more complete, as it'll look for sources in Maven Central and different Nexus repository managers, based on the SHA1 checksum of your jar. It's downside is it'll bring down a bunch of dependencies in Eclipse you don't necessarily need (JBoss Servers stuff)
When PDE creates the Plug-in Dependencies classpath container, source attachments are added based on what is known to org.eclipse.pde.internal.core.SourceLocationManager. While older source models are still supported (extension point), source is now typically delivered via source bundle. A source bundle will have a manifest entry describing what it provides source for.
Eclipse-SourceBundle: org.apache.ant;version="1.9.2.v201307241445";roo
ts:="libsrc"
If a source bundle is available for what you need source for, you can add that source bundle to your target platform and PDE will attach the source when creating the classpath container.
Alternatively, you can temporarily attach a source zip/folder to the entry.
PDE does not provide a service to search for source. One other option could be the "Add Artifact to Target Platform" dialog (Ctrl+Alt+Shift+A), which can search through known p2 repositories for the needed source bundle and add it to your target platform.
I'd like to force p2 so set singleton='false' to some of my bundle that are defined as singleton in their manifest.
I know that multiple singleton plugins cannot be activated at the same time in an Eclipse runtime, but I would like them to be installed (no in the OSGI sense), meaning present on the disc. I have implemented my own configurator to activate the required bundle according to some license file.
I have tried to modify the content.xml manually to add the singleton='false' attribute to all my bundle IUs and it works fine. But I'd like to know if there is a way using a p2.inf file ?
Thanks for any lead.
The standard publishers that come with p2 cater for the standard Eclipse installation use case. The aim is to create an installation that will run, and fail the installation if it would fail at runtime. Therefore, I'd be surprised to see support for your use case in the standard p2 publishers.
Note however that you are free to write your own publishers. p2 (i.e. the entire project, not just the p2 publishers) aims to support all kinds of different installation scenarios and not only OSGi/Eclipse installations.
I'm using some 3rd party libraries to create my RCP application. These libraries are available as update site / p2 repository, and they are provided by eclipse (e.g., the RCP target, EMF) or by a third-party repository. Accordingly, I've created a target file to describe what I'm using to build my application.
Due to a recent outage of one of these repositories, I want to have a local mirror of all the stuff I'm using to build my application. Somebody told be to look at b3, but I need some additional help. Following the tutorial, I've copied from my target file the p2 repositories and created some validation rules (according to the feature I use).
However, when I start the build, it mirrors huge parts of the eclipse's indigo repository (including, for example, the JDT, WTP, and linuxTools, which are NOT required directly or indirectly by my RCP app).
Is it possible to limit the mirror to the features listed in my target file?
I have only the Helios version of b3 installed (not sure how it works in a newer one, but probably its similar), there I can add some child items to the Mapped repository elements to add an exclusion rule to remove some items, or add some specific features or plugins.