I have an internal p2 site with a number of different utility features we use in our products. I have just added a new set of plug-ins along with a new feature with utility functions for RAP (whereas the "old" functionality is for RCP/SWT).
In order to compile stuff, I use two different target platforms (one for RCP and a new one for RAP) and refer to these from the plug-ins and features. I have organized the modules so I have the usual two layers of parent POMs:
...parent - with all the common Tycho and Maven booking
...parent.rcp - container for all plug-ins that depends on/uses RCP/SWT functionality - also sets the target platform to include RCP/SWT features
...parent.rap - same for RAP
No problems there. Everything compiles and all tests runs.
I even have some of the existing plug-ins in both the features (RCP and RAP) as they don't depend on any UI functionality (e.g. OSGi test utilities). No problems there either.
But... when I try to make a single p2 update site with both the features (RCP and RAP), I run into a problem. I get the following message:
[INFO] Resolving dependencies of MavenProject: com.rcpcompany:com.rcpcompany.uibindings.updatesite:3.0.0-SNAPSHOT # /Git/ui-bindings/com.rcpcompany.uibindings.updatesite/pom.xml
[INFO] Cannot complete the request. Generating details.
[INFO] Cannot complete the request. Generating details.
[INFO] {osgi.ws=gtk, osgi.os=linux, osgi.arch=x86, org.eclipse.update.install.features=true}
[ERROR] Cannot resolve project dependencies:
[ERROR] Software being installed: com.rcpcompany.uibindings.updatesite raw:3.0.0.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):3.0.0-SNAPSHOT
[ERROR] Missing requirement: com.rcpcompany.utils.rap.feature.feature.group 1.0.0.qualifier requires 'org.eclipse.rap.ui.forms 0.0.0' but it could not be found
[ERROR] Cannot satisfy dependency: com.rcpcompany.uibindings.updatesite raw:3.0.0.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):3.0.0-SNAPSHOT depends on: com.rcpcompany.utils.rap.feature.feature.group [1.0.0,1.0.1)
[ERROR]
[ERROR] Internal error: java.lang.RuntimeException: "No solution found because the problem is unsatisfiable.": ["Unable to satisfy dependency from com.rcpcompany.utils.rap.feature.feature.group 1.0.0.qualifier to org.eclipse.rap.rwt.osgi [2.0.0,2.1.0).", "Unable to satisfy dependency from com.rcpcompany.utils.rap.feature.feature.group 1.0.0.qualifier to org.eclipse.rap.rwt.testfixture [2.0.0,2.1.0).", "Unable to satisfy dependency from com.rcpcompany.utils.rap.feature.feature.group 1.0.0.qualifier to org.eclipse.rap.ui.forms 0.0.0.", "No solution found because the problem is unsatisfiable."] -> [Help 1]
....
As the update project is associated with the RCP target platform, I understand the messages above such that Tycho (or p2) cannot find the plug-ins from the RAP target platform and complains.
(If I make two different update sites, everything works fine, but I don't want that :-/)
How can I convince Tycho to construct update site with both features? Do I have to make a combined target platform with all the possible dependencies or are there another way?
Let's start with the obvious: The things that you want to aggregate into the p2 repository need to be in the target platform because the build can only use things that are in the target platform. But this doesn't seem to be your problem - there is rather a problem with the dependencies of the things you want to aggregate.
Currently, the dependencies of the aggregated content also needs to be in the target platform. You should be able to create a joint RCP&RAP target platform by merging the configuration from both your parents.
Unfortunately, this isn't all yet: Currently, it also needs to be possible to install all your features at once. This is what Tycho simulates during dependency resolution: It pretends to do a p2 installation with the build result of a module. If you get a "cannot be installed at once" error during dependency resolution, you can may try to set the target-platform-configuration switch allowConflictingDependencies to true. This switch was originally introduced to support exactly your use case in the (now deprecated) eclipse-update-site packaging type. I'm not sure if it works for eclipse-repository though.
If it doesn't work, I only see the possibility to build two separate p2 repositories, and to combine them in an additional (post-)build step. You can either put both p2 repositories on your web server and group them logically using a so-called composite repository, or you copy ("mirror") the two repositories together using a p2 mirror tool.
Related
The paket.dependencies sample file produced when running dotnet new fake currently looks like:
// [ FAKE GROUP ]
group Build
source https://api.nuget.org/v3/index.json
nuget Fake.DotNet.Cli
nuget Fake.IO.FileSystem
nuget Fake.Core.Target
I understand how dependency groups can be used to solve version conflicts, however it seems unnecessary to introduce them until an actual version conflict situation arises.
What is the semantic of the Build group here and why not just have the three dependencies under the Main default group? The same reflection applies to the Test group in the Paket documentation example.
Can one elaborate on reasons for segregating dependencies in groups in the case of no version conflicts? Maybe explaining a bit more the rationale behind the Build and Test groups?
As I have basically introduced that split for FAKE 5:
The reasoning is that one set of the dependencies is used at BUILD-time (ie when running the build script) and one is for your project RUN-time. It is completely valid to have a different set of dependencies for those two.
Consider the following scenario: You use the FSharp.Formatting (FSF, a markdown parser) project in your build process to generate API documentation and in your project to generate websites. Now you want to update the API documentation by updating FSF but you cannot upgrade FSF in your project for compatibility reasons. With the separation between BUILD and RUN-time this is not a problem and you can see them as "different" dependencies in different versions.
I'd like to see that approach similar to how node separates dependencies and dev-dependencies
Regarding the split between RUN and TEST: Personally I'm not a huge fan. I can see how people want to separate their dependencies but paket currently doesn't "really" support that scenario and you can indeed run into issues with that approach. My current suggestion would be to not split between RUN and TEST and manage them in a single group.
To properly split between RUN & TEST paket would need a new feature to reference another group:
group Run
source https://api.nuget.org/v3/index.json
nuget MyDep1
group Test
reference_group Run
source https://api.nuget.org/v3/index.json
nuget MyRunner1
Similar to the external lock-file feature: https://github.com/fsprojects/Paket/pull/3062#issuecomment-367658114
From the site https://wiki.eclipse.org/Tycho/Target_Platform, I infer the following:
If the 'repositories' section contains a p2 repository, everything inside that repository is automatically considered part of the target platform as far as Tycho is concerned.
If a target definition file is referenced, everything inside that target definition file is considered part of the target platform as far as tycho is concerned.
Let's say that I have a repository under 'repositories' that points to http://download.eclipse.org/releases/indigo like in the example. Furthermore, I declare a target definition file that points to http://download.eclipse.org/releases/helios instead.
In Eclipse, developers then use the target definition file as the target platform. For dependencies in individual plug-in projects no version is defined, since the versions of the bundles are already defined by the target definition file.
The question: Will Tycho build using Indigo or Helios versions?
The target platform will contain both content from Indigo and Helios. Quoting the Target Platform wiki page:
In case multiple target platform configuration approaches are combined, the target platform contains the union of the content defined through each approach.
So for the dependency resolution, Tycho could either use Indigo bundles, or Helios bundles, or a mixture of these.
The resolution is based on the p2 planner which finds a valid solution to satisfy the requirements. In case there are multiple solutions, the p2 planner has a preference towards later bundle versions and a small set of transitive dependencies. These preferences often contradict each other, e.g. when a later version of a bundle has a larger set of transitive dependencies. So in general it is hard to predict which versions are picked in such a case.
So, if you need to know what your bundles are compiled against, use a target platform which appropriately restricts the available versions.
We aim at using Tycho+Eclipse PDE to build OSGi bundles in a distributed team.
So far artifacts are built and deployed to a Nexus OSS repository. This has been
augmented with p2 support, "artifacts.xml" and "content.xml" are generated
(or supplied by Tycho) and correctly resolved by Tycho and the p2 Browser.
The missing link is to add the resultant p2 bundle repository to the target platform
definition used by PDE. The PDE target editor apparently only supports features
or "categorized" plugins, no plain bundles.
Tycho's repository plugin and feature-packaging of bundles independently developed by
different partners appears too cumbersome to synchronize. We'd like to adhere to simple
Maven/OBR-like sharing of bundles via a single repository.
Is there a way to enhance the bundle's or repository's p2 metadata in terms of a
generic category as suggested in this blog, e.g. either via the "tycho-p2-publisher:publish-categories" goal or by configuring/extending the "Nexus p2 Repository Plugin" to make them accessible to the PDE UI ?
This questions seems related to this question, with a hint that support for the "iu" syntax is not implemented yet.
Maybe you should try another target editor. There exists a alternative TPD editor/generator from Mikaël Barbero with some useful features:
autocomplition
version management
mergeable structure
...
How does one perform an ad-hoc reactor build over multiple maven projects without a root project?
This used to be possible in maven2 by invoking the mvn command with the '-r' option which would search recursively from the working directory for projects and organize them in the reactor to build in the correct order even if the projects did not share a common parent pom.xml. Optionally one could specifically include or exclude certain projects using maven.reactor.includes and maven.reactor.excludes option.
I realize that the legacy reactor mode was removed from maven3 but I can't figure out how to achieve this functionality using the 'make-like' reactor mode.
The "Maven 2"-style reactor feature has been removed following this discussion on the mailing list. The relevant JIRA issue is MNG-4260.
As mentioned in the comments above, it's best to create a top-level pom with a <modules> section that lists the directories containing projects. (If you don't always build all of your projects at the same time, you can put separate modules sections in profiles).
I have a situation that I'm sure must be fairly common. I have some Maven-built applications that deploy to different types of application server - like Tomcat, JBoss, etc.
The build processes 'tunes' the deployable artifact to the specific target type of application server (for example, different included dependencies, context roots, other config). This tuning is controlled with build profiles (-Ptomcat, -Pjboss etc)
So, for a given version of my application, I need to run builds that produce different deployables. I run mvn -Ptomcat clean package for example and I get an artifact in my /target directory that is the tomcat-tuned version.
The best approach I've been able to come up with so far is to specify finalnames for the artifacts that include the profile information, but for that approach, I'm not sure how to configure Maven to copy the final artifact off to some specific location so that the next build for a different type doesn't overwrite it.
Is this a good approach? If so, how can I achieve that final copy?
Or is there a better way?
You'll need to use Maven Assembly Plugin.