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?

Comments are currently closed.