Community
Participate
Working Groups
I20081014 The PDE project is looking for the wrong jar file on disk which cause the project to fail compiling. Steps to reproduce: - load org.eclipse.equinox.p2.director project from the RT repository (/cvsroot/rt). The project is located under org.eclipse.equinox/p2/bundles. - compile and notice the compile error, you will see that it is looking for a file called org.sat4j.core.jar whereas the file on disk is org.sat4j.core_v....jar
Any idea when this started to happen? I just traced through PDE code and it's added things properly to the classpath. /Users/chrisaniszczyk/eclipses/eclipse-SDK-3.5M3/eclipse/plugins/org.sat4j.core_2.0.0.v20080602.jar[CPE_LIBRARY][K_BINARY][sourcePath:/Users/chrisaniszczyk/eclipses/eclipse-SDK-3.5M3/eclipse/plugins/org.sat4j.core_2.0.0.v20080602.jar][isExported:false][AccessRuleSet {pattern=org/sat4j/* (ACCESSIBLE), pattern=org/sat4j/core/* (ACCESSIBLE), pattern=org/sat4j/minisat/* (ACCESSIBLE), pattern=org/sat4j/minisat/constraints/* (ACCESSIBLE), pattern=org/sat4j/minisat/constraints/card/* (ACCESSIBLE), pattern=org/sat4j/minisat/constraints/cnf/* (ACCESSIBLE), pattern=org/sat4j/minisat/core/* (ACCESSIBLE), pattern=org/sat4j/minisat/learning/* (ACCESSIBLE), pattern=org/sat4j/minisat/orders/* (ACCESSIBLE), pattern=org/sat4j/minisat/restarts/* (ACCESSIBLE), pattern=org/sat4j/minisat/uip/* (ACCESSIBLE), pattern=org/sat4j/opt/* (ACCESSIBLE), pattern=org/sat4j/reader/* (ACCESSIBLE), pattern=org/sat4j/specs/* (ACCESSIBLE), pattern=org/sat4j/tools/* (ACCESSIBLE), pattern=**/* (NON ACCESSIBLE | IGNORE IF BETTER)} [classpath entry: /Users/chrisaniszczyk/eclipses/eclipse-SDK-3.5M3/eclipse/plugins/org.sat4j.core_2.0.0.v20080602.jar]] debugging JDT code...
figured it out. org.sat4j.pb has this header: Class-Path: org.sat4j.core.jar JavaProject, line 2577 // resolve Class-Path: in manifest ClasspathEntry[] extraEntries = cEntry.resolvedChainedLibraries(); for (int k = 0, length2 = extraEntries.length; k < length2; k++) { addToResult(rawEntry, extraEntries[k], result, resolvedEntries, externalFoldersManager); } That line is adding 'org.sat4j.core.jar' to the build path based on the Class-Path entry in the MANIFEST.MF of org.sat4j.pb. If that header is removed, I think we'll be fine. I think JDT needs to be more careful when adding these types of entries.
It works in one of my workspace, but it fails in a fresh new workspace.
Moving to JDT/Core.
bug 250973 is probably a dup then. PW
Shouldn't classpath be only related to OSGi declarations for OSGi bundles? I use the Class-Path entry for auto-executable jars. That way, the same jar can be used as OSGi bundles and as command line tools.
*** Bug 250973 has been marked as a duplicate of this bug. ***
To summarize the issue, a build path problem is reported because a plugin contains a bogus reference in its MANIFEST.MF's Class-Path: I will make sure that we don't report such problem in the future. In the meantime, a workaround is to set "Preferences > Compiler > Building > Build path problems > Incomplete build path" to Warning.
Jerome, Am I supposed to either remove the Class-Path: entry or to fill it with the jar file using Eclipse naming convention for the next release of SAT4J?
(In reply to comment #9) > Jerome, > > Am I supposed to either remove the Class-Path: entry or to fill it with the jar > file using Eclipse naming convention for the next release of SAT4J? > Daniel, I would say that using Eclipse naming convention would be better. However I'm wondering why the Class-Path: is simply there. Is it used at runtime? If it is, how can this works since the referenced jar doesn't exist? Do you look up a jar with a similar name at runtime?
Created attachment 115233 [details] Proposed fix and regression test
Jerome, The Class-Path entry is there because some (me included :)) users of SAT4J use it from the command line and I would like to use the same jar files for my OSGi bundles and my auto-executable jar files. The two packages that ship with Eclipse contain the Pseudo Boolean solvers that take an input file and display a solution according to the guidelines in http://www.cril.univ-artois.fr/PB07/ When I build the jar files, they are named org.sat4j.core.jar and org.sat4j.pb.jar to make life easier for command line users. Pascal renames the jar files according to Eclipse guidelines before integration into Orbit. Until now, it did not cause any trouble since Eclipse was only relying on the OSGi information available in the manifest file. If this is a wrong practice, I will simply generate the jar files using Eclipse guidelines and fix the Class-Path entry to make it consistent with the bundle names.
(In reply to comment #12) Thanks for the explanation Daniel. I think I now understand: org.sat4j.pb has 2 ways to define its dependency to org.sat4j.core. The Require-Bundle: entry and the Class-Path: entry. The first one is used by PDE at compile time and OSGI at runtime. The second one is used by JDT at compile time and the VM at runtime. The problem is that JDT is not permissive enough and creates a build path marker if the jar referenced by the Class-Path: entry doesn't exit. One way to solve this would be for you to change the reference in the Class-Path: entry to a jar with a name that follows the Eclipse guideline (and thus this jar would exist). The other way is for JDT to simply not create a build path marker. This is what the proposed fix from comment 11 does. I will go with the latter solution since (as shown by 250973) other jars exist which assume that the Class-Path: entry is optional (i.e. that the jar may or may not exit).
It looks like this bug is preventing us from compiling our workspaces when using an IBM JDK as the default JRE. (See also bug 251079 - is this related in any way?) Are you planning to ask for a rebuild?
(In reply to comment #14) > It looks like this bug is preventing us from compiling our workspaces when > using an IBM JDK as the default JRE. Are you saying that the workaround from comment 8 doesn't work for you? > (See also bug 251079 - is this related in any way?) I don't think this is related. > Are you planning to ask for a rebuild? Only if the workaround doesn't work.
(In reply to comment #8) > I will make sure that we don't report such problem in the future. In the > meantime, a workaround is to set "Preferences > Compiler > Building > Build > path problems > Incomplete build path" to Warning. This workaround is not really an option for us since all these settings are project-specific. We'd have to go through all our projects, change this, check in the change, and then remember to undo it later.
Fix and test released for 3.5M3. I'm preparing the build input and I will ask for a rebuild when ready.
If possible it would be much better for SAT4J come as real bundles rather than nesting the JAR inside. This is the standard way we package and ship third party (see pretty much any Orbit bundle). If the SAT4J team could produce such a bundle that would be fantastic. If not, then we should package the provided JAR as a bundle using the Orbit conventions. AFAIK there is nothing special about SAT4J that should demand special packaging. While the issue in JDT may still be real and bear fixing, this is approach would both avoid the problem and help SAT4J follow the Eclipse best practices.
(In reply to comment #18) > If possible it would be much better for SAT4J come as real bundles rather than > nesting the JAR inside. This is the standard way we package and ship third > party (see pretty much any Orbit bundle). If the SAT4J team could produce such > a bundle that would be fantastic. If not, then we should package the provided > JAR as a bundle using the Orbit conventions. AFAIK there is nothing special > about SAT4J that should demand special packaging. > > While the issue in JDT may still be real and bear fixing, this is approach > would both avoid the problem and help SAT4J follow the Eclipse best practices. > SAT4J is a real bundle, correct? The issue is when using sat4j from the command line without OSGi: java -jar org.sat4j.pb.jar In this case the org.sat4j.core.jar is *not* embedded in the org.sat4j.pb.jar, instead it is in the same directory as the pb.jar and the VM adds the core.jar to the app classpath along with the pb.jar. I imagine the SAT4J folks do not want to use the version of core down to the qualifier in their Class-Path header for the same reason we do not restrict Require-Bundle version ranges down to the qualifier. It is too brittle.
Thomas, you are right. That's exactly the problem.
I verified that the fix is getting rid of both errors (the one from p2.director and the one from IBM JDK 6).
The problem is no longer an error, but we should make the warning optional. Setting up a project with an IBM 1.6.0 as the JRE leads too many warnings in the .log file each time the classpath is touched. eclipse.buildId=I20081026-2000 java.version=1.6.0_10 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=fr_CA Command-line arguments: -os win32 -ws win32 -arch x86 -debug -consolelog -console Warning Mon Oct 27 16:10:56 EDT 2008 Invalid Class-Path header in manifest of jar file: D:\jdks\ibm1.6.0\jre\lib\ibmcfw.jar Verified for 3.5M3 using I20081026-2000
In some cases, I still get a build path error.
*** Bug 252364 has been marked as a duplicate of this bug. ***
(In reply to comment #23) > In some cases, I still get a build path error. This is tracked by bug 252392
I've just seen this in I20081210-0100 (the current M4 candidate). All OK...then error spam. Clean/rebuild...no dice...shutdown/restart...no dice...Arghh!! Switched back to a previous install (I20081202-1812)..all OK. I've also seen this in yesterday's build on my co-op's Workspace... We're both using an IBM jre...
Mike Valenta just ran into this and switching to a Sun JRE solved it...
If there is still an issue with IBM VM, please reopen it and provide steps to reproduce.
(In reply to comment #26) > I've just seen this in I20081210-0100 (the current M4 candidate). Eric can you please clarify what "this" is? Note that comment 0 refers to the wrong org.sat4j.core.jar being looked up? Is this what you're seeing? If not please enter a separate bug report.
And do not reopen if it is a different issue than comment 0.
I think Eric is getting what I reported in comment 22.
(In reply to comment #31) > I think Eric is getting what I reported in comment 22. > Really? A warning in the log and this is reported as: " All OK...then error spam. Clean/rebuild...no dice...shutdown/restart...no dice...Arghh!! Switched back to a previous install (I20081202-1812)..all OK."
