Thought's about software, Grails, Java, web development and anything else that comes to mind.
Thursday, May 01, 2008
Spring Application Platform and Grails
For those of you interested, Grails applications deploy and execute on SpringSource's new Application Platform without any issues. I have updated the Grails deployment page to that effect.
ok.. I am not real fluent in OSGi yet.. but does this mean we could load and unload OSGi bundles dynamically into SAP and then call them from Grails? In a way providing a dynamically reload-able and version-able services layer for Grails apps?
What is involved in calling an OSGi bundle/resource in SAP from a Grails app?
I have tried deploying simple generated grails projects (generated from a domain class with one String property)on SAP with out any luck. They deploy fine and I can access the generated controller page but when I attempt to access the /create URL I get a 404 (the logs tell me that it is a ClassNotFound error). Thing is everything is auto generated so I am not sure what could be wrong.
I've been trying for quite a while to understand what to me is a deep flaw in the Groovy/Grails strategy. That flaw is that unlike Spring, Groovy/Grails practically *requires* the use of an expensive, proprietary IDE that costs $400 per year per license. By contrast, Spring is designed to work with the *free* Eclipse IDE. Worse, the standard response from all the top Groovy/Grails people when asked about Eclipse is to say, "What a piece of bloated garbage Eclipse is. I never use it. I do all my Groovy/Grails work using IntelliJ." In my judgment this anti-Eclipse bias is a huge mistake. There are many, many more developers who exclusively the Eclipse IDE than there are developers who shell out $400 for IntelliJ. It's really a shame that the groovy/grails people have let them selves becomes dependent on IntelliJ to such a degree that they are practically extensions of the IntelliJ marketing department.
In my experience, anyone who uses IDEA becomes "extensions of the IntelliJ marketing department"... I buy the license myself when my employer wont buy it.
I can see what you mean with groovy/grails "requiring" IDEA... as all Java based development "requires" it, IMO :)
The Jetbrains guys jumped in and embraced groovy and grails while the Eclipse community has not... Why should the people who create the language and platform be held accountable when the open source solution can't keep up with the industry leader in IDE development?
I understand your concern, I don't know who from the Groovy/Grails community say Eclipse is a bad IDE. I know for a fact its a great IDE. Unfortunately the reason you may get a response like that is the IntelliJ support for Groovy puts the Eclipse one to shame.
There obviously needs to be a concerted effort to improve the Eclipse plug-in. The problem is these things typically require a commercial backer to reach commercial quality (Eclipse had IBM, NetBeans has Sun).
Fortunately Sun have woken up and realized Groovy/Grails support is important and aim to bring their IDE up to the levels of IntelliJ over the next year.
Now its time to find someone who wants to do the same for Eclipse, we hope that it will be IBM, but we (G2One) are exploring options on how we can get backing for such an effort, whether it be ourselves or a partner organisation.
Eclipse may be free, but a quality Groovy/Grails plugin for Eclipse won't come for free unfortunately
"That flaw is that unlike Spring, Groovy/Grails practically *requires* the use of an expensive, proprietary IDE that costs $400 per year per license."
Just because IDEA currently sports one of the more mature plugins that is no reason to bash a technology. And you are far from required to use it. I personally use TextPad - I just happen to write good code that doesn't fail often :-P
LOTS of people swear by IDEA not just Groovy/Grails folk. The majority of SpringSource use it too (from the horses mouth). It's a brilliant IDE hence the reason why people shell out the money for it ime and time again.
It just think it's ridiculous to call plugin availability a language flaw - especially considering you can do most code generation using the command line!
I do sympathize with the groovy/grails developers and wish them well. And, it's very easy for me (as an RAD7 and eclipse user) to acknowledge that InteliJ is doubtless a much better IDE. Consider though, that groovy/grails heavyweight Scott Davis (author of 'Groovy Recipes') is writing a series of articles about groovy/grails for the IBM developer online journals. In those articles, Scott Davis gives the impression that RAD7 (i.e., a thin wrapper around eclipse) and IBM Websphere are a good fit for groovy/grails development. This is rather misleading, to say the least. Using groovy/grails with IBM RAD7 and IBM Websphere is of course possible, but it is certainly not a good enough fit to justify a corporate developer making the case to his/her management to use RAD7 to develop production quality groovy/grails apps. I certainly agree it would be wonderful if IBM took the lead and wrote a groovy/grails plug-in for Eclipse and better yet for RAD7. By the way, another beef I have with Groovy/grails is that I keep hearing how great it is to be able to use dynamic scripting for parts of an application that change frequently, thus avoiding the need to recompile java code. However, in the corporate world it is not allowed for a program in production or in QA to have it's property files and configuration files modified. Thus, keeping groovy code in flat files does not help at all in a corporate setting. On if the groovy code is kept in a database can it be changed in a corporate setting. But sadly, the only way to keep groovy code in a database is to write complicated, difficult custom code. I.e., groovy does not "out of the box" support being run from a database. This really is a big problem for corporate developers that I hope will one day be solved by the groovy team by providing that support as a first class citizen of the groovy core.
"However, in the corporate world it is not allowed for a program in production or in QA to have it's property files and configuration files modified."
Why? How do changes ever get made? I have spent the last few weeks doing exactly what you say isn't done - I've even been doing it under full Sarbanes & Oxeley compliance. If a change goes into a production environment no matter how big or small each second of downtime could potentially cost the corporation ALOT of money - being able to change configuration and reduce downtime is brilliant. That said, everyone knows, small changes rarely happen in a Production environment but just because a language has a feature such as this shouldn't have a negative impact on people opinions! There are plenty of places that this type of hot deployment is favored (especially large public websites and so forth)
>How do changes ever get made? Speaking from experience, here is how changes occur. First the developer copies the EAR file into the QA staging directory. Then paperwork is filled out online requesting the EAR file be installed on a date and time at least two days in the future. (two day advance notice is the mandatory minimum except for emergency changes, which require a different form be filled out). For a production migration, the developer is not allowed to copy the EAR file into the production staging area. A separate form must be filled out requesting the business domain owner to request the project leader to request the area liason to copy the EAR file from the QA staging area into the PROD staging area. In addition to that, a separate form must be filled out to request (giving two days advance notice) that the operations department install that production EAR file. The rule is that nothing is allowed in production until it has been tested in QA, and nothing is allowed to change between what is in QA versus what is in PROD. *That* is why the database is the only way to configure PROD differently than QA. and *that* is why it is so crucial in a corporation that is drowning in red tape to have an easy way to invoke groovy scripts from a database. What I have just described is a way of life in big corporations. And I might add, using IBM RAD7 is very often a given in a great big, giant corporation. Trying to use InteliJ instead of RAD7 in a big corporation would require so many approvals and red tape it would make most people's head spin.
True there is a formal process to be followed but just because you can hot deploy something doesn't mean the formal process can;t be followed. What hot deployment would do is eliminate or at the very least reduce the downtime - I have seen estimates for how much downtime in banks (2 of the biggest in Ireland/UK) can cost. Reducing downtime by even minutes in certain circumstances can save thousands.
To be fair I am not promoting this approach I am just offering a differing opinion.
I just don't think that complaining about a technology based on how some people choose to promote it is particularly productive.
I've had similar experiences having worked with 3 top tier banks in the UK. However, I don't see how your problem excludes the use of Grails
With Grails you can externalize configuration into regular Java properties files. You can then build a WAR that can get included in your EAR which gets taken through the steps from QA to Production.
This whole "running Groovy from the database" thing seems a little pointless. The way you can configure a Grails application is very similar to how you would configure any Spring app, the difference Grails makes is the simple case is easy.
12 comments:
Thanks Graeme!
this link doesn't require login and gives an overview of SAP.
ok.. I am not real fluent in OSGi yet.. but does this mean we could load and unload OSGi bundles dynamically into SAP and then call them from Grails? In a way providing a dynamically reload-able and version-able services layer for Grails apps?
What is involved in calling an OSGi bundle/resource in SAP from a Grails app?
This sounds really wonderful!
I have tried deploying simple generated grails projects (generated from a domain class with one String property)on SAP with out any luck. They deploy fine and I can access the generated controller page but when I attempt to access the /create URL I get a 404 (the logs tell me that it is a ClassNotFound error). Thing is everything is auto generated so I am not sure what could be wrong.
James
I've been trying for quite a while to understand what to me is a deep flaw in the Groovy/Grails strategy. That flaw is that unlike Spring, Groovy/Grails practically *requires* the use of an expensive, proprietary IDE that costs $400 per year per license. By contrast, Spring is designed to work with the *free* Eclipse IDE. Worse, the standard response from all the top Groovy/Grails people when asked about Eclipse is to say, "What a piece of bloated garbage Eclipse is. I never use it. I do all my Groovy/Grails work using IntelliJ." In my judgment this anti-Eclipse bias is a huge mistake. There are many, many more developers who exclusively the Eclipse IDE than there are developers who shell out $400 for IntelliJ. It's really a shame that the groovy/grails people have let them selves becomes dependent on IntelliJ to such a degree that they are practically extensions of the IntelliJ marketing department.
In my experience, anyone who uses IDEA becomes "extensions of the IntelliJ marketing department"... I buy the license myself when my employer wont buy it.
I can see what you mean with groovy/grails "requiring" IDEA... as all Java based development "requires" it, IMO :)
The Jetbrains guys jumped in and embraced groovy and grails while the Eclipse community has not... Why should the people who create the language and platform be held accountable when the open source solution can't keep up with the industry leader in IDE development?
danb
unapologetic Intellij Fanboy
@anonymous
I understand your concern, I don't know who from the Groovy/Grails community say Eclipse is a bad IDE. I know for a fact its a great IDE. Unfortunately the reason you may get a response like that is the IntelliJ support for Groovy puts the Eclipse one to shame.
There obviously needs to be a concerted effort to improve the Eclipse plug-in. The problem is these things typically require a commercial backer to reach commercial quality (Eclipse had IBM, NetBeans has Sun).
Fortunately Sun have woken up and realized Groovy/Grails support is important and aim to bring their IDE up to the levels of IntelliJ over the next year.
Now its time to find someone who wants to do the same for Eclipse, we hope that it will be IBM, but we (G2One) are exploring options on how we can get backing for such an effort, whether it be ourselves or a partner organisation.
Eclipse may be free, but a quality Groovy/Grails plugin for Eclipse won't come for free unfortunately
"That flaw is that unlike Spring, Groovy/Grails practically *requires* the use of an expensive, proprietary IDE that costs $400 per year per license."
Just because IDEA currently sports one of the more mature plugins that is no reason to bash a technology. And you are far from required to use it. I personally use TextPad - I just happen to write good code that doesn't fail often :-P
LOTS of people swear by IDEA not just Groovy/Grails folk. The majority of SpringSource use it too (from the horses mouth). It's a brilliant IDE hence the reason why people shell out the money for it ime and time again.
It just think it's ridiculous to call plugin availability a language flaw - especially considering you can do most code generation using the command line!
James
I do sympathize with the groovy/grails developers and wish them well. And, it's very easy for me (as an RAD7 and eclipse user) to acknowledge that InteliJ is doubtless a much better IDE. Consider though, that groovy/grails heavyweight Scott Davis (author of 'Groovy Recipes') is writing a series of articles about groovy/grails for the IBM developer online journals. In those articles, Scott Davis gives the impression that RAD7 (i.e., a thin wrapper around eclipse) and IBM Websphere are a good fit for groovy/grails development. This is rather misleading, to say the least. Using groovy/grails with IBM RAD7 and IBM Websphere is of course possible, but it is certainly not a good enough fit to justify a corporate developer making the case to his/her management to use RAD7 to develop production quality groovy/grails apps. I certainly agree it would be wonderful if IBM took the lead and wrote a groovy/grails plug-in for Eclipse and better yet for RAD7.
By the way, another beef I have with Groovy/grails is that I keep hearing how great it is to be able to use dynamic scripting for parts of an application that change frequently, thus avoiding the need to recompile java code. However, in the corporate world it is not allowed for a program in production or in QA to have it's property files and configuration files modified. Thus, keeping groovy code in flat files does not help at all in a corporate setting. On if the groovy code is kept in a database can it be changed in a corporate setting. But sadly, the only way to keep groovy code in a database is to write complicated, difficult custom code. I.e., groovy does not "out of the box" support being run from a database. This really is a big problem for corporate developers that I hope will one day be solved by the groovy team by providing that support as a first class citizen of the groovy core.
"However, in the corporate world it is not allowed for a program in production or in QA to have it's property files and configuration files modified."
Why? How do changes ever get made? I have spent the last few weeks doing exactly what you say isn't done - I've even been doing it under full Sarbanes & Oxeley compliance. If a change goes into a production environment no matter how big or small each second of downtime could potentially cost the corporation ALOT of money - being able to change configuration and reduce downtime is brilliant. That said, everyone knows, small changes rarely happen in a Production environment but just because a language has a feature such as this shouldn't have a negative impact on people opinions! There are plenty of places that this type of hot deployment is favored (especially large public websites and so forth)
My 2cents.
James
>How do changes ever get made?
Speaking from experience, here is how changes occur. First the developer copies the EAR file into the QA staging directory. Then paperwork is filled out online requesting the EAR file be installed on a date and time at least two days in the future. (two day advance notice is the mandatory minimum except for emergency changes, which require a different form be filled out). For a production migration, the developer is not allowed to copy the EAR file into the production staging area. A separate form must be filled out requesting the business domain owner to request the project leader to request the area liason to copy the EAR file from the QA staging area into the PROD staging area. In addition to that, a separate form must be filled out to request (giving two days advance notice) that the operations department install that production EAR file.
The rule is that nothing is allowed in production until it has been tested in QA, and nothing is allowed to change between what is in QA versus what is in PROD.
*That* is why the database is the only way to configure PROD differently than QA. and *that* is why it is so crucial in a corporation that is drowning in red tape to have an easy way to invoke groovy scripts from a database.
What I have just described is a way of life in big corporations. And I might add, using IBM RAD7 is very often a given in a great big, giant corporation. Trying to use InteliJ instead of RAD7 in a big corporation would require so many approvals and red tape it would make most people's head spin.
True there is a formal process to be followed but just because you can hot deploy something doesn't mean the formal process can;t be followed. What hot deployment would do is eliminate or at the very least reduce the downtime - I have seen estimates for how much downtime in banks (2 of the biggest in Ireland/UK) can cost. Reducing downtime by even minutes in certain circumstances can save thousands.
To be fair I am not promoting this approach I am just offering a differing opinion.
I just don't think that complaining about a technology based on how some people choose to promote it is particularly productive.
James
I've had similar experiences having worked with 3 top tier banks in the UK. However, I don't see how your problem excludes the use of Grails
With Grails you can externalize configuration into regular Java properties files. You can then build a WAR that can get included in your EAR which gets taken through the steps from QA to Production.
This whole "running Groovy from the database" thing seems a little pointless. The way you can configure a Grails application is very similar to how you would configure any Spring app, the difference Grails makes is the simple case is easy.
Post a Comment