User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
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.
The run configurations can be edited via an
action in the toolbar of the java perspective.
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.
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.
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
selects the IGNORE option,
builds 2 (test) subject projects
that are mutually-dependent,
assuming that the subject projects
successfully build, launches the main
(entry-point) project (which triggers loading
the second one, etc), and
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
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