[
https://jira.codehaus.org/browse/SUREFIRE-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287223#comment-287223
]
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 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
> Integrating Gosu (http://gosu-lang.org) tests into Surefire.
> ------------------------------------------------------------
>
> Key: SUREFIRE-815
> URL: https://jira.codehaus.org/browse/SUREFIRE-815
> 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:
>
> https://github.com/carsongross/maven-gosu-plugin/blob/master/src/main/java/org/gosu_lang/tools/maven/GosuArtifactMojo.java
> 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:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
