Lars,
Comments below.
On 13.08.2019 12:15, Lars Vogel wrote:
Hi Ed,
> with the right URLs for Gerrit access (which are?)
If you clone via Eclipse these URLs are automatically configured.
If you go here:
https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/
It shows several choices:
git://git.eclipse.org/gitroot/jdt/eclipse.jdt.core.git
https://git.eclipse.org/r/jdt/eclipse.jdt.core
ssh://user...@git.eclipse.org:29418/jdt/eclipse.jdt.core
Not all of these will provide Gerrit access, right?
So one must choose the correct one, which is not the first one.
> avoiding projects nested in tests
Definitely annoying, I agree. For platform.ui test data I removed the
.project files for them so that this is no an issue for this repo.
IMHO JDT could do the same.
Getting all 37 repos to clean up such problems is a challenge... And one
most hope no one is compelled to introduce a project at the root of the
repo too.
> only the core platform developers feel so inclined to keep
Lets not discuss that again. :-)
No, it's clearly better to not respond to at all to all the changes I
made to address the outstanding concerns that were raised. But I'd
prefer that newcomers not be steered down the dark path.
> only real problem here is that Mylyn is messed up because the project
Then I wrote my answer, I did not know that and wanted to help Richard
to get started.
It sounded to me like you wanted to help him to avoid using Oomph.
IMHO Mylyn should finally remove their views from the default Java
perspective (https://bugs.eclipse.org/bugs/show_bug.cgi?id=480696). If
someone agrees, please speak up in the bug.
Indeed, and I did.
Best regards, Lars
On Tue, Aug 13, 2019 at 12:06 PM Ed Merks <ed.me...@gmail.com
<mailto:ed.me...@gmail.com>> wrote:
Lars,
Not only do you need to clone the relevant repos, (which ones?),
with the right URLs for Gerrit access (which are?), but you need
to import the projects from them, at which point you need to
figure out which ones are sensible to import, avoiding projects
nested in tests that aren't intended to really be independent
projects in the workspace.
The whole manual process is painful at best and only the core
platform developers feel so inclined to keep following that
painful approach. But I don't feel it's a good idea to to suggest
that this is an approach that a novice should follow.
In the end, the only real problem here is that Mylyn is messed up
because the project is relatively inactive and is apparently not
keeping up with the times, so best just to close this view. I
fear that at some point Mylyn will just stop working entirely.
The Bugzilla integration has been working poorly for quite some
time...
Regards,
Ed
On 13.08.2019 10:54, Lars Vogel wrote:
Hi Richard,
as an alternative to Oomph you can use the latest I-Build from
https://download.eclipse.org/eclipse/downloads and clone the
relevant repos. The only additional setup is the target platform
setup.
See
https://www.vogella.com/tutorials/EclipsePlatformDevelopment/article.html#exericse-eclipse-user-creation-and-gerrit-server-configuration
for
the process.
Setup usually takes 10-20 min.
Best regards, Lars
On Tue, Aug 13, 2019 at 10:41 AM Richard Steiger
<rstei...@ensemblesoft.net <mailto:rstei...@ensemblesoft.net>> wrote:
Hi Ed,
Taking your advice, I've been trying to follow
(https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning),
and it went pretty much along the Tutorial's path, until the
provisioned IDE was launched, at which point, the Task List
view shows
and clicking Details popped-open the attached Error Log.
At this point, I have no idea in what state the SDK's
internal invariants are, hence what my next step should be,
obvious choices being
1. Is the IDE hosed and I need to start over?
2. can this be ignored and all will be well going forward?
3. is there a voodoo ritual that will unwedge and allow
proceeding?
Kudos to you for whatever role you played in implementing the
installer! Great tool!
Much thanks,
-rjs
On 8/12/2019 12:58 AM, Ed Merks wrote:
Richard,
As Paul suggests, if you really want to clone the repos and
work with (or see all) the source, better to use the
installer. There is a tutorial describing how the create an
installation with the complete platform SDK:
https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning
Likely this is overkill for your purpose, but I find this an
extremely useful resource to have around. It can help you
find out how other things are already implemented in the
platform and provides search capabilities not possible in
any other way. For example, if I see a string some where in
some dialog or elsewhere in the UI, I can search all the
source to find where that is specified, e.g., often in a
properties file. Then I can figure out the name of that
property and can search for all uses of that property name
in the *.java file files. Typically this will be some
static final constant, and then I can open a call hierarchy
on that constant to find all the places that its used. The
advantage of having all the source is that a constant's
value (if it's really a static constant with a constant
expression), gets inlined by the compiler, so you cannot
find uses of the static constants in other .class files.
But with the source available, you can find the uses of
constants in other *.java files in the workspace as well.
So probably best not to include all the projects from the
tutorial because that takes very long to set up, but
following the tutorial you can go back to the previous page
of the installer and select the subset of projects likely to
be useful, e.g., the JDT projects and the various platform
UI projects.
Best of luck with your explorations.
Cheers,
Ed
On 12.08.2019 09:38, Paul Pazderski wrote:
You don't need to clone/import Platform projects to work on
JDT. If compilation failed you might not have a correct
target platform because the target platform is what is used
to resolve dependencies.
Also even if most Platform or JDT projects contain pom.xml
files you should import them as existing Eclipse projects.
I would recommend you to try Oomph setup (Eclipse
Installer). https://www.eclipse.org/downloads/packages/
* In Eclipse Installer select advanced mode
* select Eclipse IDE for Eclipse Committers (Latest)
* on the next page you can select JDT projects and any
other projects you are interested
Notes on some of your other points:
* If you get a timeout while cloning you can try it again.
Those errors are usually temporarily.
* The URLs on the Git Workflow page look outdated. In
general Eclipse git repos are listed at
https://git.eclipse.org/c/ and you can find clone URLs if
you select a repo.
* Regards the using http: as anonymous. You can clone from
https: as anonymous. Anonymous only means you do not
provide your username. (as required for ssh clone)
Best regards
Paul
PS: found a wiki page for Eclipse SDK Oomph setup.
https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning
Maybe that helps too.
Am 12.08.2019 um 09:04 schrieb Richard Steiger:
[FYI, despite having reported and done a bit of
investigation on
https://bugs.eclipse.org/bugs/show_bug.cgi?id=518095, I'm
still a total eclipse noob, so please go easy on anything
stupid below.]
I have a few JDT experiments ("hacks") I want to try-out,
and have been trying to follow the instructions in the
various dev resources and guides, such as
* eclipse.org/jdt/core/dev.php
<http://eclipse.org/jdt/core/dev.php>
* wiki.eclipse.org/JDT_Core_Committer_FAQ
<http://wiki.eclipse.org/JDT_Core_Committer_FAQ>
* https://wiki.eclipse.org/JDT_Core_Programmer_Guide
* eclipse.org/forums/index.php/f/13/
<http://eclipse.org/forums/index.php/f/13/>
* and numerous others.
The central problem (that's blocking me) is the fact that
none of the above appear to be both current and correct,
compounded by the fact that none of the docs have overt
last-modified dates, nor major release level ranges. I
therefore invested a fair amount of time trying to build a
JDT dev project going down multiple routes, only to
discover that each was effectively an abandoned
gopher-hole. In more detail:
* I tried to clone the repos listed in
https://github.com/eclipse/eclipse.jdt.core; determined
that maven
can build all modules from the command-line with the
-Pbuild-individual-bundles profile, but have yet to
successfully
import the modules into eclipse as a set of maven
projects, since
the project can't be compiled without the core eclipse
infrastructure jars; attempting to extract them from
the parent pom
is a total crap-shoot, given its inherent complexity
(else I might
be on my way to at least prototyping the hacks, but
miles from
creating even a personal release);
* I also tried cloning the repose listed in
https://wiki.eclipse.org/Platform-releng/Git_Workflows
(using http:
as anonymous as instructed); the first 3 clones
worked, but the next
several crapped-out with timeouts, premature EOFs, or
other faults;
url #6
(*ssh://use...@git.eclipse.org:29418/jdt/eclipse.jdt.core.git*
<http://use...@git.eclipse.org:29418/jdt/eclipse.jdt.core.git*>)
with
the magic *29418
<ssh://use...@git.eclipse.org:29418/jdt/eclipse.jdt.core.git>
<mailto:ssh://use...@git.eclipse.org:29418/jdt/eclipse.jdt.core.git>*
segment alludes to this link being release-specific
(viewing History
doesn't pin-point what release the page presents, but
the latest
entry is back to '16
* I was initially excited to find
eclipse.platform.common-I20190808-1800, then tracked
it to
https://projects.eclipse.org/projects/eclipse.platform,
only to find
it's either not indexed there, or might be stale.
Any advice or live/good links to Getting Started docs
would be most appreciated.
Thanks,
-rjs
_______________________________________________
platform-dev mailing list
platform-dev@eclipse.org <mailto:platform-dev@eclipse.org>
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@eclipse.org <mailto:platform-dev@eclipse.org>
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@eclipse.org <mailto:platform-dev@eclipse.org>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
--
Eclipse Platform project co-lead
CEO vogella GmbH
Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (040) 5247 6322, Email: lars.vo...@vogella.com
<mailto:lars.vo...@vogella.com>, Web: http://www.vogella.com
_______________________________________________
platform-dev mailing list
platform-dev@eclipse.org <mailto:platform-dev@eclipse.org>
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@eclipse.org <mailto:platform-dev@eclipse.org>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
--
Eclipse Platform project co-lead
CEO vogella GmbH
Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (040) 5247 6322, Email: lars.vo...@vogella.com
<mailto:lars.vo...@vogella.com>, Web: http://www.vogella.com
_______________________________________________
platform-dev mailing list
platform-dev@eclipse.org
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@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
