Details
-
Type:
Task
-
Status: Closed (View Workflow)
-
Priority:
Major
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: None
-
Labels:None
-
Story Points:2
-
Epic Link:
-
Sprint:Spring 9 2023 May 1
Description
After updating the libraries and running IGB, some of the many errors that appear at runtime is an osgi wiring package error attributed to com.apple.laf as shown below.
[main] ERROR com.affymetrix.main.OSGiHandler - Unable to resolve org.lorainelab.igb.bai [5](R 5.0): missing requirement [org.lorainelab.igb.bai [5](R 5.0)] osgi.wiring.package; (&(osgi.wiring.package=com.affymetrix.genometry.comparator)(version>=9.1.0)(!(version>=10.0.0))) [caused by: Unable to resolve genometry [30](R 30.0): missing requirement [genometry [30](R 30.0)] osgi.wiring.package; (osgi.wiring.package=com.apple.laf)] Unresolved requirements: [[org.lorainelab.igb.bai [5](R 5.0)] osgi.wiring.package; (&(osgi.wiring.package=com.affymetrix.genometry.comparator)(version>=9.1.0)(!(version>=10.0.0)))] org.osgi.framework.BundleException: Unable to resolve org.lorainelab.igb.bai [5](R 5.0): missing requirement [org.lorainelab.igb.bai [5](R 5.0)] osgi.wiring.package; (&(osgi.wiring.package=com.affymetrix.genometry.comparator)(version>=9.1.0)(!(version>=10.0.0))) [caused by: Unable to resolve genometry [30](R 30.0): missing requirement [genometry [30](R 30.0)] osgi.wiring.package; (osgi.wiring.package=com.apple.laf)] Unresolved requirements: [[org.lorainelab.igb.bai [5](R 5.0)] osgi.wiring.package; (&(osgi.wiring.package=com.affymetrix.genometry.comparator)(version>=9.1.0)(!(version>=10.0.0)))] at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4398) at org.apache.felix.framework.Felix.startBundle(Felix.java:2308) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:1006) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:992) at com.affymetrix.main.OSGiHandler.loadBundles(OSGiHandler.java:83) at com.affymetrix.main.OSGiHandler.startOSGi(OSGiHandler.java:63) at com.affymetrix.main.Main.main(Main.java:30)
Task: Determine why this error is appearing, if it can be fixed then update this ticket as needed.
Attachments
Issue Links
Activity
So far I have been unable to provide the com.sun.java.swing.plaf.windows capabilities in such a way that it fulfills the requirements for jidesoft. I am unable to locate or create a jar file for plaf.windows. I am unable to make my own bundle with the plaf.windows classes as they have intricate dependencies on the rest of the jdk, to the extent that we would have to add hundreds of additional classes. However, while testing I added an export statement to the igb pom for com.sun.java.swing.plaf.windows. This effectively tricks OSGI and all bundles are able to be resolved. However, the IGB application does not appear when the jar is started indicating there are still other issues.
One of the issues may be that we do need to provide access to the java.desktop module. While sun.* and some parts of com.sun.* are not exported/made available, other parts such as java.awt.color (which we use) are exported by the java.desktop module. IGV uses the module-info.java to require the java.desktop module in their use of Java 11. However, I am unclear how IGB's use of OSGI interacts with the module system. At the moment I am investigating how we might be able to use the module system with IGB.
Suggestions:
1)
If the apple and windows laf packages, their classes, and their methods are all known, we could create classes with all those methods, but not fully implemented. They would return the declared values, but the actual values themselves would be meaningless. If the Jidesoft code IGB uses does not actually use these "laf" class objects or methods, then the Jidesoft code would run perfectly well alongside this faked laf code. Also, none of these packages could be exported from the bundle.
2)
We locate "laf" jar files that satisfy jidesoft's requirements and package those with the jidesoft code as a bundle that does not export the "laf" packages but makes them available to the jidesoft code packaged with them.
I think 1) or 2) could work because we're running IGB inside an OSGi framework / run-time. It gives us multiple java classpaths in a single application. In theory, this aspect lets us use different versions of the same library in isolation from each other, in the same application.
From a computer science perspective, it might be interesting to try this. We might discover a new aspect of software engineering in the process.
Stackoverflow - OpenJDK 11: Getting ClassNotFound on Linux, works fine on windows
It appears that JDK 11 does not include the look and feel for all operating systems. So the jdk I have for Mac does not include the windows look and feel. This would suggest that there is not a way to use the --add-export for the java.desktop module. The remaining solutions would be to include the required look and feel files or to remove Jide from the IGB project.
Open JDK: Manipulating of dock icon under OSX in Java 9
Blog: What is Java MacOS Dock: -Xdock ?
While investigating this issue I found the above resources regarding changes that will be needed for the IGB icon to appear correctly in the dock on Mac when running Java 11. We will most likely need to rewrite MacIntegration.java.
- The two mentions of com.apple.laf is in the src/main/resources/config.properties and in core/genometry/pom.xml and it doesn't seem to packaged with IGB code.
- In the genometry pom.xml its a single line:
<Import-Package>com.apple.laf,*;resolution:=optional</Import-Package> - The errors mentioning com.apple.laf point to the plugins module, specifically, bai, bed, bam, bigBedHandler, bigWigHandler
As it is unclear if we can provide jidesoft with the required laf dependencies, we are going to try to remove jidesoft from IGB.
Closing ticket.