Development Process - Revision history

Keshav at 17:39, 26 January 2006

2006-01-26T17:39:43Z

Keshav: /* Proposing a Bug or Feature Enhancement */

2006-01-26T17:24:27Z

‎Proposing a Bug or Feature Enhancement

Keshav: /* geWorkbenchCore */

2006-01-26T17:20:56Z

‎geWorkbenchCore

Keshav: /* Open Source Component */

2006-01-26T17:18:56Z

‎Open Source Component

Keshav: /* Using Independent CVS */

2006-01-26T17:15:06Z

‎Using Independent CVS

Keshav: /* Closed Source Component */

2006-01-26T17:14:55Z

‎Closed Source Component

Keshav: /* Using Project CVS */

2006-01-26T17:13:51Z

‎Using Project CVS

Keshav: /* Using Independent CVS */

2006-01-26T17:12:48Z

‎Using Independent CVS

Keshav: /* Using Independent CVS */

2006-01-26T17:12:26Z

‎Using Independent CVS

Keshav: /* Components */

2006-01-26T17:09:24Z

‎Components

← Older revision		Revision as of 17:39, 26 January 2006
Line 1:		Line 1:
−		+	== ==
	The geWorkbench CVS source tree comprises 2 modules: '''geWorkbenchCore''' and '''geWorkbenchComponents'''. geWorkbenchCore contains "framework" code which under normal circumstances component developers will not have to modify, and geWorkbenchComponents contains components that can be one of two types, '''closed source''' or '''open source'''.		The geWorkbench CVS source tree comprises 2 modules: '''geWorkbenchCore''' and '''geWorkbenchComponents'''. geWorkbenchCore contains "framework" code which under normal circumstances component developers will not have to modify, and geWorkbenchComponents contains components that can be one of two types, '''closed source''' or '''open source'''.

← Older revision		Revision as of 17:24, 26 January 2006
Line 11:		Line 11:

	==== Proposing a Bug or Feature Enhancement ====		==== Proposing a Bug or Feature Enhancement ====
		+
		+	Enter an issue in the geWorkbenchCore JIRA Issue Tracker.
		+
		+	We value your support there. We can't fix bugs we don't know about!
		+
		+	<u>JIRA usage guidelines</u>
		+
		+	Before submitting an issue, please:
		+
		+	* Do your due-diligence to verify the bug does in fact exist.
		+	* Search the issue tracker to verify there is no existing issue reporting the bug you've found.
		+	* Consider tracking down the bug yourself in the geWorkbenchCore codebase, and submitting a patch along with the bug report. This is a great time saver for the core developers and helps ensure the bug will be fixed quickly.
		+
		+	Enhancement requests for new features are also welcome. The more concrete and rationale the request is, the greater the chance it will incorporated into future geWorkbenchCore releases.

	== geWorkbenchComponents ==		== geWorkbenchComponents ==

← Older revision		Revision as of 17:20, 26 January 2006
Line 9:		Line 9:

	Subscribe to the [[Mailing List]]. You do not need to subscribe to submit a patch or two, but if you would like to be involved with development on a regular basis, you may want to consider subscribing.		Subscribe to the [[Mailing List]]. You do not need to subscribe to submit a patch or two, but if you would like to be involved with development on a regular basis, you may want to consider subscribing.
		+
		+	==== Proposing a Bug or Feature Enhancement ====

	== geWorkbenchComponents ==		== geWorkbenchComponents ==

@@ Line 34: / Line 34: @@
 === Open Source Component ===
-This allows taking advantage of our existing CVS infrastructure and also working with the development version of the geWorkbenchCore module (for the latter consultation with the core development team is recommended). Under this model a subdirectory for the new component will be created within geWorkbenchComponents and CVS accounts will be issued to the members of the component development team. All developers in that team will become members of a new Unix group which will own the subdirectory (the rest of the world will have read-only rights).
+Open source component developers can take advantage of our existing CVS infrastructure and also working with the development version of the geWorkbenchCore module (for the latter consultation with the core development team is recommended). Under this model a subdirectory for the new component will be created within geWorkbenchComponents and CVS accounts will be issued to the members of the component development team. All developers in that team will become members of a new Unix group which will own the subdirectory (the rest of the world will have read-only rights).
-<add usage of build script information>
+Developers here are expected to checkout a copy of the development version of the geWorkbenchCore component and test integration of their component plugin by:
 = Versioning Guidelines =

← Older revision		Revision as of 17:15, 26 January 2006
Line 31:		Line 31:

	Under this model component developers are responsible for setting up their own development environment as well as setting up and maintaining their own cvs repository. The geWorkbench SDK (which contains jar files for the core and components modules) will be used in this case. The SDK contains instructions explaining how to setup a local development environment as well as ant scripts for building component code and for packaging components into a .gear archive file, appropriate for distribution through the geWorkbench component repository. When the component is ready for release the '''.gear''' file should be communicated to the geWorkbench team which will then enter it in the component repository. See [[Plugin certification checklist]] for more information on .gear file preparation and the versioning guidlines below.		Under this model component developers are responsible for setting up their own development environment as well as setting up and maintaining their own cvs repository. The geWorkbench SDK (which contains jar files for the core and components modules) will be used in this case. The SDK contains instructions explaining how to setup a local development environment as well as ant scripts for building component code and for packaging components into a .gear archive file, appropriate for distribution through the geWorkbench component repository. When the component is ready for release the '''.gear''' file should be communicated to the geWorkbench team which will then enter it in the component repository. See [[Plugin certification checklist]] for more information on .gear file preparation and the versioning guidlines below.
−
−	'''NOTE:''' Closed source component developers using independent cvs are expected to checkout a copy of the core, include their unit tests in AllTests, and run the test suite to make sure all tests pass with the inclusion of their component. They should submit the unit test report along with the .gear files.

	=== Open Source Component ===		=== Open Source Component ===

← Older revision		Revision as of 17:14, 26 January 2006
Line 17:		Line 17:

	Development teams can either take advantage of our CVS infrastructure, or host the component in their own repository.		Development teams can either take advantage of our CVS infrastructure, or host the component in their own repository.
		+
		+	Developers here are expected to checkout a copy of the development version of the geWorkbenchCore component and test integration of their component plugin by:
		+
		+	* Adding their JUnit test cases to AllTests.
		+	* Running AllTests and making sure all tests pass safely.
		+	* Communicating with development team the desire for release, the .gear files, and their unit test report.

	===== Using Project CVS =====		===== Using Project CVS =====

@@ Line 20: / Line 20: @@
 ===== Using Project CVS =====
 This option allows taking advantage of our existing CVS infrastructure and also working with the development version of the geWorkbenchCore module (for the latter consultation with the core development team is recommended). Under this model a subdirectory for the new component will be created within geWorkbenchComponents and CVS accounts will be issued to the members of the component development team. All developers in that team will become members of a new Unix group which will own the subdirectory, and the rest of the world will '''not''' have read or write access to this directory (this is differnent from the open source component development).
 ===== Using Independent CVS =====

@@ Line 34: / Line 34: @@
 Under this model component developers are responsible for setting up their own development environment as well as setting up and maintaining their own cvs repository. The geWorkbench SDK (which contains jar files for the core and components modules) will be used in this case. The SDK contains instructions explaining how to setup a local development environment as well as ant scripts for building component code and for packaging components into a .gear archive file, appropriate for distribution through the geWorkbench component repository. When the component is ready for release the '''.gear''' file should be communicated to the geWorkbench team which will then enter it in the component repository.  See [[Plugin certification checklist]] for more information on .gear file preparation and the versioning guidlines below.
-'''NOTE:''' Closed source component developers using independent cvs are expected to checkout a copy of the core, include their unit tests in AllTest, and run the test suite to make sure all tests pass with the inclusion of their component.  They should submit the unit test report along with the .gear files.
+'''NOTE:''' Closed source component developers using independent cvs are expected to checkout a copy of the core, include their unit tests in AllTests, and run the test suite to make sure all tests pass with the inclusion of their component.  They should submit the unit test report along with the .gear files.
 === Open Source Component ===

← Older revision		Revision as of 17:12, 26 January 2006
Line 33:		Line 33:

	Under this model component developers are responsible for setting up their own development environment as well as setting up and maintaining their own cvs repository. The geWorkbench SDK (which contains jar files for the core and components modules) will be used in this case. The SDK contains instructions explaining how to setup a local development environment as well as ant scripts for building component code and for packaging components into a .gear archive file, appropriate for distribution through the geWorkbench component repository. When the component is ready for release the '''.gear''' file should be communicated to the geWorkbench team which will then enter it in the component repository. See [[Plugin certification checklist]] for more information on .gear file preparation and the versioning guidlines below.		Under this model component developers are responsible for setting up their own development environment as well as setting up and maintaining their own cvs repository. The geWorkbench SDK (which contains jar files for the core and components modules) will be used in this case. The SDK contains instructions explaining how to setup a local development environment as well as ant scripts for building component code and for packaging components into a .gear archive file, appropriate for distribution through the geWorkbench component repository. When the component is ready for release the '''.gear''' file should be communicated to the geWorkbench team which will then enter it in the component repository. See [[Plugin certification checklist]] for more information on .gear file preparation and the versioning guidlines below.
		+
		+	'''NOTE:''' Closed source component developers using independent cvs are expected to checkout a copy of the core, include their unit tests in AllTest, and run the test suite to make sure all tests pass with the inclusion of their component. They should submit the unit test report along with the .gear files.

	=== Open Source Component ===		=== Open Source Component ===

← Older revision		Revision as of 17:09, 26 January 2006
Line 59:		Line 59:

	Modifications to existing components will be packaged in the next minor release.		Modifications to existing components will be packaged in the next minor release.
−
−	~~'''NOTE:''' Closed source component developers using independent cvs must submit their test suite and test script so we can run the tests before inclusion in the release.~~