|Re: [jdt-dev] Need some more current pointers for getting started on JDT projects|
I understand you have a workspace packed with JDT projects and error free, right? Next step, how to run tests, Manoj already replied: > If you would like to run all JDT Core tests locally, try running > RunJDTCoreTests as a JUnit plugin test.This will run quite long time, so feel free to play with any subset, as the mentioned class is just an umbrella pulling in lots of individual test suites.
Running Eclipse with your changes: the recommended way is to lauch a runtime workbench (Run > Run configurations > Eclipse Application). Actual deployment takes just a few more steps but should rarely be needed for development. Let's get there when you really need it.
Next step, for understanding the code: I doubt there is anybody who understands "the JDT code" :), but there's a group of people with different focus areas. So while I applaud your intention of understanding, I suggest to do the same: pick one focus area where you want to start. Is your primary interest in the compiler? Or in convenience features like quick assists? Debugging support? Or ...?
Yes, the tutorial shouldn't, despite its age, be very far off, since JDT is not a fast moving component. So the general concepts of Java Model, DOM AST and search engine can indeed be learned through it.
Do you care to tell us what your current goal is? Work on a reported bug / RFE from bugzilla? If so, bugzilla would be the place to discuss details about the code including hints on where to start reading / debugging. Typically a committer familiar with a code region in question will mentor each contributor who is crunching a bug. If you don't get an answer in bugzilla immediately, feel free to ping again after some time or eventually bring the question to this mailing list.
Once you have something worth sharing we mildly urge you to push to gerrit, as this is the simplest workflow integrated with our infra. JDT does not actively use github (which is just a mirror). Feature branches are only used by committers working on a bigger sub-project, but gerrit changes fully serve the same purpose. This doesn't preclude the use of a local branch, of course - we'll never see it anyway :)
Once you have specific questions, browsing the history of particular code sections will give lots of information, in particular through the references to bugzilla.
so, welcome and see you in bugzilla :) Stephan
Back to the top