maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Rosenvold (JIRA)" <>
Subject [jira] (SUREFIRE-815) Integrating Gosu ( tests into Surefire.
Date Sun, 01 Jan 2012 21:56:02 GMT


Kristian Rosenvold commented on SUREFIRE-815:

I am not sure what the run-time requirements are for transforming a gosu source file into
one or more java .class files, it may be acceptable for you to have all these things added
to the project itself.
Normally we try to isolate stuff like this into the *plugin* classloader space but for more
interpreted languages I assume they equally well belong in the actual project runtime classloader,
which would probably mean all the bits & pieces necessary for compilation would be added
to the actual project's dependencies.

In such a case you might get away with just having the specialized scanner compile the source
files to class files on the fly. You may want to start off by just hard-coding a different
scanner at BaseProviderFactory#getDirectoryScanner

This would be a quick way to just determine a proof-of concept to see how feasible this is.

Once this works the patch would have to involve using the ProviderDetector (which is really
a "ServiceLocator") to look for alternate implementations of the DirectoryScanner and use
any configured alternatives. Once you have a hard-coded scanner working I might be able to
asssist some more with this last bit, since it's not entirly as straight forward as you might
think; there's forking logic involved and the service locator is currently being used on the
plugin side of the fork, whereas the BaseProviderFactory may be on the remote side of the

There's also all sorts of classloader pitfalls that might arise, but a simple proof of concept
will tell you a lot more about that

> Integrating Gosu ( tests into Surefire.
> ------------------------------------------------------------
>                 Key: SUREFIRE-815
>                 URL:
>             Project: Maven Surefire
>          Issue Type: New Feature
>          Components: Maven Surefire Plugin
>    Affects Versions: 2.11
>            Reporter: Carson Gross
> I would like to integrate Gosu-based tests into the Surefire plugin.  Gosu is a JVM-based
programming language.  It is compiled with a slightly different model than java: rather than
shipping class files, it ships source files and compiles them on-demand, more like scripting
languages such as JRuby.
> We are developing a maven plugin that wires in gosu support for maven here:
> As you can see, it adds POM dependencies to the core gosu jars, providing gosu support.
 I'd like to extend this plugin to direct surefire how to detect and run Gosu-based tests.
> Investigating the surefire plugin code, it looks like what I need to do is specify a
custom DirectoryScanner.  I have two questions on this (and I apologize, I am very new to
Maven, but could not find how to do this via the documentation):
> 1) Can I specify a custom scanner from the command line?  That would get me started writing
my scanner.
> 2) Is there an API in Maven for automatically setting properties (or does it use the
standard System properties API) such that I could pass this custom DirectoryScanner along
programmatically from our maven plugin?
> In a private email, Kristian mentioned the following issue:
> "There is one more hurdle you will need to solve, and that's how to add the Gosu stuff
to the classpath of the fork. I suppose you should add them as dependencies to the surefire-plugin,
but there is currently no automatic way to transfer these to the fork."
> I'm hoping that the fact that we add the dependencies to the parent POM solves this problem
(I assume that this is how other libraries are included in surefire tests) but I do not understand
the Maven dependencies and classloader setup well enough to know for sure.  I'll need to experiment.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message