grails....

classic Classic list List threaded Threaded
55 messages Options
123
Reply | Threaded
Open this post in threaded view
|

grails....

corey_s

Been using grails since the 0.3.0 days.

I've written, and currently maintain, 6 largish non-trivial apps with it.

Approximately 20%-40% of my time on every grails app I work with, involves at
least one or two iterations of  the following vicious cycle:

1 - get bitten by some grails bug or another

2 - confirm that the issue is in fact a grails bug and not user error

3 - trail and error to identify and reliably reproduce bug

4 - bug identified, trial and error to find work around

5 - small to major refactor of codebase to implement work around

[
6 - work around toggles new/different bug, begin again at at step 1
]

Steps 2-5 individually each take a significant amount of time and effort; step 6
doesn't always occur, but it's happened enough that I've become somewhat
paranoid when embarking upon any serious refactoring of an existing app,
especially when the refactor is due to a bug.

I look forward to when grails finally becomes more _deeply_ stable - so that I
can work in confidence and with peace of mind that this or that functionality
isn't going to blow up when I try to actually use it.

When it works, it purrs - but man when things fail, they fail hard... train
wreck style.

Maybe I just have a way of pressing all the wrong buttons on every new release
with every new app I start on.



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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: grails....

Miguel Ping
Hi Corey,

Unfortunately, I know your grief. Same thing here :(

On Sat, Jun 13, 2009 at 1:28 AM, Corey <[hidden email]> wrote:

Been using grails since the 0.3.0 days.

I've written, and currently maintain, 6 largish non-trivial apps with it.

Approximately 20%-40% of my time on every grails app I work with, involves at
least one or two iterations of  the following vicious cycle:

1 - get bitten by some grails bug or another

2 - confirm that the issue is in fact a grails bug and not user error

3 - trail and error to identify and reliably reproduce bug

4 - bug identified, trial and error to find work around

5 - small to major refactor of codebase to implement work around

[
6 - work around toggles new/different bug, begin again at at step 1
]

Steps 2-5 individually each take a significant amount of time and effort; step 6
doesn't always occur, but it's happened enough that I've become somewhat
paranoid when embarking upon any serious refactoring of an existing app,
especially when the refactor is due to a bug.

I look forward to when grails finally becomes more _deeply_ stable - so that I
can work in confidence and with peace of mind that this or that functionality
isn't going to blow up when I try to actually use it.

When it works, it purrs - but man when things fail, they fail hard... train
wreck style.

Maybe I just have a way of pressing all the wrong buttons on every new release
with every new app I start on.



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

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: grails....

Daniel Guryca
That's exactly what I was talking about.
I would really much much appriciate if Grails developers would work on fixing all bugs a realease one "really stable" version and just after all these fixing new features could be added.

Cheers.
Daniel

On Sat, Jun 13, 2009 at 11:25 AM, Miguel Ping <[hidden email]> wrote:
Hi Corey,

Unfortunately, I know your grief. Same thing here :(


On Sat, Jun 13, 2009 at 1:28 AM, Corey <[hidden email]> wrote:

Been using grails since the 0.3.0 days.

I've written, and currently maintain, 6 largish non-trivial apps with it.

Approximately 20%-40% of my time on every grails app I work with, involves at
least one or two iterations of  the following vicious cycle:

1 - get bitten by some grails bug or another

2 - confirm that the issue is in fact a grails bug and not user error

3 - trail and error to identify and reliably reproduce bug

4 - bug identified, trial and error to find work around

5 - small to major refactor of codebase to implement work around

[
6 - work around toggles new/different bug, begin again at at step 1
]

Steps 2-5 individually each take a significant amount of time and effort; step 6
doesn't always occur, but it's happened enough that I've become somewhat
paranoid when embarking upon any serious refactoring of an existing app,
especially when the refactor is due to a bug.

I look forward to when grails finally becomes more _deeply_ stable - so that I
can work in confidence and with peace of mind that this or that functionality
isn't going to blow up when I try to actually use it.

When it works, it purrs - but man when things fail, they fail hard... train
wreck style.

Maybe I just have a way of pressing all the wrong buttons on every new release
with every new app I start on.



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

   http://xircles.codehaus.org/manage_email




Reply | Threaded
Open this post in threaded view
|

Re: grails....

corey_s
On Saturday 13 June 2009 13:12:46 Daniel Guryca wrote:
> That's exactly what I was talking about.
> I would really much much appriciate if Grails developers would work on
> fixing all bugs a realease one "really stable" version and just after all
> these fixing new features could be added.
>

I would very much like to see this also.

There was a recent interview with Graeme Rocher where he said the next
release was going to be primarily dedicated towards stabilization, removing
more stuff into modules, and focusing on core:

  http://thirstyhead.com/news/show/Interview_with_Graeme_Rocher


... hopefully he keeps his promise and we'll finally see a rock stable and
predictably reliable grails release pretty soon. I mean, the growing pains
have got to end at some point, right?

There's been a few points in the last couple years when I've honestly wondered
whether instability and general bugginess is simply an intrinsic property of
grails - it being, essentially, an abstraction layer over abstraction layer
over abstraction layer over...



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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: grails....

Müller, Wolfgang


There's been a few points in the last couple years when I've honestly wondered
whether instability and general bugginess is simply an intrinsic property of
grails - it being, essentially, an abstraction layer over abstraction layer
over abstraction layer over...
 
Well, it surely is and probably inherits errors or difficulties from things it abstracts from. 

What I am asking myself is what could be done to make us more part of the process. I mean, Grails is a great piece of software, really helpful, and the things that do work are great++. I am wondering on how we could contribute to automated testing? I guess testing grails is hard, and regression testing must be very hard. All these apps out there trying to combine JAVA and Grails (in order to combine functionalities from JAVA and ease Grails) must be hard to simulate. I find it an interesting, challenging intellectual question on how to test stuff like that, and I do find this would be something where the users (i.e. us) could really contribute. If e.g. the main features of Corey's app would be part of a huge big regression tests to be run before each release, the vicious circle stuff would stop. The challenge probably lies in building a test framework capable of the task of testing multiple setups. Or is there one such framework already?

Cheers,
Wolfgang
Reply | Threaded
Open this post in threaded view
|

Re: grails....

Mingfai
In reply to this post by corey_s


On Sun, Jun 14, 2009 at 10:00 AM, Corey <[hidden email]> wrote:
On Saturday 13 June 2009 13:12:46 Daniel Guryca wrote:
> That's exactly what I was talking about.
> I would really much much appriciate if Grails developers would work on
> fixing all bugs a realease one "really stable" version and just after all
> these fixing new features could be added.
>

I would very much like to see this also.

There was a recent interview with Graeme Rocher where he said the next
release was going to be primarily dedicated towards stabilization, removing
more stuff into modules, and focusing on core:

 http://thirstyhead.com/news/show/Interview_with_Graeme_Rocher


good news. fully support the directions of stabilization and modularization.

anyway, i think Grails 1.1 has great improvement over the previous release already.

regards,
mingfai
Reply | Threaded
Open this post in threaded view
|

Re: grails....

Robert Fletcher
Some interesting points.

The last 2 releases have been painful for us but the upgrade to 1.1
was worth it. The problems experienced going to 1.1 were mostly down
to the callsite caching problems in Groovy. We haven't gone to 1.1.1
and again an underlying Groovy bug (failure to parse nested config) is
the reason. A good portion of the questions asked on this mailing list
are as much about how stuff works in Hibernate or other underlying
libraries. The impression I get is that Grails is (especially
recently) mostly very stable but has an issue with problems from
underlying stuff bubbling through or people assuming some behaviour is
a Grails issue when in fact if you took Grails out of the equation the
same thing would happen with straight Hibernate or whatever.

I think the idea of some of the community contributing to automated
testing is a really good one. True, some things are hard to test, but
I'm sure some of us are used to testing complicated integration
scenarios. I know I've done my share of that. Not all of the coverage
is that complex, though - integration tests should have caught the
config parsing bug, for example.

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: grails....

mpermar
Hi.

In our case we didn't upgrade to grails 1.1 because as per other opinions posted in this forum it looked like it would be painful and take too much time from us. So we stuck with 1.0.x.

News about stability and consolidation are really welcome here. There has been a trend in Grails about trying to add support to as many technologies as it was possible (e.g. JCR, portal,..). My personal opinion is that there is nice to have that support, but the support is already present in Java and Spring. Having a grovified version of JCR, yes it is cool and that, but it would not be top priority for me. Apart from that, I think the grails team should focus on grails core and let other people create useful plugins. Said this, grails-ui is an awesome plugin coming from the grails team, and I think such plugins that allow rapid RIA development are the way to go.

This is a very humble opinion but focus on bug fixing, focus on stability and focus on better Java and IDE integration would be what I would like to see. I like what you can do now in Spring Roo and I wonder if you could do the same with the Java support in grails without having to redeploy Java services (even though it is automatically done it fails quite frequently), but not sure if it would make sense to integrate both projects.

Martin


On Sun, Jun 14, 2009 at 10:00 AM, Robert Fletcher <[hidden email]> wrote:
Some interesting points.

The last 2 releases have been painful for us but the upgrade to 1.1
was worth it. The problems experienced going to 1.1 were mostly down
to the callsite caching problems in Groovy. We haven't gone to 1.1.1
and again an underlying Groovy bug (failure to parse nested config) is
the reason. A good portion of the questions asked on this mailing list
are as much about how stuff works in Hibernate or other underlying
libraries. The impression I get is that Grails is (especially
recently) mostly very stable but has an issue with problems from
underlying stuff bubbling through or people assuming some behaviour is
a Grails issue when in fact if you took Grails out of the equation the
same thing would happen with straight Hibernate or whatever.

I think the idea of some of the community contributing to automated
testing is a really good one. True, some things are hard to test, but
I'm sure some of us are used to testing complicated integration
scenarios. I know I've done my share of that. Not all of the coverage
is that complex, though - integration tests should have caught the
config parsing bug, for example.

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

   http://xircles.codehaus.org/manage_email





--
Martín Pérez

Founder,
http://www.jobsket.com

Reply | Threaded
Open this post in threaded view
|

Re: grails....

Daniel Guryca
In reply to this post by Robert Fletcher
I agree with all of you guys.

But what I see a main source of trouble is groovy.
How anything in grails can be stabilized if a core programming layer is buggy and every new groovy release contains new unknown bugs.
I know that some of hibernate behaviour is maybe awkward but that's not a problem.

Testing framework:
Everything said (to develop any huge testing framework) should go to groovy too.
One concern - is it possible to include all thinkable programming variations ? - I think it's impossible.
One say to do it this way other person wants to do it that way ... yes developers itself should be put into an account and should participate on a testing framework development.

cheers
Daniel

On Sun, Jun 14, 2009 at 10:00 AM, Robert Fletcher <[hidden email]> wrote:
Some interesting points.

The last 2 releases have been painful for us but the upgrade to 1.1
was worth it. The problems experienced going to 1.1 were mostly down
to the callsite caching problems in Groovy. We haven't gone to 1.1.1
and again an underlying Groovy bug (failure to parse nested config) is
the reason. A good portion of the questions asked on this mailing list
are as much about how stuff works in Hibernate or other underlying
libraries. The impression I get is that Grails is (especially
recently) mostly very stable but has an issue with problems from
underlying stuff bubbling through or people assuming some behaviour is
a Grails issue when in fact if you took Grails out of the equation the
same thing would happen with straight Hibernate or whatever.

I think the idea of some of the community contributing to automated
testing is a really good one. True, some things are hard to test, but
I'm sure some of us are used to testing complicated integration
scenarios. I know I've done my share of that. Not all of the coverage
is that complex, though - integration tests should have caught the
config parsing bug, for example.

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

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: grails....

Daniel Guryca
In reply to this post by mpermar
To Martin Perez

Yes you have my VOTE !!

Daniel

On Sun, Jun 14, 2009 at 11:27 AM, Martin Perez <[hidden email]> wrote:
Hi.

In our case we didn't upgrade to grails 1.1 because as per other opinions posted in this forum it looked like it would be painful and take too much time from us. So we stuck with 1.0.x.

News about stability and consolidation are really welcome here. There has been a trend in Grails about trying to add support to as many technologies as it was possible (e.g. JCR, portal,..). My personal opinion is that there is nice to have that support, but the support is already present in Java and Spring. Having a grovified version of JCR, yes it is cool and that, but it would not be top priority for me. Apart from that, I think the grails team should focus on grails core and let other people create useful plugins. Said this, grails-ui is an awesome plugin coming from the grails team, and I think such plugins that allow rapid RIA development are the way to go.

This is a very humble opinion but focus on bug fixing, focus on stability and focus on better Java and IDE integration would be what I would like to see. I like what you can do now in Spring Roo and I wonder if you could do the same with the Java support in grails without having to redeploy Java services (even though it is automatically done it fails quite frequently), but not sure if it would make sense to integrate both projects.

Martin



On Sun, Jun 14, 2009 at 10:00 AM, Robert Fletcher <[hidden email]> wrote:
Some interesting points.

The last 2 releases have been painful for us but the upgrade to 1.1
was worth it. The problems experienced going to 1.1 were mostly down
to the callsite caching problems in Groovy. We haven't gone to 1.1.1
and again an underlying Groovy bug (failure to parse nested config) is
the reason. A good portion of the questions asked on this mailing list
are as much about how stuff works in Hibernate or other underlying
libraries. The impression I get is that Grails is (especially
recently) mostly very stable but has an issue with problems from
underlying stuff bubbling through or people assuming some behaviour is
a Grails issue when in fact if you took Grails out of the equation the
same thing would happen with straight Hibernate or whatever.

I think the idea of some of the community contributing to automated
testing is a really good one. True, some things are hard to test, but
I'm sure some of us are used to testing complicated integration
scenarios. I know I've done my share of that. Not all of the coverage
is that complex, though - integration tests should have caught the
config parsing bug, for example.

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

   http://xircles.codehaus.org/manage_email





--
Martín Pérez

Founder,
http://www.jobsket.com


Reply | Threaded
Open this post in threaded view
|

Re: grails....

Björn Wilmsmann-2
In reply to this post by corey_s
I agree with pretty much everything that's been said in this thread.  
Another thing that bugs me are the Grails stack traces, which are just  
hideous long and complex. Maybe displaying just the 'Caused by ...'  
statement would already help in most cases.

Corey wrote:

>
> Been using grails since the 0.3.0 days.
>
> I've written, and currently maintain, 6 largish non-trivial apps  
> with it.
>
> Approximately 20%-40% of my time on every grails app I work with,  
> involves at
> least one or two iterations of  the following vicious cycle:
>
> 1 - get bitten by some grails bug or another
>
> 2 - confirm that the issue is in fact a grails bug and not user error
>
> 3 - trail and error to identify and reliably reproduce bug
>
> 4 - bug identified, trial and error to find work around
>
> 5 - small to major refactor of codebase to implement work around
>
> [
> 6 - work around toggles new/different bug, begin again at at step 1
> ]
>
> Steps 2-5 individually each take a significant amount of time and  
> effort; step 6
> doesn't always occur, but it's happened enough that I've become  
> somewhat
> paranoid when embarking upon any serious refactoring of an existing  
> app,
> especially when the refactor is due to a bug.
>
> I look forward to when grails finally becomes more _deeply_ stable -  
> so that I
> can work in confidence and with peace of mind that this or that  
> functionality
> isn't going to blow up when I try to actually use it.
>
> When it works, it purrs - but man when things fail, they fail  
> hard... train
> wreck style.
>
> Maybe I just have a way of pressing all the wrong buttons on every  
> new release
> with every new app I start on.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

--
Best regards,
Bjoern Wilmsmann




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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: grails....

Müller, Wolfgang
In reply to this post by Daniel Guryca
Well,

I find that there are some interesting (at least for me interesting) requirements popping up. Is there a wiki where we could "persist" and extend this discussion?

What I would find useful is a bunch of testers who agree to run some scripts on their development server from time to time.

The scripts would do the following:

1) Modify the groovy/grails config, iterating through a number of possibilities.
2) For each config: Deploy in different fashions
3) for each config/deploy combination run a unit test/webtest

The tester reports anything that breaks with the new config.

Of course this takes time and would be a contribution that actually takes time from the contributor.

However, as maintainer of a grails app we are likely to be forced to do that anyways for each version bump of grails (in order to catch bugs in advance), so we might as well do it in a way that helps others.

Cheers,
Wolfgang


On Sun, Jun 14, 2009 at 11:42 AM, Daniel Guryca <[hidden email]> wrote:
I agree with all of you guys.

But what I see a main source of trouble is groovy.
How anything in grails can be stabilized if a core programming layer is buggy and every new groovy release contains new unknown bugs.
I know that some of hibernate behaviour is maybe awkward but that's not a problem.

Testing framework:
Everything said (to develop any huge testing framework) should go to groovy too.
One concern - is it possible to include all thinkable programming variations ? - I think it's impossible.
One say to do it this way other person wants to do it that way ... yes developers itself should be put into an account and should participate on a testing framework development.

cheers
Daniel

On Sun, Jun 14, 2009 at 10:00 AM, Robert Fletcher <[hidden email]> wrote:
Some interesting points.

The last 2 releases have been painful for us but the upgrade to 1.1
was worth it. The problems experienced going to 1.1 were mostly down
to the callsite caching problems in Groovy. We haven't gone to 1.1.1
and again an underlying Groovy bug (failure to parse nested config) is
the reason. A good portion of the questions asked on this mailing list
are as much about how stuff works in Hibernate or other underlying
libraries. The impression I get is that Grails is (especially
recently) mostly very stable but has an issue with problems from
underlying stuff bubbling through or people assuming some behaviour is
a Grails issue when in fact if you took Grails out of the equation the
same thing would happen with straight Hibernate or whatever.

I think the idea of some of the community contributing to automated
testing is a really good one. True, some things are hard to test, but
I'm sure some of us are used to testing complicated integration
scenarios. I know I've done my share of that. Not all of the coverage
is that complex, though - integration tests should have caught the
config parsing bug, for example.

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

   http://xircles.codehaus.org/manage_email




Reply | Threaded
Open this post in threaded view
|

Re: grails....

Graeme Rocher-3
In reply to this post by Robert Fletcher
We would appreciate as much help as we can get with testing Grails
milestone releases (RC, betas) as possible. Its definitely hard to
test Grails, we have like 1500 tests the majority of which are
integration tests that bootstrap in-memory databases etc. We also have
a couple of hundred functional tests

However, there is always seems to be some use case that we haven't
considered that pops up. One feeling I get is that because Grails
provides an out of the box experience where we provide a build system,
container, persistence, etc. etc. what has resulted is that we have a
load more issues reported against Grails than other frameworks.

If this was Java people would report persistence issues against
Hibernate, build issues against Ant, integration issues against Spring
and so on. With Grails we get everything even if the issue is in an
underlying framework or language. The goal for Grails 1.2 is
definitely to just focus on stability and improvements with a few
refactorings (standalone GSP) and upgrades (Spring 3)

Regards

On Sun, Jun 14, 2009 at 9:00 AM, Robert
Fletcher<[hidden email]> wrote:

> Some interesting points.
>
> The last 2 releases have been painful for us but the upgrade to 1.1
> was worth it. The problems experienced going to 1.1 were mostly down
> to the callsite caching problems in Groovy. We haven't gone to 1.1.1
> and again an underlying Groovy bug (failure to parse nested config) is
> the reason. A good portion of the questions asked on this mailing list
> are as much about how stuff works in Hibernate or other underlying
> libraries. The impression I get is that Grails is (especially
> recently) mostly very stable but has an issue with problems from
> underlying stuff bubbling through or people assuming some behaviour is
> a Grails issue when in fact if you took Grails out of the equation the
> same thing would happen with straight Hibernate or whatever.
>
> I think the idea of some of the community contributing to automated
> testing is a really good one. True, some things are hard to test, but
> I'm sure some of us are used to testing complicated integration
> scenarios. I know I've done my share of that. Not all of the coverage
> is that complex, though - integration tests should have caught the
> config parsing bug, for example.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>



--
Graeme Rocher
Head of Grails Development
SpringSource - Weapons for the War on Java Complexity
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: grails....

Marcel Overdijk
Hi Graeme,

When can we expect the first 1.2 release candidate?
Good to hear to upgrade to Spring 3.

Cheers,
Marcel

Graeme Rocher-3 wrote
We would appreciate as much help as we can get with testing Grails
milestone releases (RC, betas) as possible. Its definitely hard to
test Grails, we have like 1500 tests the majority of which are
integration tests that bootstrap in-memory databases etc. We also have
a couple of hundred functional tests

However, there is always seems to be some use case that we haven't
considered that pops up. One feeling I get is that because Grails
provides an out of the box experience where we provide a build system,
container, persistence, etc. etc. what has resulted is that we have a
load more issues reported against Grails than other frameworks.

If this was Java people would report persistence issues against
Hibernate, build issues against Ant, integration issues against Spring
and so on. With Grails we get everything even if the issue is in an
underlying framework or language. The goal for Grails 1.2 is
definitely to just focus on stability and improvements with a few
refactorings (standalone GSP) and upgrades (Spring 3)

Regards

On Sun, Jun 14, 2009 at 9:00 AM, Robert
Fletcher<robert.w.fletcher@googlemail.com> wrote:
> Some interesting points.
>
> The last 2 releases have been painful for us but the upgrade to 1.1
> was worth it. The problems experienced going to 1.1 were mostly down
> to the callsite caching problems in Groovy. We haven't gone to 1.1.1
> and again an underlying Groovy bug (failure to parse nested config) is
> the reason. A good portion of the questions asked on this mailing list
> are as much about how stuff works in Hibernate or other underlying
> libraries. The impression I get is that Grails is (especially
> recently) mostly very stable but has an issue with problems from
> underlying stuff bubbling through or people assuming some behaviour is
> a Grails issue when in fact if you took Grails out of the equation the
> same thing would happen with straight Hibernate or whatever.
>
> I think the idea of some of the community contributing to automated
> testing is a really good one. True, some things are hard to test, but
> I'm sure some of us are used to testing complicated integration
> scenarios. I know I've done my share of that. Not all of the coverage
> is that complex, though - integration tests should have caught the
> config parsing bug, for example.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>



--
Graeme Rocher
Head of Grails Development
SpringSource - Weapons for the War on Java Complexity
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: grails....

felipero
In reply to this post by Daniel Guryca
It is an opensource project. Why don't you help in fixing it?


Daniel Guryca wrote:
That's exactly what I was talking about.
I would really much much appriciate if Grails developers would work on fixing all bugs a realease one "really stable" version and just after all these fixing new features could be added.

Cheers.
Daniel

On Sat, Jun 13, 2009 at 11:25 AM, Miguel Ping <[hidden email]> wrote:
Hi Corey,

Unfortunately, I know your grief. Same thing here :(


On Sat, Jun 13, 2009 at 1:28 AM, Corey <[hidden email]> wrote:

Been using grails since the 0.3.0 days.

I've written, and currently maintain, 6 largish non-trivial apps with it.

Approximately 20%-40% of my time on every grails app I work with, involves at
least one or two iterations of  the following vicious cycle:

1 - get bitten by some grails bug or another

2 - confirm that the issue is in fact a grails bug and not user error

3 - trail and error to identify and reliably reproduce bug

4 - bug identified, trial and error to find work around

5 - small to major refactor of codebase to implement work around

[
6 - work around toggles new/different bug, begin again at at step 1
]

Steps 2-5 individually each take a significant amount of time and effort; step 6
doesn't always occur, but it's happened enough that I've become somewhat
paranoid when embarking upon any serious refactoring of an existing app,
especially when the refactor is due to a bug.

I look forward to when grails finally becomes more _deeply_ stable - so that I
can work in confidence and with peace of mind that this or that functionality
isn't going to blow up when I try to actually use it.

When it works, it purrs - but man when things fail, they fail hard... train
wreck style.

Maybe I just have a way of pressing all the wrong buttons on every new release
with every new app I start on.



---------------------------------------------------------------------
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: grails....

Robert Fischer
In reply to this post by corey_s
This is part of the reason I created TestingLabs/GORM Labs.

~~ Robert.

Corey wrote:

> Been using grails since the 0.3.0 days.
>
> I've written, and currently maintain, 6 largish non-trivial apps with it.
>
> Approximately 20%-40% of my time on every grails app I work with, involves at
> least one or two iterations of  the following vicious cycle:
>
> 1 - get bitten by some grails bug or another
>
> 2 - confirm that the issue is in fact a grails bug and not user error
>
> 3 - trail and error to identify and reliably reproduce bug
>
> 4 - bug identified, trial and error to find work around
>
> 5 - small to major refactor of codebase to implement work around
>
> [
> 6 - work around toggles new/different bug, begin again at at step 1
> ]
>
> Steps 2-5 individually each take a significant amount of time and effort; step 6
> doesn't always occur, but it's happened enough that I've become somewhat
> paranoid when embarking upon any serious refactoring of an existing app,
> especially when the refactor is due to a bug.
>
> I look forward to when grails finally becomes more _deeply_ stable - so that I
> can work in confidence and with peace of mind that this or that functionality
> isn't going to blow up when I try to actually use it.
>
> When it works, it purrs - but man when things fail, they fail hard... train
> wreck style.
>
> Maybe I just have a way of pressing all the wrong buttons on every new release
> with every new app I start on.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

--
~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: grails....

Graeme Rocher-3
In reply to this post by Marcel Overdijk
We're following the rest of SpringSource's policy of doing milestones.
So Grails 1.2 M1 is targeted for the end of June

On Sun, Jun 14, 2009 at 9:35 PM, Marcel
Overdijk<[hidden email]> wrote:

>
> Hi Graeme,
>
> When can we expect the first 1.2 release candidate?
> Good to hear to upgrade to Spring 3.
>
> Cheers,
> Marcel
>
>
> Graeme Rocher-3 wrote:
>>
>> We would appreciate as much help as we can get with testing Grails
>> milestone releases (RC, betas) as possible. Its definitely hard to
>> test Grails, we have like 1500 tests the majority of which are
>> integration tests that bootstrap in-memory databases etc. We also have
>> a couple of hundred functional tests
>>
>> However, there is always seems to be some use case that we haven't
>> considered that pops up. One feeling I get is that because Grails
>> provides an out of the box experience where we provide a build system,
>> container, persistence, etc. etc. what has resulted is that we have a
>> load more issues reported against Grails than other frameworks.
>>
>> If this was Java people would report persistence issues against
>> Hibernate, build issues against Ant, integration issues against Spring
>> and so on. With Grails we get everything even if the issue is in an
>> underlying framework or language. The goal for Grails 1.2 is
>> definitely to just focus on stability and improvements with a few
>> refactorings (standalone GSP) and upgrades (Spring 3)
>>
>> Regards
>>
>> On Sun, Jun 14, 2009 at 9:00 AM, Robert
>> Fletcher<[hidden email]> wrote:
>>> Some interesting points.
>>>
>>> The last 2 releases have been painful for us but the upgrade to 1.1
>>> was worth it. The problems experienced going to 1.1 were mostly down
>>> to the callsite caching problems in Groovy. We haven't gone to 1.1.1
>>> and again an underlying Groovy bug (failure to parse nested config) is
>>> the reason. A good portion of the questions asked on this mailing list
>>> are as much about how stuff works in Hibernate or other underlying
>>> libraries. The impression I get is that Grails is (especially
>>> recently) mostly very stable but has an issue with problems from
>>> underlying stuff bubbling through or people assuming some behaviour is
>>> a Grails issue when in fact if you took Grails out of the equation the
>>> same thing would happen with straight Hibernate or whatever.
>>>
>>> I think the idea of some of the community contributing to automated
>>> testing is a really good one. True, some things are hard to test, but
>>> I'm sure some of us are used to testing complicated integration
>>> scenarios. I know I've done my share of that. Not all of the coverage
>>> is that complex, though - integration tests should have caught the
>>> config parsing bug, for example.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>
>>
>>
>> --
>> Graeme Rocher
>> Head of Grails Development
>> SpringSource - Weapons for the War on Java Complexity
>> http://www.springsource.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/grails....-tp24007981p24025490.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
>
>
>



--
Graeme Rocher
Head of Grails Development
SpringSource - Weapons for the War on Java Complexity
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: grails....

Robert Fischer
In reply to this post by corey_s
Just FYI, submitting JIRAs with projects whose unit tests demonstrate the bug are a great way to
improve the stability of Grails.  I notice that in your 1-6, you nowhere say "JIRA", and that's a
problem.

~~ Robert.

Corey wrote:

> Been using grails since the 0.3.0 days.
>
> I've written, and currently maintain, 6 largish non-trivial apps with it.
>
> Approximately 20%-40% of my time on every grails app I work with, involves at
> least one or two iterations of  the following vicious cycle:
>
> 1 - get bitten by some grails bug or another
>
> 2 - confirm that the issue is in fact a grails bug and not user error
>
> 3 - trail and error to identify and reliably reproduce bug
>
> 4 - bug identified, trial and error to find work around
>
> 5 - small to major refactor of codebase to implement work around
>
> [
> 6 - work around toggles new/different bug, begin again at at step 1
> ]
>
> Steps 2-5 individually each take a significant amount of time and effort; step 6
> doesn't always occur, but it's happened enough that I've become somewhat
> paranoid when embarking upon any serious refactoring of an existing app,
> especially when the refactor is due to a bug.
>
> I look forward to when grails finally becomes more _deeply_ stable - so that I
> can work in confidence and with peace of mind that this or that functionality
> isn't going to blow up when I try to actually use it.
>
> When it works, it purrs - but man when things fail, they fail hard... train
> wreck style.
>
> Maybe I just have a way of pressing all the wrong buttons on every new release
> with every new app I start on.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

--
~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: grails....

Konstantyn Smirnov
In reply to this post by corey_s
I have 3 grails-apps, and the only headache I had was the migration from one version to the newer. All bugs I saw were not that critical, to start long debug-sessions.

Looks like I have nothing to complain about :) but some stabililty and smoothnes of migration would be really nice.

And Graeme, I'm still waiting for the sub-flows that work and do not throw OSIW-related exceptions ;)
Reply | Threaded
Open this post in threaded view
|

Re: grails....

Benjamin Gandon
Well, 3 week since I'm discovering Grails...
Fantastic journey!

but indeed, had to submit first patches after 5 days...
Better stability and above all, better IDE (Eclipse) integration
desperately needed.

(I even checked out the Grails Eclipse plugin, but I'm too new to
Eclipse plugin development, I'd love to get some input about how to set
all that up and start testing new additions/improvements.)



Konstantyn Smirnov a écrit :

> I have 3 grails-apps, and the only headache I had was the migration from one
> version to the newer. All bugs I saw were not that critical, to start a long
> debug-sessions.
>
> Looks like I have nothing to complain about :) but some stabililty and
> smoothnes of migration would be really nice
>
> -----
> Konstantyn Smirnov, CTO
> http://www.poiradar.ru www.poiradar.ru
> http://www.poiradar.com.ua www.poiradar.com.ua
> http://www.poiradar.com www.poiradar.com
> http://www.poiradar.de www.poiradar.de
>  

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

    http://xircles.codehaus.org/manage_email


123