Skip to main content
Jump to: navigation, search


Important Links

  • Project Homepage @ [1]with
  • Project Homepage of the Eclipse Consortium: [2]
  • Milestone and Release Planning: g-Eclipse Planning

g-Eclipse Developer FAQ

How to work with the Subversion repository?

Using subclipse:

  1. In the preferences ('Team' > 'SVN') switch to the pure Java implementation 'SVNKit', otherwise you will get errors.
  2. Switch to the 'SVN Repository Exploring' perspective
  3. Create a new repository location:
  4. Now you can browse and check-out plug-ins from the SVN repository. It contains the usual SVN directory structure TRUNK, BRANCHES, and TAGS. The development version of the code can be found in TRUNK, all other directories are currently empty. The TRUNK directory contains the following substructure:
  • doc/ documentation and documentation plug-ins
  • features/ the core feature
  • plugins/ the core plug-ins (middleware independent) including eu.geclipse.core and eu.geclipse.ui
  • releng/ everything that is needed for building the feature; at the moment it contains a simple update-site project
  • test/ some JUnit tests

How can I change my SSH password in Subclipse?

When using Subclipse with SVNKit the user password is stored in an encrypted keyring file.

If someone has problems with his/her username/password and the svn+ssh:// connection, it is worth to look for a file called '.keyring' in the configuration area ('configuration/org.eclipse.core.runtime/'). If you remove this file, SVNKit will ask for your username/password the next time you try to access the Subversion repository.

BUT: All other passwords that are stored in this file are also lost!

For a dry-run use start Eclipse with the -keyring parameter:

eclipse -keyring c:\my_pw\eclipse.keyring

I am a contributor, not a committer: How do I add my code changes?

If you have checked out the g-Eclipse projects from the following read-only URL and you have done some programming... svn://

  1. 'Synchronize with Repository' and integrate all incoming changes. Look for possible compile problems or conflicting changes and fix these...
  2. Select all projects that contain your outgoing code changes; by right-clicking you will find 'Team' > 'Create Patch'; use the unified diff format, and choose workspace if you changed code in more than one project.
  3. Now this is important: Create a new Bugzilla item (or use an already existing if there is an appropriate one), describe your changes and attach your patch to the Bugzilla item.
    While the diff/patch works fine with ASCII data, it has its problems with binary files. These files are usually not included in the patch, so please attach all binary files (images, jar's, ...) separately to the Bugzilla item.
  4. A committer should review the patch and integrate it into the subversion repository.

Back to the top