|
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_id@xxxxxxxxxxxxxxx: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.
Indeed, and I did.
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,
Setup usually takes 10-20 min.
Best regards, Lars
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
- Is the IDE hosed and I need to start over?
- can this be ignored and all will be well going
forward?
- 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
* wiki.eclipse.org/JDT_Core_Committer_FAQ
* https://wiki.eclipse.org/JDT_Core_Programmer_Guide
* 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://userid@xxxxxxxxxxxxxxx:29418/jdt/eclipse.jdt.core.git*)
with
the magic *29418
<ssh://userid@xxxxxxxxxxxxxxx: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@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
--
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.vogel@xxxxxxxxxxx,
Web: http://www.vogella.com
_______________________________________________
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
--
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.vogel@xxxxxxxxxxx, Web: http://www.vogella.com
_______________________________________________
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
|
