User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
Richard,
Unfortunately the API tools sometimes just report bogus API
problems. I semi-regularly get such errors (after doing a pull)
even though the API baseline is properly set and properly
populated with the 4.13 release's bundles and features. Typically
what makes it go away again is to do a clean build on the project
(Project -> Clean -> selected project) with these errors.
So there are no stale jars involve in these errors. The baseline
is Window -> Preferences -> Plug-in Development - API
Baselines.
Also, sometimes randomly after a pull I even get actual JDT
compile errors (syntax errors) on *.java files that are in fact
syntactically correct. Adding a space and removing that space
from the file and saving corrects the error.
A full clean build (Project -> Clean -> all projects)
generally also fixes all such problems.
When you say "the compiler plugins are still missing" are you
writing a brand new test plugin rather than adding test to
existing test plugins? The latter would seem to be easier. Even
if doing the former it would be good to look at the latter to see
how they run and which bundles are imported in the MANFEST.MF. The
things you describe must already all be done to run the JDT
tests. There are already even JDT UI tests. It it were me, I
would start by trying to run the JDT tests.
In that regard, you should have a look in Debug -> Debug
Configurations and look in JUnit and the JUnit Plug-in Test
groups. I don't think there are existing JDT test launchers,
except for JDT Debug ones. There probably should be such ones if
we want contributors to more easily find and run the appropriate
tests and run them the appropriate way. Note in particular the
distinction between a JUnit test and a JUnit Plug-in test. The
former I'm sure you're familiar with, but the latter launches the
tests as an Equinox application and will use the MANIFEST.MF
dependencies to ensure that the necessary bundles are included.
It also ensures that everything registered via plugin.xml
extensions is properly registered while running the tests.
Regards,
Ed
On 05.10.2019 00:54, 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.
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
