I code so I don't have to ...

#shlcon2010 - Arquitecturas que crecen y arquitecturas que no

2010-12-07T01:46:00.001-08:00

Me dió un enorme gusto dar esta plática, ya que es la primera vez que expongo ideas que llevan más de un año gestándose en mi mente. En particular:

Las analogías entre el desarrollo y crecimiento de organismos vivos con las condiciones que propician o inhiben el crecimiento de un sistema de software.
La relevancia de las ideas que Steele expuso en 1997 en su keynote "Growing a Language" al aplicarlas en el contexto de la arquitectura de sistemas.
La relevancia que tienen en el contexto de desarrollo de software las 15 propiedades que Christopher Alexander destiló e identificó como intrínsecas en los sistemas vivos (en un sentido muy amplio de la palabra).

Estas ideas pueden ser discutibles y finalmente erróneas, pero personalmente me han servido de diferentes maneras:

A entender de fondo los procesos y eventos que permiten a un sistema de software crecer adecuadamente.
A mejorar mis diseños, refinando el arte de no diseñar.
A diseñar explícitamente la manera en que un sistema puede y debe crecer. Entendemos que no es conveniente diseñar demasiado desde un inicio, sin embargo SÍ debemos ser explícitos en las maneras en que un sistema y su diseño puede crecer o de lo contrario el caos reinará. Debemos poner siempre atención en diseñar patrones de crecimiento.
A entender que el lugar 'natural' del software no es un repositorio, mucho menos el ambiente de desarrollo de un programador o el entorno creado por todo un equipo de desarrolladores. Aunque todos estos elementos son importantes, el lugar natural del software es en gran medida su entorno de operación, es decir, cuando se encuentra en interacción directa con el complejo entorno social, económico y tecnológico que lo rodea, lo define y al cual, en el mejor de los casos, se integra de manera 'vital', catalizando otros procesos y fenómenos, habilitando la transformación y evolución del entorno en sí, de tal manera que el software es un órgano funcional y vivo dentro de un sistema más grande y complejo. Cuando esto sucede, se da una co-evolución de software-entorno. Cuando el software es exitoso, esta co-evolución se puede presentar de manera muy acelerada.
A razonar el concepto de robustez... y entender la gran ausencia de esta propiedad en los sistemas que desarrollamos de acuerdo a las prácticas más usadas hoy en día.
A identificar intuitivamente los llamados "atributos de calidad" con propiedades estéticas... Solo algunos atributos de calidad por su puesto, y la interpretación puede ser muy cuestionable.

En fin, muy grato compartir algo de esto con los asistentes al #shlcon de hace ... ¡¡¡2 semanas!!!

¡Qué rápido pasa el tiempo! =)

Arquitecturas que crecen y arquitecturas que no

View more presentations from Agustín Ramos.

Spring IO 2010

2010-06-22T22:34:00.000-07:00

I'd rather not talk about it, except for two things:

We have a long way to go.
I'm available for giving FREE workshops at your university.

Here are the slides of the 2 talks I gave last Saturday.

Desarrollo Dirigido por Comportamiento (con Cucumber y Groovy)

View more presentations from Agustín Ramos.

Hola OSGi

View more presentations from Agustín Ramos.

Software Craftsmanship, why it matters?

2010-05-18T12:36:00.000-07:00

While reading Donald Norman's "The design of everyday things" unexpectedly I found a most useful idea for explaining the relevance of the Software Craftsmanship movement (strikethrough is mine):

"Without a good model theory we operate by rote, blindly; we do operations as we were told to do them; we can't fully appreciate why, what effects to expect, or what to do if things go wrong. As long as things work properly, we can manage. When things go wrong, however, or when we come up with a novel situation, then we need a deeper understanding, a good model theory"

That's it. I've seen so many software developers that are clueless when given a new project, team, environment, technology, etc. They have no idea what direction to follow when one is not given to them, or how to improve their careers and skills. In short: They don't have a good theory of what software development is all about.

I think Software Craftsmanship is an attempt to create a good theory of what sound software development is all about. Now we know our craft, and we must tell everybody who doesn't.

GULEV 2010 - Wrap up

2010-04-29T23:35:00.000-07:00

I really enjoyed participating in GULEV 2010.

Although I had expected it to be a far greater event, It was a friendly and smooth place to meet some interesting people.

In particular I had the chance to talk a while with some true great open source developers like Federico Mena (GNOME co-founder, now with Novell) and Alexandro Colorado (OpenOffice.org). I also had the chance to meet the guys behind springhispano.org and javamexico.org. All of them are nice and interesting guys, everyone in his own way.

Miguel Angel, the founder and organizer of this conference (which will celebrate it's 10th aniversary next year, prepare yourself for the party!), is a most gentle and passionate guy. He explained me all the struggle he had to go in order to keep the conference going on, because last year the AH1N1 virus and global economic factors forced him and his kind wife to cancel the conference. Fortunately this year was different and although small, the conference was very successful and it got many new friends (me included).

The most interesting chat (and dinner) was with Alexandro, who through his opinions and recaps on some software history reminded me of the years when I was fully committed to promoting open source software, but most importantly, that open source is not much about convenience as it is about an idea: freedom. And freedom my friends, is undervalued nowadays.

I also spent some time with my colleague and neighbor Chris, his wife and their newborn baby Natalia. They are such a trio! Congrats for being such good parents!

I want to share with you the slides I used in my talks.

The last one (BDD) was somehow improvised. It's a trimmed down version of a talk Chris and me gave a few days ago at Certum. Miguel made room for some unscheduled talks, and lately we've been having so much fun developing tests with cucumber and friends. So it seemed the perfect moment to introduce some real polyglot programming in the JVM applied to solve the annoyances of Test Driven Development, although the real stars here are not so much the tools as the method.

That's all for today.
Take care.

Modularización efectiva - domando a la hidra

La nueva imagen del gurú - El maestro artesano dentro del ingeniero

BDD - Desarrollo dirigido por comportamiento

Source code evolution visualization: the moving picture metaphor

2010-02-07T06:24:00.000-08:00

Just to share with you a visualization from the development history of my relatively recent OSGi based project at Certum.

It's not Star Wars! I'd rather call it "Code Wars" =)

It was created with Andrew Caudwell's gource and it's based on our project's 2nd repository (we moved from CVS without preserving full history), but you can quickly get a feeling of these points:

Developer participation was very intermittent (due to customer and management decisions).
We lacked (and it was impossible to set) a clear responsibility demarcation for each developer and module (a developer should touch only upon a restricted set of modules).
Developers had very different involvement and working patterns.

I think the most important thing about gource is that it enables and gives inspiration for a whole new family of software archeology tools and practices, with far reaching implications for software maintenance. Imagine this:

Having a control panel for the replay of this kind of visualizations, with 1) filters for developers, modules and time frame. And 2) controls for playback, zooming and panning at will.
Being able to specify mapping rules from physical files to design modules (which could be much more useful) and with the option to choose between both.
Integrating this view with your project dashboards (e.g. JIRA)

You could use this setup to:

Quickly get an objective idea of the source code evolution, in terms of work done.
If you are new to the project, get a feeling of the most recent project dynamics.
Identify time frames which produced the most unstable modules, and try to correlate this with the project's context and practices at the time.
Correlate with other charts and visualizations.
Identify project landmarks, and attach metadata and links to other sources providing more information of the events.

In a sense, this kind of view is an implementation of "The Moving Picture Metaphor" as exposed by Mark Mahoney last OOPSLA conference. It's not an implementation of the whole metaphor, but It's a feasible one and it's certainly a great start.

A complementary view to the one provided by gource is that of the source code metrics evolution, for example, as given by the Motion Chart plugin for Sonar. I've found it really useful.

You may think software archaeology is a useless subject which people like me do just for fun. If you are that kind of guy, let me tell you this, loud and clear: people who don't know and understand the past are condemned to repeat the same mistakes over and over again.

If you are interested in the high definition video, let me know =)

Mining your source code repository - Part 1

2010-01-08T12:08:00.000-08:00

A new coincidence made me throw myself into another adventure: mining my dear old CVS repository.

Why would you do that? From trivial to more advanced:

Detect stagnant and dead applications and modules.
Know your team commit habits.
Know "who is who" among your team.
Detect sources of instability within projects.
Detect unrecognized software assets.
Test hypothesis about the impact of certain practices and developmnent models.

In other words, you could make your repository talk to you: If you have built history, it certainly has a story to tell =)

The commit history view

There are a lot of views of a source code repository, so I decided to start with something very basic: the commit history, and now I'll tell you how you can do the same.

1. Decide which modules are of your interest and do a clean checkout.

Once you've decided on your modules, you may do a batch checkout like this (bash):

for m in module1 module2 module3 moduleN; do 
  cvs co $m; 
done

2. Extract your change log

First, you need to install cvs2cl, a perl script which "does what you think it does: it produces a GNU-style ChangeLog for CVS-controlled source". Once in place, you should be able to execute this:

for d in `ls`; do 
  cd $d && echo -ne "Procesing $d ... " ;
  cvs2cl.pl --revisions > /dev/null 2>&1 ; 
  if [[ -f ChangeLog ]]; then  
    awk  '/^[0-9]{4}.*/ {print $0}' ChangeLog | uniq > ChangeLog.tstamps && echo "DONE" ; 
  else 
    echo "WARNING" ; 
  fi;
  cd - ;
done

This will produce 2 files for each project: your normal ChangeLog file and a second derived ChangeLog.tsamps with, well, the timestamp of every commit, besides the author of it.

The if is necessary because it may be the case that some revision history files are corrupted, and by default, cvs2cl fails whenever a file causes problems. Nevertheless you can create a somewhat stripped down version of your ChangeLog by skipping that file, but that needs to be on a per case basis.

You could further improve the awk part by, for example, extracting the commit comments (mostly useful if you have a commit comment template and the corresponding server side verification which, for example, distinguish between features and bug-fixes), including the list of files modified by each commit, the total number of lines modified, or calculating some other derived data. That's up to how you canalize Ch'i through scripting in the language dearest to your heart.

3. Summarize your data.

I find more useful to have a single data file for further analysis, so I aggregate all my single .tstamp files and take the opportunity to switch to .csv format

for d in `ls`; do 
  cd $d && echo "Processing $d ... " ; 
  awk -v project=$d '{ printf "%s,%s,%s,%s\n",project,$1,$2,$3 }' ChangeLog.tstamps | sort -n -r >> ../cvs-activity-all.csv ;
  cd - ; 
done

4. Leverage your spreadsheet software.

A pivot table is the most strightforward way to do some exploratory data analyisis. You can, for example, create some views for answering questions like:

- What's the commit density history (for example, by month or quarter of the year) of every project?
- Who are the top committers for this project?

The following table is a color coded view for answering the former question on some sample projects, grouping commits by quarter

Gaining knowledge

Knowledge only comes after reflection and further inquiry on your data. I found, for example, a very explicit causality relationship between the waterfall development followed by several projects (don't blame me yet!) and a fast growing commit density function approaching a peek just before the release date, followed by a long tail of, mostly, bug fixes. Those are clearly not great examples of sound software development, everyoune could tell, but I have data to prove it.

Final remarks

The approach presented here for commit history extraction is limited in the sense that it ignores files which are present in branches other than HEAD and haven't been merged yet.
If your interesting history is in a subversion repository, you can leverage the svn log command and svn2cl.

Further knowledge extraction will be the subject of a second part in this series. Im expecting to apply some machine learning techniques, particularly unsupervised learning ones to make sense of the data. Time to clear the dust from my ML training! =)

OOPSLA Day 1: Modularization

2009-10-27T10:14:00.000-07:00

It´s an open problem. That's all.

No wait, there´s a lot of work in progress, but at the end, as Aslam Khan wisely said at the afternoon panel backed by a very nice picture: "I feel like a kid".

Why? The benefits of modularization are well understood. At least of modularization as a very general concept. But what techniques, language features or practices are the best for imposing modularity to existing and new systems? No one knows for sure.

A tale of 3 language designers and one architect

First, the panel brought together 3 language designers and a software architect (Aslam). He talked quickly about early indicators of relatively good modularization principles in an existing codebase:

Test cases: If there are enough of them, and they work, it means that your code base implements some design principles which allow to implement fixtures and mocks. Hence, it may be the case that your code is modularized.
Pointcuts: Throwing pointcuts to an existing codebase and measuring how many hits they have is also an indicator of the homogeneity of the code base.

For new systems, he suggested:

Using a domain language throughout your project communication. This enables the natural identification of modules.
Using a domain specific language for system implementation. The next logical step.

So he's a Domain Driven Design (DDD) advocate, which got confirmed when we had a chat after the panel and I asked about the best modularization techniques and strategies he has found in the field. I don't know the relationship between DDD and modularization, so he suggested me to read the 2nd part of Evan's book. =$

The language guys presented some AOP like stuff and took a position of 'language gene designers', but, why do you design a 'language gene' in the first place? Isn't it for building real software? I was amazed of the ignorance of these researches about the current practice of programming regarding the effects of language features in the current software industry, which has vast amounts of data to grasp what is really needed.

Fortunately it turned out that these language designers were just guests at the workshop and they ran as soon as the panel ended, which leaved room to real talks about modularity.

JDK modularizations says "I'm here! talk to me!"

At the corridor, there was this guy from Sun who showed some graphviz pics representing modularization efforts on the jdk (perhaps he's from jigsaw), and remarked that all was OK when managing modularity at the source code level, but at runtime you still have spaghetti. Then Aslam and the language guys made the observation that besides phenomenology and an impressive picture, what's the point of modularization at runtime within the jdk? No real answer.

OSGi deemed not ready/suitable for enterprise development

At some point in that chat someone mentioned OSGi because he thought that I was talking about it when said something about my "embed-script-engine-add-spring-and-be-god" technique (which allows me to add/remove aspects at runtime ) and the sun guy got an upset face. "OSGi breaks Hibernate, not the other way around"was heard regarding it's class loader model. Nobody seemed to support OSGi as a modularization technology ready for real world app development. Ouch!

A nice talk and wrap-up

Then a few short presentations came, most of the things presented spinned around Aspects, until the agenda was fulfilled and a very interesting 1 hour chat took place. Topics we talked about:

The organizational and social aspects of development and how it impacts modularity.
Modularization evidence left behind by development patterns: branches in repository, average of affected artifacts by bug fix or requirement, etc.
The problem of making the business case for a refactoring towards better modularity, in the face of not having proper and convincing metrics to support it.
The convenience and inconvenience of current metrics relating to modularization.
The current practice of AOP, when some people introduce bugs for not being aware that an aspect or aspects existed, or when people use them like a commodity but they don't understand/manage them.
The nature of dependencies. Yo can't avoid them, but you can manage them.

A nice talk overall.

Modularization is necessary, and it is a very complex problem.

We are beginning to understand it at large scale.

OOPSLA Day 1: Architecture meets testing

2009-10-27T07:52:00.000-07:00

As an architect, do you...

involve yourself in the tasks of

Devising a testing strategy?
Helping test managers build a test architecture?
Promoting test design methods?

consider testability as a quality attribute to be addressed just as you do with any other?
really practice test driven design (i. e. starting from the definition of the architecture)?
care about the effectiveness and efficiency of the team who is gonna test your stuff?

As far as I see, it´s unlikely that you answer "yes" to most of the questions above. But you should.
Why? Because your architecture is not something that abstract as the maya in hinduism. It's the very foundation on which working software will be built. So your responsibility is not just delivering an architecture (not to say a Power Point), but a strategy for building working software based on that architecture.

Peter Zimmerer's tutorial gave me great insight. Lately I've discussed some ideas about testing strategies and testability with my team's new test manager, and raised questions such as:

How do I design my systems and programs in order to be more testable?
How should the testing teams apply their effort in the most valuable way?

Besides this we started using sonar as a code quality management all-in-one-place tool. But Peter's talk just revealed that I had still a lot of work to do. Some of the lessons are:

Devise a risk based testing strategy.
Metrics about bugs, coverage and testing progress should be your drivers for test exit criteria.
Coverage has very different meanings: risks, quality attributes, features, requirements, use cases, user profiles, operations, data, platforms, etc.
Practice architecture testing. Don´t wait for functionality to be built.
If you practice TDD, there´s no reason for not doing it from the very beginning: architecture.
Integration testing != integration.
Integration testing usually takes most of testing effort.
Design for testability. Testability = f ( Observability, Controllability, Modularity, ... )
Internal code quality affects directly external system quality.

This one last point may be better represented with a very recent story.

As I've said, I dropped a sonar instance a few weeks ago, and the very first project which got analyzed had respectable quality metrics (it's OSGi based and highly modularized), except for the web module. Then integration of the app began, and the oldest code in the web module (no need to say that the project had been asleep for a while due to organization priority changes) started giving problems: ugly code, specifically in 2 classes.

Then testing began, and although I had to stop making commits to the project, I saw that these 2 classes continued to give trouble to the rest of the team. I jumped to the sonar board and guess what I found: those 2 classes where the ones with the most violations and the worst metrics. They urgently need a refactoring.

So, this is not talking. Code quality metrics matter for very different purposes.

If you are not that bored enough by now, you may check out this tool: Testability Explorer. It calculates a metric about the suitability of your code for unit testing. How it does what it does? According to the project site, it computes

Non-Mockable Total Recursive Cyclomatic Complexity (What?!!! Fortunaley there's an explanation for it).
Global mutable state.
Law of Demeter violations.

I have found it very useful. Although I've had not time to delve into the relation of the above metrics to compute the final result or integrate the analyzer as part of sonar (a must!)

Next post will be about the workshop on assessment of contemporary modularization techniques =)

SG09 slides - OSGi as a foundation for platform and product lines development

2009-09-30T15:40:00.000-07:00

Just to let you know I've uploaded the slides used at the Software Guru talk last Monday.

En español :)

http://bit.ly/SG09-OSGi

Upcoming events 2009

2009-09-26T15:48:00.000-07:00

Well, I'm pretty excited about the upcoming events.

First of all, I'm giving a talk next Monday at Software Guru 2009 about OSGi as technological foundation for developing software platforms and product lines, based on our own experience at certum.

Besides this, I'm going to OOPSLA 2009 (Orlando) and QCon 2009 (San Francisco) for the very first time =). Here is a draft of my OOPSLA schedule.

I'm specially interested in modularity, architecture and testing. So I've already signed for the following tutorials:

All of them are well known and respected professionals, but best of all is that I'll have the chance to meet and listen to great people like 2008 Turing Award Recipient: Barbara Liskov, C++ Father: Bjarne Stroustrup and the like

If that's not enough, OOPSLA is colocated with Onward! conference.

So, I'll be very busy =), not to mention that I'm enrolled in a rock climbing course with sights on climbing at Potrero Chico on December and I'm having trouble imaging a compelling development strategy for a SOA/JEE project which just got approved.

What's the trouble with this project? Let me explain: we estimated almost 60,000 development hours and must be delivered within 8 months (I've never worked on something like this from scratch). Best of all, for security reasons, we weren't given specs to make our estimate, just many clues about size and complexity and a list of deliverables. If I were a believer, I'd be praying for the specs not to come and make me regret not adding other 60k hours to cover my 'risk factor'.

I'm very far from being a JEE fan, but this will really be a challenge for me. Why? Three reasons: size, complexity and people.

So, don't be surprised if I start posting about JEE and development methodologies in the months to come.

The one sure thing I can say for now is: test your ejb's using OpenEjb and nothing else out there!

Advancing OSGi tools, enterprise features and real world experience

2009-08-16T19:45:00.000-07:00

I recently stumbled upon Craig Wall's (of "Spring in Action" and, lately, "Modular Java" fame) blog. I highly recommend his recipes for OSGi related stuff, particularly:

Integration testing of OSGi bundles with PAX Exam and Spring-DM support.

Testing is important, so both options are welcomed. Nonetheless, I find PAX Exam more flexible and powerful. I prepared a feature matrix for you:

Feature		PAX Exam	Spring DM
Provisioning	Maven	Yes	Yes
	HTTP	Yes	No
	File	Yes	No
Test Service Injection		No	Yes
Different Runtime Support	Different Types	Yes	Yes
Different Runtime Support	Different Versions	Yes	No
Multiple Runtimes/same test		Yes	No
Profiles Support		Yes	No
Junit 3		No	Yes
Juni 4		Yes	No
TestNG		Yes	No

One great feature of PAX Exam is that of running the same test against a bunch of different OSGi runtimes. If you are a OSGi component developer, you probably want to be sure your bundles run on every possible platform.

Two in a row: PAX Runner profiles and Distributed OSGi.

You don´t have to wait for the final release of R4.2 to be ready, neither your favorite OSGi distribution to implement it in order to use some nice Enterprise OSGi features.

Living in a service oriented world, I´m interested in Distributed OSGi and the reference implementation is already here from Apache CFX. With PAX Runner profiles it´s easier than ever to test drive this Enterprise OSGi goodie. Before this, I had to rely on traditional spring remoting support.

More to come

My current team developed an OSGi based transactional platform (I'll give a talk about it at SG'09), my favorite IDE is OSGi based and I have an OSGi enabled phone (more about this on a later post). The question is: Do OSGi really pays off ?

Well, I know it can. But when introducing yourself to the world of OSGi based apps, it´s not absolutely clear how to avoid getting into more trouble than you probably deserve.

Today you can get 1 published book in german, 3 in english and there are at least two more on the way (early access program), but there´s no much real world experience published on developing large scale OSGi based enterprise applications. We need to fix this ;-)

This year I won´t make it into the 3rd Workshop on Assessment of Contemporary Modularization Techniques. Nevertheless keep an eye on it. I'm sure great insight will come.

Persistent Buiness Rules as Groovy Closures

2009-08-10T16:13:00.000-07:00

I think groovy closures are an excellent choice for implementing and executing business rules, having them persistent on a database. What's the big deal of having business rule code on a database?

- It makes the business rules implementations more managable.
- You adhere to the "Don't Repeat Yourself" principle (DRY)
- A change in a rule can be immediately consumed by all the applications.
- All of the above implies that your applications are less error prone.

How?

Every business rule can be expressed as a formula, and some business rules are composites, which can be expresssed as composite formulas. In turn, each formula can be expressed as a groovy closure, and you can have composite groovy closures too. Finally, yo can easily store your closures as strings and evaluate them at runtime: groovy magic ! =)

Example

Suppose we have a rule which sums the result of making some calculation on 2 properties (a and b) of every element in a collection, then applies a factor an returns the result. In groovy we can express this rule as the following closure:


// Rule A
{ v, rule, factor -> def total = 0; v.each { total += rule( it.a, it.b ) } ; total*factor }

Now, one variant of the nested rule (closure), which takes any two parameters, could be something like:


// Rule B
{ x, y -> Math.sqrt( x.power(y) ) }

Both rules can be stored as strings in a database, then you retrieve, assemble and execute them this way:


def ruleACode = ruleDAO.findRule('RULE_A')
def ruleA = Eval.me(ruleACode)

def ruleBCode = ruleDAO.findRule('RULE_B')
def ruleB = Eval.me(ruleBCode)

def entities =
[ new MyBean(a:5, b:2), new MyBean(a:2, b:4) ]

assert ruleA(entities, ruleB, 0.5) == 4.5

In the code above, first I get the string representation of both rules and convert them to individual closures, which is achieved with Eval.me(). Eval is a convenience class designed to easily execute groovy scripts from plain old java code. I recommend reading the javadoc.

The list 'entities' can be replaced with any collection of objects with properties of name 'a and 'b'.

Finally I just call the closure (which implements Rule A) passing the list, the second closure (which implements Rule B) and the factor as parameters.

Discussion

You may argue that you can achieve business rules implementation management through proper component design, modularization and management. And, although I think it's the only way to go on some scenarios, I see various inconveniences in it when compared with the groovy+closure approach:

Code Bloating
Did you notice how easy is to compose and execute closures? This is because a closure resembles a function, which is a vastly simpler concept than a class. Implementing rules with classes packaged in different jars can easily lead you to piles of complex boilerplate code to maintain and tons of related build and dependency management scripts and configuration files.

Incompatible components
One drawback of highly modularized systems, where each module can have a life cycle of it's own, is how easy is to get into component impedance headaches (I believe most of you know what I am talking about)

Separation of rule definition and implementation
If you separate them, you need extra work (code, process, practice, people) to get them in sync.

This may seem like nothing new if you have played with the Java Compiler API (part of SE 1.6), but having groovy at hand enhances the whole approach.

Final Thoughts

You don't even need your whole team to learn groovy stuff. Here you have the execution of the same rules from pure Java code:


public void testComposedRules() throws Exception {

String ruleACode = ruleDAO.findRule("RULE_A");
Closure ruleA = (Closure) Eval.me(ruleACode);

String ruleBCode = ruleDAO.findRule("RULE_B");
Closure ruleB = (Closure) Eval.me(ruleBCode) ;

  List entities = new ArrayList() {{
    add( new MyBean() {{ setA(5); setB(2); }} );
    add( new MyBean() {{ setA(2); setB(4); }} );
  }};

  assertEquals(
    ruleA.call( new Object[] {entities, ruleB, 0.5 }), 4.5 );
}

You just need the groovy jar. Your class dependencies will limit to the Eval and Closure classes.

Let me know how it works for you! =)