Wim,

Thanks for the advice.   Using any available UI, how does one control which bundles are exported for a given launch?   Or, is there a doc that explains this?

Thanks again,

-rjs

On 10/3/2019 2:41 AM, Wim Jongman wrote:
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 <mailto: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
        <http://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 <mailto: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
_______________________________________________
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

Reply via email to