Re: [jdt-dev] [platform-dev] Need hint on how to configure launch for te

[Ed Merks <ed.merks@xxxxxxxxx>]

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 
> > > > <rsteiger@xxxxxxxxxxxxxxxx <mailto:rsteiger@xxxxxxxxxxxxxxxx>> 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
> > > > >     <rsteiger@xxxxxxxxxxxxxxxx <mailto:rsteiger@xxxxxxxxxxxxxxxx>> 
> > > > > 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@xxxxxxxxxxx <mailto:platform-dev@xxxxxxxxxxx>
> > > > >         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@xxxxxxxxxxx <mailto:platform-dev@xxxxxxxxxxx>
> > > > >     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@xxxxxxxxxxx <mailto:platform-dev@xxxxxxxxxxx>
> > > >     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@xxxxxxxxxxx
> > > > 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@xxxxxxxxxxx
> > > 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
> > jdt-dev@xxxxxxxxxxx
> > 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
> jdt-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or 
> unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jdt-dev