Skip to main content
Jump to: navigation, search

Developer Team Page


Higgins logo 76Wx100H.jpg

Note: This page is relevant only for Higgins committers and active contributors.

Meetings and Events

Version Numbering

There are four levels of granularity in the Higgins project:

SVN Projects
are named major.minor.service.qualifier as described in the "plugins" section here: Version Numbering. [For java projects every project is indeed a plugin. But for non-java projects a project might be a C++ lib, etc.] For projects (plugins) we are following the rules in Version Numbering.
We only have one feature and we DO follow the rules in Version Numbering.
in Higgins are sets of related projects. But they are just organizing concepts and not digital artifacts. We have not found a need to have version numbers for components. So there is no problem here.
in Higgins are complete working apps or web services. There is no equivalent concept in Version Numbering. We do not use version numbers at the solution level.
is the name for the entire project. This is roughly equivalent to numbering of the entire Eclipse IDE (e.g. Eclipse 3.1 or 3.2).
  • The first bugfix release after 1.0.0 will be 1.0.1 (see Beyond Higgins 1.0)
  • The first milestone (stable build) after 1.0.0 will be 1.1M1 (see Beyond Higgins 1.0)
  • We expect to have Higgins 1.1 stable builds approx every 6 weeks or so.


The list of all kinds of things that we might like to do someday is here:



  • Component Owners MUST:
    1. Create rows (and sometimes entire tables) for each project on the Components page.
    2. Manually create (and constantly update) the "dep" wiki page in the "Dependencies" column (entitled "Dep.") for each project/row on the Components page.
    3. Edit the autobuild scripts to include java components in the nightly build
    4. Create a "row" wiki page for each row using the Component Description Template
    5. Make sure that automated build scripts are using the latest build.xml
    6. Make sure that all 3rd party dependent jars are read from the dependencies.redistributable project. For projects that autobuild this can be verified by checking that the auto-generated "Third Party Dependencies" section of the "dependencies" page linked from a build page (see the "downloads" column on the Components page.
  • Solution Owners MUST:
    1. Add a link to the solution here Solutions
    2. Create the solution page using Solution Description Template
  • Anyone editing the wiki MUST
    1. Put the following string #eclipseproject:technology.higgins preceeded and followed by two sets of { brackets in the top line of all wiki pages they create so that the wiki page will have the Higgins left-hand navigation links. (If I put the actual full string in here, it messes up the formatting.)
    2. Put the mouse on new pages by inserting Image:Higgins_logo_76Wx100H.jpg|right preceeded and followed by two sets of square brackets.
    3. Use versioning conventions when you need to version wiki pages. Since we are using the Higgins wiki for documentation, we need to be able to version our wiki pages. To minimize duplication, we are only versioning pages as it becomes necessary. (For example HGG with its many references to entity.) If you need to version a page that hasn't been versioned before:
      1. Create two new copies, one for the released version and one for the version under development. (For example: Higgins Global Graph 1.0.x and Global Graph 1.1M1 )
      2. Add a version section at the top of each of the new pages as shown in the examples above.
      3. After you have created these new pages, update the unversioned page to add a redirect to the released version and delete the actual contents. See Higgins Global Graphfor an example.
    1. Categorize the page by including the category at the bottom of the page. See [1]for a list of all Higgins Categories. For example:
      1. Category:Higgins (Preceeded and followed by two sets of square brackets. If I put the actual full string here, it messes up the categorization of this page.) for general Higgins info. (Yes, the categories could use some maintenance.)
      2. Category:Higgins Data Model for data model.




Misc Tools


Contributions by team members

Eclipse Foundation-related Info

Eclipse Committers



Clarification of IP processes for use of third party libraries

  • Any time anyone working on the Higgins project wants to introduce a project dependency, it needs to be brought forward to the Higgins project.
  • If the decision is made to introduce the dependency and the dependency involves software that is not licensed under the EPL, then a formal IP process needs to be gone though to approve the software binaries for inclusion in the project cvs. Note that this process must be followed even if the software is a common java library used by other Eclipse processes. (If the software has been used by another Eclipse project, the process is much faster.) Eclipse has a system IPzilla for managing this process. If you are anticipating a dependency, you need to bring it forward as soon as possible to allow time for the IP due diligence process to take place. See more about IPzilla below.
  • Libraries licensed with EPL are the easiest to get permission to use, followed by Apache 2.0. GPL and LGPL licences are not compatible with EPL.


  • Orbit is designed to be a repository for third party libraries that are approved for use in Eclipse projects. If the incoming libraries are not already bundles then Orbit committers will work to create a bundle that is suitable for use in Eclipse projects. See for a list or Orbit managed libraries. Orbit managed libaries are the easiest of third party libraries to add to an Eclipse project. Even if a library is listed under Orbit, you still need to go through the IPzilla process before putting it into the Higgins CVS.

Back to the top