h1. Introduction
*Disclaimer - I'm no expert in Grails but here are my experiences - anyone with any tips - much appreciated!*
I'd like to think I work for a pretty forward thinking group of people. But often at work you can't take as many technical risks as you'd do if it were your own money.
h1. Maven2, Clover and Grails don't get on, but they're working through their issues
Maven2 is our company's standard build system for Java projects. We also use Clover2 for code coverage.
When we first set up some new Java projects and got the Bamboo dashboards up management loved it, and the developers loved it too. I also managed to get coverage for the acceptance tests using Clover2 which really pleased the testers and myself - I could check that the testers were automating their stuff.
We were also getting surefire test reports and coverage trending in Bamboo our build server. So far so great - expectations are high for metrics from all parties.
Enter Grails - trying to get this working with maven2 is getting a lot better thanks to the Grails team's plugin support but it's still not a walk in the park. I couldn't get the test reports to come out right (all tests were duplicated in the surefire reports - probably my bad but spending more than a couple of hours trying to get this to work just isn't an option for me at the moment).
Next up coverage reports - again some helpful Grails plugin developer had put together a cobertura plugin. Cobertura is good - infact it's great in that it works on byte code. This should provide some coverage support for all the new JVM languages out there. I got this working producing coverage reports in the "right" place in maven2 with some help from the antrun plugin.
But another issue was with Bamboo - the Cobertura plugin is broken for our version of Bamboo so we can't get coverage trending either.
But Cobertura is not our standard. Clover2 is - and Clover2 just kicks Cobertura's butt in terms of Java support. I'm hoping that Clover2 will be made to work with bytecode quickly.
The thing is none of this looks good - the Bamboo dashboard is often how projects are judged in our space (rightly or wrongly) - and we're trying to get our first Grails application accepted. For me the Grails tooling support just isn't there right now and in a world full of Java apps with great support it's hard to fit in.
That said there is a lot more going on under the covers on our Grails apps than just stats. Well one great stat is the lines of code - very low compared with a Java version. Just makes understanding the problem / relaxing of code ownership / refactoring easier. There's just less stuff!
Plus the dynamic reloading of controllers and services really is a very productive feature in Grails that I really like.
So it is with some trepidation that I move our services and domain objects back to Java (keeping the rest in Grails) so we can look credible. I can get ATDD coverage and decent looking code coverage in my app again (admittedly without controller layer coverage - but I'm not as precious with controllers).
This will give us all the dashboard features of the Java apps. I just hope I don't miss the dynamic reload of services too much. (Although maybe I can still have my cake and eat it - time will tell).
h2. GORM - I can't get the right schema
At the moment, although I really like GORMs superfast dsl I can't get it to do the right thing when it comes to association mappings. (Many-to-many with join table?). So we're moving back to Hibernate Annotated POJOs. This just felt pretty good as I got full control back for my mappings.
When you change the domain model in Grails it often means a restart of the application anyway so doing this has just given us much more control back without too much extra cost. We also still get all the GORM features we like too. It's a win - win. That said, when you're just writing logic in domain classes we'll _have_ to restart which isn't so good.
h3. Summary
Well we've still got all of our controllers and view layer in Grails. This still totally rocks in terms of the Convention over Configuration style, dynamic reloading and the productivity this brings.
For domain objects, services and repositories - these are all in Java now. This may only be a temporary move. When Clover2 Grails support arrives I'll be the first to check it out. Also if the test reporting in Grails becomes a bit more Maven friendly then I may yet get my services back in Grails.
Also as I work with GORM a bit more maybe we can get our domain objects back into Grails too.
*Disclaimer - I'm no expert in Grails but here are my experiences - anyone with any tips - much appreciated!*
I'd like to think I work for a pretty forward thinking group of people. But often at work you can't take as many technical risks as you'd do if it were your own money.
h1. Maven2, Clover and Grails don't get on, but they're working through their issues
Maven2 is our company's standard build system for Java projects. We also use Clover2 for code coverage.
When we first set up some new Java projects and got the Bamboo dashboards up management loved it, and the developers loved it too. I also managed to get coverage for the acceptance tests using Clover2 which really pleased the testers and myself - I could check that the testers were automating their stuff.
We were also getting surefire test reports and coverage trending in Bamboo our build server. So far so great - expectations are high for metrics from all parties.
Enter Grails - trying to get this working with maven2 is getting a lot better thanks to the Grails team's plugin support but it's still not a walk in the park. I couldn't get the test reports to come out right (all tests were duplicated in the surefire reports - probably my bad but spending more than a couple of hours trying to get this to work just isn't an option for me at the moment).
Next up coverage reports - again some helpful Grails plugin developer had put together a cobertura plugin. Cobertura is good - infact it's great in that it works on byte code. This should provide some coverage support for all the new JVM languages out there. I got this working producing coverage reports in the "right" place in maven2 with some help from the antrun plugin.
But another issue was with Bamboo - the Cobertura plugin is broken for our version of Bamboo so we can't get coverage trending either.
But Cobertura is not our standard. Clover2 is - and Clover2 just kicks Cobertura's butt in terms of Java support. I'm hoping that Clover2 will be made to work with bytecode quickly.
The thing is none of this looks good - the Bamboo dashboard is often how projects are judged in our space (rightly or wrongly) - and we're trying to get our first Grails application accepted. For me the Grails tooling support just isn't there right now and in a world full of Java apps with great support it's hard to fit in.
That said there is a lot more going on under the covers on our Grails apps than just stats. Well one great stat is the lines of code - very low compared with a Java version. Just makes understanding the problem / relaxing of code ownership / refactoring easier. There's just less stuff!
Plus the dynamic reloading of controllers and services really is a very productive feature in Grails that I really like.
So it is with some trepidation that I move our services and domain objects back to Java (keeping the rest in Grails) so we can look credible. I can get ATDD coverage and decent looking code coverage in my app again (admittedly without controller layer coverage - but I'm not as precious with controllers).
This will give us all the dashboard features of the Java apps. I just hope I don't miss the dynamic reload of services too much. (Although maybe I can still have my cake and eat it - time will tell).
h2. GORM - I can't get the right schema
At the moment, although I really like GORMs superfast dsl I can't get it to do the right thing when it comes to association mappings. (Many-to-many with join table?). So we're moving back to Hibernate Annotated POJOs. This just felt pretty good as I got full control back for my mappings.
When you change the domain model in Grails it often means a restart of the application anyway so doing this has just given us much more control back without too much extra cost. We also still get all the GORM features we like too. It's a win - win. That said, when you're just writing logic in domain classes we'll _have_ to restart which isn't so good.
h3. Summary
Well we've still got all of our controllers and view layer in Grails. This still totally rocks in terms of the Convention over Configuration style, dynamic reloading and the productivity this brings.
For domain objects, services and repositories - these are all in Java now. This may only be a temporary move. When Clover2 Grails support arrives I'll be the first to check it out. Also if the test reporting in Grails becomes a bit more Maven friendly then I may yet get my services back in Grails.
Also as I work with GORM a bit more maybe we can get our domain objects back into Grails too.