Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Higgins 1.x Developer Page

Higgins logo 76Wx100H.jpg

This page is information for active committers and contributors.

Dev Processes

Releases

Milestones

Each release (e.g. Higgins 1.1) is divided into milestones (e.g. 1.1M7, 1.1M8...) according the the project plan. At the completion of each milestone we:

  • Update the project plan with the completion date
  • Create a branch in SVN
  • Create a new table on the downloads page with all deliverables

Hierarchy

  • Solutions (see Exploring Higgins) are deployable, usable apps and web services (and in a couple of cases, libraries).
  • Packages are mid-level multi-component packages used to create solutions
  • Components are low level building blocks comprised of Eclipse projects (folders) that in turn contain files.

Solutions

How to create a new solution:

  1. Create the solution page using Solution Description Template
  2. Make sure there is a link to your solution from one of the "Exploring Higgins" web/wiki pages
  3. Make sure your solution build (see Building section below)
  4. Make sure your solution is included as a row in one of the Downloads tables

Solutions are composed of components. For each new component:

  1. Create a new table on the appropriate Components page for the component following the Components Page Conventions
  2. Edit the autobuild scripts to include java components in the nightly build
  3. Make sure that automated build scripts are using the latest build.xml
  4. 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.

Building

Nightly Builds

  • How to sign up for daily build pass/fail email notifications:
    1. Modify the the successMailList or failMailList in the projects.xml file in org.eclipse.higgins.auto.resources project located at trunk/builds folder in SVN.
    2. These fields will contain comma separated email lists. Anyone can add their name to any component and either pass list, fail list or both if they desire.
  • The following is an example:
 <buildProject id="org.eclipse.higgins.idas.cp.jena2">
   <pathFromWebHome>downloads/idas.cp.jena2</pathFromWebHome>
   <successMailList>slyakhov@aquasoft.dp.ua</successMailList>
   <failMailList>slyakhov@aquasoft.dp.ua,jimse@novell.com</failMailList>
   <targetToRun>plugin</targetToRun>
   <targetToRun>jar</targetToRun>
   <targetToRun>javadoc</targetToRun>
 </buildProject>"
  • Adding your name to the successMailList will then include you on daily emails if all component targets passed the daily build.
  • Adding your name to the failMailList will then include you on daily emails if all component targets failed the daily build.
  • Adding your name to both lists will include you in daily status emails whether the component passes or fails.

Bugzilla

  • Bugs, features, etc. for each component and each milestone are tracked in Eclipsezilla (Bugzilla)
  • All bugs: open, closed
  • To see the open, closed bugs for each component see Components pages

Source Code

Java Projects

  1. Higgins 1.1 projects MUST be developed using Eclipse 3.4
  2. MUST follow Project Structure and Naming
  3. MUST follow Project Dependencies
  4. MUST use Higgins2Ant
  5. In general it MUST build using JRE 1.4 (and must support both Sun and IBM JREs). To ensure this, projects must set compiler compliance level to 1.4. The Higgins project team may decide to make exceptions for specific components for Higgins 1.1 to use JRE 5.0 (1.5)

All Projects

  1. All files MUST carry correct headers, copyrights, license. See Higgins File Headers
  2. All projects MUST support internationalization. See Internationalization Support
    • The goal is to have Higgins 1.1 code internationalized, such that other users could localize the code to their native deployment requirements. Some specific elements of this would include:
    • Static strings must be stored in external resource bundles that can be called at runtime. These resource bundles can then be the focal point for localization.
    • We can leverage the Babel project/tools in Eclipse found here. This tool can be used to help in doing translations.
    • There are also some Eclipse plug-in internationalization 'how to' instructions for development and testing located here.

SVN

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.
Features
We only have one feature and we follow the rules in Version Numbering.
Packages
a set of Components. They are organizing concepts, not digital artifacts. We have not found a need to have version numbers for components.
Components
in Higgins are sets of one or more related project-folders. They are just organizing concepts and not digital artifacts. We have not found a need to have version numbers for components.
Solutions
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.
Higgins
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.


Higgins Bug-Fix Release Criteria

Higgins patch releases (e.g. 1.0.X number scheme) would include exclusively bug fixes (e.g. no new features/enhancements) for the following type of bug severity:

  1. Bugs in any of the Higgins platform components that cause a crash of the overall Higgins system or Higgins based application.
  2. Bugs that cause a loss of any persistent data.
  3. Bugs that cause a severe security breach where sensitive end user data can be exposed to the outside world or accessed by unauthorized users.
  4. Bugs that cause a "major" feature to not function and there is no workaround available to accomplish the same task.
  5. Bugs that cause a "major" business impact such as loss of revenue or customers.

For all other bugs fixes of lesser severity than those described above, they will be included as part of major or minor (point) Higgins releases and not necessarily included as part of a special bug fix release. By way of example, the bug fixes included in the major or minor (point) releases would include such items as:

  • bugs that cause an aspect of a feature to not work properly.
  • bugs are that are cosmetic in nature, misspellings in dialogs, annoying to users, etc.

The following are the process guidelines Higgins team members should follow to support bug-fix releases:

  1. Ensure that a bugzilla ticket has been created for the issue outline the details of the bug in the ticket.
  2. Review the nature of their bug against the above outlined criteria
  3. If you feel the bug matches the criteria to be included in a future bug-fix release, send an email to Higgins-Dev and address request to Brian Walker to include this in an upcoming bug-fix release. Please note in the email whether the bug has been fixed already, or requires the component owner to work on creating the fix.
  4. If you have already made the code fix and you are not the component owner, all you need to do is submit the code fix to the appropriate component owner and request they commit the code fix.
  5. Most Important - when the code fix is committed, please make sure that the code is committed to the head branch, as well as the B-1-0-0 code branch as well. The patch release will be completed off the B-1-0-0 code branch.

Technical References

Misc Tools

IP-Related


Eclipse Foundation-related Info

Eclipse Committers

IPZilla

Legal

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

  • Orbit http://www.eclipse.org/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 http://wiki.eclipse.org/index.php/Orbit_Faq 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.

Wiki Pages

  1. Put the mouse on new pages by inserting the string [[Image:Higgins_logo_76Wx100H.jpg|right]] at the top of the page.
  2. Version wiki pages (adding a "Version" section at the top) as needed (see below).
  3. Categorize the page by including the category at the bottom of the page. See [1] for a list of all Higgins Categories. For example insert [[Category:Higgins]] for general Higgins info. (Yes, the categories could use some maintenance.). Or insert [[Category:Higgins Data Model]]

Versioned Wiki Pages

We have worked out a convention for dealing with versioning in wiki pages. For any wiki page that needs versioning, there should exist a wiki page name that does NOT include a trailing version number (e.g. http://wiki.eclipse.org/Context_Data_Model). This un-versioned page should use the #REDIRECT command to redirect to a versioned page (e.g. http://wiki.eclipse.org/Context_Data_Model_1.0) that includes in its URL a version suffix (e.g. “1.0”) taken from the most recent released version of Higgins (i.e. the “1.0” in “Higgins 1.0”). Lastly, at the top of every page, there should be a “Version X.X” section (see, for example the top of http://wiki.eclipse.org/Context_Data_Model_1.1) preferably containing links to the other versions of the page.

To minimize work, create multiple versions of a wiki page only when absolutely necessary, and to reuse and link to any (unversioned) pages and sub-pages where ever possible. Unversioned wiki pages don't have to have a "Version" section at the top.

Examples:

If you need to version a page that hasn't been versioned before:

  1. Create TWO new pages that are copies of the original page. Edit each copy to describe the applicable version.
  2. Add a version section at the top of each of the two new pages as shown in the examples above.
  3. After you have created these new pages, change the original unversioned page such that it contains nothing but a #REDIRECT [[<page name>]] (where <page name> is the name of the page that describes the released version of Higgins.

Meetings and Events

Upcoming:

Past:

Under Discussion

The items in this section have NOT been agreed to and put into production. For discussion only.

Deployment Requirements

Component and Integration Test Automation

  • A sub-team has been meeting to assess what auto-test tool could be adopted by Higgins project to support automated component level and solution level integration testing that can be run after the auto build process.
  • The baseline assumption is the auto-test solution Higgins choses would need to build on top of the auto-build platform. The two basic auto-test (and build platform) options would include either:
    1. Identify/develop autotest capabilty on top of our existing Higgins centric ANT based autobuild platform OR
    2. Extend Buckminster autobuild capability and migrate Higgins components to this new build platform over time. The follow on would be to leverage this same platform (with collaboration from wider Buckminster team) to develop integrated auto-test capability over time.
  • To support the scoping of option (2) above, we (Mike M from IBM) is working on determining the extensions needed to the the current Buckminster build capability to support the current STS autobuild needs. Mike is currently investigating this.

Back to the top