Hi Ed,
I just saw your reply of 3/1 to Gayan Perera’s question about building a JDT distribution. I have the same issue (see below).
In reviewing
https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning, specifically section 8 (“Update the Installation and Workspace"), in what workspace/context is this to be performed? E.g. I looked in my dev workspace, and couldn’t find any Oomph tool bar contributions.
Do these instructions assume running in the Eclipse Installer?
Thanks,
-rjs
From: jdt-dev-bounces@xxxxxxxxxxx <jdt-dev-bounces@xxxxxxxxxxx>
On Behalf Of R Steiger
Sent: Tuesday, March 24, 2020 1:35 AM
To: jdt-dev@xxxxxxxxxxx
Subject: Re: [jdt-dev] discussion about my current "Enable Classpath Cycles"project
After being away from doing any eclipse work since last October, I’ve resumed getting ejc to allow project dependency cycles. (All the following in on 2020-03.)
[Stephan and Andrey, Cc’ing you since you’ve both helped orient me on this project, and also in case you’re interested in the changes I’m proposing, especially if you see problems and/or have suggestions.]
The mods I’ve made and tested are, briefly:
-
Added an Ignore option to ... -> Compiler -> Building -> Build path problems
-> Circular dependencies:
-
In JavaProject:createClasspathProblemMarker, when
Ignore is selected, in the absence of any other classpath problems, detected dependency cycles are ignored. The net effect of this is to suppress adding a buildpath problem marker to the project, altogether. This approach of ditching markers at the
earliest opportunity proved to be surgically clean, and avoided “chasing” after markers, then suppressing them downstream in the
Ignore case.
-
I hacked
MultiProjectTests:testCycle*, setting
CORE_CIRCULAR_CLASSPATH to
JavaCore.IGNORE instead of
JavaCore.WARNING, but only tested
testCycle1, which covers my core use-case.
-
Before submitting these changes, I’d like to properly parameterize the
testCycle* methods, and have them run twice, once with
IGNORE, once with
WARNING. While I have an idea how to do this without bloating the code, I’d feel better making this change after discussing how best to handle such parameterized tests with someone who’s familiar with the existing testing rubric, and maybe has implemented
such parameterization.
The next step is to road-test these mods. My thought is to locally build a stock
Eclipse IDE for Java Developers package, having the above mods, and put it into daily use for a couple of weeks, using it to work on a large code-base.
What’s the recipe for building the IDE? I’d like to use the most lightweight path, e.g. don’t need to create an update site, doesn’t require pushing to git, etc.
Thanks,
-rjs
|
