I am trying to install a feature (com.iar.cdt.arm.sdk.feature) in an Eclipse product (MCUXpressoIDE).
The feature has a requirement on another feature (org.eclipse.emf.feature, with no version specified) which is part of the product itself (in version 2.19, as org.eclipse.emf.common.feature). Despite this, p2 is trying to fetch the same feature from one of the available update sites, resulting in a conflict and installation error.
Does p2 consider the product itself as a source for needed features, in addition to the update sites? If not, why?
EDIT: It does, see the accepted answer
The original installation exception follows:
Cannot complete the install because of a conflicting dependency.
Software being installed: IAR Toolchain for ARM (8.30.x - 8.50.x) 8.1.0.202007252323 (com.iar.cdt.arm.sdk.feature.feature.group 8.1.0.202007252323)
Software currently installed: MCUXpresso IDE 11.2.0.202007071544 (MCUXpressoIDE 11.2.0.202007071544)
Only one of the following can be installed at once:
EMF Common 2.17.0.v20190920-0401 (org.eclipse.emf.common.feature.jar 2.17.0.v20190920-0401)
EMF Common 2.19.0.v20200324-0932 (org.eclipse.emf.common.feature.jar 2.19.0.v20200324-0932)
Cannot satisfy dependency:
From: MCUXpresso IDE 11.2.0.202007071544 (MCUXpressoIDE 11.2.0.202007071544)
To: org.eclipse.equinox.p2.iu; org.eclipse.emf.common.feature.group [2.19.0.v20200324-0932,2.19.0.v20200324-0932]
Cannot satisfy dependency:
From: IAR Toolchain for ARM (8.30.x - 8.50.x) 8.1.0.202007252323 (com.iar.cdt.arm.sdk.feature.feature.group 8.1.0.202007252323)
To: org.eclipse.equinox.p2.iu; org.eclipse.emf.feature.group 0.0.0
Cannot satisfy dependency:
From: EMF Common 2.17.0.v20190920-0401 (org.eclipse.emf.common.feature.group 2.17.0.v20190920-0401)
To: org.eclipse.equinox.p2.iu; org.eclipse.emf.common.feature.jar [2.17.0.v20190920-0401,2.17.0.v20190920-0401]
Cannot satisfy dependency:
From: EMF Common 2.19.0.v20200324-0932 (org.eclipse.emf.common.feature.group 2.19.0.v20200324-0932)
To: org.eclipse.equinox.p2.iu; org.eclipse.emf.common.feature.jar [2.19.0.v20200324-0932,2.19.0.v20200324-0932]
Cannot satisfy dependency:
From: EMF - Eclipse Modeling Framework Runtime and Tools 2.20.0.v20191028-0905 (org.eclipse.emf.feature.group 2.20.0.v20191028-0905)
To: org.eclipse.equinox.p2.iu; org.eclipse.emf.common.feature.group [2.17.0.v20190920-0401,2.17.0.v20190920-0401]
According to the installation exception, the IAR Toolchain for ARM (com.iar.cdt.arm.sdk.feature.feature.group) requires EMF (org.eclipse.emf.feature.group) of any version (0.0.0). The in the update sites available EMF is 2.20 which comes with EMF Common 2.17. But this conflicts with EMF Common 2.19 that is a fixed part of the MCUXpresso IDE product (MCUXpressoIDE).
To solve this conflict, make available EMF 2.22 using EMF Common 2.19 by adding the following update site:
https://download.eclipse.org/modeling/emf/emf/builds/release/2.22
Related
I want to have a rpm package build with Copr1. My current build target list is Fedora 35, 36, rawhide and Centos 7 and Stream 8. I have not yet created the copr project.
Compiling on one of my machines, the package builds successfully on the Fedora variants with mock. The problem is that on Centos variants one of the build dependencies and some of its dependencies are not available. I have found appropriate srpm files and compiled them on one of my machines with the Centos Stream 8 (one of them required two custom patches). With those custom dependencies I am able to successfully compile the original package.
So just to be clear, the problem is that the spec file contains for example
BuildRequires: libsomething
where libsomething is available as a plain upstream package in some of the build targets while needs an additional custom repo for some other build targets.
The FAQ says the following about dependencies:
Can I depend on other packages, which are not in Fedora/EPEL?
Yes, they just need to be available in some yum repository. It can either be another Copr repo or a third-party yum repo (e.g jpackage). Click on “Edit” in your project and add the appropriate repositories into the “Repos” field. Packages from your project are available to be used at build time as well, but only for the project you are currently building and not from your other projects.
But this sounds like an all or nothing approach, and I absolutely do not want to override the already existing upstream packages, only provide them when they are missing.
So what strategy do people use to handle this?
Update: I have now created copr projects and made some attempts at building (after resolving dependencies of dependencies in several levels), but the problem is as I describe above. If I add copr://hlovdal/projectname as a build dependency then epel-8-x86_64 compiles fine because it is provided with the missing dependencies while fedora-35-x86_64 fails because the repository does not have any fedora packages. If I remove the repo epel fails while fedora succeeds.
I also attempted to add the base url from the corresponding /etc/yum.d.repo file, and only hardcode epel instead of $distname hoping that the fedora builds would just ignore non-existing/wrong repo setting, but the build does not like that and still fails.
1 Copr is Fedora's freely available build system.
In order to be able to use my Eclipse plugin "treezCore" also as a Java9 module I created a module-info.java in my src folder.
Furthermore, I moved the Plug-in Dependencies from the Classpath to the Modulepath. I can see a module "org.eclipse.swt.3.106.1.v20170926" in the plugin dependencies:
However, I am not able to reference that module in my module-info.java. I tried
require org.eclipse.swt.3.106.1.v20170926;
require org.eclipse.swt;
require swt;
None of those options worked. The jar file \plugins\org.eclipse.swt_3.106.1.v20170926-0519.jar that is used by Eclipse does not contain a module definition and
jar --file org.eclipse.swt_3.106.1.v20170926-0519.jar -d
says that the module descriptor can not be derived. Also see
Unable to derive module descriptor for auto generated module names in Java 9?
If I download a newer version of swt.jar from
http://download.eclipse.org/eclipse/downloads/drops4/R-4.7.1a-201710090410/download.php?dropFile=swt-4.7.1a-win32-win32-x86_64.zip
I get following output that looks promising:
swt automatic
requires java.base mandated
contains org.eclipse.swt
contains org.eclipse.swt.accessibility
contains org.eclipse.swt.awt
contains org.eclipse.swt.browser
contains org.eclipse.swt.custom
contains org.eclipse.swt.dnd
contains org.eclipse.swt.events
contains org.eclipse.swt.graphics
contains org.eclipse.swt.internal
contains org.eclipse.swt.internal.gdip
contains org.eclipse.swt.internal.image
contains org.eclipse.swt.internal.mozilla
contains org.eclipse.swt.internal.mozilla.init
contains org.eclipse.swt.internal.ole.win32
contains org.eclipse.swt.internal.opengl.win32
contains org.eclipse.swt.internal.webkit
contains org.eclipse.swt.internal.win32
contains org.eclipse.swt.layout
contains org.eclipse.swt.ole.win32
contains org.eclipse.swt.opengl
contains org.eclipse.swt.printing
contains org.eclipse.swt.program
contains org.eclipse.swt.widgets
I also depend on org.eclipse.jface and could not find a seperate download for it.
=> Do I really have to wait for a new release of Eclipse that uses new plugin versions including module definitions?
Or can I somehow reference the old version of swt from the plugins folder, even if it does not include a module definition? I looked for an easy way to define an alias or a fallback dependency e.g.
requires ../plugins/org.eclipse.swt_3.106.1.v20170926-0519.jar as 'org.eclipse.swt'
or
requires org.eclipse.swt fallback ../plugins/org.eclipse.swt_3.106.1.v20170926-0519.jar
but module-info.java does not seem to support such a syntax.
I have about 20 plugin dependencies and do not want to manually download each of them (if it would be possible) and include them as external jar file. Nor do I want to hack the individual Manifest/jar files in the Eclipse plugin folder. There are many jar files I would need to alter and an update of Eclipse would break that hack.
I am using Eclipse for RCP and RAP Developers, Version: Oxygen.1a Release (4.7.1a), Build id: 20171005-1200
Edit
When using Version: Photon Milestone 4 (4.8.0M4) Build id: 20171214-1849, the error in module-info.java vanishes when using
require org.eclipse.swt;
and having the Plug-in Dependencies in the Modulepath.
However, my imports do not work yet, see following image. If I move the Plug-in Dependencies from the Modulepath to the Classpath, the imports work but the error in module-info.java reappears.
I created a min example at
https://github.com/stefaneidelloth/Java9EclipsePluginExample/tree/master/MyPlugin
and I filed a bug report at
https://bugs.eclipse.org/bugs/show_bug.cgi?id=529089
Related questions:
How to use 3rd party library in Java9 module?
Unable to derive module descriptor for auto generated module names in Java 9?
Force Eclipse (Helios) to use a newer version of SWT at application runtime
JFace libraries stand-alone download (not picked from Eclipse plug-ins)
New Keywords in Java 9
What you observe is tracked in bug 525660, which starts with the observation that all existing (OSGi) artifacts of Eclipse don't work as automatic modules, because Java 9 fails to derive a valid module name from jar filenames of the shape org.eclipse.swt_3.106.1.v20170926-0519.jar.
Since this was discovered too late to request improving the algorithm for automatic module name derivation, this can only be fixed by adding Automatic-Module-Name headers to the manifests of future releases.
This header is present starting from Photon M4 as can be seen in org.eclipse.swt_3.107.0.v20171205-0742.jar, containing:
Automatic-Module-Name: org.eclipse.swt
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.
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.
I have an ivy.xml file where I specify my dependencies explicitly. Is there any functionality built into Ivy that will let me discover or automatically update my dependencies which are out of date?
I don't want to use latest.release because I want a completely stable and reproducible build. But every once in a while I'll want to update some dependencies and at the same time it would be good to answer the question, which other dependencies are out of date?
Like you, I only use dynamic versions for in-house dependencies. When upgrading, at the start of a new development phase, I would use one of the repository search tools to discover new versions of 3rd party libraries:
http://mvnrepository.com/
http://mavencentral.sonatype.com/
As I'm sure you're aware, another problem is that upgrading dependencies can often lead to an involuntary upgrade of your transitive dependencies....
What I'd suggest is to generate an ivy dependency report and use this to review your code's module usage. I find this very useful especially considering that some 3rd party Maven modules are not well behaved and will import many unnecessary libraries onto my classpath.
The following is an example of my standard dependencies target:
<target name='dependencies' description='Resolve project dependencies and set classpaths'>
<ivy:resolve/>
<ivy:report todir='${ivy.reports}' graph='false' xml='false'/>
<ivy:cachepath pathid="compile.path" conf="compile"/>
<ivy:cachepath pathid="provided.path" conf="provided"/>
<ivy:cachepath pathid="runtime.path" conf="runtime"/>
<ivy:cachepath pathid="test.path" conf="test"/>
</target>
Hope this helps.... If you find a way to automatically manage this I'd be interested.
One workaround is to use ivy:makepom and then run mvn versions:display-dependency-updates using the generated pom.
I'm not sure if this is the best solution or not, but you can create a configuration (e.g., "checklatest") that asks for the latest versions, then run a report against that.
For example, in your ivy.xml file:
...
<dependencies>
....
<dependency org="somegroup" name="somename"
rev="latest.release" conf="checklatest->default"/>
</dependencies>
and then run an ant task that uses the task for that configuration.
Even there, it isn't necessarily going to pick up the latest version -- e.g., Apache's commons-httpclient eventually got incorporated into the httpcomponents project, so a request for the latest "commons-httpclient" in group "commons-httpclient" will only find version 3.1. But if you look at the publication date on the report Ivy generates, it should be fairly clear that something happened, when the latest publication is 2007. At that point, you would have to investigate.
checkdepsupdate is the rough equivalent in Ivy.
It gives you output like:
[ivy:checkdepsupdate] com.sun.mail#javax.mail 1.5.4 -> 1.6.2
[ivy:checkdepsupdate] commons-codec#commons-codec 1.10 -> 1.11
[ivy:checkdepsupdate] org.apache.commons#commons-compress 1.12 -> 1.18
[ivy:checkdepsupdate] commons-dbutils#commons-dbutils 1.5 -> 1.7
[ivy:checkdepsupdate] commons-io#commons-io 2.4 -> 2.6
[ivy:checkdepsupdate] org.apache.commons#commons-lang3 3.6 -> 3.8.1
[ivy:checkdepsupdate] org.apache.commons#commons-text 1.1 -> 1.6
[ivy:checkdepsupdate] org.apache.poi#poi 3.13 -> 4.0.0