We've using groovy/grails for a couple of months and find it very nice language and framework, at least for prototyping.
The only thing constantly driving us mad is projects build time.
Compiling small app consisting of few tiny domain classes took up as much time as if we are compiling something well, something more serious )))
So, the question is - are there any techniques and approaches which can be used to reduce grails project build time?
UPD:
this question covers one of aspects, which make grail deployment slow - dependency resolution. In short, get rid of snapshot dependencies. The subquestion is how can I detect such dependencies fast?
In development, you can try running the script runner in interactive mode:
grails interactive
or, in Grails 2, simply
grails
It keeps JVM running between grails commands invocations, which greatly reduces their overhead. I found this of a great use when doing TDD, as running tests becomes much quickier that way.
Related
I recently get to know grails and start to using it, I know that grails is a great language and it is very helpful for rapid development, but I cant understand why grails dont have a good backward compatibility, I use grails 2.3.8 and grails 2.4 for my projects but many of sample codes in the internet are 2.2 or less, and it isn't time efficient to convert them to 2.3.8 or 2.4 because there are many changes from one version to another. And some times although I do any things right and every thing must work like it works with grails 2.1 or 2.2 but some things still remains.
Am I wrong? I skipped some things that make converting version so hard?
And above all this, what are the guaranties that projects I'm developing right now will be compatible with higher versions of grails that comes in the future?
Joshua Moore is right with his answer, but I do not see it as passimistic as he does.
The grails development team is brave enough to make changes which break with the past. I consider this as a great feature - Grails does not ride dead horses.
For me, most of the changes don't seem to bee too radical. Most of the time, I skip 2-3 version and then upgrade my apps to the current stable version in less than a day. This also helps me to get to know the new features.
If you don't know how to upgrade, the safest way is to use the grails upgrade command. Just increase you version number step by step and do an upgrade and re-run your test (yes, tests help you in your upgrade process :-). If tests fail, take a look at the great changelogs and the "What new in Grails x.y?" sections of the documentation.
Often it is also helpful to compare your old grails version app with a new and empty target version project with a good comparison tool like BeyondCompare. This way you easily spot changed configurations.
Hope that helps
Update: When you are new to "all those webconcepts" you should first decide on the platform you want to work on. If it is the java ecosystem, Grails is the best webframework on the market :-) Otherwise PHP, Rails, DJango etc. could also be a match.
So if you want to learn Grails (and with Grails all those webconcepts), I would suggest to start reading the Guide which will tell you how Grails works. If you need more examples, I can suggest the "The Definitive Guide to Grails 2" published by Apress. It covers basically the same content as the guide, but it does so by walking you through a process of building a sample application.
When it comes to the samples you find on the net... as soon as you get to know the framework better, you will probaply know ho to handle the examples - but there is no silver bullet...
Nothing guaranties that your projects will be compatible with future versions of Grails. In fact, from my own experience, they won't. Often things change, and sometimes radically too, as Grails matures into higher versions.
The same holds true of backwards compatibility as well.
All you need do is take a look at the introduction section of the Grails documentation to see how often things change significantly between versions. A lot of times these changes require significant refactoring of older projects to upgrade them. I still have several large projects running on the 1.3.x branch of Grails because we don't have the resources (time) to go through and upgrade them.
Often this upgrade process involves creating a new empty project then slowly moving the code from the old project into the new project, updating code to reflect newer means of doing the same thing and testing. It's not easy for projects where you have 100+ Domain classes, 1000+ GSPs, 50+ Services and several hundred thousand lines of tests.
Hy there. I have a number of software projects (also iOS and OSX) which I build with Apache ant`.
Although I quite like Ant it is often too verbose and some things which should be easy are quite tricky or I have to use shell scripts along with ant.
Is there a good alternative for which is extensible, easy to use and should work well on my jenkins build server.
Thanks for your input.
Have a look at Gradle - it's quite different from Ant and may take a little while to get your head around, but I think it's going to be the new standard for build systems. One nice thing is that it has full Ant support under the hood, so you can easily get your existing Ant builds running and then port them to Gradle.
Gareth's answer of Gradle is a good one. But do take a look at what you are doing that is hard with Ant. In my experience, a fair portion of the time its "non-build" stuff. Perhaps leave Ant for the pure build stuff, and use an alternate tool for and deploy or test stuff that's snuck in there.
Although gradle looks very promising I decided to use Rake instead.
I should say that this is a biased decision since I am already using ruby for other parts in my build setup. I found a good Article by Martin Fowler
Another point is that by doing OSX development the platform-independence-aspect of Ant (or Gradle) does not have such a big weight for me.
BTW Besi's Rake answer:
JRuby's Rake+Ant integration seems like a really powerful combo:
http://www.engineyard.com/blog/2010/rake-and-ant-together-a-pick-it-n-stick-it-approach
One big advantange there, it fully supports integration with Ant, allowing step-by-step migration.. which IMHO is only viable strategy for large, existing projects.
Gradle seems similar and while it looks good; I think learning Rake could be a better investment as it's more universal outside of Java.
(The other thing I'm seriously considering is BuildR http://buildr.apache.org, but Jenkins doens't explicitly support it yet, so have to use scripted build steps, which seems less preferable. TODO: a BuildR plugin).
G'day guys,
I've started a new role at a company and am working on a rails application that's used internally for particular management applications. At any rate, there are no unit tests associated with this system, and as I am building the system out I've realised there is a serious need to build unit tests so that I can have regression testing as I continue to add to this codebase.
It's a rails 1.2.7 app that I cannot migrate for reasons of compatibility, but I will be beginning to port components over it to 3.0 in the background.
There is currently only the built in tests that rails makes, and I would love some insights into how to get started with building small tests into the system and particularly at what aspects would be good to start?
This system builds a lot of individual config files, so I'm assuming a lot of the test generation would begin with testing those config files for individual aspects/elements and going from there.
I've had a look at cucumber and rspec, but just wanted to find something straightforward and easy to use that I could slowly build upon within the current system and build up a testing base over time.
Any insights, links or others would be really really appreciated.
Cheers!
A lot has changed since Rails 1.2.7, definitely one of the first things would be to right unit tests, but instead of going an all out unit test attack.. Attack the problem component,
Write tests
Upgrade the component
Run Tests ( mostly they'll fail / possibilities of errors )
Make them pass
Refactor ( May be the new features at your disposal )
I usually do the above steps with writing the integration tests, and functional tests and unit tests for the components in the integration tests.
All the best, this ain't going to be a simple task :).
Help! I'm porting a large ruby app to Grails - but the Grails startup of my application takes more than 2 minutes.
I've already set dbCreate to "read" I've ensured my high end dual processor desktop windows box gives Grails needed RAM (1 Gig). I have no plugins installed. I have 170 domain classes that used to be ruby classes.
When it starts up it prints out the line "Running Grails App.." and then hangs for a long time before it then prints out the "Server running" line.
I just did something where I migrated all my ids to bigints. That seems to have worsened the problem. Now it takes about 10 minutes to startup.
I am new to grails would you please give me a few more details on what and where to log the events at startup? As to profiling the vm, its been a few years since I did a lot of Java. What do you recommend as the best profiling tool to use now?
What else can I do to speed up Grails startup?
Unfortunately, I am not sure too much can be done beyond what you already did. As you know, there is a lot going on when it starts up, with all the plugin resolution / loading, adding dynamic methods to your domain objects, and overall dynamic nature of Groovy.
I am not sure which version you are using, but I've asked for ability to turn off dependency checking when you start up in 1.2, since that adds a bunch of time to startup time as well.
I realize above isn't too helpful, so perhaps this will be: I split up my application into several plugins. One for domain objects, one for graphing capability, one for excel import, another for some UI constructs I needed. I didn't do it just because of slow startup times, but the advantage is that I can test parts of the system separately from each other before integrating everything together.
I am about to add a piece of new functionality that involves at least 10 new domain objects, and I am first developing them in a separate plugin by having stubs for the few objects they have to interact with from the core app. That allows me to both reduce startup times, and also have my code better isolated.
So if it's an option for you, try to separate out things so you can work on them separately, which will alleviate your issue somewhat. There may also be other benefits in terms of having your team work on smaller components separately, better modularization, etc.
Hope this is helpful.
170 domain classes is fairly large, but 2 minutes still seems really long to me. Do you have a ton of plugins installed? Potentially too verbose debug settings?
I'd be curious how long it took if you created a fresh grails app, copied in all of your domain objects (and the subset of plugins that the domain objects might need to actually operate) and see how long that takes to start.
Jean's suggestion about separating things out if possible is a good one. I've done something similar on previous projects where we have a domain plugin, and our other apps all rely on that domain plugin.
You could also use the grails events to log some timing information on start up to see where your bottlenecks are. Timing the "PluginInstalled" event should be good as I think that the hibernate plugin would be caught by this in addition to the other plugins.
You may have a dependency problem. If a plugin you use relies on a library in maven that has 'open ended' dependencies, grails will go and look each time if there are newer versions to download in the range. I have no idea why anyone would specify it like this. It seems it would lead to unreliable behaviour. For me, the culprit is Amazon's java aws library, naturally used by a plugin that talks to Amazon's cloud.
http://mvnrepository.com/artifact/com.amazonaws/aws-java-sdk/1.2.10
note how some of its dependencies are like this
org.apache.httpcomponents httpclient [4.1, 5.0)
it appears that every time, grails is looking for a newer version (and downloading if it exists, I just noticed 4.2-alpha1 of httpclient come down when I ran this time).
By removing that dependency from the plugin and manually adding the required libraries to my .lib folder, I reduced my startup time from >30sec to <1sec
You might want to see if there are other knobs you can turn other than Grails in order to fix this.
Have you tried approaching this as a performance issue? You can a look at the box performance and try to find out what the bottleneck is. Is it CPU? Is it a disk read issue? Can you attach a profiler to the VM and find out what's using up most of your startup time?
Have you tried basics like these for further deployment to a servlet container of your choice or in-place .war bootstrapping?
grails -Ddisable.auto.recompile=true run-app
grails run-war
grails war
Have been developing with Grails for couple of weeks now,
Though I've loved the experience and the possibilities, I've seen following problems starting up.
Please share if you've had similar issues.. and remedies would help too.
Transaction management (in-built) doesn't seem to work in some circumstances.
AOP with domain objects doesn't work
Grails IDE-plugins are pretty primitive
GWT-Integration (with the plugin)
Plugin installation (fails unusually) probably cause plugins are not matured enough.
Lack of extensive documentation (though what is available is pretty good)
Debugging support
If you actually want solutions for these problems you should post a separate question for each with a lot more information than you've provided here. For example, I can't possibly diagnose the cause of the problem when all I know is
Transaction management (in-built)
doesn't seem to work in some
circumstances.
Here is my opinion on these issues:
Transaction management (in-built) doesn't seem to work in some circumstances.
I haven't noticed any such problem
AOP with domain objects doesn't work
I guess what you mean here is that meta-programming domain objects doesn't work. I have encountered this and haven't found any solution. If you really meant AOP then I can't help you as I've never used it with Groovy.
Grails IDE-plugins are pretty primitive
The IntelliJ plugin is very, very good. The Netbeans plugin is OK. Last time I tried the Eclipse Groovy plugin it was awful. However, I believe that a new Eclipse Groovy plugin has recently been released as part of the Spring Tool Suite (STS). It's supposed to be big improvement on the previous Eclipse Groovy plugin, but I don't think it has much Grails support yet
GWT-Integration (with the plugin)
I don't use GWT, so have no comment
Plugin installation (fails unusually) probably cause plugins are not matured enough.
I've never had problems installing plugins, though if I update a plugin, I sometimes need to manually remove the old version from the .grails directory.
Lack of extensive documentation (though what is available is pretty good)
I think the level of documentation for Grails is way ahead of most OS projects. There is a wide range of Grails books available, there's an active mailing list, and the official document is 176 page long.
Debugging support
Again, it depends on the tools you're using. With IntelliJ, debugging a Grails app is as easy as debugging a Java app with Eclipse.
My own pet peeves about Grails development are:
Upgrading from one version to another is often a very painful process due to lack of backward compatibility. When I upgraded from 1.0.4 to 1.1.1 about 20% of my tests started failing
Application reloading is very hit and miss.
My feedback after few months with Grails:
Didn't happen to me.
I don't use AOP
Wrong. IntelliJ is very good and especially the last beta version. You can download it for a free trial. I know that Eclipse support is very limited and NetBeans becomes better but still behind IntelliJ
I can't say. I don't use it
Agree. My piece of advice here is to follow these following principles: 1.Use plugins as few as you can. Your application will be lighter and more maintainable. Also, you will upgrade Grails version more easily. 2.if you want to use a plugin, test it before with a dummy project. It takes few minutes for creating a grails application and you could test your next plugin rapidly. Be aware that sometimes plugins have compatibility issues between theselves so, do not hesitate to install all of the plugins you need into your dummy project
Agree. Grails is a very complex framework and documentation does not cover every aspect of Grails. But what is available is well explained. Also, grails community is very responsive, so if you don't find something you will easily have an answer in Grails forum or even on StackOverflow
Definitely Agree. Again, with IntelliJ you can debug easily but it is resource-consuming and takes time when reloading your app. So usually, I end up with logging traces and I debugg my full stack of exceptions like that! IMHO, this is one of the major shortcomings of Grails.