Since upgrading to Eclipse Galileo (a.k.a. 3.5) I've noticed that there has been a definite lag in plugin developers supporting the latest version.
A couple of examples that have resulted in me keeping a parallel Ganymede (3.4) version installed include:
- Google App Engine
- Spring Tool Suite (well, not really, as I uninstalled this once I saw the recommended configuration tweaks to get the plugins to play nicely with OSGi)
Today I noticed that SpringSource have blogged and tweeted about an impending milestone 1 release of Eclipse Groovy Tools, still tied to 3.4 but with the assurance that 3.5 support will be available soon.
Showing posts with label groovy. Show all posts
Showing posts with label groovy. Show all posts
Thursday, 30 July 2009
Monday, 22 June 2009
Grails gotchas / showstoppers effecting uptake
I was somewhat relieved when I came across this blog post which highlights the fact that other developers have also faced a loss of productivity when working with Grails.
The "convention over configuration" approach speeds up development and keeps the learning curve fairly easy for most developers, but the list of open issues on the Jira suggests that there are still some aspects that need tuning - or detuning in some cases (e.g. domain objects not having GORM functionality due to something missing in lazy decoration/injection).
I've been wondering what sort of risks are involved when you use a software product that is essentially just providing a layer of abstraction over several loosely related other products.
For example, what can you do if you want to upgrade to a later version of one of the underlying technologies (for a fixed bug, or to use a new feature), when the layer above that hasn't been tested or made configurable for that new release? At present, I would expect that you would be stuck with whatever version is compatible with your version of Grails. This could change once OSGi becomes a bit more mainstream, allowing for the use of multiple versions of the same libraries within a single application. I wouldn't want to rely on that being the saviour of any application of mine though.
The "convention over configuration" approach speeds up development and keeps the learning curve fairly easy for most developers, but the list of open issues on the Jira suggests that there are still some aspects that need tuning - or detuning in some cases (e.g. domain objects not having GORM functionality due to something missing in lazy decoration/injection).
I've been wondering what sort of risks are involved when you use a software product that is essentially just providing a layer of abstraction over several loosely related other products.
For example, what can you do if you want to upgrade to a later version of one of the underlying technologies (for a fixed bug, or to use a new feature), when the layer above that hasn't been tested or made configurable for that new release? At present, I would expect that you would be stuck with whatever version is compatible with your version of Grails. This could change once OSGi becomes a bit more mainstream, allowing for the use of multiple versions of the same libraries within a single application. I wouldn't want to rely on that being the saviour of any application of mine though.
Thursday, 4 June 2009
Technologies I am currently looking into
Here's a list of tools / libraries / methodologies that I am hoping to reading about and have a play with while I some spare time on my hands.
TestNG - why use it instead of JUnit? How does its support for running tests in parallel work?
JSF 2 - what's changed since I last used RichFaces, Facelets etc.? Is it now possible to utilise the various open source widgets side-by-side?
Groovy - What cool features are there that I haven't already come across in using Grails?
easyb - will this give maximum value by allowing developers to write tests more rapidly (Groovy vs Java), and have the tests more human readable?
Spring
Google App Engine - just got an account set up, installing exclipse plugin ...
Google Web Driver - an alternative to Selenium
TestNG - why use it instead of JUnit? How does its support for running tests in parallel work?
JSF 2 - what's changed since I last used RichFaces, Facelets etc.? Is it now possible to utilise the various open source widgets side-by-side?
Groovy - What cool features are there that I haven't already come across in using Grails?
easyb - will this give maximum value by allowing developers to write tests more rapidly (Groovy vs Java), and have the tests more human readable?
Spring
- STS (Spring Tool Suite)
- Spring 3.0
- Spring Security 3 - initial overview makes me want to have a play with the @PreAuthorize and @PostFilter annotations, the codebase tidy up should make it easier to get setup up too.
- Roo
- tc Server
- DM Server
- OSGi support
Google App Engine - just got an account set up, installing exclipse plugin ...
Google Web Driver - an alternative to Selenium
Sunday, 24 May 2009
Upgrading fixed updating, but may have broken creation.
It's a bit late in the evening for me to give a detailed account of what exactly I did, why, and what I found - so here's the short version.
Grails 1.1 was misbehaving whenever we tried to update an existing persisted object.
Grails version 1.1.1 was shown as fixing that particular issue.
I volunteered to be the guinea pig to be the first in the office to try upgrading.
Hurdle 1 - Original Grails 1.1.1 download included an install script with a Windows specific issue
Hurdle 2 - Maven plugin for Grails also would not play nicely (something about a dependency introduced by one of the minor new features added in Grails 1.1.1)
...
It works - even the updates to existing objects make it to the database without throwing exceptions etc. Hoorah!
A couple of days later we struck an issue where Groovy was unable to determine that an object was supposed to have GORM methods injected. The symptom being that it was unable to find a property (actually method) called save.
Mutter mutter mutter....
The workaround for that case has been to add some code to the BootStrap.groovy file to force Grails/GORM to be aware of that type of object - preventing us from relying on lazy initialisation.
Grails 1.1 was misbehaving whenever we tried to update an existing persisted object.
Grails version 1.1.1 was shown as fixing that particular issue.
I volunteered to be the guinea pig to be the first in the office to try upgrading.
Hurdle 1 - Original Grails 1.1.1 download included an install script with a Windows specific issue
Hurdle 2 - Maven plugin for Grails also would not play nicely (something about a dependency introduced by one of the minor new features added in Grails 1.1.1)
...
It works - even the updates to existing objects make it to the database without throwing exceptions etc. Hoorah!
A couple of days later we struck an issue where Groovy was unable to determine that an object was supposed to have GORM methods injected. The symptom being that it was unable to find a property (actually method) called save.
Mutter mutter mutter....
The workaround for that case has been to add some code to the BootStrap.groovy file to force Grails/GORM to be aware of that type of object - preventing us from relying on lazy initialisation.
Subscribe to:
Posts (Atom)