Remove Groovy support?
arjantijms opened this issue · 21 comments
This project has added a quite a bit of complexity in order to support Groovy for test files.
I wonder, is this really worth it? Maybe I'm missing something, but I see only 3 .groovy files being used in the entire project.
Besides the complexity vs usage, is it really a good idea to have tests in totally different formats? I would argue it's better for consistency to have all tests in the same format using the same testing system and same language.
The idea was to use Spock for testing, but it is apparently not gaining any attention.
I don't really feel like it is bringing that much of complexity, but on the other hand having multiple test frameworks won't really help to have consistency, if that's our goal...
I don't really feel like it is bringing that much of complexity
For pure Maven command line usage, it's perhaps just a bit. The pom.xml is already big and complex and groovy support adds just that extra bit.
But for Eclipse users it really is more than a bit. Installing the Groovy-Eclipse plug-in is quite involved and a bit invasive. Worse yet, at the moment the Groovy-Eclipse plug-in can't even be installed in Eclipse Luna SR1 with the intermediate git update (some JDT incompatibility).
I currently solved this by having a second Eclipse instance just for the EE samples project. For something that is barely used this is perhaps a bit too much trouble?
For something that is barely used this is perhaps a bit too much trouble?
I wonder how many users are probably affected by the scenario (read: "the trouble") you describe above? It seems to me we are talking about removing the 3 dependencies to groovy-all, spock and the groovy-eclipse-compiler to reduce a hassle that Eclipse is implying to Groovy users at the moment. We could also consider raising an awareness to the problem in form of an issue on the Groovy Eclipse Plugin. Would that be an option?
I definitely agree with @bartoszmajsak that it's a pity we didn't invest more effort into spock, yet. :-| Will mark it as a TODO for myself.
I would prefer to keep consistency and use the same system / language for tests.
BTW, the Groovy dependencies also cause some problems on IntelliJ. If you try to run the tests directly on IntelliJ, sometimes you get an Exception. The only reliable way to prevent it, is for me to comment out the arquillian-spock-container dependency.
+1 for scrapping Groovy.
All the three Spock tests are also written in jUnit - so scrapping Groovy will have no impact on coverage. As no additional tests were written since introducing Spock (a year ago) scrapping Groovy support seem a good idea.
As no additional tests were written since introducing Spock (a year ago)...
What's the issue with Groovy and Eclipse?
I just tried a fresh Luna EE SP1 install. Imported the servlet-filter sample via m2e. M2e found the groovy compiler settings, installed groovy m2e integration, groovy compiler and groovy eclipse integration.. restart.. run as test and all green.. ?
I dunno, TBH I think most of the issues are simply due to the number of modules in the project, not the implementation language of some tests over others.
What's the issue with Groovy and Eclipse?
I just tried a fresh Luna EE SP1 install.
It works on a fresh Luna EE SR1, it doesn't work anymore on SR1a. SR1a wasn't packaged, but after you install a fresh Luna EE SR1, then do Help -> Check for Updates, you should see an incoming update. See also http://jdevelopment.nl/mysterious-44120150109-eclipse-luna-update-sr1a
I would prefer to keep consistency and use the same system / language for tests.
Indeed, even if Groovy would work out of the box with zero extra effort and zero extra dependencies, I'd still prefer a consistent system.
Now someone wanted Groovy tests. Maybe tomorrow we have someone who really likes Scala and adds support for that, then a little while later we have someone who thinks JavaScript based tests are the best. Then someone else might prefer TestNG, and yet another person SureAssert, etc. It's a slippery slope IMHO.
It's a slippery slope IMHO.
Don't really agree with this being a problem per say. This is samples repository, not an Enterprise app.
You could say the same about anything that is not pure JavaEE APIs, AngularJS, NoSQL, Quartz, Twitter, Apache Camel etc etc..
I'm not necessarily for rewriting all Test cases in Groovy because I think that is just as wrong from a diversity standpoint.. But in this case where we're talking about a language, perhaps the sample as well as the test should be written in Groovy. A Groovy servlet via a groovy test.
We could then create language based sub modules, groovy/scala/jruby/ceylon and isolate the pom configuration to that sub module. Submodules of that again would inherit the given language config.
We could then show how to use JavaEE API's in alt languages.
You could say the same about anything that is not pure JavaEE APIs, AngularJS, NoSQL, Quartz, Twitter, Apache Camel etc etc..
I do indeed think that in the Java EE samples project, usage of AngularJS, Twitter etc, should be minimized. Before you know it the EE samples project loses coherence and it will become a general coding samples project (any language, any technology, any system).
Of course, at some point it may make some sense to use AngularJS, e.g. perhaps to show it can easily do requests to JAX-RS, and to use Quartz to show it can be a JCA inflow resource adapter and integrate with MDBs, and Twitter may be used to demonstrate an OAuth login via JASPIC, etc, but for this particular repository I think we should minimize it.
But having some tests almost arbitrary use one system or language and another test using another system, where the test is mainly doing assertions and is not really about explicitly demo'ing how language X can use technology Y... I don't think that adds much but inconsistencies.
We could have a separate repo to showcase integration with other technologies and leave this one with plain Java.
Another problem is that sometime people only want to run demos for JPA or JAX-RS, you name it. At the moment they have to download the full repo and load everything in the IDE and so on. Maybe this is a different discussion, but I would like to hear your thoughts about it.
@radcortez downloading the 'complete repo' isn't much hassle.. and you choose to import the whole thing. You don't need to. You can choose to only import the samples you want or a section e.g. servlet.
Perhaps we should document that a bit better
This repo is fantastic and I find it the canonical repo for showcasing the JavaEE framework. I really appreciate the hard work and dedication it takes to make this happen!
In this instance I see value in showcasing the fact that JavaEE isn't the stodgy framework it once was and is sometimes still perceived to be by some.
Part of that is showcasing just how flexible an environment it is. If you have people who love Scala, or love Groovy, or love TestNG having some examples in this repo which showcase that is only going to further champion JavaEE in that light.
I think there's also value in finding out if one of these integrations causes pain as an issue can be raised with the appropriate project (Eclipse, Jetbrains, etc.) to hopefully improve things and thus improve the JavaEE ecosystem.
@arjantijms raises a good point which to me is more one about the quality of the test vs. whether its written in Groovy, Scala, Java, Nashorn etc. and that comes down to how PRs are curated.
There are always going to be a ton of technologies with varying levels of 'industry' uptake and that list is constantly changing. While that could be an argument for keeping things in plain and simple vanilla Java I think it makes a case for the value showcasing how they play with JavaEE. Most real world JavaEE projects I've seen are not pure vanilla Java but include some level of integration.
What you think of moving groovy / spock from the main project and put it into extras. After all Spock tests didn't show up at http://javaee-samples.github.io/ (at least some time ago) and maybe the extras folder is a better place for that.
That will make the repo cleaner, but still show capabilities of Arquillian Sputnik within the project. Steps would be
- removing groovy from
pom.xml - removing Arquillian Sputnik and
maven-surefire-pluginmagic from main pom.xml - moving
ExtendedPersistenceContextSpecificationandJpaListenerInjectionSpecificationandFilterServletSpecificationto a new project - updating README file
If so - I'll put it on Gdańsk Hackergarten backlog.
@kubamarchwicki sounds like a plan ;)
I encountered some additional issue with the Groovy support.
Builds now hang at this:
[INFO] Scanning for projects...
[INFO] Downloading: http://repository.codehaus.org/org/codehaus/groovy/groovy-eclipse-batch/2.3.1-01-SNAPSHOT/maven-metadata.xml
I tried to resolve the URL manually, and it either hangs or at an re-attempt returns a 404:
wget http://repository.codehaus.org/org/codehaus/groovy/groovy-eclipse-batch/2.3.1-01-SNAPSHOT/maven-metadata.xml
--2015-03-20 14:21:25-- http://repository.codehaus.org/org/codehaus/groovy/groovy-eclipse-batch/2.3.1-01-SNAPSHOT/maven-metadata.xml
Resolving repository.codehaus.org (repository.codehaus.org)... 199.193.192.103
Connecting to repository.codehaus.org (repository.codehaus.org)|199.193.192.103|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
With the imminent shutdown of codehaus, do we to boost this issue a little perhaps?
Pull request is proposed #310, waiting for feedback :)
With the imminent shutdown of codehaus, do we to boost this issue a little perhaps?
Just wondering how is that related to using spock for testing...
With the imminent shutdown of codehaus, do we to boost this issue a little perhaps?
Just wondering how is that related to using spock for testing...
It doesn't; there was a codehaus repository defined in pom. Dropping it didn't change anything - and now whole Spock testing thing (thus Groovy) in hidden in a single extras/ project - with dependencies from central repo.