1.5 Years with Garils: Thoughts

classic Classic list List threaded Threaded
78 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

1.5 Years with Garils: Thoughts

Jonathan Rosenberg
About 1.5 years ago I made the jump to Grails for new web apps.  I
have been wanting to write a summary of my experience for a while now
& I'm finally getting around to it.  Please don't take anything
personally: this is meant in the spirit of making things better.

Intro Notes

1) I have a PhD in CS & over 35 years of programming experience.
2) I had recently been programming for several years in PHP, initially
without a framework and then with Zend.
3) I did a lot of research before choosing Grails.
4) I started with very little Java experience, a small amount of
Groovy experience and no Java web app experience.
5) At this time I am by no means a Grails expert, but I am certainly
"Grails competent"

The Good

1) Groovy: cool language, feels very natural to me.  Java
compatibility is a HUGE win.
2) Spring integration: enough said
3) GSPs, Sitemesh integration & tag libs: hits the sweet spot
4) STS: excellent IDE integration.  A pleasure to use.
5) Webflow: yes, Webflow has some nasty quirks and feels unpolished,
but I love it.
6) Directory/framework structure: I know this isn't unique to Grails
but it works very well here.

The Bad

1) Hidden magic:  there is a ton of hidden runtime magic in Grails.
This is no problem when things work out of the box, but I found it
very hard to get my hands on the guts & tweak it.  Most of the magic
seems to be undocumented, and is certainly unspecified.  So even if
one reads the source code, it is risky to make use of what you find.
I spent far too much time trying to modify things created
automagically (e.g., Session Factory)..

I really wish the magic (& hooks) were specified.

2) Convention over configuration: yeah, this is GREAT when it works,
but a nightmare when it doesn't. How many times have you spelled a
service name incorrectly (when you wanted automatic DI)?  Or typed
"constraitns" instead of "constraints"?  You only find out at runtime
and the exceptions/problems that arise can be extremely difficult to
track down.

3) GORM: feels very awkward to me and I am constantly forgetting how
to use belongsTo (which side gets this?) & other features.  I gave up
and used Hibernate mappings in quite a few cases.

4) This mailing list: A non-trivial percentage of questions that are
posted are never answered, or get only partial answers.  It has gotten
to the point where I typically don't bother posting a question, as I
know I am so unlikely to get an answer.

I know and appreciate that (almost) everyone here is a volunteer and
the product is free.  I contrast this to the Tomcat user list, where I
know I'll get help of I post a question.  This is a major frustration.

The Bottom Line

So, would I abandon Grails going forward?  I'm honestly not sure how I
will build my next web app.  I'm not sure there's anything "better:"

- Spring Roo, I don't know much about it.  And while programming in
Java feels like going back to assembly language after Groory, I find
the IDE-time type checking very useful.
- Scala/Lift: I don't really feel like learning yet another language &
Lift is pretty new, but it's not out of the question
- Spring straight up: a possibility.  I'm quite comfortable with XML &
everything is exposed ...

That's all I have to say for now.  Responses, rants, etc. welcome.

--
Jonathan Rosenberg
Founder &  Executive Director
Tabby's Place, a Cat Sanctuary
http://www.tabbysplace.org/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: 1.5 Years with Garils: Thoughts

Chris Polderman
Hi Jonathan,

Thank you for sharing your experiences with us. My experience is in large lines the same as yours: great when things work out of the box,  a puzzle when things don't.

In addition, I find the upgrade path quite troublesome.  I've jumped on the grails bandwagon since 1.3 and every release brings it's own challenges.

Mind you that I would not like to create j2ee apps using only java and some core libraries. Grails better suits my work I think...

Chris

Jonathan Rosenberg <[hidden email]>schreef:

>About 1.5 years ago I made the jump to Grails for new web apps.  I
>have been wanting to write a summary of my experience for a while now
>& I'm finally getting around to it.  Please don't take anything
>personally: this is meant in the spirit of making things better.
>
>Intro Notes
>
>1) I have a PhD in CS & over 35 years of programming experience.
>2) I had recently been programming for several years in PHP, initially
>without a framework and then with Zend.
>3) I did a lot of research before choosing Grails.
>4) I started with very little Java experience, a small amount of
>Groovy experience and no Java web app experience.
>5) At this time I am by no means a Grails expert, but I am certainly
>"Grails competent"
>
>The Good
>
>1) Groovy: cool language, feels very natural to me.  Java
>compatibility is a HUGE win.
>2) Spring integration: enough said
>3) GSPs, Sitemesh integration & tag libs: hits the sweet spot
>4) STS: excellent IDE integration.  A pleasure to use.
>5) Webflow: yes, Webflow has some nasty quirks and feels unpolished,
>but I love it.
>6) Directory/framework structure: I know this isn't unique to Grails
>but it works very well here.
>
>The Bad
>
>1) Hidden magic:  there is a ton of hidden runtime magic in Grails.
>This is no problem when things work out of the box, but I found it
>very hard to get my hands on the guts & tweak it.  Most of the magic
>seems to be undocumented, and is certainly unspecified.  So even if
>one reads the source code, it is risky to make use of what you find.
>I spent far too much time trying to modify things created
>automagically (e.g., Session Factory)..
>
>I really wish the magic (& hooks) were specified.
>
>2) Convention over configuration: yeah, this is GREAT when it works,
>but a nightmare when it doesn't. How many times have you spelled a
>service name incorrectly (when you wanted automatic DI)?  Or typed
>"constraitns" instead of "constraints"?  You only find out at runtime
>and the exceptions/problems that arise can be extremely difficult to
>track down.
>
>3) GORM: feels very awkward to me and I am constantly forgetting how
>to use belongsTo (which side gets this?) & other features.  I gave up
>and used Hibernate mappings in quite a few cases.
>
>4) This mailing list: A non-trivial percentage of questions that are
>posted are never answered, or get only partial answers.  It has gotten
>to the point where I typically don't bother posting a question, as I
>know I am so unlikely to get an answer.
>
>I know and appreciate that (almost) everyone here is a volunteer and
>the product is free.  I contrast this to the Tomcat user list, where I
>know I'll get help of I post a question.  This is a major frustration.
>
>The Bottom Line
>
>So, would I abandon Grails going forward?  I'm honestly not sure how I
>will build my next web app.  I'm not sure there's anything "better:"
>
>- Spring Roo, I don't know much about it.  And while programming in
>Java feels like going back to assembly language after Groory, I find
>the IDE-time type checking very useful.
>- Scala/Lift: I don't really feel like learning yet another language &
>Lift is pretty new, but it's not out of the question
>- Spring straight up: a possibility.  I'm quite comfortable with XML &
>everything is exposed ...
>
>That's all I have to say for now.  Responses, rants, etc. welcome.
>
>--
>Jonathan Rosenberg
>Founder &  Executive Director
>Tabby's Place, a Cat Sanctuary
>http://www.tabbysplace.org/
>
>---------------------------------------------------------------------
>To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
Reply | Threaded
Open this post in threaded view
|

Re: 1.5 Years with Garils: Thoughts

xmly
My suggestion would be using Java EE first, then go to Spring/Hibernate.  You would feel world becomes better...
Finally come to Grails...  What a great framework....


On Tue, Jul 17, 2012 at 2:35 PM, Chris Polderman <[hidden email]> wrote:
Hi Jonathan,

Thank you for sharing your experiences with us. My experience is in large lines the same as yours: great when things work out of the box,  a puzzle when things don't.

In addition, I find the upgrade path quite troublesome.  I've jumped on the grails bandwagon since 1.3 and every release brings it's own challenges.

Mind you that I would not like to create j2ee apps using only java and some core libraries. Grails better suits my work I think...

Chris

Jonathan Rosenberg <[hidden email]>schreef:

>About 1.5 years ago I made the jump to Grails for new web apps.  I
>have been wanting to write a summary of my experience for a while now
>& I'm finally getting around to it.  Please don't take anything
>personally: this is meant in the spirit of making things better.
>
>Intro Notes
>
>1) I have a PhD in CS & over 35 years of programming experience.
>2) I had recently been programming for several years in PHP, initially
>without a framework and then with Zend.
>3) I did a lot of research before choosing Grails.
>4) I started with very little Java experience, a small amount of
>Groovy experience and no Java web app experience.
>5) At this time I am by no means a Grails expert, but I am certainly
>"Grails competent"
>
>The Good
>
>1) Groovy: cool language, feels very natural to me.  Java
>compatibility is a HUGE win.
>2) Spring integration: enough said
>3) GSPs, Sitemesh integration & tag libs: hits the sweet spot
>4) STS: excellent IDE integration.  A pleasure to use.
>5) Webflow: yes, Webflow has some nasty quirks and feels unpolished,
>but I love it.
>6) Directory/framework structure: I know this isn't unique to Grails
>but it works very well here.
>
>The Bad
>
>1) Hidden magic:  there is a ton of hidden runtime magic in Grails.
>This is no problem when things work out of the box, but I found it
>very hard to get my hands on the guts & tweak it.  Most of the magic
>seems to be undocumented, and is certainly unspecified.  So even if
>one reads the source code, it is risky to make use of what you find.
>I spent far too much time trying to modify things created
>automagically (e.g., Session Factory)..
>
>I really wish the magic (& hooks) were specified.
>
>2) Convention over configuration: yeah, this is GREAT when it works,
>but a nightmare when it doesn't. How many times have you spelled a
>service name incorrectly (when you wanted automatic DI)?  Or typed
>"constraitns" instead of "constraints"?  You only find out at runtime
>and the exceptions/problems that arise can be extremely difficult to
>track down.
>
>3) GORM: feels very awkward to me and I am constantly forgetting how
>to use belongsTo (which side gets this?) & other features.  I gave up
>and used Hibernate mappings in quite a few cases.
>
>4) This mailing list: A non-trivial percentage of questions that are
>posted are never answered, or get only partial answers.  It has gotten
>to the point where I typically don't bother posting a question, as I
>know I am so unlikely to get an answer.
>
>I know and appreciate that (almost) everyone here is a volunteer and
>the product is free.  I contrast this to the Tomcat user list, where I
>know I'll get help of I post a question.  This is a major frustration.
>
>The Bottom Line
>
>So, would I abandon Grails going forward?  I'm honestly not sure how I
>will build my next web app.  I'm not sure there's anything "better:"
>
>- Spring Roo, I don't know much about it.  And while programming in
>Java feels like going back to assembly language after Groory, I find
>the IDE-time type checking very useful.
>- Scala/Lift: I don't really feel like learning yet another language &
>Lift is pretty new, but it's not out of the question
>- Spring straight up: a possibility.  I'm quite comfortable with XML &
>everything is exposed ...
>
>That's all I have to say for now.  Responses, rants, etc. welcome.
>
>--
>Jonathan Rosenberg
>Founder &  Executive Director
>Tabby's Place, a Cat Sanctuary
>http://www.tabbysplace.org/
>
>---------------------------------------------------------------------
>To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

Reply | Threaded
Open this post in threaded view
|

RE: 1.5 Years with Garils: Thoughts

Ryan Vanderwerf
I too learned Grails without learning Spring first(I knew Struts and Guice though). I wish I had at least bought a Spring framework book first and read it, things would have made much more sense. I still find it's an easy framework for java-centric developers to pick up and be much more productive. I think the key is having access to someone in the office or nearby who is well versed with other developers that get 'stuck' on those puzzles (i.e. a typo in a domain class causes a puzzling error and app won't start). People on the the list have been generally helpful, especially Burt. Sometimes I think people don't respond because they honestly don't know the answer to your question, and people certainly (myself included) come up with some puzzling problems (that are very very hard to reproduce in a test project)!

Ryan
________________________________________
From: Gavin Yue [[hidden email]]
Sent: Tuesday, July 17, 2012 1:48 PM
To: [hidden email]
Subject: Re: [grails-user] 1.5 Years with Garils: Thoughts

My suggestion would be using Java EE first, then go to Spring/Hibernate.  You would feel world becomes better...
Finally come to Grails...  What a great framework....


On Tue, Jul 17, 2012 at 2:35 PM, Chris Polderman <[hidden email]<mailto:[hidden email]>> wrote:
Hi Jonathan,

Thank you for sharing your experiences with us. My experience is in large lines the same as yours: great when things work out of the box,  a puzzle when things don't.

In addition, I find the upgrade path quite troublesome.  I've jumped on the grails bandwagon since 1.3 and every release brings it's own challenges.

Mind you that I would not like to create j2ee apps using only java and some core libraries. Grails better suits my work I think...

Chris

Jonathan Rosenberg <[hidden email]<mailto:[hidden email]>>schreef:

>About 1.5 years ago I made the jump to Grails for new web apps.  I
>have been wanting to write a summary of my experience for a while now
>& I'm finally getting around to it.  Please don't take anything
>personally: this is meant in the spirit of making things better.
>
>Intro Notes
>
>1) I have a PhD in CS & over 35 years of programming experience.
>2) I had recently been programming for several years in PHP, initially
>without a framework and then with Zend.
>3) I did a lot of research before choosing Grails.
>4) I started with very little Java experience, a small amount of
>Groovy experience and no Java web app experience.
>5) At this time I am by no means a Grails expert, but I am certainly
>"Grails competent"
>
>The Good
>
>1) Groovy: cool language, feels very natural to me.  Java
>compatibility is a HUGE win.
>2) Spring integration: enough said
>3) GSPs, Sitemesh integration & tag libs: hits the sweet spot
>4) STS: excellent IDE integration.  A pleasure to use.
>5) Webflow: yes, Webflow has some nasty quirks and feels unpolished,
>but I love it.
>6) Directory/framework structure: I know this isn't unique to Grails
>but it works very well here.
>
>The Bad
>
>1) Hidden magic:  there is a ton of hidden runtime magic in Grails.
>This is no problem when things work out of the box, but I found it
>very hard to get my hands on the guts & tweak it.  Most of the magic
>seems to be undocumented, and is certainly unspecified.  So even if
>one reads the source code, it is risky to make use of what you find.
>I spent far too much time trying to modify things created
>automagically (e.g., Session Factory)..
>
>I really wish the magic (& hooks) were specified.
>
>2) Convention over configuration: yeah, this is GREAT when it works,
>but a nightmare when it doesn't. How many times have you spelled a
>service name incorrectly (when you wanted automatic DI)?  Or typed
>"constraitns" instead of "constraints"?  You only find out at runtime
>and the exceptions/problems that arise can be extremely difficult to
>track down.
>
>3) GORM: feels very awkward to me and I am constantly forgetting how
>to use belongsTo (which side gets this?) & other features.  I gave up
>and used Hibernate mappings in quite a few cases.
>
>4) This mailing list: A non-trivial percentage of questions that are
>posted are never answered, or get only partial answers.  It has gotten
>to the point where I typically don't bother posting a question, as I
>know I am so unlikely to get an answer.
>
>I know and appreciate that (almost) everyone here is a volunteer and
>the product is free.  I contrast this to the Tomcat user list, where I
>know I'll get help of I post a question.  This is a major frustration.
>
>The Bottom Line
>
>So, would I abandon Grails going forward?  I'm honestly not sure how I
>will build my next web app.  I'm not sure there's anything "better:"
>
>- Spring Roo, I don't know much about it.  And while programming in
>Java feels like going back to assembly language after Groory, I find
>the IDE-time type checking very useful.
>- Scala/Lift: I don't really feel like learning yet another language &
>Lift is pretty new, but it's not out of the question
>- Spring straight up: a possibility.  I'm quite comfortable with XML &
>everything is exposed ...
>
>That's all I have to say for now.  Responses, rants, etc. welcome.
>
>--
>Jonathan Rosenberg
>Founder &  Executive Director
>Tabby's Place, a Cat Sanctuary
>http://www.tabbysplace.org/
>
>---------------------------------------------------------------------
>To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: 1.5 Years with Garils: Thoughts

a.shneyderman
In reply to this post by Jonathan Rosenberg
Hi, Jonathan!

> 1) Hidden magic:  there is a ton of hidden runtime magic in Grails.
> This is no problem when things work out of the box, but I found it
> very hard to get my hands on the guts & tweak it.  Most of the magic
> seems to be undocumented, and is certainly unspecified.  So even if
> one reads the source code, it is risky to make use of what you find.
> I spent far too much time trying to modify things created
> automagically (e.g., Session Factory)..
>
> I really wish the magic (& hooks) were specified.

a good deal of it is documented.  But it is not possible to document all
of it. That is why grails being an open-source helps quite a bit. You open
up the hood and look what's underneath. If you want to stay a driver
do not bother if you want to become a mechanic then you will have to
open up the hood and look underneath - luckily there is no lock.

One thing I found frustrating though is the speed of changes. I find it
impossible to stay on top of all the changes that are happening. Not sure
though if this is a thing to feel bad about or be happy for. It also might be
me being slow - I gave up asking why, a long time ago.

> 2) Convention over configuration: yeah, this is GREAT when it works,
> but a nightmare when it doesn't. How many times have you spelled a
> service name incorrectly (when you wanted automatic DI)?  Or typed
> "constraitns" instead of "constraints"?  You only find out at runtime
> and the exceptions/problems that arise can be extremely difficult to
> track down.

this is a general problem of dynamic language not just Grails. The way
to remedy this is to get in a habit of writing tests. You write enough
of them you will have no problems with names.

> 3) GORM: feels very awkward to me and I am constantly forgetting how
> to use belongsTo (which side gets this?) & other features.  I gave up
> and used Hibernate mappings in quite a few cases.

Hibernate feels just as awkward to be honest. GORM is a mapping of
that awkwardness, IMO.

> 4) This mailing list: A non-trivial percentage of questions that are
> posted are never answered, or get only partial answers.  It has gotten
> to the point where I typically don't bother posting a question, as I
> know I am so unlikely to get an answer.

well I am sure you wil get plenty of responses to this mail :-)

Cheers and good luck with your next project,
Alex.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: 1.5 Years with Garils: Thoughts

Gert Wohlgemuth
I'm also working with grails since 1.3 and I love it. But have to
agree to a lot of these issues lined out. My biggest problem is still
that you can't assume that something works with 'grails 1.x' will work
with 'grails 1.x+1' and more often than not one plugin in use with
another completely breaks the system.

I do admit at the end of the day I do not want to remember how it was
to develop webpages before grails. It was just plain bad.

g.

On Tue, Jul 17, 2012 at 12:47 PM, Alex Shneyderman
<[hidden email]> wrote:

> Hi, Jonathan!
>
>> 1) Hidden magic:  there is a ton of hidden runtime magic in Grails.
>> This is no problem when things work out of the box, but I found it
>> very hard to get my hands on the guts & tweak it.  Most of the magic
>> seems to be undocumented, and is certainly unspecified.  So even if
>> one reads the source code, it is risky to make use of what you find.
>> I spent far too much time trying to modify things created
>> automagically (e.g., Session Factory)..
>>
>> I really wish the magic (& hooks) were specified.
>
> a good deal of it is documented.  But it is not possible to document all
> of it. That is why grails being an open-source helps quite a bit. You open
> up the hood and look what's underneath. If you want to stay a driver
> do not bother if you want to become a mechanic then you will have to
> open up the hood and look underneath - luckily there is no lock.
>
> One thing I found frustrating though is the speed of changes. I find it
> impossible to stay on top of all the changes that are happening. Not sure
> though if this is a thing to feel bad about or be happy for. It also might be
> me being slow - I gave up asking why, a long time ago.
>
>> 2) Convention over configuration: yeah, this is GREAT when it works,
>> but a nightmare when it doesn't. How many times have you spelled a
>> service name incorrectly (when you wanted automatic DI)?  Or typed
>> "constraitns" instead of "constraints"?  You only find out at runtime
>> and the exceptions/problems that arise can be extremely difficult to
>> track down.
>
> this is a general problem of dynamic language not just Grails. The way
> to remedy this is to get in a habit of writing tests. You write enough
> of them you will have no problems with names.
>
>> 3) GORM: feels very awkward to me and I am constantly forgetting how
>> to use belongsTo (which side gets this?) & other features.  I gave up
>> and used Hibernate mappings in quite a few cases.
>
> Hibernate feels just as awkward to be honest. GORM is a mapping of
> that awkwardness, IMO.
>
>> 4) This mailing list: A non-trivial percentage of questions that are
>> posted are never answered, or get only partial answers.  It has gotten
>> to the point where I typically don't bother posting a question, as I
>> know I am so unlikely to get an answer.
>
> well I am sure you wil get plenty of responses to this mail :-)
>
> Cheers and good luck with your next project,
> Alex.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>



--
------------------------------------------------------------
Lead Developer - Fiehnlab, UC Davis

gert wohlgemuth

work:
http://fiehnlab.ucdavis.edu/staff/wohlgemuth

phone:
530 665 9477

coding blog:
http://codingandmore.blogspot.com

linkedin:
http://www.linkedin.com/profile/view?id=28611299&trk=tab_pro

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: 1.5 Years with Garils: Thoughts

longwa
In some ways, I think Grails is trying to be too much too quickly and some of the core things just aren't getting a chance to mature. It's definitely frustrating to start using a feature only to find that it doesn't work in some case that is poorly documented. Grails 2.0 is especially bad about this with some of the new features like DetachedCriteria and the weird dichotomy, for example, that exists between those and Criteria.

That said, I think Grails is tackling a different set of problems than a comparable framework like Rails. Grails is having to act as the glue to bind together all these different frameworks, all with their own behaviors and issues. A lot of people (like us) are using Grails to replace legacy J2EE code because it fits well in our existing architecture. If we were using Rails for some of this stuff, we'd be stretching it pretty thin as well and I'm sure we'd be finding issues.

-Aaron

On Tue, Jul 17, 2012 at 4:04 PM, wohlgemuth <[hidden email]> wrote:
I'm also working with grails since 1.3 and I love it. But have to
agree to a lot of these issues lined out. My biggest problem is still
that you can't assume that something works with 'grails 1.x' will work
with 'grails 1.x+1' and more often than not one plugin in use with
another completely breaks the system.

I do admit at the end of the day I do not want to remember how it was
to develop webpages before grails. It was just plain bad.

g.

On Tue, Jul 17, 2012 at 12:47 PM, Alex Shneyderman
<[hidden email]> wrote:
> Hi, Jonathan!
>
>> 1) Hidden magic:  there is a ton of hidden runtime magic in Grails.
>> This is no problem when things work out of the box, but I found it
>> very hard to get my hands on the guts & tweak it.  Most of the magic
>> seems to be undocumented, and is certainly unspecified.  So even if
>> one reads the source code, it is risky to make use of what you find.
>> I spent far too much time trying to modify things created
>> automagically (e.g., Session Factory)..
>>
>> I really wish the magic (& hooks) were specified.
>
> a good deal of it is documented.  But it is not possible to document all
> of it. That is why grails being an open-source helps quite a bit. You open
> up the hood and look what's underneath. If you want to stay a driver
> do not bother if you want to become a mechanic then you will have to
> open up the hood and look underneath - luckily there is no lock.
>
> One thing I found frustrating though is the speed of changes. I find it
> impossible to stay on top of all the changes that are happening. Not sure
> though if this is a thing to feel bad about or be happy for. It also might be
> me being slow - I gave up asking why, a long time ago.
>
>> 2) Convention over configuration: yeah, this is GREAT when it works,
>> but a nightmare when it doesn't. How many times have you spelled a
>> service name incorrectly (when you wanted automatic DI)?  Or typed
>> "constraitns" instead of "constraints"?  You only find out at runtime
>> and the exceptions/problems that arise can be extremely difficult to
>> track down.
>
> this is a general problem of dynamic language not just Grails. The way
> to remedy this is to get in a habit of writing tests. You write enough
> of them you will have no problems with names.
>
>> 3) GORM: feels very awkward to me and I am constantly forgetting how
>> to use belongsTo (which side gets this?) & other features.  I gave up
>> and used Hibernate mappings in quite a few cases.
>
> Hibernate feels just as awkward to be honest. GORM is a mapping of
> that awkwardness, IMO.
>
>> 4) This mailing list: A non-trivial percentage of questions that are
>> posted are never answered, or get only partial answers.  It has gotten
>> to the point where I typically don't bother posting a question, as I
>> know I am so unlikely to get an answer.
>
> well I am sure you wil get plenty of responses to this mail :-)
>
> Cheers and good luck with your next project,
> Alex.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>



--
------------------------------------------------------------
Lead Developer - Fiehnlab, UC Davis

gert wohlgemuth

work:
http://fiehnlab.ucdavis.edu/staff/wohlgemuth

phone:
<a href="tel:530%20665%209477" value="+15306659477">530 665 9477

coding blog:
http://codingandmore.blogspot.com

linkedin:
http://www.linkedin.com/profile/view?id=28611299&trk=tab_pro

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: 1.5 Years with Garils: Thoughts

Sebastian Gozin
In reply to this post by Jonathan Rosenberg
My advice would be to not expect (hope?) for Grails or any other framework for that matter to solve your problems for you. It is inherently unable to. Though Grails like other new generation frameworks such as rails, roo, play does remove a lot of the complexity inherent in Java based web applications.

Instead focus on TDD and clean code. Solve your problems without Grails first. Then just use Grails to expose the functionality as web services or a set of dumb controller+JSP+taglibs. Implement your persistence layer with one of the many GORM plugins. Stuff like that is much easier if you know your core system already works.

At the risk of sounding like that crazy, annoying, non-pragmatic, zealot who clearly hasn't written a whole heck of a lot of code in his life.

Most of the questions on this mail list are a mix of many different problems mixed together. I have enough of those to deal with at the customer's where not everyone practices TDD. And there as well I have great trouble solving them.
I suspect the same is true for everyone else so incomplete solutions and suggestions may not be strange. It would help a lot at least if people simply had 1 problem instead of 10 at a time.

- Sebastian


On 17 Jul 2012, at 20:21, Jonathan Rosenberg wrote:

> About 1.5 years ago I made the jump to Grails for new web apps.  I
> have been wanting to write a summary of my experience for a while now
> & I'm finally getting around to it.  Please don't take anything
> personally: this is meant in the spirit of making things better.
>
> Intro Notes
>
> 1) I have a PhD in CS & over 35 years of programming experience.
> 2) I had recently been programming for several years in PHP, initially
> without a framework and then with Zend.
> 3) I did a lot of research before choosing Grails.
> 4) I started with very little Java experience, a small amount of
> Groovy experience and no Java web app experience.
> 5) At this time I am by no means a Grails expert, but I am certainly
> "Grails competent"
>
> The Good
>
> 1) Groovy: cool language, feels very natural to me.  Java
> compatibility is a HUGE win.
> 2) Spring integration: enough said
> 3) GSPs, Sitemesh integration & tag libs: hits the sweet spot
> 4) STS: excellent IDE integration.  A pleasure to use.
> 5) Webflow: yes, Webflow has some nasty quirks and feels unpolished,
> but I love it.
> 6) Directory/framework structure: I know this isn't unique to Grails
> but it works very well here.
>
> The Bad
>
> 1) Hidden magic:  there is a ton of hidden runtime magic in Grails.
> This is no problem when things work out of the box, but I found it
> very hard to get my hands on the guts & tweak it.  Most of the magic
> seems to be undocumented, and is certainly unspecified.  So even if
> one reads the source code, it is risky to make use of what you find.
> I spent far too much time trying to modify things created
> automagically (e.g., Session Factory)..
>
> I really wish the magic (& hooks) were specified.
>
> 2) Convention over configuration: yeah, this is GREAT when it works,
> but a nightmare when it doesn't. How many times have you spelled a
> service name incorrectly (when you wanted automatic DI)?  Or typed
> "constraitns" instead of "constraints"?  You only find out at runtime
> and the exceptions/problems that arise can be extremely difficult to
> track down.
>
> 3) GORM: feels very awkward to me and I am constantly forgetting how
> to use belongsTo (which side gets this?) & other features.  I gave up
> and used Hibernate mappings in quite a few cases.
>
> 4) This mailing list: A non-trivial percentage of questions that are
> posted are never answered, or get only partial answers.  It has gotten
> to the point where I typically don't bother posting a question, as I
> know I am so unlikely to get an answer.
>
> I know and appreciate that (almost) everyone here is a volunteer and
> the product is free.  I contrast this to the Tomcat user list, where I
> know I'll get help of I post a question.  This is a major frustration.
>
> The Bottom Line
>
> So, would I abandon Grails going forward?  I'm honestly not sure how I
> will build my next web app.  I'm not sure there's anything "better:"
>
> - Spring Roo, I don't know much about it.  And while programming in
> Java feels like going back to assembly language after Groory, I find
> the IDE-time type checking very useful.
> - Scala/Lift: I don't really feel like learning yet another language &
> Lift is pretty new, but it's not out of the question
> - Spring straight up: a possibility.  I'm quite comfortable with XML &
> everything is exposed ...
>
> That's all I have to say for now.  Responses, rants, etc. welcome.
>
> --
> Jonathan Rosenberg
> Founder &  Executive Director
> Tabby's Place, a Cat Sanctuary
> http://www.tabbysplace.org/
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: 1.5 Years with Garils: Thoughts

Gary Affonso
In reply to this post by Jonathan Rosenberg
This is month 4 for me (after a lot of experience developing apps with JSP (or Freemarker or Velocity), Struts, Spring, Hibernate, etc.).  comments inline below...

On Jul 17, 2012, at 11:21 AM, Jonathan Rosenberg wrote:

> 1) Groovy: cool language, feels very natural to me.  Java
> compatibility is a HUGE win.

Groovy is what has kept me *away* from Grails for a couple of years.  I just didn't see the point in learning yet another JVM language when there are so many out there.  What's wrong with Java (my pre-Grails self, thought)?

Now that I'm here in Grails, I find Groovy to be a HUGE advantage in the GSP.  I think this is where it really, really, shines.  SO much better than the various template and expression languages that have been used in JSP (EL, etc) and/or Struts (OGNL).

Groovy is a decent win for the domain objects (things like the ability to easily add toString implementations is really cool).  But I do have to say that "Groovy" Domain objects drive me batshit crazy by requiring me to keep 3 (3!) separate lists of my properties (the property declaration, the constraints, and the mappings).  I'm not a huge fan of annotations, but this is better?

I find Groovy pretty cool for the controllers.  The auto-DI is nice.  And Groovy is great for parameter processing, IMO.

I don't find Groovy particularly helpful for the service layer.  Not sure if I think it's an advantage.  I'm still on the fence here.  Java (and strong type checking) just feels safer here for writing bulletproof service methods.

> 2) Spring integration: enough said

Agreed.

> 3) GSPs, Sitemesh integration & tag libs: hits the sweet spot

Agree.

> 4) STS: excellent IDE integration.  A pleasure to use.

STS is great.  Particularly for the price.  I shifted to IntelliJ last month and I have not looked backed.  IntelliJ is way better for grails development, IMO.

> 6) Directory/framework structure: I know this isn't unique to Grails
> but it works very well here.

Agreed.  I've spent days on past projects just setting up the project structure, build-environemtn, getting libraries downloaded (and conflicts resolved), etc.  It's really, really nice to have Grails lay that all out.

> 2) Convention over configuration: yeah, this is GREAT when it works,
> but a nightmare when it doesn't. How many times have you spelled a
> service name incorrectly (when you wanted automatic DI)?  Or typed
> "constraitns" instead of "constraints"?  You only find out at runtime
> and the exceptions/problems that arise can be extremely difficult to
> track down.

I haven't had much problem with this.  IntelliJ really helps, it understands many of the Grails/Groovy-ish things.  Your "constraitns" example above is something IntelliJ will notice.  Doesn't give you an error, exactly, but it's syntax coloring makes it obvious that something weird has happened.

> 3) GORM: feels very awkward to me and I am constantly forgetting how
> to use belongsTo (which side gets this?) & other features.  I gave up
> and used Hibernate mappings in quite a few cases.

Completely agree.  Hibernate is enough of a semi-necessary evil.  I know GORM tries to make Hibernate easier (and is a nod to Rails) but I find that for anything beyond simple cases, GORM just complicates and confuses an already complicated and confusing task. (I agree, the belongsTo subtleties are not cool).

> 4) This mailing list: A non-trivial percentage of questions that are
> posted are never answered, or get only partial answers.  It has gotten
> to the point where I typically don't bother posting a question, as I
> know I am so unlikely to get an answer.

> I know and appreciate that (almost) everyone here is a volunteer and
> the product is free.  I contrast this to the Tomcat user list, where I
> know I'll get help of I post a question.  This is a major frustration.

Completely agree.  Wayyyy back in 2006, I started using WebWork (which became Struts 2).  It was a similarly small user community at the time but the support list was absolutely stellar.  Thank you Partrick Lightbody and friends.

There are a few notable standouts here (Burt and Ian come to mind) but, for the most part, support via this list sucks.  The fact that this is an OpenSource project is not an excuse.  webwork-users was awesome.  This could (and should) be too.

For my part, I try to answer one question for every question I ask.  The tough part is that I'm still so new that many questions are just not something I can help with.

The fact that the docs are so incomplete just makes the situation worse.  Things that should be well doc'd (like how to control the sort order of lists retrieved by navigating an association such as author.books) should be doc'd dammit!  That's just one of a many, many examples of missing docs.

If I was grading Grails, It'd get a D+/C- for docs and support.

Now, let me confess I have not yet bought a Grails book.  I jumped on the Grails bandwagon at 2.0.1 and most of the books out all seem to be for version < 2.  If there's a great Grails 2 book, I'd love to hear about it.

>

Can I also add #5)

DSLs suck.

Yes, I said it.

Grails is lousy with DSLs...

  CriteriaQueries
  Log4J configuration
  Liquibase changesets
  etc…

Why?  Why is a DSL better than the "native" configuration or code it "wraps"?

CriteriaQueries are not better served by the DSL, IMO.   Not more clear, than just constructing a Hibernate criteria query.  More terse, yes, but who needs another layer of a poorly documented DSL "language" on top of an already complicated API?  Not being able to see the underlying code or config that the DSL generates makes trying to debug DSL problems really hard.  And DSLs sometimes limit the underlying functionality they "wrap" (you cannot do correlated subqueries via a DSL-wrapped hibernate criteria query, you can easily do them via a hand-constructed hibernate query).

For other things (like Log4J, or for liquibase change sets, specifically) I like the XML just fine.  Certainly better than a DSL wherein I have to guess how the DSL translates into the underlying XML.

I could see the argument that DSLs were better if they had "type safe" compile-time-checked references.  That *would* make them handier than native configs (like XML).  Things like bad field-references would be checked in the IDE.   But in the criteria DSL, for example, you end up just quoting a bunch of field names that could (potentially) be a compile-time-checked reference.  So the "checked-references" argument in favor of of that particular DSL is lost (for me) if it's not consistently implemented throughout.

The one thing I do like about the DSLs is that they offer conditional or looped sections in the configs.  That's good.  But can't we get there without an entire DSL "wrapper" around things?  Maybe something more "template" like instead (like the native xml-config but supporting looping and conditional constructs)?

The fact that DSLs are so poorly documented is a real productivity killer for me, too.  I cannot tell you how many times I've painstakingly tried to construct a Liquibase change set via the DSL language and then just punted and used the straight Liquibase XML.  There seems to be this idea (I've seen it posted to this list) that the DSLs should be "self-documenting" because they're just a "thin wrapper" around the underlying native config.  I don't buy it.  I've spent a lot of time trying to figure out the DSL-syntax that will generate the XML I want for a liquibase change set.

Wrapping things like Hibernate Criteria Queries or Liquibase Changesets in DSLs also kills (or maims) your ability to use web-search to get your answer.  There are a lot of answers and examples via google for how to do all kinds of stuff with Hibernate Criteria Queries or Liquibase Changesets.  Near-zero answers for how to do those things via a Grails' DSL wrapper around those technologies.  This is a *really* frustrating aspect of Grails.  I know how to do what I want!  I have the example from the web!  I know Grails uses the same underlying technology!  But I can't figure out how to get the damn DSL to generate what I want.  Feh.

And 6#)  Scaffolded Views

Scaffolding for Views is nearly worthless for me as a production feature.  It flat-out doesn't work with Domain classes containing more than just a few properties.  And if you want to customize the UI to *any* significant degree, you're better off just rolling your own views, IMO.  And the fact that it has such a heavy presence in the web-app assets directories (littering and re-littering it with css, images, and js I don't ever use) is just irritating.

I do like the controller-generation.  I use those as my starting point.  That's good, generic staring code, IMO.

The one HUGE benefit of scaffolded Views is that it's sometimes the best (and only) "documentation" for the "right way" to do things in Controllers and Views.  But that's just sad.  :-(

> The Bottom Line
>
> So, would I abandon Grails going forward?  I'm honestly not sure how I
> will build my next web app.  I'm not sure there's anything "better:"
>
> - Spring Roo, I don't know much about it.  And while programming in
> Java feels like going back to assembly language after Groory, I find
> the IDE-time type checking very useful.
> - Scala/Lift: I don't really feel like learning yet another language &
> Lift is pretty new, but it's not out of the question
> - Spring straight up: a possibility.  I'm quite comfortable with XML &
> everything is exposed …

I also did a lot of research before choosing Grails.  Evaluated the last two on your list (along with a variety of other options such as rails, scala/lift, etc.).  I think Grails has a lot going for it.  But overall, I'm kind of disappointed.  I approached Grails with the idea that much of my previous Spring and Hibernate experience would transfer.  Certainly all the *concepts* transfer.  Grails embeds the notions of Domain Objects, Controllers, Services, View, Configuration, Unit Tests, Integration Tests (!!), etc. right in the project structure.  Something you have to setup by hand with the various other java-based choices (and many of the non-java ones).

But other than the concepts, Grails has been mostly a LOT of new ground: groovy (the language), GORM (particularly Domain mapping and criteria querying), DSL wrappers around things I already know how to do, Controllers, views (particularly resource loading), etc.

The nice thing about Grails is that I still like it better than everything else.  I think it's got the right idea, in general:  Take a solid, proven, scalable ingredients (n-tier architecture, java, spring, hibernate, liquibase, etc.), mix it together, frost with convention over config and bam! you've got a tasty cake.

Where I think Grails gets it wrong is where it hides the underlying tools unnecessarily (the DSLs) or where it tries to innovate conceptually (GORM's rails-inspired mappings).

The one "innovation" I have to give it props for is Groovy in the .gsp views.  I have never, ever, used a view-technology better than .gsp.  (I've done projects with view technologies that have included Perl, ASP, Cold Fusion, JSP, Freemarker, Velocity and EL, UEL, OGNL, and MVEL.)  Grails' groovy-based .gsp pages are awesome.


---

In the end, I think it comes down to the fact that I still believe there's no better out-of-the-box framework than Grails.  It's got a lot of warts still but that's just another word for opportunity.

So while I gave Grails a barely passing grade of D+/C- for support and docs, I think overall Grails gets a solid B.  I've got some choices for my next project, I think it's going to be Grails again unless something else becomes more compelling.  But I will no longer be doing Criteria Queries of any complexity via the DSL, (I'll just code them by hand), I will be extra wary of Grails View scaffolding and how it mucks with my web-app assets (css, images, and js) and I'll continue to try to provide some support back to this list in the hopes that everyone else will try to do the same.

Thanks, Jonathan for inspiring this rant.  Been meaning to blog something similar for awhile.

- Gary
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: 1.5 Years with Garils: Thoughts

Jonathan Rosenberg-2
In reply to this post by Sebastian Gozin
Sebastian,

I'm very interested in the following suggestions:

"Solve your problems first."

Jonathan Rosenberg
Founder & Executive Director
Tabby's Place, a Cat Sanctuary
http://www.tabbysplace.org/


On Jul 17, 2012, at 5:52 PM, Sebastian Gozin <[hidden email]> wrote:

> My advice would be to not expect (hope?) for Grails or any other framework for that matter to solve your problems for you. It is inherently unable to. Though Grails like other new generation frameworks such as rails, roo, play does remove a lot of the complexity inherent in Java based web applications.
>
> Instead focus on TDD and clean code. Solve your problems without Grails first. Then just use Grails to expose the functionality as web services or a set of dumb controller+JSP+taglibs. Implement your persistence layer with one of the many GORM plugins. Stuff like that is much easier if you know your core system already works.
>
> At the risk of sounding like that crazy, annoying, non-pragmatic, zealot who clearly hasn't written a whole heck of a lot of code in his life.
>
> Most of the questions on this mail list are a mix of many different problems mixed together. I have enough of those to deal with at the customer's where not everyone practices TDD. And there as well I have great trouble solving them.
> I suspect the same is true for everyone else so incomplete solutions and suggestions may not be strange. It would help a lot at least if people simply had 1 problem instead of 10 at a time.
>
> - Sebastian
>
>
> On 17 Jul 2012, at 20:21, Jonathan Rosenberg wrote:
>
>> About 1.5 years ago I made the jump to Grails for new web apps.  I
>> have been wanting to write a summary of my experience for a while now
>> & I'm finally getting around to it.  Please don't take anything
>> personally: this is meant in the spirit of making things better.
>>
>> Intro Notes
>>
>> 1) I have a PhD in CS & over 35 years of programming experience.
>> 2) I had recently been programming for several years in PHP, initially
>> without a framework and then with Zend.
>> 3) I did a lot of research before choosing Grails.
>> 4) I started with very little Java experience, a small amount of
>> Groovy experience and no Java web app experience.
>> 5) At this time I am by no means a Grails expert, but I am certainly
>> "Grails competent"
>>
>> The Good
>>
>> 1) Groovy: cool language, feels very natural to me.  Java
>> compatibility is a HUGE win.
>> 2) Spring integration: enough said
>> 3) GSPs, Sitemesh integration & tag libs: hits the sweet spot
>> 4) STS: excellent IDE integration.  A pleasure to use.
>> 5) Webflow: yes, Webflow has some nasty quirks and feels unpolished,
>> but I love it.
>> 6) Directory/framework structure: I know this isn't unique to Grails
>> but it works very well here.
>>
>> The Bad
>>
>> 1) Hidden magic:  there is a ton of hidden runtime magic in Grails.
>> This is no problem when things work out of the box, but I found it
>> very hard to get my hands on the guts & tweak it.  Most of the magic
>> seems to be undocumented, and is certainly unspecified.  So even if
>> one reads the source code, it is risky to make use of what you find.
>> I spent far too much time trying to modify things created
>> automagically (e.g., Session Factory)..
>>
>> I really wish the magic (& hooks) were specified.
>>
>> 2) Convention over configuration: yeah, this is GREAT when it works,
>> but a nightmare when it doesn't. How many times have you spelled a
>> service name incorrectly (when you wanted automatic DI)?  Or typed
>> "constraitns" instead of "constraints"?  You only find out at runtime
>> and the exceptions/problems that arise can be extremely difficult to
>> track down.
>>
>> 3) GORM: feels very awkward to me and I am constantly forgetting how
>> to use belongsTo (which side gets this?) & other features.  I gave up
>> and used Hibernate mappings in quite a few cases.
>>
>> 4) This mailing list: A non-trivial percentage of questions that are
>> posted are never answered, or get only partial answers.  It has gotten
>> to the point where I typically don't bother posting a question, as I
>> know I am so unlikely to get an answer.
>>
>> I know and appreciate that (almost) everyone here is a volunteer and
>> the product is free.  I contrast this to the Tomcat user list, where I
>> know I'll get help of I post a question.  This is a major frustration.
>>
>> The Bottom Line
>>
>> So, would I abandon Grails going forward?  I'm honestly not sure how I
>> will build my next web app.  I'm not sure there's anything "better:"
>>
>> - Spring Roo, I don't know much about it.  And while programming in
>> Java feels like going back to assembly language after Groory, I find
>> the IDE-time type checking very useful.
>> - Scala/Lift: I don't really feel like learning yet another language &
>> Lift is pretty new, but it's not out of the question
>> - Spring straight up: a possibility.  I'm quite comfortable with XML &
>> everything is exposed ...
>>
>> That's all I have to say for now.  Responses, rants, etc. welcome.
>>
>> --
>> Jonathan Rosenberg
>> Founder &  Executive Director
>> Tabby's Place, a Cat Sanctuary
>> http://www.tabbysplace.org/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>   http://xircles.codehaus.org/manage_email
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: 1.5 Years with Garils: Thoughts

rlovtangen
In reply to this post by Jonathan Rosenberg

On Jul 17, 2012, at 8:21 PM, Jonathan Rosenberg wrote:

>
> 4) This mailing list: A non-trivial percentage of questions that are
> posted are never answered, or get only partial answers.  It has gotten
> to the point where I typically don't bother posting a question, as I
> know I am so unlikely to get an answer.
>
> I know and appreciate that (almost) everyone here is a volunteer and
> the product is free.  I contrast this to the Tomcat user list, where I
> know I'll get help of I post a question.  This is a major frustration.
>

This frustrates me a bit as well. Looking at the questions I've posted this year, half of them can be marked as solved. It would be close to zero if it hadn't been for a core group of people (mostly Burt Beckwith, Peter Ledbrook, Ian Roberts, Marc Palmer and Graeme Rocher. Thanks a lot!)
It might be because after three years of using Grails, the stuff I run into is not the most trivial stuff, and often requires the knowledge of those developing Grails itself, especially someone that can give insight on how stuff are supposed to work when the documentation is ambiguous or missing. An example to this would be http://grails.1312388.n4.nabble.com/integration-tests-in-Grails-2-0-td4630370.html


On Jul 17, 2012, at 11:20 PM, Aaron Long wrote:

> In some ways, I think Grails is trying to be too much too quickly and some of the core things just aren't getting a chance to mature. It's definitely frustrating to start using a feature only to find that it doesn't work in some case that is poorly documented. Grails 2.0 is especially bad about this with some of the new features like DetachedCriteria and the weird dichotomy, for example, that exists between those and Criteria.

I wish there would be a 3 month period without adding new features, but rather fighting the big backlog in Jira and let things mature. While I really, really love Grails, and wouldn't use anything else, I've never run into so many issues in any other framework I've used in the past. It's also kind of demotivating to file bugs when you know they probably never will be handled or even get a response. If I can figure out the problem myself, I send a pull request as well, but that's not always the case. Sometimes it also requires some decision making on how things should work.
The documentation is really great IMO, but it has too many missing pieces. Whenever a new feature is added to Grails, it should make it into the docs immediately. The good thing is that it's really easy to contribute to the documentation. And I'm looking forward to Burts new book!

Ronny


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: 1.5 Years with Garils: Thoughts

Jonathan Rosenberg-2
In reply to this post by a.shneyderman
Alex,

Thanks for the thoughts.

>> I really wish the magic (& hooks) were specified.

> a good deal of it is documented.

I would love to know where this documentation is.  For example, where is the doc that explains when/how the SessionFactory is created and how I can hook into it to modify its properties?

> But it is not possible to document all of it.

Well that's just silly, Of course, it's possible.  Not fun, mind you, but possible.

--
Jonathan Rosenberg
Founder & Executive Director
Tabby's Place, a Cat Sanctuary
http://www.tabbysplace.org/


On Jul 17, 2012, at 3:47 PM, Alex Shneyderman <[hidden email]> wrote:

> Hi, Jonathan!
>
>> 1) Hidden magic:  there is a ton of hidden runtime magic in Grails.
>> This is no problem when things work out of the box, but I found it
>> very hard to get my hands on the guts & tweak it.  Most of the magic
>> seems to be undocumented, and is certainly unspecified.  So even if
>> one reads the source code, it is risky to make use of what you find.
>> I spent far too much time trying to modify things created
>> automagically (e.g., Session Factory)..
>>
>> I really wish the magic (& hooks) were specified.
>
> a good deal of it is documented.  But it is not possible to document all
> of it. That is why grails being an open-source helps quite a bit. You open
> up the hood and look what's underneath. If you want to stay a driver
> do not bother if you want to become a mechanic then you will have to
> open up the hood and look underneath - luckily there is no lock.
>
> One thing I found frustrating though is the speed of changes. I find it
> impossible to stay on top of all the changes that are happening. Not sure
> though if this is a thing to feel bad about or be happy for. It also might be
> me being slow - I gave up asking why, a long time ago.
>
>> 2) Convention over configuration: yeah, this is GREAT when it works,
>> but a nightmare when it doesn't. How many times have you spelled a
>> service name incorrectly (when you wanted automatic DI)?  Or typed
>> "constraitns" instead of "constraints"?  You only find out at runtime
>> and the exceptions/problems that arise can be extremely difficult to
>> track down.
>
> this is a general problem of dynamic language not just Grails. The way
> to remedy this is to get in a habit of writing tests. You write enough
> of them you will have no problems with names.
>
>> 3) GORM: feels very awkward to me and I am constantly forgetting how
>> to use belongsTo (which side gets this?) & other features.  I gave up
>> and used Hibernate mappings in quite a few cases.
>
> Hibernate feels just as awkward to be honest. GORM is a mapping of
> that awkwardness, IMO.
>
>> 4) This mailing list: A non-trivial percentage of questions that are
>> posted are never answered, or get only partial answers.  It has gotten
>> to the point where I typically don't bother posting a question, as I
>> know I am so unlikely to get an answer.
>
> well I am sure you wil get plenty of responses to this mail :-)
>
> Cheers and good luck with your next project,
> Alex.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: 1.5 Years with Garils: Thoughts

Jordon Saardchit
In reply to this post by rlovtangen
I would also like to preface my 2 cents with "I adore the framework".  Like most of the others who chimed in, "I'd certainly not rather not go back to pure java webapps".  However, I must agree the aggresive release schedule for grails core can be very cumbersome.  Its really impractical to attempt to keep up with each release.  I guess my question really is why not make greater use of the plugin architecture (which is fabulous btw) for rapidly moving feature sets while allowing the core framework to mature and stabilize.  I had originally thought this was one of the driving forces behind the plugin architecture.  Example, removing webflow from grails core.  Just a thought, but I also, have faced challenges when attempting to keep up with the framework's release schedule.

Jordon

On Jul 17, 2012, at 4:03 PM, Ronny Løvtangen wrote:

>
> On Jul 17, 2012, at 8:21 PM, Jonathan Rosenberg wrote:
>>
>> 4) This mailing list: A non-trivial percentage of questions that are
>> posted are never answered, or get only partial answers.  It has gotten
>> to the point where I typically don't bother posting a question, as I
>> know I am so unlikely to get an answer.
>>
>> I know and appreciate that (almost) everyone here is a volunteer and
>> the product is free.  I contrast this to the Tomcat user list, where I
>> know I'll get help of I post a question.  This is a major frustration.
>>
>
> This frustrates me a bit as well. Looking at the questions I've posted this year, half of them can be marked as solved. It would be close to zero if it hadn't been for a core group of people (mostly Burt Beckwith, Peter Ledbrook, Ian Roberts, Marc Palmer and Graeme Rocher. Thanks a lot!)
> It might be because after three years of using Grails, the stuff I run into is not the most trivial stuff, and often requires the knowledge of those developing Grails itself, especially someone that can give insight on how stuff are supposed to work when the documentation is ambiguous or missing. An example to this would be http://grails.1312388.n4.nabble.com/integration-tests-in-Grails-2-0-td4630370.html
>
>
> On Jul 17, 2012, at 11:20 PM, Aaron Long wrote:
>
>> In some ways, I think Grails is trying to be too much too quickly and some of the core things just aren't getting a chance to mature. It's definitely frustrating to start using a feature only to find that it doesn't work in some case that is poorly documented. Grails 2.0 is especially bad about this with some of the new features like DetachedCriteria and the weird dichotomy, for example, that exists between those and Criteria.
>
> I wish there would be a 3 month period without adding new features, but rather fighting the big backlog in Jira and let things mature. While I really, really love Grails, and wouldn't use anything else, I've never run into so many issues in any other framework I've used in the past. It's also kind of demotivating to file bugs when you know they probably never will be handled or even get a response. If I can figure out the problem myself, I send a pull request as well, but that's not always the case. Sometimes it also requires some decision making on how things should work.
> The documentation is really great IMO, but it has too many missing pieces. Whenever a new feature is added to Grails, it should make it into the docs immediately. The good thing is that it's really easy to contribute to the documentation. And I'm looking forward to Burts new book!
>
> Ronny
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: 1.5 Years with Garils: Thoughts

Nathan Wells
If I had to sum up my opinion it would be:

"Yeah, features are great - they make it so I have to code less. But you can't give me too much stability/reliability/documentation/support - it's these that make me worry less"

Now that I've gotten the negative out of the way... There's no way I would choose anything other than Grails for a Java webapp. You guys have just made it too dang easy to show results quickly. GSP/Taglibs is a godsend. The Controller/Service model is insanely helpful. i18n is drop-dead simple. Spock makes testing fun again (I understand this isn't grails-proper, but let that serve as an exclamation point on Jordan's point about plugins over "built-ins"). Even ancillary stuff like Codecs are pretty sweet.

But seriously, I gotta have more cowbell!


Nathan Wells


On Tue, Jul 17, 2012 at 5:22 PM, Jordon Saardchit <[hidden email]> wrote:
I would also like to preface my 2 cents with "I adore the framework".  Like most of the others who chimed in, "I'd certainly not rather not go back to pure java webapps".  However, I must agree the aggresive release schedule for grails core can be very cumbersome.  Its really impractical to attempt to keep up with each release.  I guess my question really is why not make greater use of the plugin architecture (which is fabulous btw) for rapidly moving feature sets while allowing the core framework to mature and stabilize.  I had originally thought this was one of the driving forces behind the plugin architecture.  Example, removing webflow from grails core.  Just a thought, but I also, have faced challenges when attempting to keep up with the framework's release schedule.

Jordon

On Jul 17, 2012, at 4:03 PM, Ronny Løvtangen wrote:

>
> On Jul 17, 2012, at 8:21 PM, Jonathan Rosenberg wrote:
>>
>> 4) This mailing list: A non-trivial percentage of questions that are
>> posted are never answered, or get only partial answers.  It has gotten
>> to the point where I typically don't bother posting a question, as I
>> know I am so unlikely to get an answer.
>>
>> I know and appreciate that (almost) everyone here is a volunteer and
>> the product is free.  I contrast this to the Tomcat user list, where I
>> know I'll get help of I post a question.  This is a major frustration.
>>
>
> This frustrates me a bit as well. Looking at the questions I've posted this year, half of them can be marked as solved. It would be close to zero if it hadn't been for a core group of people (mostly Burt Beckwith, Peter Ledbrook, Ian Roberts, Marc Palmer and Graeme Rocher. Thanks a lot!)
> It might be because after three years of using Grails, the stuff I run into is not the most trivial stuff, and often requires the knowledge of those developing Grails itself, especially someone that can give insight on how stuff are supposed to work when the documentation is ambiguous or missing. An example to this would be http://grails.1312388.n4.nabble.com/integration-tests-in-Grails-2-0-td4630370.html
>
>
> On Jul 17, 2012, at 11:20 PM, Aaron Long wrote:
>
>> In some ways, I think Grails is trying to be too much too quickly and some of the core things just aren't getting a chance to mature. It's definitely frustrating to start using a feature only to find that it doesn't work in some case that is poorly documented. Grails 2.0 is especially bad about this with some of the new features like DetachedCriteria and the weird dichotomy, for example, that exists between those and Criteria.
>
> I wish there would be a 3 month period without adding new features, but rather fighting the big backlog in Jira and let things mature. While I really, really love Grails, and wouldn't use anything else, I've never run into so many issues in any other framework I've used in the past. It's also kind of demotivating to file bugs when you know they probably never will be handled or even get a response. If I can figure out the problem myself, I send a pull request as well, but that's not always the case. Sometimes it also requires some decision making on how things should work.
> The documentation is really great IMO, but it has too many missing pieces. Whenever a new feature is added to Grails, it should make it into the docs immediately. The good thing is that it's really easy to contribute to the documentation. And I'm looking forward to Burts new book!
>
> Ronny
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: 1.5 Years with Garils: Thoughts

Graeme Rocher
Administrator
Great feedback all, it is interesting you guys would prefer less
features and fewer major releases. That may be something we should
consider when adding new features to core. We certainly should be
delivering a smaller core and more via plugins.

Cheers

On Wed, Jul 18, 2012 at 1:45 AM, Nathan Wells <[hidden email]> wrote:

> If I had to sum up my opinion it would be:
>
> "Yeah, features are great - they make it so I have to code less. But you
> can't give me too much stability/reliability/documentation/support - it's
> these that make me worry less"
>
> Now that I've gotten the negative out of the way... There's no way I would
> choose anything other than Grails for a Java webapp. You guys have just made
> it too dang easy to show results quickly. GSP/Taglibs is a godsend. The
> Controller/Service model is insanely helpful. i18n is drop-dead simple.
> Spock makes testing fun again (I understand this isn't grails-proper, but
> let that serve as an exclamation point on Jordan's point about plugins over
> "built-ins"). Even ancillary stuff like Codecs are pretty sweet.
>
> But seriously, I gotta have more cowbell!
>
> (for the uninitiated: http://en.wikipedia.org/wiki/More_cowbell)
>
> Nathan Wells
>
>
>
> On Tue, Jul 17, 2012 at 5:22 PM, Jordon Saardchit <[hidden email]>
> wrote:
>>
>> I would also like to preface my 2 cents with "I adore the framework".
>> Like most of the others who chimed in, "I'd certainly not rather not go back
>> to pure java webapps".  However, I must agree the aggresive release schedule
>> for grails core can be very cumbersome.  Its really impractical to attempt
>> to keep up with each release.  I guess my question really is why not make
>> greater use of the plugin architecture (which is fabulous btw) for rapidly
>> moving feature sets while allowing the core framework to mature and
>> stabilize.  I had originally thought this was one of the driving forces
>> behind the plugin architecture.  Example, removing webflow from grails core.
>> Just a thought, but I also, have faced challenges when attempting to keep up
>> with the framework's release schedule.
>>
>> Jordon
>>
>> On Jul 17, 2012, at 4:03 PM, Ronny Løvtangen wrote:
>>
>> >
>> > On Jul 17, 2012, at 8:21 PM, Jonathan Rosenberg wrote:
>> >>
>> >> 4) This mailing list: A non-trivial percentage of questions that are
>> >> posted are never answered, or get only partial answers.  It has gotten
>> >> to the point where I typically don't bother posting a question, as I
>> >> know I am so unlikely to get an answer.
>> >>
>> >> I know and appreciate that (almost) everyone here is a volunteer and
>> >> the product is free.  I contrast this to the Tomcat user list, where I
>> >> know I'll get help of I post a question.  This is a major frustration.
>> >>
>> >
>> > This frustrates me a bit as well. Looking at the questions I've posted
>> > this year, half of them can be marked as solved. It would be close to zero
>> > if it hadn't been for a core group of people (mostly Burt Beckwith, Peter
>> > Ledbrook, Ian Roberts, Marc Palmer and Graeme Rocher. Thanks a lot!)
>> > It might be because after three years of using Grails, the stuff I run
>> > into is not the most trivial stuff, and often requires the knowledge of
>> > those developing Grails itself, especially someone that can give insight on
>> > how stuff are supposed to work when the documentation is ambiguous or
>> > missing. An example to this would be
>> > http://grails.1312388.n4.nabble.com/integration-tests-in-Grails-2-0-td4630370.html
>> >
>> >
>> > On Jul 17, 2012, at 11:20 PM, Aaron Long wrote:
>> >
>> >> In some ways, I think Grails is trying to be too much too quickly and
>> >> some of the core things just aren't getting a chance to mature. It's
>> >> definitely frustrating to start using a feature only to find that it doesn't
>> >> work in some case that is poorly documented. Grails 2.0 is especially bad
>> >> about this with some of the new features like DetachedCriteria and the weird
>> >> dichotomy, for example, that exists between those and Criteria.
>> >
>> > I wish there would be a 3 month period without adding new features, but
>> > rather fighting the big backlog in Jira and let things mature. While I
>> > really, really love Grails, and wouldn't use anything else, I've never run
>> > into so many issues in any other framework I've used in the past. It's also
>> > kind of demotivating to file bugs when you know they probably never will be
>> > handled or even get a response. If I can figure out the problem myself, I
>> > send a pull request as well, but that's not always the case. Sometimes it
>> > also requires some decision making on how things should work.
>> > The documentation is really great IMO, but it has too many missing
>> > pieces. Whenever a new feature is added to Grails, it should make it into
>> > the docs immediately. The good thing is that it's really easy to contribute
>> > to the documentation. And I'm looking forward to Burts new book!
>> >
>> > Ronny
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe from this list, please visit:
>> >
>> >    http://xircles.codehaus.org/manage_email
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>



--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: 1.5 Years with Garils: Thoughts

suryazi
If smaller core and more plugins is the way to go then there should be proper standardization of designing and publishing the plugins such that one plugin in use with another should not breaks the system.

Graeme Rocher-4 wrote
Great feedback all, it is interesting you guys would prefer less
features and fewer major releases. That may be something we should
consider when adding new features to core. We certainly should be
delivering a smaller core and more via plugins.

Cheers

On Wed, Jul 18, 2012 at 1:45 AM, Nathan Wells <[hidden email]> wrote:
> If I had to sum up my opinion it would be:
>
> "Yeah, features are great - they make it so I have to code less. But you
> can't give me too much stability/reliability/documentation/support - it's
> these that make me worry less"
>
> Now that I've gotten the negative out of the way... There's no way I would
> choose anything other than Grails for a Java webapp. You guys have just made
> it too dang easy to show results quickly. GSP/Taglibs is a godsend. The
> Controller/Service model is insanely helpful. i18n is drop-dead simple.
> Spock makes testing fun again (I understand this isn't grails-proper, but
> let that serve as an exclamation point on Jordan's point about plugins over
> "built-ins"). Even ancillary stuff like Codecs are pretty sweet.
>
> But seriously, I gotta have more cowbell!
>
> (for the uninitiated: http://en.wikipedia.org/wiki/More_cowbell)
>
> Nathan Wells
>
>
>
> On Tue, Jul 17, 2012 at 5:22 PM, Jordon Saardchit <[hidden email]>
> wrote:
>>
>> I would also like to preface my 2 cents with "I adore the framework".
>> Like most of the others who chimed in, "I'd certainly not rather not go back
>> to pure java webapps".  However, I must agree the aggresive release schedule
>> for grails core can be very cumbersome.  Its really impractical to attempt
>> to keep up with each release.  I guess my question really is why not make
>> greater use of the plugin architecture (which is fabulous btw) for rapidly
>> moving feature sets while allowing the core framework to mature and
>> stabilize.  I had originally thought this was one of the driving forces
>> behind the plugin architecture.  Example, removing webflow from grails core.
>> Just a thought, but I also, have faced challenges when attempting to keep up
>> with the framework's release schedule.
>>
>> Jordon
>>
>> On Jul 17, 2012, at 4:03 PM, Ronny Løvtangen wrote:
>>
>> >
>> > On Jul 17, 2012, at 8:21 PM, Jonathan Rosenberg wrote:
>> >>
>> >> 4) This mailing list: A non-trivial percentage of questions that are
>> >> posted are never answered, or get only partial answers.  It has gotten
>> >> to the point where I typically don't bother posting a question, as I
>> >> know I am so unlikely to get an answer.
>> >>
>> >> I know and appreciate that (almost) everyone here is a volunteer and
>> >> the product is free.  I contrast this to the Tomcat user list, where I
>> >> know I'll get help of I post a question.  This is a major frustration.
>> >>
>> >
>> > This frustrates me a bit as well. Looking at the questions I've posted
>> > this year, half of them can be marked as solved. It would be close to zero
>> > if it hadn't been for a core group of people (mostly Burt Beckwith, Peter
>> > Ledbrook, Ian Roberts, Marc Palmer and Graeme Rocher. Thanks a lot!)
>> > It might be because after three years of using Grails, the stuff I run
>> > into is not the most trivial stuff, and often requires the knowledge of
>> > those developing Grails itself, especially someone that can give insight on
>> > how stuff are supposed to work when the documentation is ambiguous or
>> > missing. An example to this would be
>> > http://grails.1312388.n4.nabble.com/integration-tests-in-Grails-2-0-td4630370.html
>> >
>> >
>> > On Jul 17, 2012, at 11:20 PM, Aaron Long wrote:
>> >
>> >> In some ways, I think Grails is trying to be too much too quickly and
>> >> some of the core things just aren't getting a chance to mature. It's
>> >> definitely frustrating to start using a feature only to find that it doesn't
>> >> work in some case that is poorly documented. Grails 2.0 is especially bad
>> >> about this with some of the new features like DetachedCriteria and the weird
>> >> dichotomy, for example, that exists between those and Criteria.
>> >
>> > I wish there would be a 3 month period without adding new features, but
>> > rather fighting the big backlog in Jira and let things mature. While I
>> > really, really love Grails, and wouldn't use anything else, I've never run
>> > into so many issues in any other framework I've used in the past. It's also
>> > kind of demotivating to file bugs when you know they probably never will be
>> > handled or even get a response. If I can figure out the problem myself, I
>> > send a pull request as well, but that's not always the case. Sometimes it
>> > also requires some decision making on how things should work.
>> > The documentation is really great IMO, but it has too many missing
>> > pieces. Whenever a new feature is added to Grails, it should make it into
>> > the docs immediately. The good thing is that it's really easy to contribute
>> > to the documentation. And I'm looking forward to Burts new book!
>> >
>> > Ronny
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe from this list, please visit:
>> >
>> >    http://xircles.codehaus.org/manage_email
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>



--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Reply | Threaded
Open this post in threaded view
|

Re: 1.5 Years with Garils: Thoughts

Konstantinos Kostarellis
Even thou I'd love to see some things on http://grails.org/Roadmap rather today then tomorrow in grails:

+1 on stablizing core and squashing bugs first 

Besides I think TagLibs are put a little in second place, IMO they could use some love :)
^^ For most parts, this can easily be handled in plugins thou.

Don't know if it is an option, but maybe we could put the planned features 
on voting at grails.org-page, so we could find out which features are desired the most.

Cheers,
   Kosta

2012/7/18 suryazi <[hidden email]>
If smaller core and more plugins is the way to go then there should be proper
standardization of designing and publishing the plugins such that one plugin
in use with another should not breaks the system.


Graeme Rocher-4 wrote
>
> Great feedback all, it is interesting you guys would prefer less
> features and fewer major releases. That may be something we should
> consider when adding new features to core. We certainly should be
> delivering a smaller core and more via plugins.
>
> Cheers
>
> On Wed, Jul 18, 2012 at 1:45 AM, Nathan Wells &lt;nwwells@&gt; wrote:
>> If I had to sum up my opinion it would be:
>>
>> "Yeah, features are great - they make it so I have to code less. But you
>> can't give me too much stability/reliability/documentation/support - it's
>> these that make me worry less"
>>
>> Now that I've gotten the negative out of the way... There's no way I
>> would
>> choose anything other than Grails for a Java webapp. You guys have just
>> made
>> it too dang easy to show results quickly. GSP/Taglibs is a godsend. The
>> Controller/Service model is insanely helpful. i18n is drop-dead simple.
>> Spock makes testing fun again (I understand this isn't grails-proper, but
>> let that serve as an exclamation point on Jordan's point about plugins
>> over
>> "built-ins"). Even ancillary stuff like Codecs are pretty sweet.
>>
>> But seriously, I gotta have more cowbell!
>>
>> (for the uninitiated: http://en.wikipedia.org/wiki/More_cowbell)
>>
>> Nathan Wells
>>
>>
>>
>> On Tue, Jul 17, 2012 at 5:22 PM, Jordon Saardchit &lt;jordon@&gt;
>> wrote:
>>>
>>> I would also like to preface my 2 cents with "I adore the framework".
>>> Like most of the others who chimed in, "I'd certainly not rather not go
>>> back
>>> to pure java webapps".  However, I must agree the aggresive release
>>> schedule
>>> for grails core can be very cumbersome.  Its really impractical to
>>> attempt
>>> to keep up with each release.  I guess my question really is why not
>>> make
>>> greater use of the plugin architecture (which is fabulous btw) for
>>> rapidly
>>> moving feature sets while allowing the core framework to mature and
>>> stabilize.  I had originally thought this was one of the driving forces
>>> behind the plugin architecture.  Example, removing webflow from grails
>>> core.
>>> Just a thought, but I also, have faced challenges when attempting to
>>> keep up
>>> with the framework's release schedule.
>>>
>>> Jordon
>>>
>>> On Jul 17, 2012, at 4:03 PM, Ronny Løvtangen wrote:
>>>
>>> >
>>> > On Jul 17, 2012, at 8:21 PM, Jonathan Rosenberg wrote:
>>> >>
>>> >> 4) This mailing list: A non-trivial percentage of questions that are
>>> >> posted are never answered, or get only partial answers.  It has
>>> gotten
>>> >> to the point where I typically don't bother posting a question, as I
>>> >> know I am so unlikely to get an answer.
>>> >>
>>> >> I know and appreciate that (almost) everyone here is a volunteer and
>>> >> the product is free.  I contrast this to the Tomcat user list, where
>>> I
>>> >> know I'll get help of I post a question.  This is a major
>>> frustration.
>>> >>
>>> >
>>> > This frustrates me a bit as well. Looking at the questions I've posted
>>> > this year, half of them can be marked as solved. It would be close to
>>> zero
>>> > if it hadn't been for a core group of people (mostly Burt Beckwith,
>>> Peter
>>> > Ledbrook, Ian Roberts, Marc Palmer and Graeme Rocher. Thanks a lot!)
>>> > It might be because after three years of using Grails, the stuff I run
>>> > into is not the most trivial stuff, and often requires the knowledge
>>> of
>>> > those developing Grails itself, especially someone that can give
>>> insight on
>>> > how stuff are supposed to work when the documentation is ambiguous or
>>> > missing. An example to this would be
>>> >
>>> http://grails.1312388.n4.nabble.com/integration-tests-in-Grails-2-0-td4630370.html
>>> >
>>> >
>>> > On Jul 17, 2012, at 11:20 PM, Aaron Long wrote:
>>> >
>>> >> In some ways, I think Grails is trying to be too much too quickly and
>>> >> some of the core things just aren't getting a chance to mature. It's
>>> >> definitely frustrating to start using a feature only to find that it
>>> doesn't
>>> >> work in some case that is poorly documented. Grails 2.0 is especially
>>> bad
>>> >> about this with some of the new features like DetachedCriteria and
>>> the weird
>>> >> dichotomy, for example, that exists between those and Criteria.
>>> >
>>> > I wish there would be a 3 month period without adding new features,
>>> but
>>> > rather fighting the big backlog in Jira and let things mature. While I
>>> > really, really love Grails, and wouldn't use anything else, I've never
>>> run
>>> > into so many issues in any other framework I've used in the past. It's
>>> also
>>> > kind of demotivating to file bugs when you know they probably never
>>> will be
>>> > handled or even get a response. If I can figure out the problem
>>> myself, I
>>> > send a pull request as well, but that's not always the case. Sometimes
>>> it
>>> > also requires some decision making on how things should work.
>>> > The documentation is really great IMO, but it has too many missing
>>> > pieces. Whenever a new feature is added to Grails, it should make it
>>> into
>>> > the docs immediately. The good thing is that it's really easy to
>>> contribute
>>> > to the documentation. And I'm looking forward to Burts new book!
>>> >
>>> > Ronny
>>> >
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe from this list, please visit:
>>> >
>>> >    http://xircles.codehaus.org/manage_email
>>> >
>>> >
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>     http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>
>
>
> --
> Graeme Rocher
> Grails Project Lead
> SpringSource - A Division of VMware
> http://www.springsource.com
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>


--
View this message in context: http://grails.1312388.n4.nabble.com/1-5-Years-with-Garils-Thoughts-tp4631669p4631716.html
Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: 1.5 Years with Garils: Thoughts

Roberto Guerra
I agree with most of what has been said. I would say improvements need to take priority over new features. 

Probably the new features can be introduced as plugins and wait and see how the users take to it. Depending on the reception of those feature-plugins, then they can be slowly incorporated in the core later on. Similar to what happened with the migration-plugin.

Also, the barrier for the community to contribute to grails is a little high (IMO). I think Bobby Warner wrote a blog about setting up the environment, but there is need for more. There are times I have been wanting to try something, but there is no guideline as to where to start. What pops to mind are the scripts. I couldn't find the tests for those and just gave up. There are probably needs for some 'Hack Meets' where people with knowledge of the core can help a group of people write a patch, fix a bug, add a new feature, whatever. This would be a nice way to spread the 'knowledge' around, and then there might be a rise in community participation. If these meets can be video taped and distributed over the Internet, even better.

On Wed, Jul 18, 2012 at 5:58 AM, Konstantinos Kostarellis <[hidden email]> wrote:
Even thou I'd love to see some things on http://grails.org/Roadmap rather today then tomorrow in grails:

+1 on stablizing core and squashing bugs first 

Besides I think TagLibs are put a little in second place, IMO they could use some love :)
^^ For most parts, this can easily be handled in plugins thou.

Don't know if it is an option, but maybe we could put the planned features 
on voting at grails.org-page, so we could find out which features are desired the most.

Cheers,
   Kosta

2012/7/18 suryazi <[hidden email]>
If smaller core and more plugins is the way to go then there should be proper
standardization of designing and publishing the plugins such that one plugin
in use with another should not breaks the system.


Graeme Rocher-4 wrote
>
> Great feedback all, it is interesting you guys would prefer less
> features and fewer major releases. That may be something we should
> consider when adding new features to core. We certainly should be
> delivering a smaller core and more via plugins.
>
> Cheers
>
> On Wed, Jul 18, 2012 at 1:45 AM, Nathan Wells &lt;nwwells@&gt; wrote:
>> If I had to sum up my opinion it would be:
>>
>> "Yeah, features are great - they make it so I have to code less. But you
>> can't give me too much stability/reliability/documentation/support - it's
>> these that make me worry less"
>>
>> Now that I've gotten the negative out of the way... There's no way I
>> would
>> choose anything other than Grails for a Java webapp. You guys have just
>> made
>> it too dang easy to show results quickly. GSP/Taglibs is a godsend. The
>> Controller/Service model is insanely helpful. i18n is drop-dead simple.
>> Spock makes testing fun again (I understand this isn't grails-proper, but
>> let that serve as an exclamation point on Jordan's point about plugins
>> over
>> "built-ins"). Even ancillary stuff like Codecs are pretty sweet.
>>
>> But seriously, I gotta have more cowbell!
>>
>> (for the uninitiated: http://en.wikipedia.org/wiki/More_cowbell)
>>
>> Nathan Wells
>>
>>
>>
>> On Tue, Jul 17, 2012 at 5:22 PM, Jordon Saardchit &lt;jordon@&gt;
>> wrote:
>>>
>>> I would also like to preface my 2 cents with "I adore the framework".
>>> Like most of the others who chimed in, "I'd certainly not rather not go
>>> back
>>> to pure java webapps".  However, I must agree the aggresive release
>>> schedule
>>> for grails core can be very cumbersome.  Its really impractical to
>>> attempt
>>> to keep up with each release.  I guess my question really is why not
>>> make
>>> greater use of the plugin architecture (which is fabulous btw) for
>>> rapidly
>>> moving feature sets while allowing the core framework to mature and
>>> stabilize.  I had originally thought this was one of the driving forces
>>> behind the plugin architecture.  Example, removing webflow from grails
>>> core.
>>> Just a thought, but I also, have faced challenges when attempting to
>>> keep up
>>> with the framework's release schedule.
>>>
>>> Jordon
>>>
>>> On Jul 17, 2012, at 4:03 PM, Ronny Løvtangen wrote:
>>>
>>> >
>>> > On Jul 17, 2012, at 8:21 PM, Jonathan Rosenberg wrote:
>>> >>
>>> >> 4) This mailing list: A non-trivial percentage of questions that are
>>> >> posted are never answered, or get only partial answers.  It has
>>> gotten
>>> >> to the point where I typically don't bother posting a question, as I
>>> >> know I am so unlikely to get an answer.
>>> >>
>>> >> I know and appreciate that (almost) everyone here is a volunteer and
>>> >> the product is free.  I contrast this to the Tomcat user list, where
>>> I
>>> >> know I'll get help of I post a question.  This is a major
>>> frustration.
>>> >>
>>> >
>>> > This frustrates me a bit as well. Looking at the questions I've posted
>>> > this year, half of them can be marked as solved. It would be close to
>>> zero
>>> > if it hadn't been for a core group of people (mostly Burt Beckwith,
>>> Peter
>>> > Ledbrook, Ian Roberts, Marc Palmer and Graeme Rocher. Thanks a lot!)
>>> > It might be because after three years of using Grails, the stuff I run
>>> > into is not the most trivial stuff, and often requires the knowledge
>>> of
>>> > those developing Grails itself, especially someone that can give
>>> insight on
>>> > how stuff are supposed to work when the documentation is ambiguous or
>>> > missing. An example to this would be
>>> >
>>> http://grails.1312388.n4.nabble.com/integration-tests-in-Grails-2-0-td4630370.html
>>> >
>>> >
>>> > On Jul 17, 2012, at 11:20 PM, Aaron Long wrote:
>>> >
>>> >> In some ways, I think Grails is trying to be too much too quickly and
>>> >> some of the core things just aren't getting a chance to mature. It's
>>> >> definitely frustrating to start using a feature only to find that it
>>> doesn't
>>> >> work in some case that is poorly documented. Grails 2.0 is especially
>>> bad
>>> >> about this with some of the new features like DetachedCriteria and
>>> the weird
>>> >> dichotomy, for example, that exists between those and Criteria.
>>> >
>>> > I wish there would be a 3 month period without adding new features,
>>> but
>>> > rather fighting the big backlog in Jira and let things mature. While I
>>> > really, really love Grails, and wouldn't use anything else, I've never
>>> run
>>> > into so many issues in any other framework I've used in the past. It's
>>> also
>>> > kind of demotivating to file bugs when you know they probably never
>>> will be
>>> > handled or even get a response. If I can figure out the problem
>>> myself, I
>>> > send a pull request as well, but that's not always the case. Sometimes
>>> it
>>> > also requires some decision making on how things should work.
>>> > The documentation is really great IMO, but it has too many missing
>>> > pieces. Whenever a new feature is added to Grails, it should make it
>>> into
>>> > the docs immediately. The good thing is that it's really easy to
>>> contribute
>>> > to the documentation. And I'm looking forward to Burts new book!
>>> >
>>> > Ronny
>>> >
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe from this list, please visit:
>>> >
>>> >    http://xircles.codehaus.org/manage_email
>>> >
>>> >
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>     http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>
>
>
> --
> Graeme Rocher
> Grails Project Lead
> SpringSource - A Division of VMware
> http://www.springsource.com
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>


--
View this message in context: http://grails.1312388.n4.nabble.com/1-5-Years-with-Garils-Thoughts-tp4631669p4631716.html
Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email






--
The Journey Is The Reward.
Reply | Threaded
Open this post in threaded view
|

Re: 1.5 Years with Garils: Thoughts

John Moore
Here's my little take on this, FWIW...

I've just got the first stage of a large project to the demonstrable stage for a client, and all along Grails has been a star. It is INCONCEIVABLE that I could have got even a fraction of this done in the time I did had I been using Spring MVC, which I used before Grails (and which I am still using on some projects), or worse, Struts, which I used before I started using Spring MVC (I still wake up screaming in the night with nightmares from my time with Struts :)). Grails seems to be thought out from the point of view of developers developing real world systems, rather than in abstractions. The things which are important to do and which you need to do often are made easy.

Having said that, I really would like to see these priorities:

1. Fast, lean, deployment capability. Dev mode is not so much of an issue, but I'd like to see a production Grails app be able to get by in a little less RAM.

2. Better documentation. The documentation is patchy, although some of it is very good. I used to find quite a lot of outdated stuff around as well, which needed to be cleared up. Don't recall seeing this for a while, so maybe there's been a purge.

3. A greater emphasis on bug fixes and stability, if necessary at the expense of new features. Grails is already pretty feature packed, and there aren't a lot of things I'm crying out for which aren't there. Having said that, I don't really run into bugs or stability issues that often.
Reply | Threaded
Open this post in threaded view
|

Re: 1.5 Years with Garils: Thoughts

longwa
In reply to this post by Roberto Guerra
Like I've said before, I think Grails has the opportunity to dominate the enterprise space by offering a fresh replacement for aging J2EE systems. Large IT shops see Java as being more enterprise-y (FWIW) than languages like Ruby and are more easily convinced to accept Grails projects. We are undertaking exactly that type of project right now, porting a large Weblogic application to Grails & Tomcat. When we looked at our options, we came down to about 3:

1. Hibernate, Spring MVC, Spring, roll your own stack
2. Rails
3. Grails, Lift, Play, other java friendly frameworks

Since doing 1 well is essentially writing your own Grails, that seemed stupid. Rails was a tricky one, and many people voted in favor of that route. But the sheer amount of existing code and libraries we use which are in Java just made it too daunting of a rewrite. The Java friendly frameworks won out and I think, for now, Grails is on top of that list for a number of reasons.

There are a few challenges for Grails playing in this space though, namely that software in this space needs to be rock solid and well supported and the challenges in the enterprise tend to be some of the larger and more complex to solve. Our application supports about 50 different business processes, has 392 domain classes, and probably close to 500k lines of code. If not already, I think this will start to become a more common use case for Grails than just the typical quick and dirty website. To be honest, if I just want to whip up a little website with a couple of model objects, I'll use Rails. It's nothing against Grails, I just don't need that big of a hammer to solve the problem.

In summary, with a little TLC, Grails will be fully ready for world (enterprise) domination.



1234