Project website: http://goclipse.github.io/
As of 2017, Goclipse is no longer actively maintained, see this blog post for more information. If you are interested in contributing, you can for now fork the project - and there should be enough information here detailing how to build, test, release, etc.
--
Developers Guide
Building the IDE:
You will need Maven for building Goclipse.
- To build, run
mvn clean verifyat the root of the repository. This will run the test suite, and afterwards produce a p2 repository (an Eclipse Software Site) atbin-maven/features.repository/repository. - To just build without running tests, invoke
mvn clean package.
Setting up a development environment:
- You need Eclipse PDE to develop Eclipse plugins. Download and start it.
- Clone the Git repository.
- In Eclipse, click "File / Import... ", and then "General / Existing projects into workspace". Select the Git repository folder as the "root directory", enable "Search for nested projects", and select all the Eclipse projects that show up. Click finish to import those projects.
Running the tests in Eclipse:
- In
releng/launchesthere is one or several Eclipse launch files for running the tests, so if this project is added to your Eclipse workspace, the launches will show up automatically inRun Configurations..., as "JUnit Plug-in Tests".
Creating and deploying a new release:
A release is a web site with an Eclipse p2 update site. The website may contain no web pages at all, rather it can be just the p2 site. To create and deploy a new release:
- Ensure the version numbers of all plugins/features/etc. are properly updated, if they haven't been already.
- Run
mvn clean verifyto perform the Tycho build (see section above). Ensure all tests pass.
- To create a signed release the
sign-buildMaven profile must be activated, and the required properties set.
- Create and push a new release tag for the current release commit.
- Go to the Github releases page and edit the newly present release. Add the corresponding (ChangeLog.md) entries to the release notes.
- Locally, run
ant -f releng/ CreateProjectSite. This last step will prepare the project web site underbin-maven/ProjectSite. - To actually publish the project site, run
ant -f releng/ PublishProjectSite -DreleaseTag=<tagName>. What happens here is that the whole project site will be pushed into a Git repository, to then be served in some way (for example Github Pages). IfprojectSiteGitURLis not specified, the default value in releng-build.properties will be used.
- For more info on the Release Engineering script, run
ant -f releng/, this will print the help.
- A branch or tag named
latestshould also be created in Github, pointing to the latest release commit. The previouslatesttag can be deleted/overwritten. The documentation pages use this tag/branch in their links.
Project design info and notes
LangEclipseIDE
This project uses the LangEclipseIDE framework, which is designed to have its source embedded in the host IDE.
See this section for more info on how this should be managed.
Extensive Compile-Time type and contract checking
See https://github.com/bruno-medeiros/MelnormeEclipse/wiki/Extensive-Compile-Time-Checking for more info on this principle.
Code style:
- Indent with tabs (tab size is 4 spaces)
- Max line width: 120
- Block style:
if(foo.blah()) {
doThis();
}
- Indentation for function arguments: 1 indent unit (= 1 tab):
foo(one, two, three,
four, five, six);
There is also an Eclipse formatter profile settings file you can use, although you are not obliged to format with all rules of that formatter settings. If you make a minor source change, don't format the whole file, but only around the changes you are contributing.
Unit tests double-method wrapper:
This code idiom is often used in this project's JUnit tests:
@Test
public void testXXX() throws Exception { testXXX$(); }
public void testXXX$() throws Exception {
This is donely solely as an aid when debugging code, so that the "Drop to frame" functionality can be used on the unit-test method. It seems the Eclipse debugger (or the JVM) cannot drop-to-frame to a method that is invoked dynamically (such as the unit-test method). So we wrap the unit-test method on another one. So while we now cannot drop-to-frame in testXXX, we can do it in testXXX$, which basically allows us to restart the unit-test.
TODO: investigate if there is an alternate way to achieve the same. I haven't actually checked that.