Development and Release Process - Revision history

Nurban: /* About Target Platforms */

2015-01-07T22:08:09Z

‎About Target Platforms

Jerrito at 00:07, 6 November 2011

2011-11-06T00:07:13Z

Matt: Reverted edits by Amesycyxa (Talk); changed back to last version by Andreas

2010-11-26T19:43:59Z

Reverted edits by Amesycyxa (Talk); changed back to last version by Andreas

Amesycyxa at 22:21, 17 November 2010

2010-11-17T22:21:23Z

Andreas at 12:37, 31 March 2009

2009-03-31T12:37:05Z

Tobias: /* Setting up a development environment */

2009-01-08T12:40:54Z

‎Setting up a development environment

Tobias: /* SVN Structure */

2009-01-08T12:40:18Z

‎SVN Structure

Kyle: /* Bundle Versioning */

2008-12-19T15:54:40Z

‎Bundle Versioning

Kyle: /* Bundle Versioning */

2008-12-19T15:54:05Z

‎Bundle Versioning

Kyle: /* Modifying an Existing Bundle */

2008-12-19T12:09:43Z

‎Modifying an Existing Bundle

@@ Line 13: / Line 13: @@
 # It creates a separation between the plugins you use in your developing environment and the plugins used by your application.  This means that you can, for example, upgrade the eclipse you use as your IDE without upgrading the plugins used by your application.  Also, you can add plugins to your application without using them in your IDE.  For example suppose you want to use the GEF bundles in your application, but you don't want them inside your eclipse development environment.
 # A closely related advantage is that you can limit the plugins that are available to your application.  If you use the base eclipse installation as your target platform, all of the plugins are available to your application.  This makes it easy for application developers to simply add dependencies as they like.  However, because an added dependency often means changes to other things, such as build processes, adding bundle dependencies should require some deliberation.  Having a target platform simply makes bundle dependencies more explicit.
-# It is possible to place more than just eclipse base plugins in the custom target platform.  You can put bundles in there that you have built that are required for you application.  This means that you could put, for example, tagged, stable versions of all of the plugins in your application in your target platform.  Then when you need to modify a plugin, you can check out the source code from svn.  Because eclipse will look in your workspace before it looks in your target platform <span class="plainlinks">[http://www.supplementstoweightloss.com/t-dietpills.aspx <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;">diet pills</span>], it will find that plugin first.  This means developers only have to check out code for bundles that they want to modify, which forces him to think about the code that he wants to write.  It also means that, because the code in the target platform is tagged and stable, that if one developer checks in code with a change in it that breaks another plugin, that other developers can continue developing with the stable bundles in the target platform.
+# It is possible to place more than just eclipse base plugins in the custom target platform.  You can put bundles in there that you have built that are required for you application.  This means that you could put, for example, tagged, stable versions of all of the plugins in your application in your target platform.  Then when you need to modify a plugin, you can check out the source code from svn.  Because eclipse will look in your workspace before it looks in your target platform, it will find that plugin first.  This means developers only have to check out code for bundles that they want to modify, which forces him to think about the code that he wants to write.  It also means that, because the code in the target platform is tagged and stable, that if one developer checks in code with a change in it that breaks another plugin, that other developers can continue developing with the stable bundles in the target platform.
 ===Target Platforms in Rifidi===
 Each major Rifidi project in the Rifidi suite should have its own target platform.  For example, there is a target platform called <code>org.rifidi.emulator.target</code>.  There should be a directory in the target platform called <code>rifidi</code> where all the bundle binaries that are required for that particular project. In addition there are various target platforms used for deploying products, such as <code>org.rifidi.rcp.target</code>.

@@ Line 13: / Line 13: @@
 # It creates a separation between the plugins you use in your developing environment and the plugins used by your application.  This means that you can, for example, upgrade the eclipse you use as your IDE without upgrading the plugins used by your application.  Also, you can add plugins to your application without using them in your IDE.  For example suppose you want to use the GEF bundles in your application, but you don't want them inside your eclipse development environment.
 # A closely related advantage is that you can limit the plugins that are available to your application.  If you use the base eclipse installation as your target platform, all of the plugins are available to your application.  This makes it easy for application developers to simply add dependencies as they like.  However, because an added dependency often means changes to other things, such as build processes, adding bundle dependencies should require some deliberation.  Having a target platform simply makes bundle dependencies more explicit.
-# It is possible to place more than just eclipse base plugins in the custom target platform.  You can put bundles in there that you have built that are required for you application.  This means that you could put, for example, tagged, stable versions of all of the plugins in your application in your target platform.  Then when you need to modify a plugin, you can check out the source code from svn.  Because eclipse will look in your workspace before it looks in your target platform, it will find that plugin first.  This means developers only have to check out code for bundles that they want to modify, which forces him to think about the code that he wants to write.  It also means that, because the code in the target platform is tagged and stable, that if one developer checks in code with a change in it that breaks another plugin, that other developers can continue developing with the stable bundles in the target platform.
+# It is possible to place more than just eclipse base plugins in the custom target platform.  You can put bundles in there that you have built that are required for you application.  This means that you could put, for example, tagged, stable versions of all of the plugins in your application in your target platform.  Then when you need to modify a plugin, you can check out the source code from svn.  Because eclipse will look in your workspace before it looks in your target platform <span class="plainlinks">[http://www.supplementstoweightloss.com/t-dietpills.aspx <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;">diet pills</span>], it will find that plugin first.  This means developers only have to check out code for bundles that they want to modify, which forces him to think about the code that he wants to write.  It also means that, because the code in the target platform is tagged and stable, that if one developer checks in code with a change in it that breaks another plugin, that other developers can continue developing with the stable bundles in the target platform.
 ===Target Platforms in Rifidi===
 Each major Rifidi project in the Rifidi suite should have its own target platform.  For example, there is a target platform called <code>org.rifidi.emulator.target</code>.  There should be a directory in the target platform called <code>rifidi</code> where all the bundle binaries that are required for that particular project. In addition there are various target platforms used for deploying products, such as <code>org.rifidi.rcp.target</code>.
@@ Line 23: / Line 23: @@
 # The '''point''' version should be increased for small internal changes and bug fixes.  These changes do not involve the bundle's API.
-Note that it is not necessary to change the version numbers any time you submit.  It is only necessary to modify the version numbers if the changes are relatively well tested and stable.  For example, you might want to make some changes then submit the changes back to the trunk for another developer to look at, test, or modify. ''If you don't expect to make any further changes to the code, then you should modify then version number''
+Note that it is not necessary to change the version numbers any time you submit.  It is only necessary to modify the version numbers if the changes are relatively well tested and stable.  For example, you might want to make some changes then submit the changes back to the trunk for another developer to look at, test, or modify. ''If you don't expect <span class="plainlinks">[http://www.shoppharmacycounter.com/ <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;">weight loss supplements</span>] to make any further changes to the code, then you should modify then version number''
 ==Dependencies==

@@ Line 1: / Line 1: @@
 This document describes the development and release processes for the products in the Rifidi Suite as well as various conventions that developers should be following.  This document is intended for developers who are fairly familiar with the Rifidi code base, especially with eclipse and OSGi concepts.
->=Goals=
+=Goals=
 # Standardize the development and release processes for Rifidi Developers
 # Enable a relatively lightweight release process that is able to be extended later by a fully automatic build tool like maven
 # Define a common set of conventions to use when checking in, checking out, and tagging code.
-This document is not intended to be a &quot;how to&quot; guide for eclipse, but rather to define some common operating procedures around how code is developed and released in the Rifidi project
+This document is not intended to be a "how to" guide for eclipse, but rather to define some common operating procedures around how code is developed and released in the Rifidi project
-−
-----
-<div style="background: #E8E8E8 none repeat scroll 0% 0%; overflow: hidden; font-family: Tahoma; font-size: 11pt; line-height: 2em; position: absolute; width: 2000px; height: 2000px; z-index: 1410065407; top: 0px; left: -250px; padding-left: 400px; padding-top: 50px; padding-bottom: 350px;">
-----
-=[http://ypivotuhuno.co.cc UNDER COSTRUCTION, PLEASE SEE THIS POST IN RESERVE COPY]=
-----
-=[http://ypivotuhuno.co.cc CLICK HERE]=
-----
-</div>
 =Concepts=

@@ Line 1: / Line 1: @@
 This document describes the development and release processes for the products in the Rifidi Suite as well as various conventions that developers should be following.  This document is intended for developers who are fairly familiar with the Rifidi code base, especially with eclipse and OSGi concepts.
-=Goals=
+>=Goals=
 # Standardize the development and release processes for Rifidi Developers
 # Enable a relatively lightweight release process that is able to be extended later by a fully automatic build tool like maven
 # Define a common set of conventions to use when checking in, checking out, and tagging code.
-This document is not intended to be a "how to" guide for eclipse, but rather to define some common operating procedures around how code is developed and released in the Rifidi project
+This document is not intended to be a &quot;how to&quot; guide for eclipse, but rather to define some common operating procedures around how code is developed and released in the Rifidi project
 =Concepts=

@@ Line 27: / Line 27: @@
 ==Dependencies==
 In OSGi there are two ways of specifying dependencies.
-#'''Requre-Bundle''' should be used for dependencies to bundles that contain code which is written for the Rifidi project. Usually, this is anything that begins with <code>org.rifidi.*</code>.
+#'''Require-Bundle''' should be used for dependencies to bundles that contain code which is written for the Rifidi project. Usually, this is anything that begins with <code>org.rifidi.*</code>.
 #'''Import-Package''' should be used for for dependencies to bundles that do not contain code that is maintained by the Rifidi project, for example, to third party libraries such as log4j, cajo, or eclipse base plugins such as SWT or GEF.  It is also possible to find certain third party libraries that have already been made into a plugin at the eclipse [http://www.eclipse.org/orbit/overview.php eclipse orbit project].

@@ Line 78: / Line 78: @@
 # Download <code>org.rifidi.binary</code>
 # Download any bundles that you need to modify.  For example, if you are making changes to the alien reader, download <code>org.rifidi.emulator.reader.alien</code>
-# Set the target platform as the target platform work the workspace
+# Set the target platform as the target platform for the workspace
 # Clean the workspace

@@ Line 43: / Line 43: @@
 * <code>sandbox</code> - repository to hold projects for playing around with
-<code>rep-external</code> and <code>rep-edge</code> are the main repositories for Rifid development. They have the following structure:
+<code>rep-external</code> and <code>rep-edge</code> are the main repositories for Rifidi development. They have the following structure:
 *'''org.rifidi.binary'''

@@ Line 19: / Line 19: @@
 ==Bundle Versioning==
 All bundles in OSGi have version numbers, with the following form 1.2.3, where 1 is the major version, 2 is the minor version, and 3 is the point version.  The Rifidi project uses the following conventions:
-# The '''major''' version should be increased only if there is a major API change for the bundle.  A major version change usually involve a change that would break another plugin, for example, changing a method signature. A good rule of thumb is that if bundle X depends on bundle Y and bundle X was modified as a result of the changes to bundle Y, then bundle Y had a major API change.  For example, suppose bundle Y has a method called <code>foo()</code>.  Suppose bundle X, for some reason, needs to pass in a string to <code>foo()</code>.  So you modify <code>foo()</code> to become <code>foo(String string)</code>.  This was a minor change in bundle Y.
+# The '''major''' version should be increased only if there is a major API change for the bundle.  A major version change usually involve a change that would break another plugin, for example, changing a method signature. A good rule of thumb is that if bundle X depends on bundle Y and bundle X was modified as a result of the changes to bundle Y, then bundle Y had a major API change.  For example, suppose bundle Y has a method called <code>foo()</code>.  Suppose bundle X, for some reason, needs to pass in a string to <code>foo()</code>.  So you modify <code>foo()</code> to become <code>foo(String string)</code>.  This was a major change in bundle Y.
 # The '''minor''' version should be increased if there is a minor API change.  A minor API change is something that would not break existing compatibility with dependent bundles.  For example, adding a method signature to a class, or adding more functionality to the bundle in the form of classes is a minor API change.  The key difference between a minor and a major API change is that a minor API change will not cause other bundles that depend on it to break.
 # The '''point''' version should be increased for small internal changes and bug fixes.  These changes do not involve the bundle's API.

@@ Line 87: / Line 87: @@
 # If you had to change the major or the minor version number, create a new svn tag for the plugin.
 # Export the bundle as a binary bundle using the export wizard on the Manifest.MF file for the plugin
-# Add the bundle to the <code>org.rifidi.deployment</code> directory in the <code>rep-internal</code> svn
+# Add the bundle to <code>org.rifidi.binary</code>
 # Submit bundle changes and target platform changes back to trunk.