Development GEM - Revision history

⚠️Wenzeslaus: move to trac

2014-01-29T02:35:00Z

move to trac

← Older revision		Revision as of 02:35, 29 January 2014
Line 1:		Line 1:
	{{OldGRASSVersion}}		{{OldGRASSVersion}}
			{{MoveToTrac}}

			''Should be moved to Trac Wiki as a historical document; better name is need.''

	- '''Applies to GRASS Version 6 (but only pre 6.4)''' -		- '''Applies to GRASS Version 6 (but only pre 6.4)''' -

Neteler: old stuff warning

2013-04-02T19:27:25Z

old stuff warning

← Older revision		Revision as of 19:27, 2 April 2013
Line 1:		Line 1:
			{{OldGRASSVersion}}

			- '''Applies to GRASS Version 6 (but only pre 6.4)''' -

	===GRASS add-on structure using GEM===		===GRASS add-on structure using GEM===

⚠️Landa: syntax fix

2008-04-13T00:07:51Z

syntax fix

← Older revision		Revision as of 00:07, 13 April 2008
Line 69:		Line 69:
	list of key words (semi-automate?)		list of key words (semi-automate?)

	[[~~Categories~~:Development]]		[[Category:Development]]

Neteler: Category:Development

2006-08-23T18:55:50Z

Category:Development

← Older revision		Revision as of 18:55, 23 August 2006
Line 68:		Line 68:
	An idea could be to assign 5 keywords to each command/man page from a		An idea could be to assign 5 keywords to each command/man page from a
	list of key words (semi-automate?)		list of key words (semi-automate?)

			[[Categories:Development]]

⚠️Wegmann at 14:19, 22 August 2006

2006-08-22T14:19:36Z

← Older revision		Revision as of 14:19, 22 August 2006
Line 3:		Line 3:
	(copy from e-mail to dev List)		(copy from e-mail to dev List)

	The following options are a sum-up of ideas so that the GEM add-on structure plus svn(?) can be properly set-up.		The following options are a sum-up of ideas concerning the GEM repository so that the GEM add-on structure plus svn(?) can be properly set-up.

	====Nomenclatur====		====Nomenclatur====

⚠️Wegmann: moved GEM explanation to this page

2006-08-22T14:15:04Z

moved GEM explanation to this page

New page

===GRASS add-on structure using GEM===

(copy from e-mail to dev List)

The following options are a sum-up of ideas so that the GEM add-on structure plus svn(?) can be properly set-up.

====Nomenclatur====

* main: path to GRASS-main code (restricted to GRASS-main developers)
* add-on: path to additional function (moderated "public" develop.)
* commands: well, single commands ...
* packages: bunch of commands dealing with a certain issues

====software constraints====

* migration to svn is necessary to have restricted/selective access for main and add-on

====add-on manager (person)====

* an add-on manager who checks incoming commands/packages for their quality (code, help, man-pages)
* a status for fresh commands would be good (fresh commands vs. "officially" accepted commands) -> how does R deal with it? Automated builds could be done on grass.itc.it along with a status page

====GEM====

* packages installed via UI or CI via WWW or local
* packages updated via UI or CI
* packages afterwards permanently loaded in certain location/mapset and not in others
* package removal from location/mapset

====add-on structure====

(I orientate myself on the R structure, because I am familiar with it and
like it, if anybody else has different ideas, please feel free to discuss
it)

* setup of different packages for different topics (classif., hydro., landscape ecol., spatial model. etc. see below)

* every command is assigned to a package, even the "old" one, just to keep the structure consistent (?) - assigned to package "base"?

* r.*, v.*, i.* commands might be together in one package and installed simultaneously - no splitting between r./v./i. commands in separate packages

* after loading in UI:
raster/package_name->command
vector/package_name->command
--> no merge inside "base" commands but in separate dir in UI

* broad package topics for starting point; in the future further splitting might be necessary to keep it simple:

** data handling
** Geo-Statistics
** GIS tasks
** image classification
** hydrology
** spatial modelling
** landscape ecology
** fire modelling
** bathymetry
** data enhancement
** ...

I would suggest to list all commands in the man pages with their package
affiliation in brackets and not to list them only if package is loaded or in
separate directory.
An idea could be to assign 5 keywords to each command/man page from a
list of key words (semi-automate?)