Archive Page 2

Build OSGi bundles with Ant+Ivy

As I said in my previous post,
the Bushel source code is now part of the Apache Ivy code base. The integration
task #IVY-1241 is
fully complete.

Now it’s possible to build OSGi bundles / eclipse plugins with Ant + Ivy. It
also supports provisionning from an OBR (OSGi Bundle Repository).

You can found more details in this documentation : http://ant.apache.org/ivy/history/trunk/osgi.html

Don’t hesitate to contact me for exchange any feedbacks.

Managing your OSGi dependencies with the power of Ivy

Since two years, Alex Radeski and me created a project on google code
[1] called Bushel [2]
[3
] . This project implements an OSGi manifest parser and an Ivy resolver
to manage OSGi dependencies with Apache Ivy.

Since, Nicolas Lavelée committer on Apache Ivy and the lead of Apache IvyDE
(Eclipse plugin for Ivy) joined us to contribute.

Now, Bushel implements some special Ivy resolver and version matching which
understand the different kind of OSGi dependency, and also understand the
repository descriptor OBR (OSGi Bundle Repository).

I’m pround to announce that our Bushel source code is promote as a part of
Apache Ivy core. [4]

Next step : Add the OSGi support on EasyAnt and EasyAnt For Eclipse
build system (based on Ivy stack) …

[1]
http://code.google.com/p/bushel/

[2]
http://ezaero.blogspot.com/2008/08/bushel-06-preview.html


[3
]
http://ezaero.blogspot.com/2008/08/build-osgi-apps-with-ant-made-easy-with.html

[4]
http://markmail.org/thread/fzdcu25qgk2svkro

Managing your OSGi dependencies with the power of Ivy

Since two years, Alex Radeski and me created a project on google code
[1] called Bushel [2]
[3
] . This project implements an OSGi manifest parser and an Ivy resolver
to manage OSGi dependencies with Apache Ivy.

Since, Nicolas Lavelée committer on Apache Ivy and the lead of Apache IvyDE
(Eclipse plugin for Ivy) joined us to contribute.

Now, Bushel implements some special Ivy resolver and version matching which
understand the different kind of OSGi dependency, and also understand the
repository descriptor OBR (OSGi Bundle Repository).

I’m pround to announce that our Bushel source code is promote as a part of
Apache Ivy core. [4]

Next step : Add the OSGi support on EasyAnt and EasyAnt For Eclipse
build system (based on Ivy stack) …

[1]
http://code.google.com/p/bushel/

[2]
http://ezaero.blogspot.com/2008/08/bushel-06-preview.html


[3
]
http://ezaero.blogspot.com/2008/08/build-osgi-apps-with-ant-made-easy-with.html

[4]
http://markmail.org/thread/fzdcu25qgk2svkro

Nicolas Lalevée joins the team

We’re glad to accept Nicolas Lalevée as a new commiter.

Nicolas has contributed a lot to Ant, Ivy and IvyDE. He’s currently one of the most active developer on IvyDE (this will really helpful for our eclipse integration easyant4e).
He has been actively involved in several discussions about Ant (extensionOf / enhancing projecthelper mechanism to support alternatives languages for ant scripts) and Ivy.

He highlighted a lots of good points to make EasyAnt much more extensible.

Welcome on board Nicolas 🙂

EasyAnt 0.8 released !

The EasyAnt project is pleased to announce its 0.8 version.

Easyant is a build system, that is based on Apache Ant and Apache Ivy.

Our goals are :

  • to leverage popularity and flexibility of Ant.
  • to integrate Apache Ivy, such that the build system combines a ready-to-use dependency manager.
  • to simplify standard build types, such as building web applications, JARs etc, by providing ready to use builds.
  • to provide conventions and guidelines.
  • to make plugging-in of fresh functionalities easy as writing simple Ant scripts as Easyant plugins.

To still remain adaptable,

  • Though Easyant comes with a lot of conventions, we never lock you in.
  • Easyant allows you to easily extend existing modules or create and use your own modules.
  • Easyant makes migration from Ant very simple. Your legacy Ant scripts could still be leveraged with Easyant.

Changelog 0.8 :

Core:

  • Feature #132: Switch to Ivy 2.2.0-rc1
  • Feature #117: Switch to ant 1.8.1
  • Feature #136: Introduce bindtarget task
    This tasks allow to change the mapping between target and phases.
  • Feature #137: Introduce findclasspath task
    This task is designed to locate the right version of a SDK (for groovy / scala, but maybe for others SDK like android etc…).
  • Feature #138: Introduce registerartifact task
    This task is in charge to register a given artifact to ivy context.
    In other words, this task is responsible of generating the right elements in the publicated module.ivy file.
  • Feature #70: Introduce a menu generator task
    This task is used by documentation plugins (like xooki) to generate menu entries
  • Feature #116: Introduce CheckResolver task to enforce plugin stability
  • Feature #124: Introduce a ant task to run an easyant build process
  • Feature #100: support for extends=info in ivy module parser
  • Feature #101: publish merged version of Ivy descriptor when using module inheritence (<extend> tag in a module.ivy file)
  • Feature #119: EasyAnt’s launch scripts now support alternative ant distribution
  • Feature #122: Simplify usage of project ivy settings (if exists use ivysettings.xml at the root level of the project)
  • Many bug fixes on core and documentation (plugin documentation now contains examples)
  • Simplify the build process of easyant core itself

Plugins :

  • Feature #94: Introduce package-test-jar plugin
  • Feature #113: Introduce maven-publication plugin
  • Feature #127: Introduce distribution plugin
  • Feature #115: Add support for integration tests
  • Feature #123: Support filterset in resources-std plugin
  • Feature #98: Support for pre-module-phases in multi module
  • Feature #128: Add a new target on skeleton plugin to choose a skeleton from a list
  • Feature #111: implement xooki menugenerator
  • Feature #92: eadoc plugin should use ant uptodate check to improve performance
  • Feature #93: add resource collection support to junit plugin
  • Feature #109: Homogenize properties referencing the main class
  • Several bugfixes on
    • skeleton
    • mannifest
    • antunit
    • ivy-provisionning

You can have further details on EasyAnt 0.8 in the release notes.

Retrieve sources from the 0.8 release files at: http://svn.easyant.org/tags/0.8/
Or download the 0.8 release files at: http://incubator.apache.org/easyant/download.cgi

More information can be found on the Easyant website: http://www.easyant.org/

Integration test

Integration test

Integration test will be supported in next release (0.8 targeted for beginning of may).

Since the beginning of the project, easyant was already designed to have a dedicated phase to run integration test.
Until now, no plugin was contributing to this phase. This will change in next release, were the following plugins will be provide ready to use targets to run integration-test :
* junit plugin
* testng plugin
* antunit plugin

 

What are the differences between UnitTest and IntegrationTest ?

Usually people think that if they use Junit they do Unit Tests, but in reality the difference if more subtile. Let’s see in details the main differences.

UnitTests

In theory, UnitTest are supposed to test the method content but not a whole choreography. It should be a stand-alone test which is not related to other resources.
Example: If you’re writing unit test on your service layer, you’re service is probably calling classes from the data access layer. So the UnitTest should test only the service method and not the sub calls done by data access layer.

UnitTests are supposed to check internal workings of a class by testing portions of code (“units”). It specify and test one point of the contract of single method of a class. This should have a very narrow and well defined scope. Complex dependencies and interactions to the outside world are stubbed or mocked.
In the previous example we should “mock” the call to the data access layer.

The objective is simple, we want to be sure that :

  • the method (excluding all sub calls) do what it is supposed to do
  • evaluate the code coverage
  • have a robust code
  • unit test will run fast (a few seconds)

Usually tests are done by developers to enforce their code base.

IntegrationTest

In opposite, IntegrationTests are designed to check inter-operation of multiple subsystems (multiple units).
There is whole spectrum there, from testing integration between two classes, to testing integration with the production environment.
Integration test can :

  • validate that all pieces of code developed individually works together.
  • test the whole choreography of a given use case (business choreography, everything from the UI to the DB, inter-operation between applications, etc…)
  • validate the application as a functional point of view (usually called Acceptance Test) before a release
  • run UI tests (done by tools like selenium, sahi, etc…)

Comparing to UnitTests, IntegrationTest can be longer. Usually we should run integration-test on nightly builds or at least before each release.

How to manage this with easyant ?

EasyAnt will provide ready to use targets configured over conventions to handle separately UnitTests and IntegrationTests.
Here again even if we provides conventions, we never lock you in, so you can adapt this to your needs.

By convention :

  • UnitTest are stored in the src/test directory
  • IntegrationTest are stored in the src/integration test directory.

UnitTest

The directory structure of Unit Tests looks like this :

  • src/test/java : for test source code (note that this can be configured through the property src.test.java)
  • src/test/resources : for test resource files (note that this can be configured through the property src.test.resources)

Note: this also apply with non-java project (like groovy / scala project).
Groovy project :

  • src/test/groovy for test source code (note that this can be configured through the property src.test.groovy)

Scala project :

  • src/test/scala for test source code (note that this can be configured through the property src.test.scala)

Antunit :

  • src/test/antunit for antunit test (note that this can be configured through the property src.test.antunit)

IntegrationTest

The directory structure for integration test looks like this:

  • src/integration-test/java for integration test source code (note that this can be configured through the property src.test.integration.java)
  • src/integration-test/resources for integrationtest resource files (note that this can be configured through the property src.test.integration resources)

Note: this also apply with non-java project (like groovy / scala project).
Groovy project :

  • src/integration-test/groovy for integration test source code (note that this can be configured through the property src.test.integration.groovy)

Scala project :

  • src/integration-test/scala for integration test source code (note that this can be configured through the property src.test.integration.scala)

Antunit :

  • src/integration-test/antunit for antunit integration test (note that this can be configured through the property src.test.integration antunit)

Others :
You can also write your own plugin by following this guide.
Your plugin should provide a target bound to integration-test. This plugin will run test-scenario’s stored in your phase to run scenario stored in src/integration-test

Example: if you want to write your own selenium plugin you could run the scenario stored in src/integration-test/selenium

findclasspath we loves you !

In the next release we’re planning to introduce a new task named <findclasspath> that will help a lot plugin writers to locate some external ressources (like a SDK).

This task is designed to locate the right version of a SDK (for groovy / scala, but maybe for others SDK like android etc…).

Let’s see in details how we can use it

The <findclasspath> task is designed to locate the right version of a SDK (for groovy / scala, but maybe for others SDK like android etc…) based on the pattern chain of responsability.

Really basic sample :

1 <ea:findclasspath org="org.codehaus.groovy" module="groovy-all" revision="1.0"/> 

 

By default if you do not specify anything inside the findclasspath task, easyant will use the default strategies :

  • ProjectDependenciesStrategy : will check if the specified dependency is contained as a project dependencies. If there is no exact match it will give a try based on organisation name. If found easyant will use the specified version in the project dependencies.
  • BasicConfiguration : will use the specified dependency (declared in <findclasspath>)

Using additional strategy

You can define (or override) the default behavior and plug your own strategy.
By default, EasyAnt came with an additional strategy : environment strategy.

This strategy can be referenced as a nested element of <findclasspath>.
If you choose to use additionnal strategy you need to define the whole chain (ordered). This allow you to interfer with the two default strategies

Say for example you want to :

  • check project dependencies
  • if not found check environment variables
  • if not found use the specified version in findclasspath argument

The task will looks like this :

1 <ea:findclasspath org="org.codehaus.groovy" module="groovy-all" revision="1.0"> 2 <project-dependency-strategy/> 3 <environment-strategy env="GROOVY_HOME"/> 4 <basic-configuration-strategy/> 5 </ea:findclasspath> 

 

Writting your own

To write your own strategy you just need to write a java class extending org.apache.easyant.tasks.findclasspath.AbstractFindClassPathStrategy.

This class will force you to implement abstract methods

1 public class MyOwnStrategy extends AbstractFindClassPathStrategy{ 2 protected boolean doCheck() { 3 //do your job 4 //the doCheck method should return true if the strategy was able to build the classpath 5 } 6 } 7 

 

As every ant tasks this class should be configured through a taskdef and be in the plugin’s classpath.

Then you need to define the whole chain (ordered). This allow you to interfer with the two default strategies and to plug your own in the right place.

So you could do the following in your plugin :

1 <ea:findclasspath org="org.codehaus.groovy" module="groovy-all" revision="1.0"> 2 <project-dependency-strategy/> 3 <mystrategy/> 4 <basic-configuration-strategy/> 5 </ea:findclasspath> 

 

As a functionnal point of view it will:

  1. check if the specified sdk (org.codehaus.groovy#groovy-all) is in project dependencies
  2. if not found it will use your own strategy
  3. if still not found it will run the basic strategy and download the sdk specified as paramters (org.codehaus.groovy#groovy-all;1.0)

By discussing with friends, i was thinking of having an optional FileSystemStategy.
The idea would be to handle OS specific installations like :

 1 <ea:findclasspath org="org.codehaus.groovy" module="groovy-all" revision="1.0">  2 <projectDependenciesStrategy/>  3 <environnementStrategy env="GROOVY_HOME"/>  4 <!-- if your os is windows find the groovy-all jar in c:\Program Files\groovy -->  5 <filesystemStategy os="windows" path="c:\Program Files\Groovy"/>  6 <!-- if your os is linux find the groovy-all jar in c:\Program Files\groovy -->  7 <filesystemStategy os="linux" path="/usr/lib/groovy/"/>  8 <filesystemStategy os="mac" path="/usr/lib/groovy/"/>  9 <pluginConfigurationStrategy/> 10 </ea:findclasspath> 

 

OS attribute could use kind of regexp and maybe handle more precisly the target os (Windows ? Windows XP? Windows Vista ? Linux ? Ubuntu ?)
Is there any way to handle as a lower level the target os (debian ? ubuntu ? mac OS 10 ? )

What do yo think about this optionnal strategy ?
Should we provide it as an option and let plugins writer configure it to their needs?