Skip to content

Before development

Jump to bottom Edit New page
Alejandro Medrano edited this page May 20, 2015 · 2 revisions

<< prev | 1 [2] 3 4 | next >>

Download all wiki pages of this project as a PDF book

Before Development

Table of Contents

Prerrequirements

The first step is to understand basics on universAAL. To achieve this aim it should be consulted the Reference Documentationhttp://forge.universaal.org/wiki/support:Developer_Handbook_0 where a summary of the universAAL platform is provided along Chapter 1 - Platform Architecture Overview http://forge.universaal.org/wiki/support:Developer_Handbook_1. Also, Chapter 2 - Development Environment Setup http://forge.universaal.org/wiki/support:Developer_Handbook_2 explains how to install the development environment (JDKhttp://forge.universaal.org/wiki/support:Developer_Handbook_2#Installing_Java, Mavenhttp://forge.universaal.org/wiki/support:Developer_Handbook_2#Installing_Maven, MySQLhttp://forge.universaal.org/wiki/support:Developer_Handbook_2#Installing_MySQL_.28optional.29 and Eclipsehttp://forge.universaal.org/wiki/support:Developer_Handbook_2#Installing_Eclipse with the needed plugins: AAL Studio) together with the SVN clienthttp://forge.universaal.org/wiki/support:Developer_Handbook_2#Installing_a_Subversion-client and configure the settingshttp://forge.universaal.org/wiki/support:Developer_Handbook_2#Configuring_your_Maven_settings. Next step is getting the universAAL source codehttp://forge.universaal.org/wiki/support:Developer_Handbook_2#Getting_the_universAAL_sources. Some interesting SVN links from where it is available are:

Project Management

Gforge

Gforge http://forge.universaal.org/wiki/support:Developer_Handbook_2#Getting_the_universAAL_sources is a tool used for project management. It is organized in projects, where each one has mainly an associated Issue tracker, Wiki and SVN.

Projects in universAAL are managed within GForge projects. Currently exists two GForge projects for WP4:

In following sections are provided further details about each part:

Issue Tracker

Issue tracker is intended to:

  • Manage detected bugs.
  • Give/receive support: Problems to run the code, etc.
  • Feature request: Suggest new functionalities that are not there.
For further information consult D2.3-D - universAAL integration and testing strategy and Issue Tracker - Software management, continuous integration, testing strategy and issue tracker - Part I, Appendix A. Quick Developer Reference https://project.sintef.no/eRoom/ikt/ICT-20097-ICTAgeing/0_6a809.

Wiki

This tool will be used to make available information about development and services within WP4 http://forge.universaal.org/wiki/Home.

SVN

SVN http://subversion.apache.org/ is a software versioning and a revision control system aimed at developers to maintain current and historical versions of files such as source code, web pages and documentation. In WP4, conventions for the SVN structure are the following:

  • Trunk/service_name/bundle: Current version of the code
  • Branch/service_name/bundle: Pararel development to the current version of the code, which include some modifications
  • Tag/service_name/bundle: Closed versions of the code

universAAL tools

In order to develop new services, universAAL provides a wide number of tools that will make your developments easier. All these tools will be included in the AAL Studio. More information about how to install AAL Studio and how to install and start using the tools can be found here http://forge.universaal.org/mediawiki/index.php?title=uaaltools:AAL_Studio_overview_and_installation.

Strategy for WP4 Ontologies

Since there is a clear problem while synchronizing WP4 ontologies with WP2 ontologies, we need to change the approach for WP4 ontologies, and make it more WP2 compliant.

WP4 ontologies repository

  1. All WP4 ontologies are to be located inside the SAME folder in the SVN.
  2. All WP4 ontologies are to have a common parent project.
  3. The WP4-ontologies subrepository is to be managed by WP4 developers, therefore the parent pom must be kept up to date.

SVN subrepository for Ontologies

Ontologies are to be moved (branched and then deleted from their original location) to the following folder 

    http://forge.universaal.org/svn/new_services/trunk/ontologies/

Therefore the structure will look like: 

     /trunk
          /service1
              /service1.pom
              /service1.module1
              /service1.module2
          /service2
              /service2.pom
              /service2.module1
              …
          /ontologies
              /ont.pom
              /ont.service1
              /ont.service2

This means that after the ontologies are moved the service.pom file no longer have to contain the ontologies as modules, and therefore should be removed.

WP4 Parent Ontology POM

The WP4 Parent for all WP4 ontologies is located at http://forge.universaal.org/svn/new_services/trunk/ontologies/ont.pom

This project is itself a child of the WP2 official ontologies root project.

The project has the following identificator: 

    <groupId>org.universAAL.ontology.services</groupid>
    <artifactId>ont.pom</artifactid>

Therefore all WP4 ontologies must change their parent to point to this project (just adding “.services” to groupId).

To maintain the artifact's maven coordinates (groupID, ArtifactID, version) add a groupID tag: 

    <groupId>org.universAAL.ontology</groupid>

This will enable WP4 to be deployed in WP4’s private nexus repository.

Inside this parent project there will be a script that will ease the maintenance of the pom itself, it is the update.bat. This script is to be executed when:

  • An ontology is added to the subrepository.
  • An ontology version is changed in the subrepository.
  • An ontology is removed from the subrepository.
And it will automatically manage the “modules” and the “dependency.management” sections of the parent pom. After each update the pom must be checked (for the modifications introduced) and commited to the SVN.

The parent WP4 ontology project will also be imported in the root pom file for WP4 which means now all versions can be removed from each service.pom file, since the version of the ontologies will be resolved through parent inheritance and import.

Instructions to transfer to new WP4 Ontology Strategy

  1. Branch all ontologies form http://forge.universaal.org/svn/new_services/trunk/myService/ont.myOntology to http://forge.universaal.org/svn/new_services/trunk/ontologies/ont.myOntology
  2. Delete form their original SVN location all branched ontologies.
  3. Remove any module that points to the removed ontologies in the service.pom.
  4. Remove any version in the dependencies from any module (or service.pom’s dependency management section) that depends on the ontologies.
  5. Update the svn repo to receive the newly branched ontologies
  6. Update the pom files of the ontologies to inherit from the WP4 ontologies parent pom (i.e. add “.services” to the groupId of the parent).
  7. Add a groupID tag for common ontologies (ie: <groupid>org.universAAL.ontology</groupid>)
  8. After all these changes an install must work, try installing new_services.pom
  9. If 8 went ok then commit all the changes.

Synchronization with WP2

When WP4 ontologies are sufficiently mature and stable, they can be moved to the WP2 ontologies repo (the official ontology repo). The steps to perform this transfer (according to the new WP4 strategy) are:

  1. SVN export the ontology, without including unversioned files, to wherever you got the official ontologies trunk.
  2. SVN add the new folder to the version control of ontologies official repository. (try if you can to SVN ignore “.settings”, “.classpath”, “.project”, and “target” files).
  3. Remove the “.services” form the parent groupID of your ontology (and the groupID tag, it should be marked as repeated).
  4. Update official ont.pom (the same script is already there)

Strategy between WP2-WP4

This strategy stems from the need of having more communication since WP4 works as client of WP2, being a synergy between both work packages in the sense of WP4 asks for new features and WP2 knows what should be priorized.

Figure 2. Strategy between WP2 and WP4

Step 1. What means a new release from WP2

  • A new release coming from WP2 means a new:
    • POM file: uAAL.pom
    • Updated examples
    • Short list of changes for each release of the runtime platform
    • Instructions of how to transfer from one release version to another

Step 2. New WP2 release in WP4

RELEASE Runtime Platform Support DATE
E.0 2.0.0 21.06.2013
D.0 1.3.0 14.12.2012
C.1 1.2.1-SNAPSHOT 15.09.2012
C.0 1.2.0 17.07.2012
B.1 1.1.1-SNAPSHOT 29.05.2012
B.0 1.1.0 27.03.2012

LEGEND:

  • RELEASE, it is the release name to be used in WP4. When a new artifact version is introduced in the current release, it is created a new release version in order to identify changes. It increases the version number (starts in 0), keeping the vowel until next official release.
  • Runtime Platform Support define the version of the artifacts included in the corresponding release version.
  • DATE is when the release was released.
  • Table is descending order by DATE, so first row is the active release.

How to know that a new release from WP2 is available

  • universAAL News
  • Responsible person from WP2 (ALEJANDRO MEDRANO) will contact the prototype manager and T4.2 leader

How WP4 partners are informed when there is a new release from WP2

  • The prototype manager and T4.2 leader notifies officially the a new release is available from WP2 to WP4 partners by means of:
    • WP4 scrum
    • new_services wiki
    • By email to WP4 partners

Step 3. Where to find release information

Step 4. Using a new release in WP4

universAAL POMs

  • All WP4 AAL services must use the same universAAL platform release.
    • Following figure shows different existing POMs in universAAL and inheritance between them:

Figure 3. Hierarchy of POM files in universAAL

Figure 4. File structure

  • uAAL.pom
    • It provides information about licenses, specific repositories, plugins, etc.
    • It is provided by WP2
    • Responsible: Alejandro Medrano ([email protected])
  • newServices.pom
    • It is referenced by each AAL service and defines common info for all AAL applications such as middleware, ontologies, etc.
    • It is provided by WP4
    • Responsible: Alejandro Medrano ([email protected])
  • myService.pom
    • Exists one per AAL service where are described artifacts of the service, dependencies with third-party software (weka, drools,…), external repositories and dependencies to other services. i.e. Nutritional Advisor needs to send SMS, then it uses Personal safety SMS artifact. Here is defined the dependency between Nutritional Advisor and Personal Safety service.
    • It is provided by each service developer
    • Responsible: Each service developer
  • myModule.pom
    • It describes the artifact and dependencies between artifacts of the service or artifacts from other services. In this last case, in the myService pom should be defined (import) the dependency to the owner (service) of the artifact that it wants to use. Here will not be specified version because it is managed in the superior level. i.e. MenuManager artifact from Nutritional Advisor service uses SMS module from Personal Safety service. Then, in myModuleMenuManager pom is specified that MenuManager artifact wants to use SMS artifact from Personal Safety service, and in myServiceNutritionalAdvisor pom is detailed that Nutritional Advisor wants to use an artifact from Personal Safety service.
    • It is provided by each service developer
    • Responsible: Each service developer

Figure 5. Sample of relationship between poms in universAAL

POMs I need to include in my AAL Service project and where

Figure 6: File structure

  • Concretely, myService.pom must be located at:
http://forge.universaal.org/svn/new_services/trunk/MYSERVICE/MYSERVICE.pom/pom.xml
  • And myModule.pom must be at:
http://forge.universaal.org/svn/new_services/trunk/MYSERVICE/ARTIFACT/pom.xml

What must be modified in POM files

The following figures show relationships between POMs and what parts must be modified: LEGEND

  • Blue arrow points at relevant info.
  • Red arrow point at info that must be fulfilled/modified by WP4 AAL Service developer/leader.
  • Circles indicate what version must be selected in parent POM to its child POM.

By defining the following in new_services.pom, the scm section will be inherited by all POMs and when the variables are resolved, then the scm is correct. 

 <scm>
    <connection>${svn.base}/${service.name.svn}/${project.artifactId}</connection>
    <developerConnection>${svn.base}/${service.name.svn}/${project.artifactId}</developerconnection>
 </scm>

myService.myArtifactX must define service.name.svn property that must be equal to svnServiceName. i.e: As the service folder is named in the SVN. 

 <properties>
     <service.name.svn>nutritional</service.name.svn>>
 </properties>

Release planning

When developers need to know what release number must be used in their service implementation or what artifact versions are inside the current release, they must consult this table:

WP2-WP4 RELEASES

WP2 - Date WP2 - Month WP2 - Version WP2 - Name WP4 - Date WP4 - Milestone
14.12.2012 M31 1.3.0 D.0 21.12.2012 -
after 17.07.2012 M32 1.2.1-SNAPSHOT C.1 2.11.2012 -
17.07.2012 M30 1.2.0 C.0 21.09.2012 R1.2
- M29 1.1.1-SNAPSHOT B.1 - -
27.03.2012 M26 1.1.0 B.0 05.06.2012 R1.1

Step 5. How to report bugs...

...to WP2

...to WP4 AAL Services

When you experience an error in one of the WP4 AAL Service you can report it in the corresponding tracker at:

Chapters

Add a custom footer
Add a custom sidebar
Clone this wiki locally