* Download (Eclipse 4.3) here: http://eclipse.org/downloads/index-developer.php?release=kepler "Eclipse Standard" (formerly called "Eclipse Classic" is a good choice. Also because it is a SDK. An alternative is RCP. It already includes Egit&Mylyn.

+

* Download Eclipse 4.3 (Kepler) here: http://eclipse.org/downloads "Eclipse Standard" (formerly called "Eclipse Classic" is a good choice. Also because it is a SDK. An alternative is RCP. It already includes Egit&Mylyn.

** Developing on a 4.2/Juno SDK will still probably work but we highly recommend using Kepler so we know our code works there.

** Developing on a 4.2/Juno SDK will still probably work but we highly recommend using Kepler so we know our code works there.

** Eclipse 3.x version have not been tested and we do not develop on them.

** Eclipse 3.x version have not been tested and we do not develop on them.

Line 44:

Line 45:

# Download the PTP master archive of the previous major release of PTP. This will be a file named ptp-master-xxx.zip.

# Download the PTP master archive of the previous major release of PTP. This will be a file named ptp-master-xxx.zip.

−

## After June, 2012, this is [http://download.eclipse.org/tools/ptp/builds/juno/milestones/RC4/ptp-master-6.0.0-201206130212.zip ptp-master-6.0.0-201206130212.zip].

+

#* After June 2013 Kepler release it will be PTP 7.0.0: ptp-master-7.0.0-xxx.zip found on http://download.eclipse.org/tools/ptp/builds/7.0.0/

Download Eclipse 4.3 (Kepler) here: http://eclipse.org/downloads "Eclipse Standard" (formerly called "Eclipse Classic" is a good choice. Also because it is a SDK. An alternative is RCP. It already includes Egit&Mylyn.

Developing on a 4.2/Juno SDK will still probably work but we highly recommend using Kepler so we know our code works there.

Eclipse 3.x version have not been tested and we do not develop on them.

Choose the branches you want to clone (usually ptp_6_0 and master==HEAD) and click Next >.

Note: all workspaces on your machine that talk to this local clone of the repository will all use the same branch at a time. You may want separate clones of the repo (one for each release/branch) for this reason. If so, the last page of the wizard lets you specify a different directory for this clone and you don't have to use same name as remote repo name for your directory.

One convention for this: Make two clones of the git repo, one for master (Kepler work) and one for the ptp_6_0 branch (Juno work). You can put both branches in each clone.

One set of suggested names of the repos:

Set of repos where 'master' is the (default) branch used - for Kepler work (that is, name the repo to match the default branch -- or, just use the same name as the server repo)

Click Next> to choose where you want the repository located locally. It can be anywhere. See suggested names above if you don't have a better idea.

Also choose what you want the default branch to be (if other than master)

Click Finish. The repository should be downloaded.

Once the repository has downloaded you should see it in the list. Select it.

If you have already cloned the repository, and it isn't shown in the list (e.g. Clone done from another workspace)

Select Add... and add it.

You should now see it in the list. Select it.

Click Next> then Next> again and you should see a list of all the projects.

Select all of the projects except the following (omitting them is optional; you can also just close then later if you like, or just ignore errors), then click Finish. (The tests projects are unit tests for RDT; to compile and run them, you would need to check out the source code for CDT's unit testing projects and their dependencies. Omitting them just keeps confusing build errors out of your way.)

Download the ptp-sdm-*.zip package. Unzip it and locate the pre-build sdm binary for your target platform (directory name matches platform).
Move the pre-built sdm binary for your target platform to some location onto the remote target.
This is the binary sdm you will need to locate from the debug launch dialog.

(Shortly, Kepler PTP plans to move the sdm to the remote target automatically, and also include a build script to build it yourself if you need to.
For now (May 14), it's prebuilt and you move it to remote target manually.)

Updating

Updating existing projects

Right-click on a project and use Team>Pull - this updates the existing projects in your entire local repository, and the current branch in your workspace

Make sure you have set branch.autosetuprebase=always and branch.<name>.rebase=true as described above

This causes a Pull (analogous to a 'cvs update') to do the following:

Fetch

Rebase (It undoes all local commits, fast-forwards the local version to the remote one, and then reapplies the local commits)

Otherwise a Pull only does a Fetch/Merge which causes a spaghetti like history

If new projects have been added to the repository,

Do an Import ... Git > Projects from Git, Next, Choose 'Local', Next, Choose your repository, Next, Next (leave default for 'Import existing projects' and working directory), and on the 'Import Projects' page you should see all the existing projects greyed out, since you already have them in your workspace; make sure all the new projects are checked and hit 'Finish'.

New Branches

If a new branch is added to the repo and you want to get the new branch into your local repo, do:

Team > Pull to get changes from remote repo (e.g. existence of the new branch) into your local repo

Team > Switch to > New Branch... and for Source Ref, choose the new remote branch

Committing to remote repository

There are two steps to getting code changes in the remote repository at git.eclipse.org: commit then push. (This was a single commit step in CVS. Eclipse Kepler's EGit allows this in a single step via a "Commit and Push" button as well.)

Pull to get the latest changes and prevent errors when you push

right-click on any project in the repository and use Team>Pull

Commit to your local repository - this can be on single files or groups/whole project

right-click on your project and use Team>Commit

If there is a associated bugzilla - copy and paste the bug number, for example, Bug 400832 (or [400832])- and the bug title or other description of the fix.

Push to copy it to the remote repository - do it on project, e.g. from Project Explorer; all commits in your local repository (including other projects) get pushed up to git.eclipse.org

right-click on any project in the repository and use Team>Push to Upstream

Alternatively, you can

Team>Pull (on any project in the repo) first to make sure you've updated, then

Team>Commit and use the checkbox to 'Push the changes to upstream' at the bottom of the 'Commit Changes' dialog.

API baseline and code formatter

Copy Remote Tools Dstore server jar

If you are using Remote Tools ... you may see the error "Unable to locate payload "rdt-server.jar" in bundle "org.eclipse.ptp.rdt.server.dstore" "
when you launch a runtime workspace and make a (purely) remote project.

So you must do the following (Until we can build rdt server jar here) ...
From a PTP (end-user) installation, unzip eclipse/plugins/org.eclipse.ptp.rdt.server.dstore_xxx.jar into a directory.
Then from the unzipped contents
move rdt-server.jar to your development workspace project: org.eclipse.ptp.rdt.server.dstore

(This is the file that will be moved up to the remote host location when you create a remote project. Remote Tools installs this jar on the server automatically and starts it for you.)

If you don't, you will see the error popup "Unable to locate payload "rdt-server.jar" in bundle "org.eclipse.ptp.rdt.server.dstore"

Copy LML Driver tar file

If you are developing PTP from source in your development workspace and launching into a runtime workspace you also get a similar error to the one above: