Jump to: navigation, search

Difference between revisions of "Acceleo/Setup Environment"

(Unit Tests)
(No difference)

Revision as of 05:25, 24 June 2010

Dependencies

  • Eclipse

Developping on Acceleo requires the use of Eclipse Platform 3.4 at least, though it is possible to use the latest releases as well. It can be obtained through the Eclipse download page.

  • EMF

Acceleo heavily relies on EMF and requires version 2.4 at least. We recommend using the SDK so as to have access to the sources as well. See the EMF downloads page

  • OCL

Acceleo is an implementation of the MOF Model to Text Transformation Language (MTL) OMG specification. MTL is built on top of OCL and Acceleo in turn depends on OCL. We require at least version 1.2 (Available for Eclipse 3.4) but OCL 1.3 (For Eclipse 3.5) and OCL 3.0 (for Eclipse 3.6) can be used as well. All three versions can be downloaded from the OCL download page.

Checking out the code

Using Project Set File (PSF)

  • Download the PSF file and save it on your computer.
  • Open Eclipse and switch to the Java perspective
  • Through the File menu, select File => Import and in the Import popup, select Team => Team Project Set and hit "Next"
  • Open the psf file you saved on your disk
  • Eclipse might prompt you to create the repository. Do so by either choosing pserver connection with "anonymous" as your user name, or extssh connection if you are a commiter.
  • Each plugin will be checked out in your workspace

Manual check out

[PENDING]

Compilation Errors

According to your development environment, the checked out code might not compile out of the box ; this is expected. Indeed the Acceleo team does its best to ensure compatibility with all versions of Eclipse since 3.4, yet OCL (which we depend on) does not. The files contained in the package org.eclipse.acceleo.internal.compatibility.parser.ast.ocl.environment allow us to remain compatible through API breakages and thus cannot compile on certain versions. Namely, the class AcceleoEnvironmentGalileo only compiles when using Eclipse 3.5 and OCL 1.3 at least, and the class AcceleoUMLReflectionHelios only compiles when using Eclipse 3.6 and OCL 3.0 at least. In short, all of Acceleo compiles under Helios, one class doesn't under Galileo, and two classes don't compile under Ganymede.

These errors are well confined in this package and will not cause any runtime error for users.

Developping Acceleo patches or code

Checkstyle

The Acceleo team uses Checkstyle with its own set of rules in order to have an homogeneous code style throughout the plugins and features.

The Eclipse plugin for Checkstyle can be downloaded on sourceforge. Once installed, it will be automatically applied to all existing Acceleo plugins as they are already configured to use it. New projects can use the same set of rule :

  • Right-click on the project which has to be checked through Checkstyle and select "Properties".
  • In the "Checkstyle" category, go to the "Local Checkstyle configuration" tab
  • Hit "New" and select "project-relative configuration" from the "type" drop down menu. Set the name of this configuration as you see fit ("Acceleo" for example) and click the "Open..." button for the localisation.
  • Browse to "org.eclipse.acceleo-feature/codeStyle" and select AcceleoCheckstyleConfiguration.xml. Select "Ok" twice to end this wizard.
  • Go back to the "General" tab, then tick "Activate Checkstyle on this project"
  • In the drop-down below, select the configuration you just created, then click OK to close the properties dialog.
  • That's it : your project will now go through the Acceleo Chekstyle rules on each compilation.

Note that Checkstyle errors are not considered fatal compilation errors : you can still run code with checkstyle errors. Nearly each of Acceleo check is set to report an error though, as we always try and comply to these rules.

Code Formatting

At first, most of the checkstyle errors that will be reported will probably be formatting errors : you can configure your formatter to use the Acceleo configuration to avoid these.

  • Click on Window => Preferences
  • Browse to the "Java => Code Style => Formatter" category and click on the "Import" button
  • Browse to the "<workspace>/org.eclipse.acceleo-feature/codeStyle" directory and select "Acceleoformatter.xml"
  • hit Ok twice to close the preferences dialog

Your formatter will now comply to Acceleo code style. Hitting ctrl+shift+F in a java editor will format your class to follow this style.

Note that all Acceleo plugins are already configured to make use of this formatter

Java

Acceleo is built against Java 1.5 : usage of JDK 1.6 specific API will result in build errors and should be avoided.

Target Platform

We try our best to ensure downward compatibility towards Eclipse Ganymede, as such we use the following as our target platform :

Eclipse SDK 3.4.2

EMF SDK 2.4.2

The target platform can be set through the preference page accessible via Window => Preferences => Plug-in Development => Target Platform. More information on how to set a target platform for development can be found in the Eclipse help.

API Tooling

The Acceleo development team uses the target platform augmented with the latest stable Acceleo build to maintain API compatibility. Checks for API breakages and evolutions are set per project and committed alongside them. All of these settings are still soft and don't ensure full API compatibility for now, they will be changed for strict API maintenance as soon as Acceleo 3.0 is released.

Unit Tests

The Acceleo team maintains a comprehensive set of unit tests to ensure that nothing gets broken when new functionality or bug fixes are implemented. Tests are all using JUnit 3 and are not compatible with JUnit 4.

To launch the whole set of tests for Acceleo, launch the Test suite located in plugin org.eclipse.acceleo.tests : org.eclipse.acceleo.tests.suite.AllTests. It has to be run as a "JUnit Plug-in Test" and you have to uncheck "run in UI Thread" on the launch configuration tab.