Details
-
Type:
New Feature
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 2.11
-
Fix Version/s: None
-
Component/s: Maven Surefire Plugin
-
Labels:None
-
Complexity:Intermediate
-
Number of attachments :
Description
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.
Activity
OK, sounds good. I can certainly hack something together quickly for you to look at.
Basically what I need to do is extend the scanner to include ".gs" files that match the given conditions and, before we load the classes, call "Gosu.init()" and ensure that when we are loading classes we use the gosu classloader, which does the on-the-fly compilation of Gosu classes. Classloader issues indeed. 
Thanks for your help.
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 fork.
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