Project Development - Revision history

Tuukka Lehtonen: /* Optional Step: Using ready-made project features */

2012-08-01T10:05:54Z

Optional Step: Using ready-made project features

← Older revision		Revision as of 10:05, 1 August 2012
Line 237:		Line 237:
	published="true">		published="true">
	<requires id="myplugin.dummy"/>		<requires id="myplugin.dummy"/>
	~~<!-- Added project feature dependency--->~~
	~~<requires id="myplugin.dependencies"/>~~
	<installGroup id="myplugin.feature.group"/>		<installGroup id="myplugin.feature.group"/>
	</feature>		</feature>
Line 257:		Line 255:
	id="myplugin.dependencies"		id="myplugin.dependencies"
	label="My plugin dependencies">		label="My plugin dependencies">
			<injectDependency targetId="myplugin.project"/>
	<!-- DependencyValidationFeature is the feature implementation. -->		<!-- DependencyValidationFeature is the feature implementation. -->
	<!-- What is specified after the ':' character is given as -->		<!-- What is specified after the ':' character is given as -->

Tuukka Lehtonen: /* Step 1: define extensions for your project features */

2012-08-01T10:05:09Z

Step 1: define extensions for your project features

← Older revision		Revision as of 10:05, 1 August 2012
Line 143:		Line 143:

	The above contains three project features, the first one is published and requires the second one. The third one is injected as a dependency of the first one. This means that when loading a project that uses the '''myplugin.project''' feature, '''myplugin.dummy''' and '''myplug.another''' features will be configured before '''myplugin.project'''.		The above contains three project features, the first one is published and requires the second one. The third one is injected as a dependency of the first one. This means that when loading a project that uses the '''myplugin.project''' feature, '''myplugin.dummy''' and '''myplug.another''' features will be configured before '''myplugin.project'''.

			Note that here both '''requires''' and '''injectDependency''' describe the two mechanisms available for defining dependencies. Using '''injectDependency''' is recommended since it promotes proper decoupling and dependency injection.

	== Step 2: define the code for the project features ==		== Step 2: define the code for the project features ==

Tuukka Lehtonen: /* Optional Step: Using ready-made project features */

2012-08-01T09:59:07Z

Optional Step: Using ready-made project features

← Older revision		Revision as of 09:59, 1 August 2012
Line 243:		Line 243:
	id="myplugin.dummy"		id="myplugin.dummy"
	label="My dummy feature">		label="My dummy feature">
			</feature>
			<feature
			class="myplugin.AnotherFeature"
			id="myplugin.another"
			label="My dummy feature">
			<injectDependency targetId="myplugin.project"/>
	</feature>		</feature>
	<!-- Added project feature -->		<!-- Added project feature -->

Tuukka Lehtonen: /* Step 2: define the code for the project features */

2012-08-01T09:58:28Z

Step 2: define the code for the project features

@@ Line 198: / Line 198: @@
          // Dispose of anything that needs to be disposed of within the project's
          // hint context which can be accessed through getProjectElement().
+     }
+}

Tuukka Lehtonen: /* Step 1: define extensions for your project features */

2012-08-01T09:57:23Z

Step 1: define extensions for your project features

← Older revision		Revision as of 09:57, 1 August 2012
Line 131:		Line 131:
	id="myplugin.dummy"		id="myplugin.dummy"
	label="My dummy feature">		label="My dummy feature">
			</feature>
			<feature
			class="myplugin.AnotherFeature"
			id="myplugin.another"
			label="My dummy feature">
			<injectDependency targetId="myplugin.project"/>
	</feature>		</feature>
	</extension>		</extension>
Line 136:		Line 142:
	</div>		</div>

	The above contains ~~two~~ project features, the first one is published and requires the second one. This means that when loading a project that uses the '''myplugin.project''' feature, '''myplugin.dummy''' ~~feature~~ will be configured before '''myplugin.project'''.		The above contains three project features, the first one is published and requires the second one. The third one is injected as a dependency of the first one. This means that when loading a project that uses the '''myplugin.project''' feature, '''myplugin.dummy''' and '''myplug.another''' features will be configured before '''myplugin.project'''.

	== Step 2: define the code for the project features ==		== Step 2: define the code for the project features ==

Tuukka Lehtonen: /* Overview */

2011-09-03T22:32:55Z

Overview

← Older revision		Revision as of 22:32, 3 September 2011
Line 1:		Line 1:
	= Overview =		= Overview =

	From the Simantics project framework's point of view the content of a Simantics database is broken into ''projects'' and ''database configuration''. A database can contain any number of projects. The configuration data is global and shared by all projects. In essence, '''projects are database entities (resources)''', that consist of all the data produced and consumed when working a subject with Simantics.		From the Simantics project framework's point of view the content of a Simantics database is broken into ''projects'' and ''database configuration''. A database can contain any number of projects. The configuration data is global and shared by all projects. In essence, '''projects are database entities (resources)''', that consist of all the data produced and consumed when working on a subject with Simantics.

Tuukka Lehtonen: /* Simantics Project Management Application (SPM) */

2011-03-30T17:18:55Z

Simantics Project Management Application (SPM)

← Older revision		Revision as of 17:18, 30 March 2011
Line 101:		Line 101:

	Since SPM is not yet usable, the Simantics Workbench platform code has a feature that works around this. When a new workspace and its database is initialized the platform code will add ''PROJ.FeatureSpec'' definitions to the project with the ''<installGroup>''s defined in all available project features marked with ''published="true"''. This makes the workbench work nicely even without SPM.		Since SPM is not yet usable, the Simantics Workbench platform code has a feature that works around this. When a new workspace and its database is initialized the platform code will add ''PROJ.FeatureSpec'' definitions to the project with the ''<installGroup>''s defined in all available project features marked with ''published="true"''. This makes the workbench work nicely even without SPM.

			* [https://www.simantics.org/wiki/index.php/Project_Management SPM Plans]

	= Project Features Step-by-step =		= Project Features Step-by-step =

Tuukka Lehtonen: /* Step 1: Configured Project Feature Resolution */

2011-03-30T17:06:39Z

Step 1: Configured Project Feature Resolution

← Older revision		Revision as of 17:06, 30 March 2011
Line 76:		Line 76:
	A project must contain definitions of what '''Eclipse Features''' are used with it. ''Eclipse Features'' are '''Feature Projects''' created for the Eclipse environment. Do not mistake them for ''project features'' that have been discussed so far. In our project feature example above, we can see the ''<installGroup>'' element stating '''id="org.example.feature.group"'''. Generally Eclipse feature projects are named '''<functionality>.feature''' and the ID given to them just leaves the '''.feature''' suffix out, leaving '''<functionality>''' as the feature ID. In our example, this gives us an Eclipse feature project named '''org.example.feature''' with ID '''org.example'''.		A project must contain definitions of what '''Eclipse Features''' are used with it. ''Eclipse Features'' are '''Feature Projects''' created for the Eclipse environment. Do not mistake them for ''project features'' that have been discussed so far. In our project feature example above, we can see the ''<installGroup>'' element stating '''id="org.example.feature.group"'''. Generally Eclipse feature projects are named '''<functionality>.feature''' and the ID given to them just leaves the '''.feature''' suffix out, leaving '''<functionality>''' as the feature ID. In our example, this gives us an Eclipse feature project named '''org.example.feature''' with ID '''org.example'''.

	Why exactly does the ''<installGroup>'' say ''org.example.feature.group'' then? The reason for this is the [http://wiki.eclipse.org/Equinox/p2 Eclipse P2 provisioning platform]. When an Eclipse feature, such as '''org.example''' is exported into a P2 repository, the feature project will become an ''~~Installable Unit~~'' with ID '''org.example.feature.group'''. Since Simantics project management is planned on top of P2, we use these P2 concepts in the project framework also.		Why exactly does the ''<installGroup>'' say ''org.example.feature.group'' then? The reason for this is the [http://wiki.eclipse.org/Equinox/p2 Eclipse P2 provisioning platform]. When an Eclipse feature, such as '''org.example''' is exported into a P2 repository, the feature project will become an ''installable unit'' with ID '''org.example.feature.group'''. Since Simantics project management is planned on top of P2, we use these P2 concepts in the project framework also.

	Due to all explained above, the project framework expects to find this ''used Eclipse features'' information attached to the project as follows (expressed in [[Graph File Format]]):		Due to all explained above, the project framework expects to find this ''used Eclipse features'' information attached to the project as follows (expressed in [[Graph File Format]]):

Tuukka Lehtonen: /* Step 1: Configured Project Feature Resolution */

2011-03-30T17:06:13Z

Step 1: Configured Project Feature Resolution

← Older revision		Revision as of 17:06, 30 March 2011
Line 76:		Line 76:
	A project must contain definitions of what '''Eclipse Features''' are used with it. ''Eclipse Features'' are '''Feature Projects''' created for the Eclipse environment. Do not mistake them for ''project features'' that have been discussed so far. In our project feature example above, we can see the ''<installGroup>'' element stating '''id="org.example.feature.group"'''. Generally Eclipse feature projects are named '''<functionality>.feature''' and the ID given to them just leaves the '''.feature''' suffix out, leaving '''<functionality>''' as the feature ID. In our example, this gives us an Eclipse feature project named '''org.example.feature''' with ID '''org.example'''.		A project must contain definitions of what '''Eclipse Features''' are used with it. ''Eclipse Features'' are '''Feature Projects''' created for the Eclipse environment. Do not mistake them for ''project features'' that have been discussed so far. In our project feature example above, we can see the ''<installGroup>'' element stating '''id="org.example.feature.group"'''. Generally Eclipse feature projects are named '''<functionality>.feature''' and the ID given to them just leaves the '''.feature''' suffix out, leaving '''<functionality>''' as the feature ID. In our example, this gives us an Eclipse feature project named '''org.example.feature''' with ID '''org.example'''.

	Why exactly does the ''<installGroup>'' say ''org.example.feature.group'' then? The reason for this is the [http://wiki.eclipse.org/Equinox/p2 Eclipse P2 provisioning platform]. When an Eclipse feature, such as '''org.example''' is exported into a P2 repository, the feature project will become an '''Installable Unit''' with ID '''org.example.feature.group'''. Since Simantics project management is planned on top of P2, we use these P2 concepts in the project framework also.		Why exactly does the ''<installGroup>'' say ''org.example.feature.group'' then? The reason for this is the [http://wiki.eclipse.org/Equinox/p2 Eclipse P2 provisioning platform]. When an Eclipse feature, such as '''org.example''' is exported into a P2 repository, the feature project will become an ''Installable Unit'' with ID '''org.example.feature.group'''. Since Simantics project management is planned on top of P2, we use these P2 concepts in the project framework also.

	Due to all explained above, the project framework expects to find this ''used Eclipse features'' information attached to the project as follows (expressed in [[Graph File Format]]):		Due to all explained above, the project framework expects to find this ''used Eclipse features'' information attached to the project as follows (expressed in [[Graph File Format]]):

Tuukka Lehtonen: /* Omnipresent Project Features */

2011-03-30T16:57:33Z

Omnipresent Project Features

← Older revision		Revision as of 16:57, 30 March 2011
Line 283:		Line 283:
	To define an omnipresent project feature, use the following template:		To define an omnipresent project feature, use the following template:

	<~~blockquote~~>		<div style="background-color:#f8f8f8; border: 1px dashed #cccccc; padding: 1ex; margin-left:2em; margin-top: 1em; margin-bottom:1em;">
	<syntaxhighlight lang="xml">		<syntaxhighlight lang="xml">
	<extension		<extension
Line 297:		Line 297:
	</extension>		</extension>
	</syntaxhighlight>		</syntaxhighlight>
	</~~blockquote~~>		</div>

	=== Load project from database and activate it ===		=== Load project from database and activate it ===