Eclipse Community Forums: Equinox » Dependency from MANIFEST.MF does not show up in Plug-in Dependencies classpath container

Home » Eclipse Projects » Equinox » Dependency from MANIFEST.MF does not show up in Plug-in Dependencies classpath container

Show: Today's Messages :: Show Polls :: Message Navigator

Dependency from MANIFEST.MF does not show up in Plug-in Dependencies classpath container [message #1831022]

Mon, 10 August 2020 04:45

Mirko Raner

Messages: 125
Registered: July 2009
Location: New York City, NY

Senior Member

I'm in the process of upgrading a large project from Java 8 to Java 9, and I've finally succeeded to get everything to build via Maven, but now my Eclipse workbench has all kinds of problems. Specifically, there is a very fundamental dependency that is (and always was) listed in the MANIFEST.MF, but now, all of a sudden, this dependency is no longer reflected in the Plug-in Dependencies classpath container, and the workbench has hundreds of compilation problems due to that missing dependency:
index.php/fa/38758/0/

net.bytebuddy.byte-buddy, version 1.10.14 is installed into the platform from a local update site (generated by a Maven build), but for some reason it does not make it to the classpath. I also noticed that the icon is somewhat different from the other dependencies (yellow ball overlay), and the only other dependency with that same icon is a dependency on another bundle in the workspace (the .runtime bundle whose full name is redacted in the screen shot). There are other dependencies that come from the same local update site (e.g., org.jgrapht.core), and those have the same regular icon as all the other dependencies.

The MANIFEST.MF lists the dependency in the regular manner, i.e.

...
 org.jgrapht.core;bundle-version="1.4.0",
 net.bytebuddy.byte-buddy;bundle-version="1.10.14",
 javax.annotation;bundle-version="1.2.0"
Bundle-RequiredExecutionEnvironment: JavaSE-9

and I also checked the manifest of the Byte Buddy dependency itself, and it appears to be well-formed and it exports all the necessary packages.

Has anybody else seen this scenario (i.e., dependencies from the manifest don't make it into the classpath)? What other diagnostics can I run to track down what happens with the problematic dependency?

Attachment: Screen Shot.png
(Size: 664.42KB, Downloaded 4015 times)

Report message to a moderator

Re: Dependency from MANIFEST.MF does not show up in Plug-in Dependencies classpath container [message #1831026 is a reply to message #1831022]

Mon, 10 August 2020 06:47

Ed Merks

Messages: 33224
Registered: July 2009

Senior Member

This is more a PDE question than an Equinox question.

One thing I would check is the contents of the .classpath file for that project. The question is whether the .classpath is in sync with the BREE in the MANIFEST.MF, as should be the case after you invoke Plug-in Tools -> Update Classpath... from the context menu of the project I'm not sure if that could cause this problem, but it's worth checking.

It's strange that it shows the plugin without a red x indicating that it's resolved, but it doesn't show up in the classpath. Does double clicking on it open it?

Another place to see this information is from the context menu of the project Properties -> Java Build Path and then the Libraries tab. Here the icons should show if it's a jar, a folder, or something int he workspace.

Sometimes PDE just doesn't seem to update all the workspace dependencies properly, so a restart after resolving the target platform might be helpful....

I wonder if it really makes sense to have a Java 9 BREE at all. Java 9 is not an LTS version. Java 11 is LTS and the next release of the platform will require Java 11 (because of Jetty needing that and Jetty being needed for the help system).

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Dependency from MANIFEST.MF does not show up in Plug-in Dependencies classpath container [message #1831054 is a reply to message #1831026]

Mon, 10 August 2020 23:34

Mirko Raner

Messages: 125
Registered: July 2009
Location: New York City, NY

Senior Member

Thanks for your quick response, Ed! I ran Plug-in Tools ▸ Update Classpath..., and the only change to the .classpath file was in the order of the elements (the update moved the source folders to the bottom):

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
	<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-9">
		<attributes>
			<attribute name="module" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins">
		<accessrules>
			<accessrule kind="accessible" pattern="org/eclipse/xtext/common/types/**"/>
			<accessrule kind="accessible" pattern="org/eclipse/xtext/xbase/scoping/**"/>
			<accessrule kind="accessible" pattern="net/bytebuddy/implementation/**"/>
		</accessrules>
	</classpathentry>
	<classpathentry kind="src" path="src"/>
	<classpathentry kind="src" path="src-gen"/>
	<classpathentry kind="src" path="xtend-gen"/>
	<classpathentry kind="output" path="bin"/>
</classpath>

At any rate, this appears to be in line with the BREE from the manifest:

Bundle-RequiredExecutionEnvironment: JavaSE-9

Double-clicking the problematic dependency indeed opens the manifest editor, and the manifest seems to be alright:

Manifest-Version: 1.0
Bundle-Description: Byte Buddy is a Java library for creating Java cla
 sses at run time.        This artifact is a build of Byte Buddy with 
 all ASM dependencies repackaged into its own name space.
Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt
Bundle-SymbolicName: net.bytebuddy.byte-buddy
Built-By: runner
Bnd-LastModified: 1596204806688
Bundle-ManifestVersion: 2
Tool: Bnd-3.5.0.201709291849
Main-Class: net.bytebuddy.build.Plugin$Engine$Default
Export-Package: net.bytebuddy;version="1.10.14",net.bytebuddy.agent.bu
 ilder;version="1.10.14",net.bytebuddy.asm;version="1.10.14",net.byteb
.
.
.
 ",net.bytebuddy.jar.asm;version="1.10.14",net.bytebuddy.jar.asm.signa
 ture;version="1.10.14",net.bytebuddy.jar.asm.commons;version="1.10.14
 "
Bundle-Name: Byte Buddy (without dependencies)
Bundle-Version: 1.10.14
Multi-Release: true
Created-By: Apache Maven Bundle Plugin
Build-Jdk: 1.8.0_262

The dependency does not show up in Properties ▸ Java Build Path either.

I also verified that the bundle is properly installed in the platform, and that seems to be the case:

...
  545|Resolved   |    4|Apache Commons Math (2.1.0.v201105210652)|2.1.0.v201105210652
  546|Resolved   |    4|JGraphT - Core (1.4.0)|1.4.0
  547|Resolved   |    4|JHeaps (0.11.0)|0.11.0
  548|Active     |    4|Tycho Project Configurators (0.8.1.201704211436)|0.8.1.201704211436
  552|Resolved   |    4|Objenesis (2.6.0.v20180420-1519)|2.6.0.v20180420-1519
  554|Resolved   |    4|Byte Buddy (without dependencies) (1.10.14)|1.10.14
  555|Resolved   |    4|Byte Buddy Java agent (1.9.0.v20181106-1534)|1.9.0.v20181106-1534
  556|Resolved   |    4|mockito-core (2.23.0.v20200310-1642)|2.23.0.v20200310-1642
osgi>

I also tried restarting the workbench, closing/re-opening all projects, deleting/re-importing all projects, Project ▸ Clean..., etc., etc.

This all used to work fine with Byte Buddy 1.9.0 (from Orbit), which is almost two years old now and has several bugs that get in the way with Java 9 and higher.
However, I am seeing two differences between the manifest for Byte Buddy 1.9.0 and the manifest for version 1.10.14:

the newer version's manifest does not have an Automatic-Module-Name entry
the older version's manifest apparently has SHA-256-Digest entries for every single class file in the jar, which are not present in the new version's manifest

Could any of the above differences be the reason why the new JAR doesn't show up in the classpath?

Report message to a moderator

Re: Dependency from MANIFEST.MF does not show up in Plug-in Dependencies classpath container [message #1831056 is a reply to message #1831054]

Tue, 11 August 2020 00:38

Mirko Raner

Messages: 125
Registered: July 2009
Location: New York City, NY

Senior Member

Never mind... I finally solved this mystery after double-clicking the dependency bundle in the manifest editor and the enabling the Link with Editor option in the Package Explorer.
It turns out that, at some point, I had extracted the bundle's manifest via jar xf bytebuddy.jar META-INF/MANIFEST.MF. I happened to do this while I was in the folder of an unrelated project in my workspace, so the manifest showed up in my workspace.
The interesting thing is that this project was not a plug-in project or even a Java project (it was the Maven parent project of some other unrelated modules). This project has only the Maven nature associated with it, so I am surprised that the MANIFEST.MF file got picked up by PDE.
So, long story short, if anyone runs into a similar issue check your workspace for rogue MANIFEST.MF files.
I'm not sure if this is a PDE bug, but apparently this rogue manifest was able to displace the real manifest just because it happened to be called MANIFEST.MF and was located in a META-INF folder. I am a little baffled that this gets picked up even from non-plugin projects.

Report message to a moderator