[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-dev] discussion about my current "Enable Classpath Cycles"project
|
Sorry, I must have overlooked this in my daily flood of email.
Note that in the wiki it references
https://bugs.eclipse.org/bugs/show_bug.cgi?id=536533 also for
asking question. In the Platform SDK Setup there is this
preference task:
<?xml version="1.0" encoding="UTF-8"?>
<setup:CompoundTask
xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:setup="http://www.eclipse.org/oomph/setup/1.0"
name="org.eclipse.oomph.setup.ui">
<setupTask
xsi:type="setup:PreferenceTask"
key="/instance/org.eclipse.oomph.setup.ui/showToolBarContributions"
value="true"/>
</setup:CompoundTask>
So I expect that the equivalent of Window -> Preferences ->
Oomph -> Setup Tasks "Show tool bar contributions" would have
been performed. If not, you can do that manually and even if not
set you can also use Help -> Perform Setup Tasks and Navigate
-> Open Setup to access the same actions/menus. So these
instructions apply to an existing development environment's
workspace from the previous steps of the tutorial, not to the
installer.
But if you're asking how to "build the IDE" and by that you don't
mean to how to set up a development environment but rather how to
replicate the Maven/Tycho build locally to produce a p2 update
site and the other artifacts produced on the build machine, that I
don't know. Generally that will involve invoking Maven on the
appropriate pom.xml.
Regards,
Ed
On 26.03.2020 03:44, R Steiger wrote:
Folks,
I’m up
against a deadline on this project, and been waiting for
Ed’s reply, but he could easily be taking a break, out of
town, whatever.
Can anyone
else point me to the first step on the path to building the
SDK? (I got stuck in section 8 of the provisioning wiki
page, not seeing any Oomph toolbar buttons in jdt-master,
leading me to try looking in the Installer, but leaving me
unable to make sense of doing so with an existing workspace,
since all the flow is aimed at building a new workspace.
And haven’t yet found any other guides covering IDE builds.)
Much thanks,
-rjs
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
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
