Re: [platform-dev] Need hint on how to configure launch for testing compiler mod

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [platform-dev] Need hint on how to configure launch for testing compiler mod

Stephan Herrmann-2
The versioning issues you are seeing are reported by "API Tooling", which helps
us to remain honest in how we evolve JDT's API. You could either disable API
analysis in your workspace (as long as you are not modifying JDT API), or try to
configure a proper Baseline (2019-09 atm).

For dependencies of your plugin: have you added "org.eclipse.jdt.core" under
"Require-Bundle"?

As for a live session: feel free to join us at EclipseCon [1], which is the
perfect place to meet some of us in person, and where we could easily arrange a
little hands-on session.

best,
Stephan

[1] https://www.eclipsecon.org/europe2019

On 05.10.19 02:23, Richard Steiger wrote:

> Apologies for sending to platform-dev instead of the intended jdt-dev (Stephan
> clued me in, but hit Reply List without checking).
>
> On 10/4/2019 3:54 PM, Richard Steiger wrote:
>>
>> Wim,
>>
>> Thanks for the helpful remarks.
>>
>> I've rebuilt my test project from scratch using PDE, and am seeing somewhat
>> similar displays in the various editors to those you shared.  I've also
>> reviewed some plugin dev tutorials and related materials, so have a slightly
>> clearer conceptual map of JDT.
>>
>> In PDE, I fiddled around with asking the (I think) Manifest Editor to
>> auto-discover the required plugins.  The resulting new project is reporting 25
>> errors, most are due (its seems) to stale version qualifiers, the following
>> lines are a reasonable proxy for most of the problems (copied from Problems view):
>>
>> Invalid @since 3.19 tag on newAST(int, boolean); expecting @since 3.20
>> AST.java /org.eclipse.jdt.core/dom/org/eclipse/jdt/core/dom    line 438    
>> @since tag problem
>> Invalid @since 3.19 tag on propertyDescriptors(int, boolean); expecting @since
>> 3.20    SwitchExpression.java
>> /org.eclipse.jdt.core/dom/org/eclipse/jdt/core/dom    line 93    @since tag
>> problem
>> Invalid @since 3.19 tag on RedundantNullCheckOnConstNonNullField; expecting
>> @since 3.20    IProblem.java
>> /org.eclipse.jdt.core/compiler/org/eclipse/jdt/core/compiler line 1806    
>> @since tag problem
>> Invalid @since 3.9 tag on org.eclipse.jface.text.MultiStringMatcher; expecting
>> @since 3.10    MultiStringMatcher.java
>> /org.eclipse.text/src/org/eclipse/jface/text    line 30 @since tag problem
>> Project has only main sources but depends on project
>> 'org.eclipse.jdt.core.tests.builder' which has only test sources.    
>> net.ess.tools.ejcx        Build path    Build Path Problem
>> The minor version should be incremented in version 3.8.700, since new APIs
>> have been added since version 3.8.500    MANIFEST.MF
>> /org.eclipse.ui.console/META-INF    line 5    Version Numbering Problem
>> The minor version should be the same for version 1.6.0, since no new APIs have
>> been added since version 1.5.0    MANIFEST.MF
>> /org.eclipse.core.databinding.beans/META-INF    line 5 Version Numbering Problem
>>
>> At this point, my blockers are
>>
>>   * I haven't discovered where the stale jars are specified (can't find
>>     anything in any project artifacts), and
>>   * the compiler plugins are still missing, despite my test project importing
>>     org.eclipse.jdt.core.JavaCore,
>>     org.eclipse.jdt.core.compiler.CompilationProgress, and
>>     org.eclipse.jdt.core.compiler.batch.BatchCompiler (which seem should have
>>     a hefty transitive closure, i.e. I expect to see >> 3 dependencies).
>>
>> Stepping back from such details, my concern at this juncture is that what I'm
>> trying to do is somewhat subtle, involves a lot of moving parts, and my
>> previous test approach has holes in it that will require invoking a lot more
>> JDT and related machinery beyond the compiler.  For example, I suspect I'll
>> need to either load the subject projects in the Runtime Workbench (where the
>> modified compiler is) instead of the Development Workbench (where the
>> unmodified compiler faults their builds due to cp cycles), then build the new
>> projects, then load and execute them, thereby completing the e2e verification.
>>
>> Given my ponderous pace up to now, extrapolating to getting this working (even
>> taking my forward learning curve into account) could take a lot of
>> hand-holding, i.e. your and/or others' time (given willingness, and I'm not
>> assuming anything).
>>
>> Let me suggest an alternative: if you or another expert would be willing to
>> get on a video call, at your convenience, and we could essentially pair-up on
>> debugging the launch configuration, it might go pretty fast, and cost
>> significantly less of everyone's time.  Could that work?
>>
>> Meanwhile, I'll refine the test harness per the above realizations, so I'll
>> have a more complete set of JDT plugin dependencies to work with.
>>
>> FWIW, I'm also willing to pay it forward by contributing what I've learned
>> (once I've really learned it :-) to (existing or new) documentation.
>>
>> Thanks again,
>>
>> -rjs
>>
>> On 10/4/2019 1:29 AM, Wim Jongman wrote:
>>> Hi Richard,
>>>
>>> If you open the MANIFEST.MF part of your new plugin you notice a green run
>>> icon in the top left of the editor. This will launch your bundle in a new
>>> eclipse instance AND will create a run configuration.
>>>
>>> eclipse_2019-10-04_10-13-37.png
>>>
>>> The run configurations can be edited via an action in the toolbar of the java
>>> perspective.
>>>
>>>
>>> image.png
>>>
>>> Find your configuration and examine all the tabs. The Plug-ins (bundles) tab
>>> lets you select the location from where the bundle should be picked.
>>>
>>> eclipse_2019-10-04_10-20-07.png
>>>
>>>
>>> On Thu, Oct 3, 2019 at 12:57 PM Richard Steiger <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>
>>>     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
>>>>     <[hidden email] <mailto:[hidden email]>> 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
>>>>         [hidden email] <mailto:[hidden email]>
>>>>         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
>>>>     [hidden email]  <mailto:[hidden email]>
>>>>     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
>>>     [hidden email] <mailto:[hidden email]>
>>>     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
>>> [hidden email]
>>> 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
>> [hidden email]
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>
> _______________________________________________
> jdt-dev mailing list
> [hidden email]
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jdt-dev
>

_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: [platform-dev] Need hint on how to configure launch for testing compiler mod

Ed Merks-2
Stephan,

As I mentioned on the other mailing list, sometimes the API tools just
produce bogus errors that can be removed with a clean build. If the IDE
was setup with Oomph, it will have a correct baseline (based currently
on the 4.13 release).  (Sometimes after a pull there are even phantom
syntax errors; a no-op edit and save on the file removes it.)

On 05.10.2019 14:54, Stephan Herrmann wrote:

> The versioning issues you are seeing are reported by "API Tooling",
> which helps us to remain honest in how we evolve JDT's API. You could
> either disable API analysis in your workspace (as long as you are not
> modifying JDT API), or try to configure a proper Baseline (2019-09 atm).
>
> For dependencies of your plugin: have you added "org.eclipse.jdt.core"
> under "Require-Bundle"?
>
> As for a live session: feel free to join us at EclipseCon [1], which
> is the perfect place to meet some of us in person, and where we could
> easily arrange a little hands-on session.
>
> best,
> Stephan
>
> [1] https://www.eclipsecon.org/europe2019
>
> On 05.10.19 02:23, Richard Steiger wrote:
>> Apologies for sending to platform-dev instead of the intended jdt-dev
>> (Stephan clued me in, but hit Reply List without checking).
>>
>> On 10/4/2019 3:54 PM, Richard Steiger wrote:
>>>
>>> Wim,
>>>
>>> Thanks for the helpful remarks.
>>>
>>> I've rebuilt my test project from scratch using PDE, and am seeing
>>> somewhat similar displays in the various editors to those you
>>> shared.  I've also reviewed some plugin dev tutorials and related
>>> materials, so have a slightly clearer conceptual map of JDT.
>>>
>>> In PDE, I fiddled around with asking the (I think) Manifest Editor
>>> to auto-discover the required plugins.  The resulting new project is
>>> reporting 25 errors, most are due (its seems) to stale version
>>> qualifiers, the following lines are a reasonable proxy for most of
>>> the problems (copied from Problems view):
>>>
>>> Invalid @since 3.19 tag on newAST(int, boolean); expecting @since
>>> 3.20 AST.java /org.eclipse.jdt.core/dom/org/eclipse/jdt/core/dom   
>>> line 438    @since tag problem
>>> Invalid @since 3.19 tag on propertyDescriptors(int, boolean);
>>> expecting @since 3.20    SwitchExpression.java
>>> /org.eclipse.jdt.core/dom/org/eclipse/jdt/core/dom    line 93   
>>> @since tag problem
>>> Invalid @since 3.19 tag on RedundantNullCheckOnConstNonNullField;
>>> expecting @since 3.20    IProblem.java
>>> /org.eclipse.jdt.core/compiler/org/eclipse/jdt/core/compiler line
>>> 1806    @since tag problem
>>> Invalid @since 3.9 tag on org.eclipse.jface.text.MultiStringMatcher;
>>> expecting @since 3.10    MultiStringMatcher.java
>>> /org.eclipse.text/src/org/eclipse/jface/text    line 30 @since tag
>>> problem
>>> Project has only main sources but depends on project
>>> 'org.eclipse.jdt.core.tests.builder' which has only test sources.   
>>> net.ess.tools.ejcx        Build path    Build Path Problem
>>> The minor version should be incremented in version 3.8.700, since
>>> new APIs have been added since version 3.8.500 MANIFEST.MF
>>> /org.eclipse.ui.console/META-INF    line 5 Version Numbering Problem
>>> The minor version should be the same for version 1.6.0, since no new
>>> APIs have been added since version 1.5.0    MANIFEST.MF
>>> /org.eclipse.core.databinding.beans/META-INF    line 5 Version
>>> Numbering Problem
>>>
>>> At this point, my blockers are
>>>
>>>   * I haven't discovered where the stale jars are specified (can't find
>>>     anything in any project artifacts), and
>>>   * the compiler plugins are still missing, despite my test project
>>> importing
>>>     org.eclipse.jdt.core.JavaCore,
>>>     org.eclipse.jdt.core.compiler.CompilationProgress, and
>>>     org.eclipse.jdt.core.compiler.batch.BatchCompiler (which seem
>>> should have
>>>     a hefty transitive closure, i.e. I expect to see >> 3
>>> dependencies).
>>>
>>> Stepping back from such details, my concern at this juncture is that
>>> what I'm trying to do is somewhat subtle, involves a lot of moving
>>> parts, and my previous test approach has holes in it that will
>>> require invoking a lot more JDT and related machinery beyond the
>>> compiler.  For example, I suspect I'll need to either load the
>>> subject projects in the Runtime Workbench (where the modified
>>> compiler is) instead of the Development Workbench (where the
>>> unmodified compiler faults their builds due to cp cycles), then
>>> build the new projects, then load and execute them, thereby
>>> completing the e2e verification.
>>>
>>> Given my ponderous pace up to now, extrapolating to getting this
>>> working (even taking my forward learning curve into account) could
>>> take a lot of hand-holding, i.e. your and/or others' time (given
>>> willingness, and I'm not assuming anything).
>>>
>>> Let me suggest an alternative: if you or another expert would be
>>> willing to get on a video call, at your convenience, and we could
>>> essentially pair-up on debugging the launch configuration, it might
>>> go pretty fast, and cost significantly less of everyone's time. 
>>> Could that work?
>>>
>>> Meanwhile, I'll refine the test harness per the above realizations,
>>> so I'll have a more complete set of JDT plugin dependencies to work
>>> with.
>>>
>>> FWIW, I'm also willing to pay it forward by contributing what I've
>>> learned (once I've really learned it :-) to (existing or new)
>>> documentation.
>>>
>>> Thanks again,
>>>
>>> -rjs
>>>
>>> On 10/4/2019 1:29 AM, Wim Jongman wrote:
>>>> Hi Richard,
>>>>
>>>> If you open the MANIFEST.MF part of your new plugin you notice a
>>>> green run icon in the top left of the editor. This will launch your
>>>> bundle in a new eclipse instance AND will create a run configuration.
>>>>
>>>> eclipse_2019-10-04_10-13-37.png
>>>>
>>>> The run configurations can be edited via an action in the toolbar
>>>> of the java perspective.
>>>>
>>>>
>>>> image.png
>>>>
>>>> Find your configuration and examine all the tabs. The Plug-ins
>>>> (bundles) tab lets you select the location from where the bundle
>>>> should be picked.
>>>>
>>>> eclipse_2019-10-04_10-20-07.png
>>>>
>>>>
>>>> On Thu, Oct 3, 2019 at 12:57 PM Richard Steiger
>>>> <[hidden email] <mailto:[hidden email]>> wrote:
>>>>
>>>>     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
>>>>>     <[hidden email] <mailto:[hidden email]>>
>>>>> 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
>>>>>         [hidden email] <mailto:[hidden email]>
>>>>>         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
>>>>>     [hidden email] <mailto:[hidden email]>
>>>>>     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
>>>>     [hidden email] <mailto:[hidden email]>
>>>>     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
>>>> [hidden email]
>>>> 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
>>> [hidden email]
>>> To change your delivery options, retrieve your password, or
>>> unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>
>> _______________________________________________
>> jdt-dev mailing list
>> [hidden email]
>> To change your delivery options, retrieve your password, or
>> unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jdt-dev
>>
>
> _______________________________________________
> jdt-dev mailing list
> [hidden email]
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jdt-dev
_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev