View source for Higgins 1.x Developer Page


[[Image:Higgins_logo_76Wx100H.jpg|right]]
This page is information for active committers and contributors.

==Dev Processes==
* Weekly [[Higgins Developer Calls]] on Thursdays
* Maintain the project plan for each major release
* Plan milestones
* See also [[Higgins Development Processes]]

==Releases==
* For each release (e.g. Higgins 1.1) we need to create the following for Eclipse legal review. 
** Higgins 1.0: [[Higgins committers with contributions active in the 1.0 repository]], [[Higgins developers with contributions active in the 1.0 repository]], [[Higgins commiters by component]]
* We need to schedule and pass an Eclipse release review

==Milestones==
Each release (e.g. Higgins 1.1) is divided into milestones (e.g. 1.1M7, 1.1M8...) according the the [http://www.eclipse.org/projects/project-plan.php?projectid=technology.higgins 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).
* [http://wiki.eclipse.org/Category:Higgins_Packages 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:
# Create the solution page using [[Solution Description Template]]
# Make sure there is a link to your solution from one of the "Exploring Higgins" web/wiki pages
# Make sure your solution build (see Building section below)
# Make sure your solution is included as a row in one of the [http://www.eclipse.org/higgins/downloads.php Downloads] tables

Solutions are composed of components. For each new component:
# Create a new table on the appropriate [[Components]] page for the component following the [[Components Page Conventions]]
# Edit the autobuild scripts to include java components in the nightly build
# Make sure that automated build scripts are using the latest build.xml
# 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==
* [[Automated Builds]] - description of the existing nightly build process (see [[Build Enhancements]] for a wishlist of enhancements to the nightly and developer build processes)
* [[Starting a Higgins Build]] - how to kick off a build on the eclipse build server
* [[Copying necessary 3rd party libs to project lib folder using PERL script]] --steps to copy all necessary 3rd party libs from centralized location (local) to project lib folder
* [[Automated Solution-Level Builds]] - under development

===Nightly Builds===

* How to sign up for daily build pass/fail email notifications:
*# 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.  
*# 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: [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Higgins&query_based_on=%20open open], [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&product=Higgins&query_based_on=%20closed closed]
* To see the open, closed bugs for each component see [[Components]] pages
== Source Code ==
===Java Projects ===
# Higgins 1.1 projects MUST be developed using Eclipse 3.4
# MUST follow [[Project Structure and Naming]]
# MUST follow [[Project Dependencies]] 
# MUST use [[Higgins2Ant]]
# 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===
# All files MUST carry correct headers, copyrights, license. See [[Higgins File Headers]] 
# 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 [http://babel.eclipse.org 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 [http://www.eclipse.org/resources/?category=Internationalization here].

===SVN===
* [[Higgins SVN Branch Structure]]

=== 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:
# Bugs in any of the Higgins platform components that cause a crash of the overall Higgins system or Higgins based application.
# Bugs that cause a loss of any persistent data.
# Bugs that cause a severe security breach where sensitive end user data can be exposed to the outside world or accessed by unauthorized users.
# Bugs that cause a "major" feature to not function and there is no workaround available to accomplish the same task.
# 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:
# Ensure that a bugzilla ticket has been created for the issue outline the details of the bug in the ticket. 
# Review the nature of their bug against the above outlined criteria
# 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. 
# 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. 
# 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==
* [[Higgins Technical References]]

==Misc Tools==
* [[Higgins Specs]] --how to generate HTML spex from XML input files
* [[Generating anonymous psf file using PERL script]] --steps to generate anonymous psf file for a project including all it's dependencies

==IP-Related==
* List of [[Higgins 1.0 Third Party Dependencies]] --status of each dependency as set by the Eclipse Legal team
* List of [[Higgins Third Party Dependencies]] --status of each dependency as set by the Eclipse Legal team  (This was the original list and has some more cross reference info than is part of the official list above, so we're keeping it around.)
* [[Higgins 1.0 IP Log]]
* [[Higgins IP log]]
* [https://dev.eclipse.org/ipzilla/buglist.cgi?bug_id=&bugidtype=include&chfieldfrom=&chfieldto=Now&chfieldvalue=&component=technology.higgins&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field-1-0-0=product&field-1-1-0=component&field0-0-0=noop&keywords=&keywords_type=allwords&long_desc=&long_desc_type=substring&product=technology&query_format=advanced&remaction=&short_desc=&short_desc_type=allwordssubstr&type-1-0-0=anyexact&type-1-1-0=anyexact&type0-0-0=noop&value-1-0-0=technology&value-1-1-0=technology.higgins&value0-0-0=&order=bugs.bug_severity&query_based_on=    Open Higgins Ipzilla items] (committers only)
* [[Response to Open Specification Promise]] --Higgins and Microsoft CardsSpace
* [[Draft Response to Open Specification Promise]] --earlier draft



==Eclipse Foundation-related Info ==

Eclipse Committers
* http://portal.eclipse.org
* [[Development Resources]]
** [[Development Conventions and Guidelines]]
* Eclipse [[Development Process 2006 Revision Final]]

IPZilla
* [https://dev.eclipse.org/ipzilla/buglist.cgi?bug_id=&bugidtype=include&chfieldfrom=&chfieldto=Now&chfieldvalue=&component=technology.higgins&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field-1-0-0=product&field-1-1-0=component&field0-0-0=noop&keywords=&keywords_type=allwords&long_desc=&long_desc_type=substring&product=technology&query_format=advanced&remaction=&short_desc=&short_desc_type=allwordssubstr&type-1-0-0=anyexact&type-1-1-0=anyexact&type0-0-0=noop&value-1-0-0=technology&value-1-1-0=technology.higgins&value0-0-0=&order=bugs.bug_severity&query_based_on=    Open Higgins Ipzilla items] (committers only)
* Raw [https://dev.eclipse.org/ipzilla/ IPzilla] (committers only)

Legal
* [http://www.eclipse.org/legal/guidetolegaldoc.php Guide to the Eclipse Legal Documents]
* [http://www.eclipse.org/legal/committerguidelines.php Eclipse Committer Due Diligence Guidelines], feel free to email license@eclipse.org with any IP related licensing or process questions
* [http://www.eclipse.org/legal/copyrightandlicensenotice.php  Eclipse Legal Copyright standards]

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 ==
# Put the mouse on new pages by inserting the string '''<nowiki>[[Image:Higgins_logo_76Wx100H.jpg|right]]</nowiki>''' at the top of the page.
# Version wiki pages (adding a "Version" section at the top) as needed (see below).
# Categorize the page by including the category at the bottom of the page. See [http://wiki.eclipse.org/Category:Higgins] for a list of all Higgins Categories. For example insert '''<nowiki>[[Category:Higgins]]</nowiki>''' for general Higgins info.  (Yes, the categories could use some maintenance.). Or insert '''<nowiki>[[Category:Higgins Data Model]]</nowiki>'''

=== 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:
* [[Context Data Model 1.0]] is one copy
* [[Context Data Model 1.1]] is the other copy 
* [http://wiki.eclipse.org/index.php?title=Context_Data_Model&redirect=no this page] is the original page that now includes the redirect command

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

==Meetings and Events==
Upcoming:

Past:
* Mary talks at EclipseCon 2009: [https://www.eclipsecon.org/submissions/2009/view_talk.php?id=656 talk]
* [[Oct_27-29_Boston_F2F_Agenda | Oct 27-29 2008 - Boston F2F]]
* [[May 20-21 Seattle F2F Agenda]]
* [[Higgins Past Meetings and Events]]

==Under Discussion==
The items in this section have NOT been agreed to and put into production. For discussion only.
===Deployment Requirements===
* [[Deployment Requirements]] -- gathering requirements for our build/deploy processes

===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:
*# Identify/develop  autotest capabilty on top of our existing Higgins centric ANT based autobuild platform OR 
*# 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.