Hey Richard, Maybe it is caused by the fact that Eclipse is using split packages. This enables multiple bundles (plugins) to contribute to the same package. I'm guessing that parts of the org.eclipse.core.runtime package are exported by other bundles. You may need to include all bundles that contribute to this package from the workspace.
Cheers, Wim On Thu, Oct 3, 2019 at 10:41 AM Richard Steiger <rstei...@ensemblesoft.net> wrote: > As I've discussed in prior messages to platform-dev@, I'm working on > prototyping a proposed new ejc feature, to surface an option in the IDE's > Java compiler preferences, allowing setting JavaCore. > *CORE_CIRCULAR_CLASSPATH*, and adding an IGNORE value to it's range (in > addition to ERROR and WARN), with the ultimate purpose of allowing building > systems that intentionally leverage mutually-recursive modules (where I use > *module > *in the classic sense, not the JDK's Module subsystem since 9). > > As I've also promised, I'll be creating a feature bug that explains the > background, rationale, and proposed code changes, hopefully by this > Friday. That said, prior to doing so, I feel it's essential for me to > empirically verify that this mod works end-to-end as I intend, and, for > example, doesn't spawn a class-loading or other runtime hornet's nest > (that's not straightforwardly avoided|addressed). > > To this verification end, I'm trying to run a test harness that > > 1. selects the IGNORE option, > 2. builds 2 (*test*) *subject *projects that are mutually-dependent, > 3. assuming that the subject projects successfully build, launches the > main (entry-point) project (which triggers loading the second one, etc), > and > 4. assuming no hornets appear, verifies that at least a minimal > circular classpath case is correctly handled, end-to-end. > > I've spent quite a bit of time reading eclipse docs, how-tos, the *Eclipse > Plugins* bible (3rd ed), and browsed a fair amount of JDT code, trying to > figure out how to get the test to work, and at this point, my pick is > bent. I could really use a hint how to proceed. > > To set context, the test project, and both subject projects, all reside in > the jdt-master workspace (btw, is there a vernacular shorthand for this > workspace?). My first attempt to get the test to work was simply to either > run or debug it as a Java app. It fails with the backtrace > > Exception in thread "main" java.lang.SecurityException: class > "org.eclipse.core.runtime.IStatus"'s signer information does not match > signer information of other classes in the same package > at java.lang.ClassLoader.checkCerts(ClassLoader.java:898) > at java.lang.ClassLoader.preDefineClass(ClassLoader.java:668) > at java.lang.ClassLoader.defineClass(ClassLoader.java:761) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:468) > at java.net.URLClassLoader.access$100(URLClassLoader.java:74) > at java.net.URLClassLoader$1.run(URLClassLoader.java:369) > at java.net.URLClassLoader$1.run(URLClassLoader.java:363) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:362) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > at > net.ess.jcore.CompilerRunner.configureCompiler(CompilerRunner.java:47) > at net.ess.jcore.CompilerRunner.doCompilation(CompilerRunner.java:42) > at net.ess.jcore.CompilerRunner.main(CompilerRunner.java:37) > > Just prior to throwing the SecurityException, the JVM's classpath is > > > C:\Users\rsteiger\.p2\pool\plugins\org.eclipse.osgi_3.15.0.v20190830-1434.jar > > C:\Users\rsteiger\.p2\pool\plugins\org.eclipse.osgi.compatibility.state_1.1.600.v20190814-1451.jar > > C:\Users\rsteiger\.p2\pool\plugins\org.eclipse.equinox.common_3.10.500.v20190815-1535.jar > T:\eclipse\SDK\jdt-master\git\eclipse.platform.runtime\bundles\ > org.eclipse.core.jobs\bin > > C:\Users\rsteiger\.p2\pool\plugins\org.eclipse.equinox.registry_3.8.500.v20190714-1850.jar > > C:\Users\rsteiger\.p2\pool\plugins\org.eclipse.equinox.preferences_3.7.500.v20190815-1535.jar > C:\Users\rsteiger\.p2\pool\plugins\javax.xml_1.3.4.v201005080400.jar > > T:\eclipse\SDK\jdt-master\git\eclipse.platform.runtime\bundles\org.eclipse.core.contenttype\bin > > C:\Users\rsteiger\.p2\pool\plugins\org.eclipse.equinox.app_1.4.300.v20190815-1535.jar > > T:\eclipse\SDK\jdt-master\git\eclipse.platform.runtime\bundles\org.eclipse.core.runtime\bin > T:\eclipse\SDK\jdt-master\git\eclipse.jdt.core\org.eclipse.jdt.core\antbin > T:\eclipse\SDK\jdt-master\git\eclipse.jdt.core\org.eclipse.jdt.core\bin > > T:\eclipse\SDK\jdt-master\git\eclipse.platform.debug\org.eclipse.core.variables\bin > > C:\Users\rsteiger\.p2\pool\plugins\org.apache.ant_1.10.5.v20190526-1402\lib\ant.jar > > C:\Users\rsteiger\.p2\pool\plugins\org.apache.ant_1.10.5.v20190526-1402\lib\ant-launcher.jar > > T:\eclipse\SDK\jdt-master\git\eclipse.platform\ant\org.eclipse.ant.core\src_ant_bin > T:\eclipse\SDK\jdt-master\git\eclipse.platform\ant\org.eclipse.ant.core\bin > > T:\eclipse\SDK\jdt-master\git\eclipse.platform.runtime\bundles\org.eclipse.core.expressions\bin > > T:\eclipse\SDK\jdt-master\git\eclipse.platform.resources\bundles\org.eclipse.core.filesystem\bin > > T:\eclipse\SDK\jdt-master\git\eclipse.platform.resources\bundles\org.eclipse.core.resources\bin > T:\eclipse\SDK\jdt-master\git\eclipse.platform.text\org.eclipse.text\bin > > T:\eclipse\SDK\jdt-master\git\eclipse.platform.ui\bundles\org.eclipse.core.commands\bin > C:\Users\rsteiger\.p2\pool\plugins\com.ibm.icu_64.2.0.v20190507-1337.jar > > T:\eclipse\SDK\jdt-master\git\eclipse.platform.team\bundles\org.eclipse.team.core\bin > > T:\eclipse\SDK\jdt-master\git\eclipse.platform.team\bundles\org.eclipse.compare.core\bin > > T:\eclipse\SDK\jdt-master\git\eclipse.jdt.core\org.eclipse.jdt.compiler.apt\bin > > T:\eclipse\SDK\jdt-master\git\eclipse.jdt.core\org.eclipse.jdt.compiler.apt\lib\java10api.jar > > T:\eclipse\SDK\jdt-master\git\eclipse.jdt.core\org.eclipse.jdt.compiler.tool\bin > > T:\eclipse\SDK\jdt-master\git\eclipse.jdt.core\org.eclipse.jdt.compiler.tool\lib\java10api.jar > > My understanding is that the launchConfiguration that's being generated > and applied is erroneous: as can be seen, the classpath includes references > to plugin jars in my base eclipse installation (paths starting with > C:\Users\rsteiger\.p2\pool\plugins\), and not from the just-built > jdt-master workspace (paths starting with T:\eclipse\SDK\jdt-master\git\). > I've tried several approaches to fix this: > > - made the test project into a plugin (not sure I didn't goof this up, > since am a plugin-noob); > - discovering that the project's *Plug-in Dependencies* is a read-only > classpath container containing the above incorrect jars, tried removing > <classpathentry > kind="con" path="org.eclipse.pde.core.requiredPlugins"/> from the > project's .classpath, then adding kind="lib" entries for (what I > thought are) the correct jars; > - revisiting various references describing care and feeding of > launchConfigs, finding nothing covering how to configure configs from the > jdt workspace UI, just how to do so programmatically (which is of course > totally useless in this context); and > - gnashing my teeth and swearing. > > None of these approaches have helped. > > I turn to y'all to suggest a viable approach. > > Thanks in advance, > > -rjs > _______________________________________________ > platform-dev mailing list > platform-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________ platform-dev mailing list platform-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
