Difference between revisions of "The ACME Project"
From GCube System
| (6 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
Let us start with a very simple service and use it to cycle quickly through all the phases of service development: configuration, implementation, building, deployment, and testing. | Let us start with a very simple service and use it to cycle quickly through all the phases of service development: configuration, implementation, building, deployment, and testing. | ||
| − | Let us call it | + | Let us call it <code>SampleService</code> and think of it as a produce of the notorious [http://www.learnthat.com/define/view.asp?id=7324 ACME]. |
| − | + | A first important question to settle concerns the organisation you should give to the implementation components. Creating a <code>SampleService</code> in Eclipse allocates a folder for them under the build location. Say we call this folder the ''service location''. But how should you organise things right below the service location? The advice is to stick to the following folder structure which besides being as simple as it gets, it is perfectly aligned with the [[gCF Primer#Building & Deploying|build facilities]] offered by gCore: | |
| − | + | * a folder <code>etc</code> for all the configuration files of the service. | |
| − | + | * a folder <code>schema</code> for the interfaces and supporting type definitions of the service port-types. | |
| − | * a folder | + | * a folder <code>src</code> for the Java implementation hierarchy. |
| − | * a folder | + | |
| − | * a folder | + | |
<pre> | <pre> | ||
| Line 16: | Line 14: | ||
</pre> | </pre> | ||
| − | '''Note''': Eclipse creates new projects with a | + | '''Note''': Eclipse creates new projects with a <code>src</code> and a <code>bin</code> folder by default, of course. <code>bin</code> collects the binaries but will play no role in our build strategy and so you can largely ignore it. Eclipse helps you here, as it excludes it by default in the package view. |
You may have noticed that there is no provision for service dependencies (typically, ''jar'' archives of | You may have noticed that there is no provision for service dependencies (typically, ''jar'' archives of | ||
| − | classpath resources, typically classes). In a word, you may be wondering where is the classic | + | classpath resources, typically classes). In a word, you may be wondering where is the classic <code>lib</code> folder. First, notice that there are |
two broad kinds of dependencies to consider: | two broad kinds of dependencies to consider: | ||
| − | * the '''standard dependencies''', i.e. dependencies to binaries which ship with the gCore distribution and can be found below the gCore location ( | + | * the '''standard dependencies''', i.e. dependencies to binaries which ship with the gCore distribution and can be found below the gCore location (<code>$GCUBE_LOCATION/lib</code>). The first and foremost dependency of this kind is of course to the gCF jar (<code>org.gcube.common.core.jar</code>), though there are plenty more pontentially available. |
| − | * the '''custom dependencies''', i.e. the dependencies which are specific to the service and whose binaries cannot be guaranteed to be part of a gCore installation. The first and foremost custom dependency of every service is to its own stubs | + | * the '''custom dependencies''', i.e. the dependencies which are specific to the service and whose binaries cannot be guaranteed to be part of a gCore installation. The first and foremost custom dependency of every service is to its own stubs. |
Clearly we need to worry only about custom dependencies. Standard dependencies are already somewhere and all we need to do is to point Eclipse to them. A clean way of doing this requires to: | Clearly we need to worry only about custom dependencies. Standard dependencies are already somewhere and all we need to do is to point Eclipse to them. A clean way of doing this requires to: | ||
| − | * create a user library, say | + | * create a user library, say <code>GCORELIBS</code>, at the workspace level (''Preferences/Java/Build Path/User Libraries/New...'') and populate it with all the binaries in <code>$GCUBE_LOCATION/lib</code> (''Preferences/Java/Build Path/User Libraries/Add Jars...''). |
| − | * specify a single dependency to | + | * specify a single dependency to <code>GCORELIBS</code> in each and very service in the workspace (''Properties/Java Build Path/Libraries/Add Library.../UserLibrary''). |
So, back to custom dependencies. The idea is to follow an unconventional strategy and keep them outside the service location. The main reason for this is that there are tools for the management of custom dependencies to other gCube services which are most conveniently used if we keep those dependencies outside the service location. This will become clear later on, when we will look at those tools. For the time being, just take our word for it. So: | So, back to custom dependencies. The idea is to follow an unconventional strategy and keep them outside the service location. The main reason for this is that there are tools for the management of custom dependencies to other gCube services which are most conveniently used if we keep those dependencies outside the service location. This will become clear later on, when we will look at those tools. For the time being, just take our word for it. So: | ||
| − | * create a generic Eclipse project | + | * create a generic Eclipse project <code>Dependencies</code> and a folder <code>SampleService</code> right under it. The idea here is to have a single project to group the custom dependencies of all the service in the workspace, to dedicate its sub-folders to individual services, and to place custom dependencies in each folder as they become manifest during service development. |
| − | * create another user library | + | * create another user library <code>SAMPLESERVICEDEPS</code> in Eclipse and add it as a single dependency to <code>SampleService</code>. For the time being this library is empty, but we will populate it with all the custom dependencies we place in <code>Dependencies/SampleService</code>''. |
You should end up with something like this: | You should end up with something like this: | ||
<pre> | <pre> | ||
| − | |- SampleService | + | |-SampleService |
|--etc | |--etc | ||
| − | |||
|--src | |--src | ||
|--schema | |--schema | ||
Latest revision as of 15:19, 14 April 2008
Let us start with a very simple service and use it to cycle quickly through all the phases of service development: configuration, implementation, building, deployment, and testing.
Let us call it SampleService and think of it as a produce of the notorious ACME.
A first important question to settle concerns the organisation you should give to the implementation components. Creating a SampleService in Eclipse allocates a folder for them under the build location. Say we call this folder the service location. But how should you organise things right below the service location? The advice is to stick to the following folder structure which besides being as simple as it gets, it is perfectly aligned with the build facilities offered by gCore:
- a folder
etcfor all the configuration files of the service. - a folder
schemafor the interfaces and supporting type definitions of the service port-types. - a folder
srcfor the Java implementation hierarchy.
|-etc |-src |-schema
Note: Eclipse creates new projects with a src and a bin folder by default, of course. bin collects the binaries but will play no role in our build strategy and so you can largely ignore it. Eclipse helps you here, as it excludes it by default in the package view.
You may have noticed that there is no provision for service dependencies (typically, jar archives of
classpath resources, typically classes). In a word, you may be wondering where is the classic lib folder. First, notice that there are
two broad kinds of dependencies to consider:
- the standard dependencies, i.e. dependencies to binaries which ship with the gCore distribution and can be found below the gCore location (
$GCUBE_LOCATION/lib). The first and foremost dependency of this kind is of course to the gCF jar (org.gcube.common.core.jar), though there are plenty more pontentially available. - the custom dependencies, i.e. the dependencies which are specific to the service and whose binaries cannot be guaranteed to be part of a gCore installation. The first and foremost custom dependency of every service is to its own stubs.
Clearly we need to worry only about custom dependencies. Standard dependencies are already somewhere and all we need to do is to point Eclipse to them. A clean way of doing this requires to:
- create a user library, say
GCORELIBS, at the workspace level (Preferences/Java/Build Path/User Libraries/New...) and populate it with all the binaries in$GCUBE_LOCATION/lib(Preferences/Java/Build Path/User Libraries/Add Jars...).
- specify a single dependency to
GCORELIBSin each and very service in the workspace (Properties/Java Build Path/Libraries/Add Library.../UserLibrary).
So, back to custom dependencies. The idea is to follow an unconventional strategy and keep them outside the service location. The main reason for this is that there are tools for the management of custom dependencies to other gCube services which are most conveniently used if we keep those dependencies outside the service location. This will become clear later on, when we will look at those tools. For the time being, just take our word for it. So:
- create a generic Eclipse project
Dependenciesand a folderSampleServiceright under it. The idea here is to have a single project to group the custom dependencies of all the service in the workspace, to dedicate its sub-folders to individual services, and to place custom dependencies in each folder as they become manifest during service development.
- create another user library
SAMPLESERVICEDEPSin Eclipse and add it as a single dependency toSampleService. For the time being this library is empty, but we will populate it with all the custom dependencies we place inDependencies/SampleService.
You should end up with something like this:
|-SampleService |--etc |--src |--schema | |-Dependencies |--SampleService
