I am creating an Eclipse plug-in that requires the use of JGit. However, I am not sure how to import the bundle as a dependency.
When I try to build with tycho I am greeted with errors about being unable to resolve the dependency. I have tried adding a dependency in the pom:
<dependency>
<groupId>org.eclipse.jgit</groupId>
<artifactId>org.eclipse.jgit</artifactId>
<version>3.2.0.201312181205-r</version>
</dependency>
Adding the bundle to Required-Bundles in the manifest:
But all efforts lead back to being unable to resolve the dependency:
org.apache.maven.InternalErrorException: Internal error: java.lang.RuntimeException: No solution found because the problem is unsatisfiable.: [Unable to satisfy dependency from com.inin.testing.eclipse.plugin.submit 0.5.0.qualifier to bundle org.eclipse.jgit 3.2.0.; Unable to satisfy dependency from org.eclipse.jdt.core 3.9.0.v_OTDT_r220_201306071800 to org.eclipse.objectteams.otdt.core.patch.feature.group [2.0.0,3.0.0).; Unable to satisfy dependency from org.eclipse.jdt.core 3.9.1.v_OTDT_r221_201309101918 to org.eclipse.objectteams.otdt.core.patch.feature.group [2.0.0,3.0.0).; No solution found because the problem is unsatisfiable.]
If anyone has had success using the JGit library in an eclipse plug-in project let me know how you are consuming it.
If you are working with PDE, JGit (or other dependencies) is best consumed through a Target Platform.
The definition below integrates JGit 3.2 from the projects' software repository at Eclipse.org.
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?pde version="3.8"?><target name="JGit" sequenceNumber="53">
<locations>
<location includeAllPlatforms="false" includeConfigurePhase="false" includeMode="planner" includeSource="true" type="InstallableUnit">
<unit id="org.eclipse.jgit.feature.group" version="3.2.0.201312181205-r"/>
<unit id="org.eclipse.jgit.source.feature.group" version="3.2.0.201312181205-r"/>
<repository location="http://download.eclipse.org/egit/updates"/>
</location>
</locations>
</target>
Paste the snippet into a file within your workspace and open it with the (default) Target Definition Editor. Select the 'Set as Target Platform' link in the top-right corner. This will download JGit along with required bundles and make them your current target platform.
Related
I just updated my application's org.eclipse.e4.rcp feature from Eclipse 4.9. to 4.10 (or 2012-09 to 2012-12). Now I get the exception:
[ERROR] Cannot resolve target definition:
[ERROR] Problems resolving provisioning plan.:
[ERROR] Unable to satisfy dependency from org.eclipse.swt 3.109.0.v20181204-1801 to org.eclipse.equinox.p2.iu; org.eclipse.swt.gtk.linux.x86_64 [3.109.0.v20181204-1801,3.109.0.v20181204-1801].
[ERROR] Unable to satisfy dependency from org.eclipse.swt 3.109.0.v20181204-1801 to org.eclipse.equinox.p2.iu; org.eclipse.swt.cocoa.macosx.x86_64 [3.109.0.v20181204-1801,3.109.0.v20181204-1801].
[ERROR] Unable to satisfy dependency from org.eclipse.swt 3.109.0.v20181204-1801 to org.eclipse.equinox.p2.iu; org.eclipse.swt.gtk.linux.ppc64le [3.109.0.v20181204-1801,3.109.0.v20181204-1801].
Both the .target file and the pom.xml have defined the target platform as being for Windows only:
<environment>
<os>win32</os>
<ws>win32</ws>
<arch>x86_64</arch>
</environment>
And the target file has additionally includeAllPlatforms="false". If I set it to true, I get the very similar exception:
[ERROR] Software being installed: org.acme.plugin 7.0.0.qualifier
[ERROR] Missing requirement: org.eclipse.swt 3.109.0.v20181204-1801 requires 'org.eclipse.equinox.p2.iu; org.eclipse.swt.gtk.linux.x86_64 [3.109.0.v20181204-1801,3.109.0.v20181204-1801]' but it could not be found
[ERROR] Cannot satisfy dependency: org.acme.plugin 7.0.0.qualifier depends on: java.package; org.eclipse.jface.preference 0.0.0
[ERROR] Cannot satisfy dependency: org.eclipse.jface 3.15.0.v20181123-1505 depends on: osgi.bundle; org.eclipse.swt [3.104.0,4.0.0)
If I add the fragments to the target platform, I get the following message (which is completely understandable):
org.eclipse.swt.gtk.linux.x86_64 3.109.0.v20181204-1801 cannot be installed in this environment because its filter is not applicable. -> [Help 1]
Setting the target platform to planner mode doesn't work. Neither does setting <org.eclipse.swt.buildtime>true</org.eclipse.swt.buildtime> in the pom.xml (false doesn't work either).
Looking at the XML file of the feature I can't see anything wrong with it (the fragments are defined for their OS only), still the target platform wants to haven the fragments for Linux and MacOS, even though I'm on Windows.
The target platform looks like this (yet again, it works if I replace 2018-12 with 2018-09):
<location includeMode="slicer" includeAllPlatforms="false" includeSource="true" includeConfigurePhase="false" type="InstallableUnit">
<repository location="https://download.eclipse.org/releases/2018-12/"/>
<unit id="org.eclipse.e4.rcp.feature.group" version="0.0.0" />
<unit id="org.eclipse.emf.common.feature.group" version="0.0.0" />
<unit id="org.eclipse.emf.ecore.feature.group" version="0.0.0" />
<unit id="org.eclipse.equinox.executable.feature.group" version="0.0.0" />
<unit id="org.eclipse.rcp.feature.group" version="0.0.0" />
</location>
And it's hooked in the pom.xml like this:
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>target-platform-configuration</artifactId>
<configuration>
<resolver>p2</resolver>
<target>
<artifact>
<groupId>groupId</groupId>
<artifactId>org.acme.plugin.build</artifactId>
<version>7.0.0-SNAPSHOT</version>
<classifier>platform</classifier>
</artifact>
</target>
<ignoreTychoRepositories>true</ignoreTychoRepositories>
<environments>
<environment>
<os>win32</os>
<ws>win32</ws>
<arch>x86_64</arch>
</environment>
</environments>
</configuration>
</plugin>
What is the problem? How can I fix it?
Who would have thought? It's the exact same Eclipse bug as in this question again. For some reason our build process gives preference to the plug-ins in Maven Central over the ones in the Eclipse repository. Since they have broken Maven dependencies, and since Tycho (obviously) still evaluates these dependencies, that breaks the build.
In our case the fix was as easy as moving Maven Central down below the Eclipse repo in our target platform.
I have an Artifactory server that I use to resolve Ivy dependencies. When I want to add a dependency to my ivy.xml, I sometimes have to add an explicit nested <artifact> tag, and I don't understand why.
Example A:
<dependency org="com.google" name="guava" rev="[7,)" conf="compile,runtime" />
Example B
<dependency org="com.twelvemonkeys.common" name="common-image" rev="3.0.1" conf="compile,runtime">
<artifact name="common-image" ext="jar"/>
</dependency>
Looking at the cached dependencies in the Artifactory tree view, there's nothing that indicates that the last example should need extra info to resolve the dependency, but Artifactory suggests it itself, and the resolution doesn't work without out.
I'm using Ivy against a repository with Maven layout. My settings where generated by Artifactory and look something like:
<?xml version="1.0" encoding="UTF-8"?>
<ivy-settings>
<settings defaultResolver="main" />
<resolvers>
<chain name="main">
<ibiblio
name="public"
m2compatible="true"
root="http://example.org/artifactory/remote-repos" />
</chain>
</resolvers>
</ivy-settings>
Why does Artifactory require an explicit artifact for some Ivy dependencies and not for others?
Edit 20151005: Added Ivy settings example
The tool performing the dependency resolution is the Ivy client and not Artifactory.
Based on the dependency deceleration the Ivy resolver decides which artifact to request from the repository (in your case it is Artifactory).
The artifact feature provides more control on a dependency for which you do not control its ivy file.
It enables to specify the artifacts required, if the dependency has no ivy file.
For more information about the artifact feature and when it should be used consult the Ivy documentation.
Certain developers on my project are unable to successfully execute an ivy resolve. We use an ivy ssh resolver to a remote server/file system. Impacted developers are typically resolving all but 1 or 2 dependencies successfully. The dependencies that fail to be resolved are the larger jars (example: nasa worldwind). Again, most users are able to resolve all dependencies with no problem. The eclipse project, ivy.xml and ivysettings.xml all come from the software repo and are identical between impacted and unimpacted users. If I copy the failed dependency from my ivy2 cache into an impacted users ivy2 cache, the problem goes away. The ivy resolve is initiated through eclipse/ivyDE.
Things I believe are eliminated:
differences in ivy.xml, ivysetings.xml, and eclipse project
existance of dependency on server
file permission issues on remote file system
network connectivity
version differences in eclipse/ivyDE
Question: What could be causing ivy resolves to fail for some users? I am starting to suspect this may be a timeout issue with ivy, given that it happens with larger jars.
Configuration:
Eclispe Kepler
IvyDE 2.2.0
example ivysettings.xml:
<ivysettings>
<settings defaultResolver="test-chain" />
<resolvers>
<chain name="test-chain">
<ssh name="test-cm" host="IPaddress">
<ivy pattern="/cm/lib/[organisation]/[module]/ivys/ivy-[revision].xml"/>
<artifact pattern="/cm/lib/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]"/>
</ssh>
<url name="test-cm-file">
<ivy pattern="file://cm/lib/[organisation]/[module]/ivys/ivy-[revision].xml"/>
<artifact pattern="file://cm/lib/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]"/>
</url>
</chain>
</resolvers>
</ivysettings>
example ivy.xml:
<?xml version="1.0" encoding="ISO-8859-1"?>
<ivy-module version="2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://ant.apache.org/ivy/schemas/ivy.xsd">
<info
organisation="test"
module="Application"
status="integration">
</info>
<dependencies>
<dependency org="nasa" name="worldwind" rev="1.4.0"/>
</dependencies>
</ivy-module>
Using Eyad Ebrahim's suggestions, I was able to examine the IvyDE console and gain insight into the problem. The issue turned out to be that several developers did not have an ivysettings.xml set in either the eclipse global or project IvyDE properties. IvyDE was attempting to use an internet resolver by default, which resulted in two subsequent issues including no public repo for products like worldwind, and blocking of certain files by my company network infrastructure. After correctly configuring the ivysettings.xml file, the custom file/url resolvers listed above were used and everything worked.
Thanks!
Uinsg IntelliJ, currently ivy gives me this error message:
:: downloading artifacts ::
[NOT REQUIRED] folder#scopt;2.10-3.1.0!scopt.jar
When I try to use our firm-internal ivy system.
I can see that the jar file is in the correct location that the resolver points to, and the ivy cache (using IntelliJ) is clean.
Ivy otherwise will download files requested.
The issue is with IntelliJ, eclipse can find and download the jar with the same ivy.xml and ivy.settings file without any issue
This is not a duplicate as suggested - if i change my internal IntelliJ settings to exclude jar files then i get an error at the bottom of the output (stating that jar files are not to be downloaded). I currently have the logging as "All" in intelliJ)
~~~~~
The ivy resolver code is:
<resolvers>
<filesystem name="secret-source-resolver" checkmodified="true" checkconsistency="false">
<artifact pattern="//a/b/c/d/[organisation]/e/f/[module]/[artifact]_[revision].[ext]" />
</filesystem>
</resolvers>
<modules>
<module organisation="theOrg" name="scopt" resolver="secret-source-resolver" />
</modules>
And the ivy.xml file is
<dependencies>
<dependency org="theOrg" name="scopt" rev="2.10-3.1.0">
<artifact name="scopt" type="jar" force="true" conf="runtime" />
</dependency>
</dependencies>
Looking at the folder that i'm getting the files from, the jar files are present.
Finally, in the output:
don't use cache for theOrg#scopt;2.10-3.1.0: checkModified=true
trying //v/campus/ny/cs/theOrg/shared/apps/scopt/scopt_2.10-3.1.0.jar
tried //v/campus/ny/cs/theOrg/shared/apps/scopt/scopt_2.10-3.1.0.jar
secret-source-resolver: no ivy file found for theOrg#scopt;2.10-3.1.0: using default data
checking theOrg#scopt;2.10-3.1.0[default] from secret-source-resolver against [none]
module revision kept as first found: theOrg#scopt;2.10-3.1.0[default] from secret-source-resolver
found theOrg#scopt;2.10-3.1.0 in secret-source-resolver
would indicate that ivy can find it, it just felt that downloading would be... bad?
I am currently using intelliJ 12.0 (company thing, v. hard to upgrade)
Any ideas?
No solution unfortunately, but we are seeing the same thing. It does not appear to be consistent however, it works as expected on some developers machines but fails with this error on others.
Using gradle, I am consuming a build from an archiva repository. One of the jars (javax.jms_1.1.0.200810061358.jar) has the following content:
about.html
about_files
LICENSE.txt
jms.jar
META-INF
MANIFEST.MF
The jar I need is actually the jms.jar inside this javax.jms_1.1.0.200810061358.jar
The only way I've been able to consume this jar is by pulling jms.jar
out of the repository's javax.jms_1.1.0.200810081358.jar and saving it
to the file system and consuming it via:
repositories { flatDir: my_dir_with_jms.jar_in_it}
someone on the gradle list suggested using an Ivy packager resolver.
I looked at this link and was
left very confused. I do have other ivy resolvers set up like this:
addIvyPattern 'http://archivaserver:8080/archiva/repository/osgi-internal/[organisation]/[module]/[revision]/ivy_[revision].xml'
addArtifactPattern
"http://archivaserver:8080/archiva/repository/osgi-official/[organisation]/[organisation]/[module]_[revision](-[classifier]).[ext]"
Anyone know of a good solution to this?
Resolving a dependency inside a dependency would require the use of the ivy packager resolver.
I've never configured the package resolver from within Gradle, but I think it would work something like the following (Referencing webpage)
repositories {
add(new org.apache.ivy.plugins.resolver.packager.PackagerResolver()) {
name = 'local Ivy packagers'
buildRoot = file("${gradle.gradleUserHomeDir}/packager/build")
resourceCache = file("${gradle.gradleUserHomeDir}/packager/cache")
addIvyPattern "file:///${project.rootDir}/ivy/[organisation]/[module]/[revision]/ivy.xml"
addArtifactPattern "file:///${project.rootDir}/ivy/[organisation]/[module]/[revision]/packager.xml"
}
}
dependencies {
compile group: 'org.myorg', name: 'jms', version: '1.1.0.200810061358'
}
The resolver requires the following files for the declared dependency:
ivy/org.myorg/jms/1.1.0.200810061358/ivy.xml
ivy/org.myorg/jms/1.1.0.200810061358/packager.xml
ivy.xml
Describes the module and in this case declares what artifacts are published:
<ivy-module version="2.0">
<info organisation="org.myorg" module="jms" revision="1.1.0.200810061358" status="release"/>
<publications>
<artifact name="jms" type="jar"/>
</publications>
</ivy-module>
packager.xml
Describes where the enclosing archive is located and instructions on how to extract jms.jar:
<packager-module version="1.0">
<resource dest="archive" url="http://archivaserver:8080/archiva/repository/??/javax.jms_1.1.0.200810061358.jar" sha1="????"/>
<build>
<move file="archive/jms.jar" tofile="artifacts/jars/jms.jar"/>
</build>
</packager-module>
The content under the build tag is used to generate an ANT script. For more details read the "Packaging instructions" section of the ivy documentation