Discussion:
Grails development is really slow
raffaele181188
2012-01-03 17:11:31 UTC
Permalink
Pentium Dual Core, 2GB RAM
Windows Seven
STS-2.8.1-RELEASE
JDK7
Grails 2.0RC1
Groovy-1.8

Grails development is very slow. Each time I create a domain/controller
(either with the graphical wizard or by typing at the Grails shell) it takes
half a minute to execute. Also, almost every change to groovy
domain/controller files requires restarting the http server component ,
otherwise weird things happen, ie I don't see my changes or MissingProperty
and other funny exception are thrown. I stop catalina with the red square
button, then I run-app (green "play" button) and everything works as
expected, but MINUTES are passed! Also, the Grails app is clearly slow in
outputting HTML and feels very laggy. All I have is 2 domains/controllers
and, in-memory database and automatic scaffolding

This must be a problem with my stack, because I can't believe that
developing with Grails is so painful

--
View this message in context: http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4257651.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
Chanwit Kaewkasi
2012-01-03 17:23:15 UTC
Permalink
Hi,

My best guess is probably JDK7.

Cheers

Chanwit

On Wed, Jan 4, 2012 at 00:11, raffaele181188 <***@gmail.com> wrote:
> Pentium Dual Core, 2GB RAM
> Windows Seven
> STS-2.8.1-RELEASE
> JDK7
> Grails 2.0RC1
> Groovy-1.8
>
> Grails development is very slow. Each time I create a domain/controller
> (either with the graphical wizard or by typing at the Grails shell) it takes
> half a minute to execute. Also, almost every change to groovy
> domain/controller files requires restarting the http server component ,
> otherwise weird things happen, ie I don't see my changes or MissingProperty
> and other funny exception are thrown. I stop catalina with the red square
> button, then I run-app (green "play" button) and everything works as
> expected, but MINUTES are passed! Also, the Grails app is clearly slow in
> outputting HTML and feels very laggy. All I have is 2 domains/controllers
> and, in-memory database and automatic scaffolding
>
> This must be a problem with my stack, because I can't believe that
> developing with Grails is so painful
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4257651.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
>
>



--
Chanwit Kaewkasi
code.google.com/p/zkgrails
twitter.com/chanwit

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

http://xircles.codehaus.org/manage_email
Gavin Yue
2012-01-03 17:28:59 UTC
Permalink
2GB memory could also be a problem....

Java app is really memory monster.



On Tue, Jan 3, 2012 at 9:23 AM, Chanwit Kaewkasi <***@gmail.com> wrote:

> Hi,
>
> My best guess is probably JDK7.
>
> Cheers
>
> Chanwit
>
> On Wed, Jan 4, 2012 at 00:11, raffaele181188 <***@gmail.com>
> wrote:
> > Pentium Dual Core, 2GB RAM
> > Windows Seven
> > STS-2.8.1-RELEASE
> > JDK7
> > Grails 2.0RC1
> > Groovy-1.8
> >
> > Grails development is very slow. Each time I create a domain/controller
> > (either with the graphical wizard or by typing at the Grails shell) it
> takes
> > half a minute to execute. Also, almost every change to groovy
> > domain/controller files requires restarting the http server component ,
> > otherwise weird things happen, ie I don't see my changes or
> MissingProperty
> > and other funny exception are thrown. I stop catalina with the red square
> > button, then I run-app (green "play" button) and everything works as
> > expected, but MINUTES are passed! Also, the Grails app is clearly slow in
> > outputting HTML and feels very laggy. All I have is 2 domains/controllers
> > and, in-memory database and automatic scaffolding
> >
> > This must be a problem with my stack, because I can't believe that
> > developing with Grails is so painful
> >
> > --
> > View this message in context:
> http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4257651.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
> >
> >
>
>
>
> --
> Chanwit Kaewkasi
> code.google.com/p/zkgrails
> twitter.com/chanwit
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
Rodrigo Rosenfeld Rosas
2012-01-03 18:37:40 UTC
Permalink
Gavin is both right and wrong.

You would be making you a favor by buying you some 8GB RAM and throwing
away your 2GB in whatever environment you might decide to work with. RAM
is very cheap nowadays that it pays off very quickly if you count your
more efficiently used developer's hours.

But Java apps doesn't really need to be memory monsters. It turns out
that Grails specifically requires an absurd amount of memory for a good
development environment where you'll want to reload your classes many times.

There are lots of adjustments that can be done to the JVM. Using default
settings in my environment, an IRB session using JRuby will take about
50MB, while a groovysh session will take 140MB. I usually set my
GRAILS_OPTS to:

-server -Xmx512M -XX:MaxPermSize=512m -Dfile.encoding=UTF-8
-Dserver.port=8081

Your app's memory requirements might be lower than mine.

An empty JRuby on Rails application would require about 300MB with
default settings in my environment.

Em 03-01-2012 15:28, Gavin Yue escreveu:
> 2GB memory could also be a problem....
>
> Java app is really memory monster.
>
>
>
> On Tue, Jan 3, 2012 at 9:23 AM, Chanwit Kaewkasi <***@gmail.com
> <mailto:***@gmail.com>> wrote:
>
> Hi,
>
> My best guess is probably JDK7.
>
> Cheers
>
> Chanwit
>
Roberto Guerra
2012-01-03 18:50:06 UTC
Permalink
Rodrigo, I believe you are wrong. I develop personal grails projects on an
hp laptop with 2GB of RAM, Centrino Processor running Ubuntu + WindowMaker
and have no issues. It performs just as well as it does on my workstation
with 16GB of RAM + Core 2 vPro. I don't use any IDE on my laptop, because
those slow me down. The suggestions by Gavin are really good and there is
nothing wrong with grails' performance.

On Tue, Jan 3, 2012 at 12:37 PM, Rodrigo Rosenfeld Rosas <
***@yahoo.com.br> wrote:

> **
> Gavin is both right and wrong.
>
> You would be making you a favor by buying you some 8GB RAM and throwing
> away your 2GB in whatever environment you might decide to work with. RAM is
> very cheap nowadays that it pays off very quickly if you count your more
> efficiently used developer's hours.
>
> But Java apps doesn't really need to be memory monsters. It turns out that
> Grails specifically requires an absurd amount of memory for a good
> development environment where you'll want to reload your classes many times.
>
> There are lots of adjustments that can be done to the JVM. Using default
> settings in my environment, an IRB session using JRuby will take about
> 50MB, while a groovysh session will take 140MB. I usually set my
> GRAILS_OPTS to:
>
> -server -Xmx512M -XX:MaxPermSize=512m -Dfile.encoding=UTF-8
> -Dserver.port=8081
>
> Your app's memory requirements might be lower than mine.
>
> An empty JRuby on Rails application would require about 300MB with default
> settings in my environment.
>
> Em 03-01-2012 15:28, Gavin Yue escreveu:
>
> 2GB memory could also be a problem....
>
> Java app is really memory monster.
>
>
>
> On Tue, Jan 3, 2012 at 9:23 AM, Chanwit Kaewkasi <***@gmail.com>wrote:
>
>> Hi,
>>
>> My best guess is probably JDK7.
>>
>> Cheers
>>
>> Chanwit
>>
>
>


--
*The Journey Is The Reward.
*
Rodrigo Rosenfeld Rosas
2012-01-03 20:31:26 UTC
Permalink
Em 03-01-2012 16:50, Roberto Guerra escreveu:
> Rodrigo, I believe you are wrong. I develop personal grails projects
> on an hp laptop with 2GB of RAM, Centrino Processor running Ubuntu +
> WindowMaker and have no issues. It performs just as well as it does on
> my workstation with 16GB of RAM + Core 2 vPro. I don't use any IDE on
> my laptop, because those slow me down. The suggestions by Gavin are
> really good and there is nothing wrong with grails' performance.
>

I didn't say that Grails performance was bad. I just said it requires a
lot of RAM for development when compared to plain Ruby on Rails, for
instance.

And you're only able to develop on Grails with 2GB of RAM because you're
running no Java-based IDE and WindowMaker...

> On Tue, Jan 3, 2012 at 12:37 PM, Rodrigo Rosenfeld Rosas
> <***@yahoo.com.br <mailto:***@yahoo.com.br>> wrote:
>
> Gavin is both right and wrong.
>
> You would be making you a favor by buying you some 8GB RAM and
> throwing away your 2GB in whatever environment you might decide to
> work with. RAM is very cheap nowadays that it pays off very
> quickly if you count your more efficiently used developer's hours.
>
> But Java apps doesn't really need to be memory monsters. It turns
> out that Grails specifically requires an absurd amount of memory
> for a good development environment where you'll want to reload
> your classes many times.
>
> There are lots of adjustments that can be done to the JVM. Using
> default settings in my environment, an IRB session using JRuby
> will take about 50MB, while a groovysh session will take 140MB. I
> usually set my GRAILS_OPTS to:
>
> -server -Xmx512M -XX:MaxPermSize=512m -Dfile.encoding=UTF-8
> -Dserver.port=8081
>
> Your app's memory requirements might be lower than mine.
>
> An empty JRuby on Rails application would require about 300MB with
> default settings in my environment.
>
> Em 03-01-2012 15:28, Gavin Yue escreveu:
>> 2GB memory could also be a problem....
>>
>> Java app is really memory monster.
>>
>>
>>
>> On Tue, Jan 3, 2012 at 9:23 AM, Chanwit Kaewkasi
>> <***@gmail.com <mailto:***@gmail.com>> wrote:
>>
>> Hi,
>>
>> My best guess is probably JDK7.
>>
>> Cheers
>>
>> Chanwit
>>
>
>
Roberto Guerra
2012-01-03 21:09:39 UTC
Permalink
On Tue, Jan 3, 2012 at 2:31 PM, Rodrigo Rosenfeld Rosas <
***@yahoo.com.br> wrote:

> **
> Em 03-01-2012 16:50, Roberto Guerra escreveu:
>
> Rodrigo, I believe you are wrong. I develop personal grails projects on an
> hp laptop with 2GB of RAM, Centrino Processor running Ubuntu + WindowMaker
> and have no issues. It performs just as well as it does on my workstation
> with 16GB of RAM + Core 2 vPro. I don't use any IDE on my laptop, because
> those slow me down. The suggestions by Gavin are really good and there is
> nothing wrong with grails' performance.
>
>
> I didn't say that Grails performance was bad. I just said it requires a
> lot of RAM for development when compared to plain Ruby on Rails, for
> instance.
>
> And you're only able to develop on Grails with 2GB of RAM because you're
> running no Java-based IDE and WindowMaker...
>

Which is what someone said before. That if you are also running an IDE,
they take up lots of resources, and it wouldn't be productive enough to do
so with just 2GB of RAM. And apparently the op also had some other
programmes running which just made matters worse (and on top of W7). If you
want to use an IDE to programme in any language, u need more RAM than if
you were not using one. It applies to groovy, java, C++, ruby, etc. You
somehow were placing all the blame on grails for being a resource hog
without any real proof. If it were so bad I wouldn't be able to deploy 3
grails app + 1 java app on the same server with only 6GB of RAM.

>
>
> On Tue, Jan 3, 2012 at 12:37 PM, Rodrigo Rosenfeld Rosas <
> ***@yahoo.com.br> wrote:
>
>> Gavin is both right and wrong.
>>
>> You would be making you a favor by buying you some 8GB RAM and throwing
>> away your 2GB in whatever environment you might decide to work with. RAM is
>> very cheap nowadays that it pays off very quickly if you count your more
>> efficiently used developer's hours.
>>
>> But Java apps doesn't really need to be memory monsters. It turns out
>> that Grails specifically requires an absurd amount of memory for a good
>> development environment where you'll want to reload your classes many times.
>>
>> There are lots of adjustments that can be done to the JVM. Using default
>> settings in my environment, an IRB session using JRuby will take about
>> 50MB, while a groovysh session will take 140MB. I usually set my
>> GRAILS_OPTS to:
>>
>> -server -Xmx512M -XX:MaxPermSize=512m -Dfile.encoding=UTF-8
>> -Dserver.port=8081
>>
>> Your app's memory requirements might be lower than mine.
>>
>> An empty JRuby on Rails application would require about 300MB with
>> default settings in my environment.
>>
>> Em 03-01-2012 15:28, Gavin Yue escreveu:
>>
>> 2GB memory could also be a problem....
>>
>> Java app is really memory monster.
>>
>>
>>
>> On Tue, Jan 3, 2012 at 9:23 AM, Chanwit Kaewkasi <***@gmail.com>wrote:
>>
>>> Hi,
>>>
>>> My best guess is probably JDK7.
>>>
>>> Cheers
>>>
>>> Chanwit
>>>
>>
>>
>
>


--
*Brother let your heart be wounded
*
*And give no mercy to your fear*
Rodrigo Rosenfeld Rosas
2012-01-03 21:39:17 UTC
Permalink
Em 03-01-2012 19:09, Roberto Guerra escreveu:
>
>
> On Tue, Jan 3, 2012 at 2:31 PM, Rodrigo Rosenfeld Rosas
> <***@yahoo.com.br <mailto:***@yahoo.com.br>> wrote:
>
> Em 03-01-2012 16:50, Roberto Guerra escreveu:
>> Rodrigo, I believe you are wrong. I develop personal grails
>> projects on an hp laptop with 2GB of RAM, Centrino Processor
>> running Ubuntu + WindowMaker and have no issues. It performs just
>> as well as it does on my workstation with 16GB of RAM + Core 2
>> vPro. I don't use any IDE on my laptop, because those slow me
>> down. The suggestions by Gavin are really good and there is
>> nothing wrong with grails' performance.
>>
>
> I didn't say that Grails performance was bad. I just said it
> requires a lot of RAM for development when compared to plain Ruby
> on Rails, for instance.
>
> And you're only able to develop on Grails with 2GB of RAM because
> you're running no Java-based IDE and WindowMaker...
>
>
> Which is what someone said before. That if you are also running an
> IDE, they take up lots of resources, and it wouldn't be productive
> enough to do so with just 2GB of RAM. And apparently the op also had
> some other programmes running which just made matters worse (and on
> top of W7). If you want to use an IDE to programme in any language, u
> need more RAM than if you were not using one. It applies to groovy,
> java, C++, ruby, etc. You somehow were placing all the blame on grails
> for being a resource hog without any real proof. If it were so bad I
> wouldn't be able to deploy 3 grails app + 1 java app on the same
> server with only 6GB of RAM.

Actually, I was able to run KDE, Netbeans and Rails in my old computer
in 2007 with only 1GB of RAM and it wasn't a bad experience at all at
that time...

I'm just saying that Grails has more memory requirements than other
alternatives...
virtualeyes
2012-01-04 21:51:20 UTC
Permalink
Well, Peter Ledbrook is the Grails advocate and you are the Rails advocate --
I remember your blog post, it had some merit ;-)

The guy needs more ram followed by command line:
grails> run-app

then, whenever a restart is needed (e.g. change a domain class)
type 'exit'

followed by run-app again.

While the instruction to type 'exit' is right there, for literally months I
just ctrl-c'd the process, hating Grails the entire time, thinking how slow
it was to restart, there must be better X framework, etc., etc. In the end,
'exit' keeps the VM running and restarts, when necessary, take 1 or 2
seconds tops, including bootstrapping a bunch of DB data.

Oh the irony of misguided malice ;-)

There should be some documentation in massive, huge bold type to clue-in new
users to this fact. Could have just been me, but perhaps some of the "grails
is slow" reputation comes from this user error. The reality is that Grails
is in fact absurdly fast to restart, faster than or as fast as, cough-cough,
Rails.

Now, I have other gripes with the framework, specifically related to
collection:
1) binding
2) interception (e.g beforeValidate) on associations
3) bean-fields (argh!) ;-)

but then again I have yet to see any framework handle collections elegantly,
so take the great with the mediocre I guess...

--
View this message in context: http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4263023.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
Stephane Maldini
2012-01-04 22:01:32 UTC
Permalink
I didn't read the whole thread but I found the virtualeyes reply very
interesting and the 3 mentioned negative points are indeed a reality.

As far as I know , Bean Fields 2 is on his way thx to Robert Fletcher,
Binding is receiving some love in Grails 2 with signature params on method
actions and finally - not really related to interception on associations
but close to - we have a simple, general concern and flexible event system
coming.

On Wed, Jan 4, 2012 at 10:51 PM, virtualeyes <***@hotmail.com> wrote:

> Well, Peter Ledbrook is the Grails advocate and you are the Rails advocate
> --
> I remember your blog post, it had some merit ;-)
>
> The guy needs more ram followed by command line:
> grails> run-app
>
> then, whenever a restart is needed (e.g. change a domain class)
> type 'exit'
>
> followed by run-app again.
>
> While the instruction to type 'exit' is right there, for literally months I
> just ctrl-c'd the process, hating Grails the entire time, thinking how slow
> it was to restart, there must be better X framework, etc., etc. In the end,
> 'exit' keeps the VM running and restarts, when necessary, take 1 or 2
> seconds tops, including bootstrapping a bunch of DB data.
>
> Oh the irony of misguided malice ;-)
>
> There should be some documentation in massive, huge bold type to clue-in
> new
> users to this fact. Could have just been me, but perhaps some of the
> "grails
> is slow" reputation comes from this user error. The reality is that Grails
> is in fact absurdly fast to restart, faster than or as fast as,
> cough-cough,
> Rails.
>
> Now, I have other gripes with the framework, specifically related to
> collection:
> 1) binding
> 2) interception (e.g beforeValidate) on associations
> 3) bean-fields (argh!) ;-)
>
> but then again I have yet to see any framework handle collections
> elegantly,
> so take the great with the mediocre I guess...
>
> --
> View this message in context:
> http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4263023.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
>
>
>


--
*Stéphane MALDINI*
--
Peter Ledbrook
2012-01-05 09:15:19 UTC
Permalink
On the original problem, I recommend using the jconsole command to
investigate the memory usage of Grails. It comes with the JDK, has a
UI, and is pretty easy to use. It's particularly useful for seeing how
close to maximum usage of the heap you are. If it's mostly filled,
then Grails will become very slow because of garbage collection churn.

> The guy needs more ram followed by command line:
> grails> run-app
>
> then, whenever a restart is needed (e.g. change a domain class)
> type 'exit'
>
> followed by run-app again.
>
> While the instruction to type 'exit' is right there, for literally months I
> just ctrl-c'd the process, hating Grails the entire time, thinking how slow
> it was to restart, there must be better X framework, etc., etc. In the end,
> 'exit' keeps the VM running and restarts, when necessary, take 1 or 2
> seconds tops, including bootstrapping a bunch of DB data.

I would like to see a stop app command. In fact, I wrote one:
http://pastebin.com/S1YTJmGx

Peter

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

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

http://xircles.codehaus.org/manage_email
John Fletcher
2012-01-05 09:52:11 UTC
Permalink
Raffaele,

There have been some good but perhaps confusing suggestions on this thread.
Here is what I would do - ignore the installation and everything else you
already have done (you can just leave it all as is), and go to
http://www.grails.org/Documentation and follow steps 1 and 2 (i.e.
Installation and Quick Start), installing to C:\Grails. Once you have
created the hello world app (i.e. completed sections 2.4 and 2.5), let us
know whether running grails run-app in your hello world application is fast
or slow. Then you and we will have further information to work from.
John

*You're old enough to make your own decisions about the environment without
me telling you what you should and shouldn't print. But if you do print, I
hope this signature doesn't cause the message to go onto an additional
page. Because that would be kind of stupid, wouldn't it?*
raffaele181188
2012-01-05 11:38:38 UTC
Permalink
Without STS everything seems a little faster. But still I want to use an
IDE. Moreover, I have monitored both RAM and CPU usage and both are around
70% at most. It seems that grails it's just slow! It's very strange...
Also, trying to request the page via browser takes too long.. Several
second after I have just saved a file.
Do you experience this "slow" development cycle? Is it normal or is it just
on my machine?

Raffaele

2012/1/5 John Fletcher-3 [via Grails] <
ml-node+***@n4.nabble.com>

> Raffaele,
>
> There have been some good but perhaps confusing suggestions on this
> thread. Here is what I would do - ignore the installation and everything
> else you already have done (you can just leave it all as is), and go to
> http://www.grails.org/Documentation and follow steps 1 and 2 (i.e.
> Installation and Quick Start), installing to C:\Grails. Once you have
> created the hello world app (i.e. completed sections 2.4 and 2.5), let us
> know whether running grails run-app in your hello world application is
> fast or slow. Then you and we will have further information to work from.
> John
>
> *You're old enough to make your own decisions about the environment
> without me telling you what you should and shouldn't print. But if you do
> print, I hope this signature doesn't cause the message to go onto an
> additional page. Because that would be kind of stupid, wouldn't it?*
>
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4264886.html
> To unsubscribe from Grails development is really slow, click here<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4257651&code=cmFmZmFlbGVzZ2Fycm9AZ21haWwuY29tfDQyNTc2NTF8LTE3Njk1MDM5MDc=>
> .
> NAML<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>


--
View this message in context: http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265151.html
Sent from the Grails - user mailing list archive at Nabble.com.
John Fletcher
2012-01-05 13:08:29 UTC
Permalink
How long does it take to create a domain or controller now?

John

2012/1/5 raffaele181188 <***@gmail.com>

> Without STS everything seems a little faster. But still I want to use an
> IDE. Moreover, I have monitored both RAM and CPU usage and both are around
> 70% at most. It seems that grails it's just slow! It's very strange...
> Also, trying to request the page via browser takes too long.. Several
> second after I have just saved a file.
> Do you experience this "slow" development cycle? Is it normal or is it
> just on my machine?
>
> Raffaele
>
> 2012/1/5 John Fletcher-3 [via Grails] <[hidden email]<http://user/SendEmail.jtp?type=node&node=4265151&i=0>
> >
>
>> Raffaele,
>>
>> There have been some good but perhaps confusing suggestions on this
>> thread. Here is what I would do - ignore the installation and everything
>> else you already have done (you can just leave it all as is), and go to
>> http://www.grails.org/Documentation and follow steps 1 and 2 (i.e.
>> Installation and Quick Start), installing to C:\Grails. Once you have
>> created the hello world app (i.e. completed sections 2.4 and 2.5), let us
>> know whether running grails run-app in your hello world application is
>> fast or slow. Then you and we will have further information to work from.
>> John
>>
>> *You're old enough to make your own decisions about the environment
>> without me telling you what you should and shouldn't print. But if you do
>> print, I hope this signature doesn't cause the message to go onto an
>> additional page. Because that would be kind of stupid, wouldn't it?*
>>
>>
>>
>> ------------------------------
>> If you reply to this email, your message will be added to the
>> discussion below:
>>
>> http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4264886.html
>> To unsubscribe from Grails development is really slow, click here.
>> NAML<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>
>
> ------------------------------
> View this message in context: Re: Grails development is really slow<http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265151.html>
> Sent from the Grails - user mailing list archive<http://grails.1312388.n4.nabble.com/Grails-user-f1312389.html>at Nabble.com.
>
Lari Hotari
2012-01-05 13:12:15 UTC
Permalink
Since you have only 2GB RAM, it might be worth adjusting GRAILS_OPTS
env. variable to lower values.

In Grails 2.0, the default is:
GRAILS_OPTS=-server -Xmx768M -Xms768M -XX:PermSize=256m
-XX:MaxPermSize=256m -Dfile.encoding=UTF-8

You could try:
GRAILS_OPTS=-server -Xmx600M -Xms600M -XX:PermSize=200m
-XX:MaxPermSize=200m -Dfile.encoding=UTF-8

(In windows, set GRAILS_OPTS in the same place (My
computer->properties->advanced->environment variables) as you would
modify the PATH setting)

--
Some other points to verify:

On windows, you might want to add the HOME_DIR/.grails to the exclusions
of your Anti-virus software. The same applies to your Grails's project
directory.
Many anti-virus packages automaticly scan all new files and changed
files and that causes a lot of overhead (some anti-virus packages even
unzip jar files and scan the included files on the fly).

If it's still slow, try removing HOME_DIR/.grails/.slcache directory
(it's the cache directory of the Spring Loaded Java agent that Grails
2.0 uses for reloading). (I've experienced that problem once before in
Grails 2.0 pre-release versions; it made everything extremely slow and
it got fixed by cleaning the .grails/.slcache dir).



Lari


05.01.2012 13:38, raffaele181188 wrote:
> Without STS everything seems a little faster. But still I want to use
> an IDE. Moreover, I have monitored both RAM and CPU usage and both are
> around 70% at most. It seems that grails it's just slow! It's very
> strange... Also, trying to request the page via browser takes too
> long.. Several second after I have just saved a file.
> Do you experience this "slow" development cycle? Is it normal or is it
> just on my machine?
>
> Raffaele
>
> 2012/1/5 John Fletcher-3 [via Grails] <[hidden email]
> </user/SendEmail.jtp?type=node&node=4265151&i=0>>
>
> Raffaele,
>
> There have been some good but perhaps confusing suggestions on
> this thread. Here is what I would do - ignore the installation and
> everything else you already have done (you can just leave it all
> as is), and go to http://www.grails.org/Documentation and follow
> steps 1 and 2 (i.e. Installation and Quick Start), installing to
> C:\Grails. Once you have created the hello world app (i.e.
> completed sections 2.4 and 2.5), let us know whether runninggrails
> run-app in your hello world application is fast or slow. Then you
> and we will have further information to work from.
> John
>
> /You're old enough to make your own decisions about the
> environment without me telling you what you should and shouldn't
> print. But if you do print, I hope this signature doesn't cause
> the message to go onto an additional page. Because that would be
> kind of stupid, wouldn't it?/
>
>
>
> ------------------------------------------------------------------------
> If you reply to this email, your message will be added to the
> discussion below:
> http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4264886.html
>
> To unsubscribe from Grails development is really slow, click here.
> NAML
> <http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
>
>
>
> ------------------------------------------------------------------------
> View this message in context: Re: Grails development is really slow
> <http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265151.html>
> Sent from the Grails - user mailing list archive
> <http://grails.1312388.n4.nabble.com/Grails-user-f1312389.html> at
> Nabble.com.
Lari Hotari
2012-01-05 13:15:37 UTC
Permalink
A Stackoverflow answer related to Eclipse performance and Windows
anti-virus software settings:
http://stackoverflow.com/a/2434369/166062

Lari

05.01.2012 15:12, Lari Hotari wrote:
>
> Since you have only 2GB RAM, it might be worth adjusting GRAILS_OPTS
> env. variable to lower values.
>
> In Grails 2.0, the default is:
> GRAILS_OPTS=-server -Xmx768M -Xms768M -XX:PermSize=256m
> -XX:MaxPermSize=256m -Dfile.encoding=UTF-8
>
> You could try:
> GRAILS_OPTS=-server -Xmx600M -Xms600M -XX:PermSize=200m
> -XX:MaxPermSize=200m -Dfile.encoding=UTF-8
>
> (In windows, set GRAILS_OPTS in the same place (My
> computer->properties->advanced->environment variables) as you would
> modify the PATH setting)
>
> --
> Some other points to verify:
>
> On windows, you might want to add the HOME_DIR/.grails to the
> exclusions of your Anti-virus software. The same applies to your
> Grails's project directory.
> Many anti-virus packages automaticly scan all new files and changed
> files and that causes a lot of overhead (some anti-virus packages even
> unzip jar files and scan the included files on the fly).
>
> If it's still slow, try removing HOME_DIR/.grails/.slcache directory
> (it's the cache directory of the Spring Loaded Java agent that Grails
> 2.0 uses for reloading). (I've experienced that problem once before in
> Grails 2.0 pre-release versions; it made everything extremely slow and
> it got fixed by cleaning the .grails/.slcache dir).
>
>
>
> Lari
>
>
> 05.01.2012 13:38, raffaele181188 wrote:
>> Without STS everything seems a little faster. But still I want to use
>> an IDE. Moreover, I have monitored both RAM and CPU usage and both
>> are around 70% at most. It seems that grails it's just slow! It's
>> very strange... Also, trying to request the page via browser takes
>> too long.. Several second after I have just saved a file.
>> Do you experience this "slow" development cycle? Is it normal or is
>> it just on my machine?
>>
>> Raffaele
>>
>> 2012/1/5 John Fletcher-3 [via Grails] <[hidden email]
>> </user/SendEmail.jtp?type=node&node=4265151&i=0>>
>>
>> Raffaele,
>>
>> There have been some good but perhaps confusing suggestions on
>> this thread. Here is what I would do - ignore the installation
>> and everything else you already have done (you can just leave it
>> all as is), and go to http://www.grails.org/Documentation and
>> follow steps 1 and 2 (i.e. Installation and Quick Start),
>> installing to C:\Grails. Once you have created the hello world
>> app (i.e. completed sections 2.4 and 2.5), let us know whether
>> runninggrails run-app in your hello world application is fast or
>> slow. Then you and we will have further information to work from.
>> John
>>
>> /You're old enough to make your own decisions about the
>> environment without me telling you what you should and shouldn't
>> print. But if you do print, I hope this signature doesn't cause
>> the message to go onto an additional page. Because that would be
>> kind of stupid, wouldn't it?/
>>
>>
>>
>> ------------------------------------------------------------------------
>> If you reply to this email, your message will be added to the
>> discussion below:
>> http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4264886.html
>>
>> To unsubscribe from Grails development is really slow, click here.
>> NAML
>> <http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>> View this message in context: Re: Grails development is really slow
>> <http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265151.html>
>> Sent from the Grails - user mailing list archive
>> <http://grails.1312388.n4.nabble.com/Grails-user-f1312389.html> at
>> Nabble.com.
>
Rodrigo Rosenfeld Rosas
2012-01-05 13:22:08 UTC
Permalink
Em 05-01-2012 09:38, raffaele181188 escreveu:
> Without STS everything seems a little faster. But still I want to use
> an IDE. Moreover, I have monitored both RAM and CPU usage and both are
> around 70% at most. It seems that grails it's just slow! It's very
> strange... Also, trying to request the page via browser takes too
> long.. Several second after I have just saved a file.
> Do you experience this "slow" development cycle? Is it normal or is it
> just on my machine?
>

No, Raffaele, it shouldn't be that slow. You should really consider the
advice on buying 8GB of RAM. It will save you lot of time even if you
decide for not using Grails at all. And time is money (usually).

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

http://xircles.codehaus.org/manage_email
Peter Ledbrook
2012-01-05 19:34:37 UTC
Permalink
> Also, trying to request the page via browser takes too long.. Several
second after I have just saved a file.
> Do you experience this "slow" development cycle? Is it normal or is it
just on my machine?

It can take anywhere between 0 and 3 seconds for a change to compile and
appear in the browser. It's not perfect, but is it really such a problem?
Hopefully we'll be able to take advantage of Java 7's file system
notifications in future, which should help.

I think if you accept the slight delay, you'll soon be able to focus on the
benefits of Grails and Java.

Peter


--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware
raffaele181188
2012-01-05 19:48:30 UTC
Permalink
Sure, I can wait 3 seconds. But often the browser is simply stuck, so I
have to wait 30seconds, then -after realized there must be something wrong-
I stop and restart the http server... so it's over 1 minute

2012/1/5 pledbrook [via Grails] <ml-node+***@n4.nabble.com>

>
> > Also, trying to request the page via browser takes too long.. Several
> second after I have just saved a file.
> > Do you experience this "slow" development cycle? Is it normal or is it
> just on my machine?
>
> It can take anywhere between 0 and 3 seconds for a change to compile and
> appear in the browser. It's not perfect, but is it really such a problem?
> Hopefully we'll be able to take advantage of Java 7's file system
> notifications in future, which should help.
>
> I think if you accept the slight delay, you'll soon be able to focus on
> the benefits of Grails and Java.
>
>
> Peter
>
>
> --
> Peter Ledbrook
> Grails Advocate
> SpringSource - A Division of VMware
>
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4266728.html
> To unsubscribe from Grails development is really slow, click here<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4257651&code=cmFmZmFlbGVzZ2Fycm9AZ21haWwuY29tfDQyNTc2NTF8LTE3Njk1MDM5MDc=>
> .
> NAML<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>


--
View this message in context: http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4266767.html
Sent from the Grails - user mailing list archive at Nabble.com.
Peter Ledbrook
2012-01-06 09:23:45 UTC
Permalink
> Sure, I can wait 3 seconds. But often the browser is simply stuck, so I have
> to wait 30seconds, then -after realized there must be something wrong- I
> stop and restart the http server... so it's over 1 minute

That should definitely not be happening. I'll try on my home Windows 7
box over the weekend. With the hanging requests, I recommend trying an
alternative browser before restarting the app. I noticed Chrome
occasionally having issues where Firefox would be fine.

Peter

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

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

http://xircles.codehaus.org/manage_email
Rodrigo Rosenfeld Rosas
2012-01-06 12:44:06 UTC
Permalink
Em 06-01-2012 07:23, Peter Ledbrook escreveu:
>> Sure, I can wait 3 seconds. But often the browser is simply stuck, so I have
>> to wait 30seconds, then -after realized there must be something wrong- I
>> stop and restart the http server... so it's over 1 minute
> ...With the hanging requests, I recommend trying an
> alternative browser before restarting the app.*I noticed Chrome
> occasionally having issues* where Firefox would be fine.

Yes, I've noticed that too while implementing a Server-Sent Events
implementation in a Grails controller's action. While indexing documents
with Solr, it will take a while and I'd like to notify the users with
the progress.

While testing, I've opened two browsers session in Chrome but the second
one wouldn't render anything before the first request completed. At
first I thought it was a Grails bug, but then, while testing in Firefox
I didn't notice this issue.

I'm using Chrome unstable repository here, but it is a good advice to
try another browser like Opera or Firefox if you're using Chrome to
avoid some strange issues we're noticing on Chrome lately...
John Thompson
2012-01-06 12:33:40 UTC
Permalink
STS is not that great. Get a copy of IntelliJ 11 if you can afford it. Its
FAR better for Groovy/Grails development.

-----
JT
jts-blog.com
--
View this message in context: http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4269222.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
Rodrigo Rosenfeld Rosas
2012-01-05 13:17:45 UTC
Permalink
Hi virtualeyes,

Em 04-01-2012 19:51, virtualeyes escreveu:
> ... The reality is that Grails
> is in fact absurdly fast to restart, faster than or as fast as, cough-cough,
> Rails.

I have no idea where you did take your estimates from. In my PC, Grails
takes from 36 to 40s to boot an empty app, while JRuby on Rails takes
about 16s and Rails itself (on CRuby) takes a single second. I guess you
were talking about using the interactive console for booting the Grails
app. In that case, for an empty app, it takes about 2 seconds here,
which is still a bit slower than vanilla Rails, but certainly much
faster than JRuby on Rails.

But anyway, I'm not really much concerned about the time required to
boot the application as long as I only have to do it once. My main gripe
with Grails 1.3.7 is that it would reboot after each little change to my
domain classes and other source files, and that took a huge time.

Now, with Grails 2, even without the interactive console, the user
experience is much better as I don't need to often reboot the
application. The interactive console just makes Grails even more
responsive. But in the expense of subtle bugs that will show up when
using the interactive console that wouldn't be present otherwise...

The main disadvantage of a slow bootup time (in any
framework/environment) is that it makes running your integration tests
slower. While using Rspec for writing tests for Rails, one can use Spork
that will take a similar approach to the one taken from Grails
interactive console, that will make tests run much faster.

So, that article that you mentioned is certainly out-of-date and I need
to rewrite it when I find some time. I'll write a new one and add a
deprecation note on that one when I'm done for keeping the old comments.

My main gripe with Grails currently is that I find it very hard to debug
and find what is causing troubles in my application setup. I often have
to create a fresh Grails app and gradually copy my files to there until
I find the source of the problem.

The Grails error messages don't give me a single clue about the problem
most of the times. That is not to say that I have no more issues with
Grails. I don't like it in many ways, but I find the over-complex black
magic behind Grails the one that takes be most of the time when I'm
trying to identify some issues.

Also, I find that the Grails community has poor support when compared
with the Rails and Ruby one. I have lots of unanswered messages in this
list where I point to buggy scenarios or plugins.

For, example, I've filled two bugs in the Rails issues system last year,
and both were fixed and commited in less than an hour:

https://github.com/rails/rails/issues/4054
https://github.com/rails/rails/issues/4067

In the other side, here are some bugs (or feature requests) I've
reported to the Grails JIRA:

http://jira.grails.org/browse/GRAILS-8568
http://jira.grails.org/browse/GRAILS-8567
http://jira.grails.org/browse/GPCONSOLE-3
http://jira.grails.org/browse/GRAILS-8539 (I'm the only one
participating on this one, for example)
http://jira.grails.org/browse/GRAILS-8485
http://jira.grails.org/browse/GRAILS-7792 (feature request)
http://jira.grails.org/browse/GRAILS-3303 (closed as won't fix, although
I think it could be fixed...)
https://github.com/SpringSource/grails-data-mapping/issues/18

Unanswered messages in this list:

http://grails.1312388.n4.nabble.com/Strange-issue-with-Grails-2-and-find-with-closure-td4222761.html
http://grails.1312388.n4.nabble.com/mongodb-and-hibernate-are-not-playing-well-together-td4222229.html
this wasn't answered. It was just told me to not report bugs in the dev
mailing list, but I didn't get any reply in the user's list too
http://grails.1312388.n4.nabble.com/MongoDB-and-multiple-databases-not-talking-about-replication-td4210794.html
just a minor part of the message was answered
http://grails.1312388.n4.nabble.com/Is-there-an-easy-way-to-set-default-mapping-options-to-all-columns-of-some-GORM-class-td4210934.html
http://grails.1312388.n4.nabble.com/mongodb-plugin-and-quot-static-mapping-version-false-quot-why-does-the-quot-version-quot-key-is-adde-td4210920.html
http://grails.1312388.n4.nabble.com/Grails-resources-plugin-still-uses-deprecated-ConfigurationHolder-td4208027.html
http://grails.1312388.n4.nabble.com/grails-shell-will-raise-an-exception-while-trying-to-autocomplete-a-Map-td4205530.html
http://grails.1312388.n4.nabble.com/Can-t-upgrade-to-Grails-2-from-1-3-7-and-have-no-clue-all-requests-yields-to-404-status-td4178489.html
http://www.digipedia.pl/usenet/thread/14352/30474/
http://grails.1312388.n4.nabble.com/How-to-write-scripts-using-GORM-enabled-domain-classes-td3868599.html
(I've got only a suggestion to use another testing framework, but didn't
get a real answer to what I was asking for)
http://grails.1312388.n4.nabble.com/Grails-scripts-help-td3867976.html


Also, besides free time, I still need some more time experimenting with
Grails 2 before I can write the new article on the subject...

Best,

Rodrigo.


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

http://xircles.codehaus.org/manage_email
Graeme Rocher
2012-01-05 13:43:04 UTC
Permalink
On Thu, Jan 5, 2012 at 2:17 PM, Rodrigo Rosenfeld Rosas
<***@yahoo.com.br> wrote:
> Hi virtualeyes,
>
> Em 04-01-2012 19:51, virtualeyes escreveu:
>>
>> ...  The reality is that Grails
>>
>> is in fact absurdly fast to restart, faster than or as fast as,
>> cough-cough,
>> Rails.
>
>
> I have no idea where you did take your estimates from. In my PC, Grails
> takes from 36 to 40s to boot an empty app, while JRuby on Rails takes about
> 16s and Rails itself (on CRuby) takes a single second. I guess you were
> talking about using the interactive console for booting the Grails app. In
> that case, for an empty app, it takes about 2 seconds here, which is still a
> bit slower than vanilla Rails, but certainly much faster than JRuby on
> Rails.
>
> But anyway, I'm not really much concerned about the time required to boot
> the application as long as I only have to do it once. My main gripe with
> Grails 1.3.7 is that it would reboot after each little change to my domain
> classes and other source files, and that took a huge time.
>
> Now, with Grails 2, even without the interactive console, the user
> experience is much better as I don't need to often reboot the application.
> The interactive console just makes Grails even more responsive. But in the
> expense of subtle bugs that will show up when using the interactive console
> that wouldn't be present otherwise...
>
> The main disadvantage of a slow bootup time (in any framework/environment)
> is that it makes running your integration tests slower. While using Rspec
> for writing tests for Rails, one can use Spork that will take a similar
> approach to the one taken from Grails interactive console, that will make
> tests run much faster.
>
> So, that article that you mentioned is certainly out-of-date and I need to
> rewrite it when I find some time. I'll write a new one and add a deprecation
> note on that one when I'm done for keeping the old comments.
>
> My main gripe with Grails currently is that I find it very hard to debug and
> find what is causing troubles in my application setup. I often have to
> create a fresh Grails app and gradually copy my files to there until I find
> the source of the problem.
>
> The Grails error messages don't give me a single clue about the problem most
> of the times. That is not to say that I have no more issues with Grails. I
> don't like it in many ways, but I find the over-complex black magic behind
> Grails the one that takes be most of the time when I'm trying to identify
> some issues.
>
> Also, I find that the Grails community has poor support when compared with
> the Rails and Ruby one. I have lots of unanswered messages in this list
> where I point to buggy scenarios or plugins.


Many of your issues (understandably) come from the perspective of a
Rails developer. The fact that you have are upset that you have
unanswered questions on integrating a Ruby testing framework into
Grails does surprise me however.

You would also get your issues fixed quicker if you provided
reproducible steps in the issues you raised. Most of your reports are
incomplete / don't have examples attached and amount to "something
doesn't work" instead of providing accurate steps to reproduce the
problem. They are reactionary and tend to be unhelpful.

You'll notice that users who report issues with actual examples
(attached example applications or test cases) get their issues fixed a
lot quicker.

You also frequently use the mailing list to report issues instead of
JIRA, if you believe you have identified a bug then raise a JIRA.
Emailing the developer list doesn't help either.

Cheers
>
> For, example, I've filled two bugs in the Rails issues system last year, and
> both were fixed and commited in less than an hour:
>
> https://github.com/rails/rails/issues/4054
> https://github.com/rails/rails/issues/4067
>
> In the other side, here are some bugs (or feature requests) I've reported to
> the Grails JIRA:
>
> http://jira.grails.org/browse/GRAILS-8568
> http://jira.grails.org/browse/GRAILS-8567
> http://jira.grails.org/browse/GPCONSOLE-3
> http://jira.grails.org/browse/GRAILS-8539 (I'm the only one participating on
> this one, for example)
> http://jira.grails.org/browse/GRAILS-8485
> http://jira.grails.org/browse/GRAILS-7792 (feature request)
> http://jira.grails.org/browse/GRAILS-3303 (closed as won't fix, although I
> think it could be fixed...)
> https://github.com/SpringSource/grails-data-mapping/issues/18
>
> Unanswered messages in this list:
>
> http://grails.1312388.n4.nabble.com/Strange-issue-with-Grails-2-and-find-with-closure-td4222761.html
> http://grails.1312388.n4.nabble.com/mongodb-and-hibernate-are-not-playing-well-together-td4222229.html
> this wasn't answered. It was just told me to not report bugs in the dev
> mailing list, but I didn't get any reply in the user's list too
> http://grails.1312388.n4.nabble.com/MongoDB-and-multiple-databases-not-talking-about-replication-td4210794.html
> just a minor part of the message was answered
> http://grails.1312388.n4.nabble.com/Is-there-an-easy-way-to-set-default-mapping-options-to-all-columns-of-some-GORM-class-td4210934.html
> http://grails.1312388.n4.nabble.com/mongodb-plugin-and-quot-static-mapping-version-false-quot-why-does-the-quot-version-quot-key-is-adde-td4210920.html
> http://grails.1312388.n4.nabble.com/Grails-resources-plugin-still-uses-deprecated-ConfigurationHolder-td4208027.html
> http://grails.1312388.n4.nabble.com/grails-shell-will-raise-an-exception-while-trying-to-autocomplete-a-Map-td4205530.html
> http://grails.1312388.n4.nabble.com/Can-t-upgrade-to-Grails-2-from-1-3-7-and-have-no-clue-all-requests-yields-to-404-status-td4178489.html
> http://www.digipedia.pl/usenet/thread/14352/30474/
> http://grails.1312388.n4.nabble.com/How-to-write-scripts-using-GORM-enabled-domain-classes-td3868599.html
> (I've got only a suggestion to use another testing framework, but didn't get
> a real answer to what I was asking for)
> http://grails.1312388.n4.nabble.com/Grails-scripts-help-td3867976.html
>
>
> Also, besides free time, I still need some more time experimenting with
> Grails 2 before I can write the new article on the subject...
>
> Best,
>
> Rodrigo.
>
>
>
> ---------------------------------------------------------------------
> 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
Rodrigo Rosenfeld Rosas
2012-01-05 15:46:05 UTC
Permalink
Em 05-01-2012 11:43, Graeme Rocher escreveu:
> On Thu, Jan 5, 2012 at 2:17 PM, Rodrigo Rosenfeld Rosas
> <***@yahoo.com.br> wrote:
>> Hi virtualeyes,
>>
>> Em 04-01-2012 19:51, virtualeyes escreveu:
>>> ... The reality is that Grails
>>>
>>> is in fact absurdly fast to restart, faster than or as fast as,
>>> cough-cough,
>>> Rails.
>>
>> I have no idea where you did take your estimates from. In my PC, Grails
>> takes from 36 to 40s to boot an empty app, while JRuby on Rails takes about
>> 16s and Rails itself (on CRuby) takes a single second. I guess you were
>> talking about using the interactive console for booting the Grails app. In
>> that case, for an empty app, it takes about 2 seconds here, which is still a
>> bit slower than vanilla Rails, but certainly much faster than JRuby on
>> Rails.
>>
>> But anyway, I'm not really much concerned about the time required to boot
>> the application as long as I only have to do it once. My main gripe with
>> Grails 1.3.7 is that it would reboot after each little change to my domain
>> classes and other source files, and that took a huge time.
>>
>> Now, with Grails 2, even without the interactive console, the user
>> experience is much better as I don't need to often reboot the application.
>> The interactive console just makes Grails even more responsive. But in the
>> expense of subtle bugs that will show up when using the interactive console
>> that wouldn't be present otherwise...
>>
>> The main disadvantage of a slow bootup time (in any framework/environment)
>> is that it makes running your integration tests slower. While using Rspec
>> for writing tests for Rails, one can use Spork that will take a similar
>> approach to the one taken from Grails interactive console, that will make
>> tests run much faster.
>>
>> So, that article that you mentioned is certainly out-of-date and I need to
>> rewrite it when I find some time. I'll write a new one and add a deprecation
>> note on that one when I'm done for keeping the old comments.
>>
>> My main gripe with Grails currently is that I find it very hard to debug and
>> find what is causing troubles in my application setup. I often have to
>> create a fresh Grails app and gradually copy my files to there until I find
>> the source of the problem.
>>
>> The Grails error messages don't give me a single clue about the problem most
>> of the times. That is not to say that I have no more issues with Grails. I
>> don't like it in many ways, but I find the over-complex black magic behind
>> Grails the one that takes be most of the time when I'm trying to identify
>> some issues.
>>
>> Also, I find that the Grails community has poor support when compared with
>> the Rails and Ruby one. I have lots of unanswered messages in this list
>> where I point to buggy scenarios or plugins.
>
> Many of your issues (understandably) come from the perspective of a
> Rails developer.

Sorry, Graeme, could you point me out what issues you think is
associated to my perspective as a Rails developer? I can only remember
the one about integrating Capybara to Grails. But as you said "many of
your issues", I'd be curious to understand what are the other issues
associated to my Rails background...

> The fact that you are upset that you have
> unanswered questions on integrating a Ruby testing framework into
> Grails does surprise me however.

Integrating JRuby and Grails wasn't exactly the part I was looking for
help. At that point I was already able to boot a Grails app from
Capybara running on JRuby and could also write HTTP-only based specs and
it would work.

But than I couldn't see much advantage on this approach when compared
with Selenium, for instance. The advantage of running the specs with
access to the application context is that I would be able to change the
state of the database before each test and use the GORM classes, for
example, for writing my expectations. So, I just asked about Grails
internals and how it does inject the GORM methods inside the Grails
domain classes so that I could try to do that from the JRuby process.

I guess JRuby and Groovy still don't inter-operate very well, sharing
methodMissing, for example. But if I could use the other methods aside
from the dynamic finders from Java (and JRuby as a consequence), I would
be able to create the instances I'd like to in my specs as well as using
methods like list and count that could be injected in the class itself
through bytecode so that a Java app could see them.

I'm not complaining at me not accomplishing my goal, but at no one to
have even tried to explain me how GORM internals work so that I could
decide if my approach was feasible or not.

I have also asked for some features in the Rails-core and ruby-core list
that were rejected. But at least I had some feedback and some
explanations why they were rejected. Even if I don't agree with them,
the important bit here is that I always got answered.

> You would also get your issues fixed quicker if you provided
> reproducible steps in the issues you raised. Most of your reports are
> incomplete / don't have examples attached and amount to "something
> doesn't work" instead of providing accurate steps to reproduce the
> problem. They are reactionary and tend to be unhelpful.

You can see them as reactionary but they are actually the best
description I could get.

Believe me: I would certainly give you the precise source of the issues
if I knew it beforehand.

For example, I have no idea about the reloading issues due to the Vim
swap files when I first reported the bug. I thought it might be related
to static methods as it only happened in my tests while working on them.
But I didn't have a single clue from Grails messages that would
associate the problem with the Vim swap files. For some unknown reason,
it came to my mind that maybe my swap files were affecting the Grails
loader issue somehow and I tried disabled them as a desperate act of
clueless trying to find the source of the reloading issue. I was
actually pretty surprised that disabling the swap files actually solved
my reloading issues.

If I knew beforehand that the cause was the Vim swap files, you can bet
that I would have reported it from the beginning. I had no clue about
the problem and I was hoping for some feedback that could help me
identifying the cause of the issue.

I don't hide any details on purpose. When I don't give many details is
because I don't have more clues about the problem or I don't know how to
reproduce them in a new app. I would expect some guidance on what to do
to try gather more information about the issue so that I can give you
better feedback. You shouldn't expect me to identify the exact issue
that is causing troubles to me. I would expect instead that you could
help me to eliminate some sources and guide me on how to get more
information about the subject. I'll certainly help as much as I can, but
I need some help usually.

As you can see from the stacktrace in my reports, they're also clueless
while identifying the source of the bug. The same way it doesn't help
you, it doesn't help me either. I would appreciate if you could help me
to find the culprit in the next reports instead of just ignoring them.

> You'll notice that users who report issues with actual examples
> (attached example applications or test cases) get their issues fixed a
> lot quicker.
>
> You also frequently use the mailing list to report issues instead of
> JIRA, if you believe you have identified a bug then raise a JIRA.
> Emailing the developer list doesn't help either.

Sometimes I'm wrong. That is why I prefer to confirm the bug first in
the mailing list before raising a JIRA.

This week, for instance, I was getting trouble while testing an
implementation of Server-Side Events that I was creating in my app. For
some reason it seemed that the Grails application was waiting for one
request to complete before starting to handle the newer one. My first
reaction was "WTF: isn't Grails 2 multi-thread anymore?!". I've tried
running it under production environment and even create a new fresh app
and it wouldn't handle the 2 requests concurrently. I was about to fill
a new bug when I decided to try another browser. So, I've identified
that Chrome wasn't issuing a new request to that address until the old
one have completed...

You can be sure that I take a lot of time before creating a JIRA issue
in your system because I value the time you spend on them. I don't just
throw any issues in your JIRA system before spending a lot of time
trying to identify what is the cause before. Please, don't get the wrong
impression about me.

With regards to JIRA vs mailing list, I don't really understand why does
it matter so much. A while ago, someone got in touch with me by e-mail
asking for supporting the newest Rails release in my rails-web-console
gem. I didn't ask him to open a new issue in the Github issues page of
the project. I just fixed it in the same day and replied to him that the
just released new version supported the latest Rails. While I find this
responsiveness very common in the Ruby land, I can't say the same about
the Grails-related projects/plugins I've worked with.

For example, there is a long time issue with the Grails console plugin
that doesn't work well on Chrome due to a bug on its CSS:

http://grails.org/plugin/console

I didn't report the bug the first time I've seen since I thought someone
else would do it. I've just kept using the old 0.2.2 release. But after
an year since it was released, there is still no newer version, so I
decided I would investigate the cause. So, I've opening the JIRA issue
pointing out what was the problem and how to fix it some days ago. But
there is still no fixed version for it... My feeling is that things
happen too slow in the Grails land.

Also, I don't understand why there is a centralized model around plugin
releases. Git is interesting because it allows a decentralized model to
work. In Ruby, the RubyGems project will allow anyone to publish new
gems without asking for permission to anyone. The Bundler project is a
Maven-like, but improved, project for dealing with dependencies in Ruby.
And it allows one to specify the dependency pointing directly to the Git
URL among other options. That is really interesting when you have forked
some project and fixed the issue yourself allowing you to use your fixed
version while the original one doesn't get fixed.

I find it really frustrating that someone needs to ask for
permission/access in the dev mailing list for publishing a new plugin.
I'd rather prefer a decentralized system like Git or RubyGems for things
like this...

Also, talking about community culture, it is very hard to find any Ruby
project those days that is not hosted on GitHub. That is part of the
culture of the Ruby community. I find it really weird that the Ruby
language itself is still hosted on Subversion with a Git official
mirror... GitHub is a great place to fork and send pull requests,
specially because most of the projects have a big test suite that will
make you more confident that you didn't break anything after your
changes by running the test suite, which is part of the project itself
and not a separate project. It is usually very easy to setup the test
environment.

While looking at the Grails plugins page, I can't find a link to the
project in GitHub for most of them, which I find kind of frustrating
since it would require more effort to me for contributing to them or
sending them pull requests... Working with Git is so easy to me that I
won't contribute to any project that is not Git hosted because it will
require me more time to generate the patch, send them to the issues
system and keep them up to date... I'm not blaming anyone for their
choice, but this is just a choice I've made myself of not contributing
to non-git projects as they will require me more free time I'm not
willing to spend...

Sorry for the long message, but I've realized I've never expressed those
opinions before and I think I shouldn't wait for my next article to
express them.

Also, I'd like to thank you for the feedback I've got today with regards
to some of the issues mentioned in this thread. I'm not ignoring them
and will reply to them as soon as I find some time, but I'm afraid I
have lots of work still to do today. Maybe tomorrow I can try to open
the remaining issues in JIRA or attach some reproducible project to some
of them.

Cheers,

Rodrigo.


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

http://xircles.codehaus.org/manage_email
Burt Beckwith
2012-01-05 13:51:50 UTC
Permalink
Sorry for cherry-picking into a long email and a long thread, but your
Rails/Grails bug comparison is very weak. You reported two simple Rails bugs
that were each fixed with a single line of code, and are comparing these to
Grails issues that are a significantly more involved.

Burt

On Thursday, January 05, 2012 11:17:45 AM Rodrigo Rosenfeld Rosas wrote:
> Hi virtualeyes,
>
> Em 04-01-2012 19:51, virtualeyes escreveu:
> > ... The reality is that Grails
> > is in fact absurdly fast to restart, faster than or as fast as, cough-
cough,
> > Rails.
>
> I have no idea where you did take your estimates from. In my PC, Grails
> takes from 36 to 40s to boot an empty app, while JRuby on Rails takes
> about 16s and Rails itself (on CRuby) takes a single second. I guess you
> were talking about using the interactive console for booting the Grails
> app. In that case, for an empty app, it takes about 2 seconds here,
> which is still a bit slower than vanilla Rails, but certainly much
> faster than JRuby on Rails.
>
> But anyway, I'm not really much concerned about the time required to
> boot the application as long as I only have to do it once. My main gripe
> with Grails 1.3.7 is that it would reboot after each little change to my
> domain classes and other source files, and that took a huge time.
>
> Now, with Grails 2, even without the interactive console, the user
> experience is much better as I don't need to often reboot the
> application. The interactive console just makes Grails even more
> responsive. But in the expense of subtle bugs that will show up when
> using the interactive console that wouldn't be present otherwise...
>
> The main disadvantage of a slow bootup time (in any
> framework/environment) is that it makes running your integration tests
> slower. While using Rspec for writing tests for Rails, one can use Spork
> that will take a similar approach to the one taken from Grails
> interactive console, that will make tests run much faster.
>
> So, that article that you mentioned is certainly out-of-date and I need
> to rewrite it when I find some time. I'll write a new one and add a
> deprecation note on that one when I'm done for keeping the old comments.
>
> My main gripe with Grails currently is that I find it very hard to debug
> and find what is causing troubles in my application setup. I often have
> to create a fresh Grails app and gradually copy my files to there until
> I find the source of the problem.
>
> The Grails error messages don't give me a single clue about the problem
> most of the times. That is not to say that I have no more issues with
> Grails. I don't like it in many ways, but I find the over-complex black
> magic behind Grails the one that takes be most of the time when I'm
> trying to identify some issues.
>
> Also, I find that the Grails community has poor support when compared
> with the Rails and Ruby one. I have lots of unanswered messages in this
> list where I point to buggy scenarios or plugins.
>
> For, example, I've filled two bugs in the Rails issues system last year,
> and both were fixed and commited in less than an hour:
>
> https://github.com/rails/rails/issues/4054
> https://github.com/rails/rails/issues/4067
>
> In the other side, here are some bugs (or feature requests) I've
> reported to the Grails JIRA:
>
> http://jira.grails.org/browse/GRAILS-8568
> http://jira.grails.org/browse/GRAILS-8567
> http://jira.grails.org/browse/GPCONSOLE-3
> http://jira.grails.org/browse/GRAILS-8539 (I'm the only one
> participating on this one, for example)
> http://jira.grails.org/browse/GRAILS-8485
> http://jira.grails.org/browse/GRAILS-7792 (feature request)
> http://jira.grails.org/browse/GRAILS-3303 (closed as won't fix, although
> I think it could be fixed...)
> https://github.com/SpringSource/grails-data-mapping/issues/18
>
> Unanswered messages in this list:
>
> http://grails.1312388.n4.nabble.com/Strange-issue-with-Grails-2-and-find-
with-closure-td4222761.html
> http://grails.1312388.n4.nabble.com/mongodb-and-hibernate-are-not-playing-
well-together-td4222229.html
> this wasn't answered. It was just told me to not report bugs in the dev
> mailing list, but I didn't get any reply in the user's list too
> http://grails.1312388.n4.nabble.com/MongoDB-and-multiple-databases-not-
talking-about-replication-td4210794.html
> just a minor part of the message was answered
> http://grails.1312388.n4.nabble.com/Is-there-an-easy-way-to-set-default-
mapping-options-to-all-columns-of-some-GORM-class-td4210934.html
> http://grails.1312388.n4.nabble.com/mongodb-plugin-and-quot-static-mapping-
version-false-quot-why-does-the-quot-version-quot-key-is-adde-td4210920.html
> http://grails.1312388.n4.nabble.com/Grails-resources-plugin-still-uses-
deprecated-ConfigurationHolder-td4208027.html
> http://grails.1312388.n4.nabble.com/grails-shell-will-raise-an-exception-
while-trying-to-autocomplete-a-Map-td4205530.html
> http://grails.1312388.n4.nabble.com/Can-t-upgrade-to-Grails-2-from-1-3-7-
and-have-no-clue-all-requests-yields-to-404-status-td4178489.html
> http://www.digipedia.pl/usenet/thread/14352/30474/
> http://grails.1312388.n4.nabble.com/How-to-write-scripts-using-GORM-enabled-
domain-classes-td3868599.html
> (I've got only a suggestion to use another testing framework, but didn't
> get a real answer to what I was asking for)
> http://grails.1312388.n4.nabble.com/Grails-scripts-help-td3867976.html
>
>
> Also, besides free time, I still need some more time experimenting with
> Grails 2 before I can write the new article on the subject...
>
> Best,
>
> Rodrigo.


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

http://xircles.codehaus.org/manage_email
Jason Davis
2012-01-05 14:06:05 UTC
Permalink
quick question... who gives a shit about rails or ruby, can we focus
on fixing the problem. Not replacing every stinking technology the OP
is using. lame...

On Thu, Jan 5, 2012 at 6:51 AM, Burt Beckwith <***@burtbeckwith.com> wrote:
> Sorry for cherry-picking into a long email and a long thread, but your
> Rails/Grails bug comparison is very weak. You reported two simple Rails bugs
> that were each fixed with a single line of code, and are comparing these to
> Grails issues that are a significantly more involved.
>
> Burt
>
> On Thursday, January 05, 2012 11:17:45 AM Rodrigo Rosenfeld Rosas wrote:
>> Hi virtualeyes,
>>
>> Em 04-01-2012 19:51, virtualeyes escreveu:
>> > ...  The reality is that Grails
>> > is in fact absurdly fast to restart, faster than or as fast as, cough-
> cough,
>> > Rails.
>>
>> I have no idea where you did take your estimates from. In my PC, Grails
>> takes from 36 to 40s to boot an empty app, while JRuby on Rails takes
>> about 16s and Rails itself (on CRuby) takes a single second. I guess you
>> were talking about using the interactive console for booting the Grails
>> app. In that case, for an empty app, it takes about 2 seconds here,
>> which is still a bit slower than vanilla Rails, but certainly much
>> faster than JRuby on Rails.
>>
>> But anyway, I'm not really much concerned about the time required to
>> boot the application as long as I only have to do it once. My main gripe
>> with Grails 1.3.7 is that it would reboot after each little change to my
>> domain classes and other source files, and that took a huge time.
>>
>> Now, with Grails 2, even without the interactive console, the user
>> experience is much better as I don't need to often reboot the
>> application. The interactive console just makes Grails even more
>> responsive. But in the expense of subtle bugs that will show up when
>> using the interactive console that wouldn't be present otherwise...
>>
>> The main disadvantage of a slow bootup time (in any
>> framework/environment) is that it makes running your integration tests
>> slower. While using Rspec for writing tests for Rails, one can use Spork
>> that will take a similar approach to the one taken from Grails
>> interactive console, that will make tests run much faster.
>>
>> So, that article that you mentioned is certainly out-of-date and I need
>> to rewrite it when I find some time. I'll write a new one and add a
>> deprecation note on that one when I'm done for keeping the old comments.
>>
>> My main gripe with Grails currently is that I find it very hard to debug
>> and find what is causing troubles in my application setup. I often have
>> to create a fresh Grails app and gradually copy my files to there until
>> I find the source of the problem.
>>
>> The Grails error messages don't give me a single clue about the problem
>> most of the times. That is not to say that I have no more issues with
>> Grails. I don't like it in many ways, but I find the over-complex black
>> magic behind Grails the one that takes be most of the time when I'm
>> trying to identify some issues.
>>
>> Also, I find that the Grails community has poor support when compared
>> with the Rails and Ruby one. I have lots of unanswered messages in this
>> list where I point to buggy scenarios or plugins.
>>
>> For, example, I've filled two bugs in the Rails issues system last year,
>> and both were fixed and commited in less than an hour:
>>
>> https://github.com/rails/rails/issues/4054
>> https://github.com/rails/rails/issues/4067
>>
>> In the other side, here are some bugs (or feature requests) I've
>> reported to the Grails JIRA:
>>
>> http://jira.grails.org/browse/GRAILS-8568
>> http://jira.grails.org/browse/GRAILS-8567
>> http://jira.grails.org/browse/GPCONSOLE-3
>> http://jira.grails.org/browse/GRAILS-8539 (I'm the only one
>> participating on this one, for example)
>> http://jira.grails.org/browse/GRAILS-8485
>> http://jira.grails.org/browse/GRAILS-7792 (feature request)
>> http://jira.grails.org/browse/GRAILS-3303 (closed as won't fix, although
>> I think it could be fixed...)
>> https://github.com/SpringSource/grails-data-mapping/issues/18
>>
>> Unanswered messages in this list:
>>
>> http://grails.1312388.n4.nabble.com/Strange-issue-with-Grails-2-and-find-
> with-closure-td4222761.html
>> http://grails.1312388.n4.nabble.com/mongodb-and-hibernate-are-not-playing-
> well-together-td4222229.html
>> this wasn't answered. It was just told me to not report bugs in the dev
>> mailing list, but I didn't get any reply in the user's list too
>> http://grails.1312388.n4.nabble.com/MongoDB-and-multiple-databases-not-
> talking-about-replication-td4210794.html
>> just a minor part of the message was answered
>> http://grails.1312388.n4.nabble.com/Is-there-an-easy-way-to-set-default-
> mapping-options-to-all-columns-of-some-GORM-class-td4210934.html
>> http://grails.1312388.n4.nabble.com/mongodb-plugin-and-quot-static-mapping-
> version-false-quot-why-does-the-quot-version-quot-key-is-adde-td4210920.html
>> http://grails.1312388.n4.nabble.com/Grails-resources-plugin-still-uses-
> deprecated-ConfigurationHolder-td4208027.html
>> http://grails.1312388.n4.nabble.com/grails-shell-will-raise-an-exception-
> while-trying-to-autocomplete-a-Map-td4205530.html
>> http://grails.1312388.n4.nabble.com/Can-t-upgrade-to-Grails-2-from-1-3-7-
> and-have-no-clue-all-requests-yields-to-404-status-td4178489.html
>> http://www.digipedia.pl/usenet/thread/14352/30474/
>> http://grails.1312388.n4.nabble.com/How-to-write-scripts-using-GORM-enabled-
> domain-classes-td3868599.html
>> (I've got only a suggestion to use another testing framework, but didn't
>> get a real answer to what I was asking for)
>> http://grails.1312388.n4.nabble.com/Grails-scripts-help-td3867976.html
>>
>>
>> Also, besides free time, I still need some more time experimenting with
>> Grails 2 before I can write the new article on the subject...
>>
>> Best,
>>
>> Rodrigo.
>
>
> ---------------------------------------------------------------------
> 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
Jason Davis
2012-01-05 14:11:54 UTC
Permalink
quick question... who gives a crap about rails or ruby, can we focus
on fixing the problem. Not replacing every stinking technology the OP
is using. lame...

On Thu, Jan 5, 2012 at 7:06 AM, Jason Davis <***@openactive.org> wrote:
> quick question... who gives a shit about rails or ruby, can we focus
> on fixing the problem. Not replacing every stinking technology the OP
> is using. lame...
>
> On Thu, Jan 5, 2012 at 6:51 AM, Burt Beckwith <***@burtbeckwith.com> wrote:
>> Sorry for cherry-picking into a long email and a long thread, but your
>> Rails/Grails bug comparison is very weak. You reported two simple Rails bugs
>> that were each fixed with a single line of code, and are comparing these to
>> Grails issues that are a significantly more involved.
>>
>> Burt
>>
>> On Thursday, January 05, 2012 11:17:45 AM Rodrigo Rosenfeld Rosas wrote:
>>> Hi virtualeyes,
>>>
>>> Em 04-01-2012 19:51, virtualeyes escreveu:
>>> > ...  The reality is that Grails
>>> > is in fact absurdly fast to restart, faster than or as fast as, cough-
>> cough,
>>> > Rails.
>>>
>>> I have no idea where you did take your estimates from. In my PC, Grails
>>> takes from 36 to 40s to boot an empty app, while JRuby on Rails takes
>>> about 16s and Rails itself (on CRuby) takes a single second. I guess you
>>> were talking about using the interactive console for booting the Grails
>>> app. In that case, for an empty app, it takes about 2 seconds here,
>>> which is still a bit slower than vanilla Rails, but certainly much
>>> faster than JRuby on Rails.
>>>
>>> But anyway, I'm not really much concerned about the time required to
>>> boot the application as long as I only have to do it once. My main gripe
>>> with Grails 1.3.7 is that it would reboot after each little change to my
>>> domain classes and other source files, and that took a huge time.
>>>
>>> Now, with Grails 2, even without the interactive console, the user
>>> experience is much better as I don't need to often reboot the
>>> application. The interactive console just makes Grails even more
>>> responsive. But in the expense of subtle bugs that will show up when
>>> using the interactive console that wouldn't be present otherwise...
>>>
>>> The main disadvantage of a slow bootup time (in any
>>> framework/environment) is that it makes running your integration tests
>>> slower. While using Rspec for writing tests for Rails, one can use Spork
>>> that will take a similar approach to the one taken from Grails
>>> interactive console, that will make tests run much faster.
>>>
>>> So, that article that you mentioned is certainly out-of-date and I need
>>> to rewrite it when I find some time. I'll write a new one and add a
>>> deprecation note on that one when I'm done for keeping the old comments.
>>>
>>> My main gripe with Grails currently is that I find it very hard to debug
>>> and find what is causing troubles in my application setup. I often have
>>> to create a fresh Grails app and gradually copy my files to there until
>>> I find the source of the problem.
>>>
>>> The Grails error messages don't give me a single clue about the problem
>>> most of the times. That is not to say that I have no more issues with
>>> Grails. I don't like it in many ways, but I find the over-complex black
>>> magic behind Grails the one that takes be most of the time when I'm
>>> trying to identify some issues.
>>>
>>> Also, I find that the Grails community has poor support when compared
>>> with the Rails and Ruby one. I have lots of unanswered messages in this
>>> list where I point to buggy scenarios or plugins.
>>>
>>> For, example, I've filled two bugs in the Rails issues system last year,
>>> and both were fixed and commited in less than an hour:
>>>
>>> https://github.com/rails/rails/issues/4054
>>> https://github.com/rails/rails/issues/4067
>>>
>>> In the other side, here are some bugs (or feature requests) I've
>>> reported to the Grails JIRA:
>>>
>>> http://jira.grails.org/browse/GRAILS-8568
>>> http://jira.grails.org/browse/GRAILS-8567
>>> http://jira.grails.org/browse/GPCONSOLE-3
>>> http://jira.grails.org/browse/GRAILS-8539 (I'm the only one
>>> participating on this one, for example)
>>> http://jira.grails.org/browse/GRAILS-8485
>>> http://jira.grails.org/browse/GRAILS-7792 (feature request)
>>> http://jira.grails.org/browse/GRAILS-3303 (closed as won't fix, although
>>> I think it could be fixed...)
>>> https://github.com/SpringSource/grails-data-mapping/issues/18
>>>
>>> Unanswered messages in this list:
>>>
>>> http://grails.1312388.n4.nabble.com/Strange-issue-with-Grails-2-and-find-
>> with-closure-td4222761.html
>>> http://grails.1312388.n4.nabble.com/mongodb-and-hibernate-are-not-playing-
>> well-together-td4222229.html
>>> this wasn't answered. It was just told me to not report bugs in the dev
>>> mailing list, but I didn't get any reply in the user's list too
>>> http://grails.1312388.n4.nabble.com/MongoDB-and-multiple-databases-not-
>> talking-about-replication-td4210794.html
>>> just a minor part of the message was answered
>>> http://grails.1312388.n4.nabble.com/Is-there-an-easy-way-to-set-default-
>> mapping-options-to-all-columns-of-some-GORM-class-td4210934.html
>>> http://grails.1312388.n4.nabble.com/mongodb-plugin-and-quot-static-mapping-
>> version-false-quot-why-does-the-quot-version-quot-key-is-adde-td4210920.html
>>> http://grails.1312388.n4.nabble.com/Grails-resources-plugin-still-uses-
>> deprecated-ConfigurationHolder-td4208027.html
>>> http://grails.1312388.n4.nabble.com/grails-shell-will-raise-an-exception-
>> while-trying-to-autocomplete-a-Map-td4205530.html
>>> http://grails.1312388.n4.nabble.com/Can-t-upgrade-to-Grails-2-from-1-3-7-
>> and-have-no-clue-all-requests-yields-to-404-status-td4178489.html
>>> http://www.digipedia.pl/usenet/thread/14352/30474/
>>> http://grails.1312388.n4.nabble.com/How-to-write-scripts-using-GORM-enabled-
>> domain-classes-td3868599.html
>>> (I've got only a suggestion to use another testing framework, but didn't
>>> get a real answer to what I was asking for)
>>> http://grails.1312388.n4.nabble.com/Grails-scripts-help-td3867976.html
>>>
>>>
>>> Also, besides free time, I still need some more time experimenting with
>>> Grails 2 before I can write the new article on the subject...
>>>
>>> Best,
>>>
>>> Rodrigo.
>>
>>
>> ---------------------------------------------------------------------
>> 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
raffaele181188
2012-01-05 14:33:26 UTC
Permalink
+1 for the anti virus checking. I won't be able to test it untile next
Monday, but hopefully this will solve the problem

Please undertand that even if RAM is very cheap I cannot buy and install it
myself without explict admins consensus :(
Also I remark that my monitors never show a RAM usage over 70%, so we are
pretty far away from swap land

I have to ask one more question. I have some background in PHP and I must
say that the development lifecycle is very smooth.
Now the new company I work for is mostly Java based, and I must say that
developing (and deploying!) feels really slow compared to PHP
If you have any experience in other dynamic languages frameworks (PHP, Ruby
+ Rails, Python, Scala), how do you compare those to
Grails development? I'm talking about the "development speed", where the
reference is the PHP cycle:
1. Edit file
2. Refresh the browser
3. (at deploy time) Copy files

Raffaele

2012/1/5 Jason Davis [via Grails] <ml-node+***@n4.nabble.com
>

> quick question... who gives a crap about rails or ruby, can we focus
> on fixing the problem. Not replacing every stinking technology the OP
> is using. lame...
>
> On Thu, Jan 5, 2012 at 7:06 AM, Jason Davis <[hidden email]<http://user/SendEmail.jtp?type=node&node=4265612&i=0>>
> wrote:
>
> > quick question... who gives a shit about rails or ruby, can we focus
> > on fixing the problem. Not replacing every stinking technology the OP
> > is using. lame...
> >
> > On Thu, Jan 5, 2012 at 6:51 AM, Burt Beckwith <[hidden email]<http://user/SendEmail.jtp?type=node&node=4265612&i=1>>
> wrote:
> >> Sorry for cherry-picking into a long email and a long thread, but your
> >> Rails/Grails bug comparison is very weak. You reported two simple Rails
> bugs
> >> that were each fixed with a single line of code, and are comparing
> these to
> >> Grails issues that are a significantly more involved.
> >>
> >> Burt
> >>
> >> On Thursday, January 05, 2012 11:17:45 AM Rodrigo Rosenfeld Rosas
> wrote:
> >>> Hi virtualeyes,
> >>>
> >>> Em 04-01-2012 19:51, virtualeyes escreveu:
> >>> > ... The reality is that Grails
> >>> > is in fact absurdly fast to restart, faster than or as fast as,
> cough-
> >> cough,
> >>> > Rails.
> >>>
> >>> I have no idea where you did take your estimates from. In my PC,
> Grails
> >>> takes from 36 to 40s to boot an empty app, while JRuby on Rails takes
> >>> about 16s and Rails itself (on CRuby) takes a single second. I guess
> you
> >>> were talking about using the interactive console for booting the
> Grails
> >>> app. In that case, for an empty app, it takes about 2 seconds here,
> >>> which is still a bit slower than vanilla Rails, but certainly much
> >>> faster than JRuby on Rails.
> >>>
> >>> But anyway, I'm not really much concerned about the time required to
> >>> boot the application as long as I only have to do it once. My main
> gripe
> >>> with Grails 1.3.7 is that it would reboot after each little change to
> my
> >>> domain classes and other source files, and that took a huge time.
> >>>
> >>> Now, with Grails 2, even without the interactive console, the user
> >>> experience is much better as I don't need to often reboot the
> >>> application. The interactive console just makes Grails even more
> >>> responsive. But in the expense of subtle bugs that will show up when
> >>> using the interactive console that wouldn't be present otherwise...
> >>>
> >>> The main disadvantage of a slow bootup time (in any
> >>> framework/environment) is that it makes running your integration tests
> >>> slower. While using Rspec for writing tests for Rails, one can use
> Spork
> >>> that will take a similar approach to the one taken from Grails
> >>> interactive console, that will make tests run much faster.
> >>>
> >>> So, that article that you mentioned is certainly out-of-date and I
> need
> >>> to rewrite it when I find some time. I'll write a new one and add a
> >>> deprecation note on that one when I'm done for keeping the old
> comments.
> >>>
> >>> My main gripe with Grails currently is that I find it very hard to
> debug
> >>> and find what is causing troubles in my application setup. I often
> have
> >>> to create a fresh Grails app and gradually copy my files to there
> until
> >>> I find the source of the problem.
> >>>
> >>> The Grails error messages don't give me a single clue about the
> problem
> >>> most of the times. That is not to say that I have no more issues with
> >>> Grails. I don't like it in many ways, but I find the over-complex
> black
> >>> magic behind Grails the one that takes be most of the time when I'm
> >>> trying to identify some issues.
> >>>
> >>> Also, I find that the Grails community has poor support when compared
> >>> with the Rails and Ruby one. I have lots of unanswered messages in
> this
> >>> list where I point to buggy scenarios or plugins.
> >>>
> >>> For, example, I've filled two bugs in the Rails issues system last
> year,
> >>> and both were fixed and commited in less than an hour:
> >>>
> >>> https://github.com/rails/rails/issues/4054
> >>> https://github.com/rails/rails/issues/4067
> >>>
> >>> In the other side, here are some bugs (or feature requests) I've
> >>> reported to the Grails JIRA:
> >>>
> >>> http://jira.grails.org/browse/GRAILS-8568
> >>> http://jira.grails.org/browse/GRAILS-8567
> >>> http://jira.grails.org/browse/GPCONSOLE-3
> >>> http://jira.grails.org/browse/GRAILS-8539 (I'm the only one
> >>> participating on this one, for example)
> >>> http://jira.grails.org/browse/GRAILS-8485
> >>> http://jira.grails.org/browse/GRAILS-7792 (feature request)
> >>> http://jira.grails.org/browse/GRAILS-3303 (closed as won't fix,
> although
> >>> I think it could be fixed...)
> >>> https://github.com/SpringSource/grails-data-mapping/issues/18
> >>>
> >>> Unanswered messages in this list:
> >>>
> >>>
> http://grails.1312388.n4.nabble.com/Strange-issue-with-Grails-2-and-find-
> >> with-closure-td4222761.html
> >>>
> http://grails.1312388.n4.nabble.com/mongodb-and-hibernate-are-not-playing-
> >> well-together-td4222229.html
> >>> this wasn't answered. It was just told me to not report bugs in the
> dev
> >>> mailing list, but I didn't get any reply in the user's list too
> >>>
> http://grails.1312388.n4.nabble.com/MongoDB-and-multiple-databases-not-
> >> talking-about-replication-td4210794.html
> >>> just a minor part of the message was answered
> >>>
> http://grails.1312388.n4.nabble.com/Is-there-an-easy-way-to-set-default-
> >> mapping-options-to-all-columns-of-some-GORM-class-td4210934.html
> >>>
> http://grails.1312388.n4.nabble.com/mongodb-plugin-and-quot-static-mapping-
> >>
> version-false-quot-why-does-the-quot-version-quot-key-is-adde-td4210920.html
>
> >>>
> http://grails.1312388.n4.nabble.com/Grails-resources-plugin-still-uses-
> >> deprecated-ConfigurationHolder-td4208027.html
> >>>
> http://grails.1312388.n4.nabble.com/grails-shell-will-raise-an-exception-
> >> while-trying-to-autocomplete-a-Map-td4205530.html
> >>>
> http://grails.1312388.n4.nabble.com/Can-t-upgrade-to-Grails-2-from-1-3-7-
> >> and-have-no-clue-all-requests-yields-to-404-status-td4178489.html
> >>> http://www.digipedia.pl/usenet/thread/14352/30474/
> >>>
> http://grails.1312388.n4.nabble.com/How-to-write-scripts-using-GORM-enabled-
> >> domain-classes-td3868599.html
> >>> (I've got only a suggestion to use another testing framework, but
> didn't
> >>> get a real answer to what I was asking for)
> >>> http://grails.1312388.n4.nabble.com/Grails-scripts-help-td3867976.html
> >>>
> >>>
> >>> Also, besides free time, I still need some more time experimenting
> with
> >>> Grails 2 before I can write the new article on the subject...
> >>>
> >>> Best,
> >>>
> >>> Rodrigo.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265612.html
> To unsubscribe from Grails development is really slow, click here<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4257651&code=cmFmZmFlbGVzZ2Fycm9AZ21haWwuY29tfDQyNTc2NTF8LTE3Njk1MDM5MDc=>
> .
> NAML<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>


--
View this message in context: http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265707.html
Sent from the Grails - user mailing list archive at Nabble.com.
Gavin Yue
2012-01-05 15:28:36 UTC
Permalink
It is really hard to compare.

But for JAVA people, Grails should the top choice.



On Thu, Jan 5, 2012 at 6:33 AM, raffaele181188 <***@gmail.com>wrote:

> +1 for the anti virus checking. I won't be able to test it untile next
> Monday, but hopefully this will solve the problem
>
> Please undertand that even if RAM is very cheap I cannot buy and install
> it myself without explict admins consensus :(
> Also I remark that my monitors never show a RAM usage over 70%, so we are
> pretty far away from swap land
>
> I have to ask one more question. I have some background in PHP and I must
> say that the development lifecycle is very smooth.
> Now the new company I work for is mostly Java based, and I must say that
> developing (and deploying!) feels really slow compared to PHP
> If you have any experience in other dynamic languages frameworks (PHP,
> Ruby + Rails, Python, Scala), how do you compare those to
> Grails development? I'm talking about the "development speed", where the
> reference is the PHP cycle:
> 1. Edit file
> 2. Refresh the browser
> 3. (at deploy time) Copy files
>
> Raffaele
>
> 2012/1/5 Jason Davis [via Grails] <[hidden email]<http://user/SendEmail.jtp?type=node&node=4265707&i=0>
> >
>
>> quick question... who gives a crap about rails or ruby, can we focus
>> on fixing the problem. Not replacing every stinking technology the OP
>> is using. lame...
>>
>> On Thu, Jan 5, 2012 at 7:06 AM, Jason Davis <[hidden email]<http://user/SendEmail.jtp?type=node&node=4265612&i=0>>
>> wrote:
>>
>> > quick question... who gives a shit about rails or ruby, can we focus
>> > on fixing the problem. Not replacing every stinking technology the OP
>> > is using. lame...
>> >
>> > On Thu, Jan 5, 2012 at 6:51 AM, Burt Beckwith <[hidden email]<http://user/SendEmail.jtp?type=node&node=4265612&i=1>>
>> wrote:
>> >> Sorry for cherry-picking into a long email and a long thread, but your
>> >> Rails/Grails bug comparison is very weak. You reported two simple
>> Rails bugs
>> >> that were each fixed with a single line of code, and are comparing
>> these to
>> >> Grails issues that are a significantly more involved.
>> >>
>> >> Burt
>> >>
>> >> On Thursday, January 05, 2012 11:17:45 AM Rodrigo Rosenfeld Rosas
>> wrote:
>> >>> Hi virtualeyes,
>> >>>
>> >>> Em 04-01-2012 19:51, virtualeyes escreveu:
>> >>> > ... The reality is that Grails
>> >>> > is in fact absurdly fast to restart, faster than or as fast as,
>> cough-
>> >> cough,
>> >>> > Rails.
>> >>>
>> >>> I have no idea where you did take your estimates from. In my PC,
>> Grails
>> >>> takes from 36 to 40s to boot an empty app, while JRuby on Rails takes
>> >>> about 16s and Rails itself (on CRuby) takes a single second. I guess
>> you
>> >>> were talking about using the interactive console for booting the
>> Grails
>> >>> app. In that case, for an empty app, it takes about 2 seconds here,
>> >>> which is still a bit slower than vanilla Rails, but certainly much
>> >>> faster than JRuby on Rails.
>> >>>
>> >>> But anyway, I'm not really much concerned about the time required to
>> >>> boot the application as long as I only have to do it once. My main
>> gripe
>> >>> with Grails 1.3.7 is that it would reboot after each little change to
>> my
>> >>> domain classes and other source files, and that took a huge time.
>> >>>
>> >>> Now, with Grails 2, even without the interactive console, the user
>> >>> experience is much better as I don't need to often reboot the
>> >>> application. The interactive console just makes Grails even more
>> >>> responsive. But in the expense of subtle bugs that will show up when
>> >>> using the interactive console that wouldn't be present otherwise...
>> >>>
>> >>> The main disadvantage of a slow bootup time (in any
>> >>> framework/environment) is that it makes running your integration
>> tests
>> >>> slower. While using Rspec for writing tests for Rails, one can use
>> Spork
>> >>> that will take a similar approach to the one taken from Grails
>> >>> interactive console, that will make tests run much faster.
>> >>>
>> >>> So, that article that you mentioned is certainly out-of-date and I
>> need
>> >>> to rewrite it when I find some time. I'll write a new one and add a
>> >>> deprecation note on that one when I'm done for keeping the old
>> comments.
>> >>>
>> >>> My main gripe with Grails currently is that I find it very hard to
>> debug
>> >>> and find what is causing troubles in my application setup. I often
>> have
>> >>> to create a fresh Grails app and gradually copy my files to there
>> until
>> >>> I find the source of the problem.
>> >>>
>> >>> The Grails error messages don't give me a single clue about the
>> problem
>> >>> most of the times. That is not to say that I have no more issues with
>> >>> Grails. I don't like it in many ways, but I find the over-complex
>> black
>> >>> magic behind Grails the one that takes be most of the time when I'm
>> >>> trying to identify some issues.
>> >>>
>> >>> Also, I find that the Grails community has poor support when compared
>> >>> with the Rails and Ruby one. I have lots of unanswered messages in
>> this
>> >>> list where I point to buggy scenarios or plugins.
>> >>>
>> >>> For, example, I've filled two bugs in the Rails issues system last
>> year,
>> >>> and both were fixed and commited in less than an hour:
>> >>>
>> >>> https://github.com/rails/rails/issues/4054
>> >>> https://github.com/rails/rails/issues/4067
>> >>>
>> >>> In the other side, here are some bugs (or feature requests) I've
>> >>> reported to the Grails JIRA:
>> >>>
>> >>> http://jira.grails.org/browse/GRAILS-8568
>> >>> http://jira.grails.org/browse/GRAILS-8567
>> >>> http://jira.grails.org/browse/GPCONSOLE-3
>>
>> >>> http://jira.grails.org/browse/GRAILS-8539 (I'm the only one
>> >>> participating on this one, for example)
>> >>> http://jira.grails.org/browse/GRAILS-8485
>> >>> http://jira.grails.org/browse/GRAILS-7792 (feature request)
>> >>> http://jira.grails.org/browse/GRAILS-3303 (closed as won't fix,
>> although
>> >>> I think it could be fixed...)
>> >>> https://github.com/SpringSource/grails-data-mapping/issues/18
>> >>>
>> >>> Unanswered messages in this list:
>> >>>
>> >>>
>> http://grails.1312388.n4.nabble.com/Strange-issue-with-Grails-2-and-find-
>> >> with-closure-td4222761.html
>> >>>
>> http://grails.1312388.n4.nabble.com/mongodb-and-hibernate-are-not-playing-
>> >> well-together-td4222229.html
>> >>> this wasn't answered. It was just told me to not report bugs in the
>> dev
>> >>> mailing list, but I didn't get any reply in the user's list too
>> >>>
>> http://grails.1312388.n4.nabble.com/MongoDB-and-multiple-databases-not-
>> >> talking-about-replication-td4210794.html
>> >>> just a minor part of the message was answered
>> >>>
>> http://grails.1312388.n4.nabble.com/Is-there-an-easy-way-to-set-default-
>> >> mapping-options-to-all-columns-of-some-GORM-class-td4210934.html
>> >>>
>> http://grails.1312388.n4.nabble.com/mongodb-plugin-and-quot-static-mapping-
>> >>
>> version-false-quot-why-does-the-quot-version-quot-key-is-adde-td4210920.html
>>
>> >>>
>> http://grails.1312388.n4.nabble.com/Grails-resources-plugin-still-uses-
>> >> deprecated-ConfigurationHolder-td4208027.html
>> >>>
>> http://grails.1312388.n4.nabble.com/grails-shell-will-raise-an-exception-
>> >> while-trying-to-autocomplete-a-Map-td4205530.html
>> >>>
>> http://grails.1312388.n4.nabble.com/Can-t-upgrade-to-Grails-2-from-1-3-7-
>> >> and-have-no-clue-all-requests-yields-to-404-status-td4178489.html
>> >>> http://www.digipedia.pl/usenet/thread/14352/30474/
>> >>>
>> http://grails.1312388.n4.nabble.com/How-to-write-scripts-using-GORM-enabled-
>> >> domain-classes-td3868599.html
>> >>> (I've got only a suggestion to use another testing framework, but
>> didn't
>> >>> get a real answer to what I was asking for)
>> >>>
>> http://grails.1312388.n4.nabble.com/Grails-scripts-help-td3867976.html
>> >>>
>>
>> >>>
>> >>> Also, besides free time, I still need some more time experimenting
>> with
>> >>> Grails 2 before I can write the new article on the subject...
>> >>>
>> >>> Best,
>> >>>
>> >>> Rodrigo.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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
>>
>>
>>
>>
>> ------------------------------
>> If you reply to this email, your message will be added to the
>> discussion below:
>>
>> http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265612.html
>> To unsubscribe from Grails development is really slow, click here.
>> NAML<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>
>
> ------------------------------
> View this message in context: Re: Grails development is really slow<http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265707.html>
> Sent from the Grails - user mailing list archive<http://grails.1312388.n4.nabble.com/Grails-user-f1312389.html>at Nabble.com.
>
raffaele181188
2012-01-05 15:36:16 UTC
Permalink
But Java itself is not such a smooth experience. My primary objective is
find a language that feels like PHP, withouth being PHP :P
and with a good framework for webapps. Grails seemed perfect, but I
expected a smoother experience..

2012/1/5 xmly [via Grails] <ml-node+***@n4.nabble.com>

> It is really hard to compare.
>
> But for JAVA people, Grails should the top choice.
>
>
>
> On Thu, Jan 5, 2012 at 6:33 AM, raffaele181188 <[hidden email]<http://user/SendEmail.jtp?type=node&node=4265909&i=0>
> > wrote:
>
>> +1 for the anti virus checking. I won't be able to test it untile next
>> Monday, but hopefully this will solve the problem
>>
>> Please undertand that even if RAM is very cheap I cannot buy and install
>> it myself without explict admins consensus :(
>> Also I remark that my monitors never show a RAM usage over 70%, so we are
>> pretty far away from swap land
>>
>> I have to ask one more question. I have some background in PHP and I must
>> say that the development lifecycle is very smooth.
>> Now the new company I work for is mostly Java based, and I must say that
>> developing (and deploying!) feels really slow compared to PHP
>> If you have any experience in other dynamic languages frameworks (PHP,
>> Ruby + Rails, Python, Scala), how do you compare those to
>> Grails development? I'm talking about the "development speed", where the
>> reference is the PHP cycle:
>> 1. Edit file
>> 2. Refresh the browser
>> 3. (at deploy time) Copy files
>>
>> Raffaele
>>
>> 2012/1/5 Jason Davis [via Grails] <[hidden email]<http://user/SendEmail.jtp?type=node&node=4265707&i=0>
>> >
>>
>> quick question... who gives a crap about rails or ruby, can we focus
>>> on fixing the problem. Not replacing every stinking technology the OP
>>> is using. lame...
>>>
>>> On Thu, Jan 5, 2012 at 7:06 AM, Jason Davis <[hidden email]<http://user/SendEmail.jtp?type=node&node=4265612&i=0>>
>>> wrote:
>>>
>>> > quick question... who gives a shit about rails or ruby, can we focus
>>> > on fixing the problem. Not replacing every stinking technology the OP
>>> > is using. lame...
>>> >
>>> > On Thu, Jan 5, 2012 at 6:51 AM, Burt Beckwith <[hidden email]<http://user/SendEmail.jtp?type=node&node=4265612&i=1>>
>>> wrote:
>>>
>>> >> Sorry for cherry-picking into a long email and a long thread, but
>>> your
>>> >> Rails/Grails bug comparison is very weak. You reported two simple
>>> Rails bugs
>>> >> that were each fixed with a single line of code, and are comparing
>>> these to
>>> >> Grails issues that are a significantly more involved.
>>> >>
>>> >> Burt
>>> >>
>>> >> On Thursday, January 05, 2012 11:17:45 AM Rodrigo Rosenfeld Rosas
>>> wrote:
>>> >>> Hi virtualeyes,
>>> >>>
>>> >>> Em 04-01-2012 19:51, virtualeyes escreveu:
>>> >>> > ... The reality is that Grails
>>> >>> > is in fact absurdly fast to restart, faster than or as fast as,
>>> cough-
>>> >> cough,
>>> >>> > Rails.
>>> >>>
>>> >>> I have no idea where you did take your estimates from. In my PC,
>>> Grails
>>> >>> takes from 36 to 40s to boot an empty app, while JRuby on Rails
>>> takes
>>> >>> about 16s and Rails itself (on CRuby) takes a single second. I guess
>>> you
>>> >>> were talking about using the interactive console for booting the
>>> Grails
>>> >>> app. In that case, for an empty app, it takes about 2 seconds here,
>>> >>> which is still a bit slower than vanilla Rails, but certainly much
>>> >>> faster than JRuby on Rails.
>>> >>>
>>> >>> But anyway, I'm not really much concerned about the time required to
>>> >>> boot the application as long as I only have to do it once. My main
>>> gripe
>>> >>> with Grails 1.3.7 is that it would reboot after each little change
>>> to my
>>> >>> domain classes and other source files, and that took a huge time.
>>> >>>
>>> >>> Now, with Grails 2, even without the interactive console, the user
>>> >>> experience is much better as I don't need to often reboot the
>>> >>> application. The interactive console just makes Grails even more
>>> >>> responsive. But in the expense of subtle bugs that will show up when
>>> >>> using the interactive console that wouldn't be present otherwise...
>>> >>>
>>> >>> The main disadvantage of a slow bootup time (in any
>>> >>> framework/environment) is that it makes running your integration
>>> tests
>>> >>> slower. While using Rspec for writing tests for Rails, one can use
>>> Spork
>>> >>> that will take a similar approach to the one taken from Grails
>>> >>> interactive console, that will make tests run much faster.
>>> >>>
>>> >>> So, that article that you mentioned is certainly out-of-date and I
>>> need
>>> >>> to rewrite it when I find some time. I'll write a new one and add a
>>> >>> deprecation note on that one when I'm done for keeping the old
>>> comments.
>>> >>>
>>> >>> My main gripe with Grails currently is that I find it very hard to
>>> debug
>>> >>> and find what is causing troubles in my application setup. I often
>>> have
>>> >>> to create a fresh Grails app and gradually copy my files to there
>>> until
>>> >>> I find the source of the problem.
>>> >>>
>>> >>> The Grails error messages don't give me a single clue about the
>>> problem
>>> >>> most of the times. That is not to say that I have no more issues
>>> with
>>> >>> Grails. I don't like it in many ways, but I find the over-complex
>>> black
>>> >>> magic behind Grails the one that takes be most of the time when I'm
>>> >>> trying to identify some issues.
>>> >>>
>>> >>> Also, I find that the Grails community has poor support when
>>> compared
>>> >>> with the Rails and Ruby one. I have lots of unanswered messages in
>>> this
>>> >>> list where I point to buggy scenarios or plugins.
>>> >>>
>>> >>> For, example, I've filled two bugs in the Rails issues system last
>>> year,
>>> >>> and both were fixed and commited in less than an hour:
>>> >>>
>>> >>> https://github.com/rails/rails/issues/4054
>>> >>> https://github.com/rails/rails/issues/4067
>>> >>>
>>> >>> In the other side, here are some bugs (or feature requests) I've
>>> >>> reported to the Grails JIRA:
>>> >>>
>>> >>> http://jira.grails.org/browse/GRAILS-8568
>>> >>> http://jira.grails.org/browse/GRAILS-8567
>>> >>> http://jira.grails.org/browse/GPCONSOLE-3
>>>
>>> >>> http://jira.grails.org/browse/GRAILS-8539 (I'm the only one
>>> >>> participating on this one, for example)
>>> >>> http://jira.grails.org/browse/GRAILS-8485
>>> >>> http://jira.grails.org/browse/GRAILS-7792 (feature request)
>>> >>> http://jira.grails.org/browse/GRAILS-3303 (closed as won't fix,
>>> although
>>> >>> I think it could be fixed...)
>>> >>> https://github.com/SpringSource/grails-data-mapping/issues/18
>>> >>>
>>> >>> Unanswered messages in this list:
>>> >>>
>>> >>>
>>> http://grails.1312388.n4.nabble.com/Strange-issue-with-Grails-2-and-find-
>>> >> with-closure-td4222761.html
>>> >>>
>>> http://grails.1312388.n4.nabble.com/mongodb-and-hibernate-are-not-playing-
>>> >> well-together-td4222229.html
>>> >>> this wasn't answered. It was just told me to not report bugs in the
>>> dev
>>> >>> mailing list, but I didn't get any reply in the user's list too
>>> >>>
>>> http://grails.1312388.n4.nabble.com/MongoDB-and-multiple-databases-not-
>>> >> talking-about-replication-td4210794.html
>>> >>> just a minor part of the message was answered
>>> >>>
>>> http://grails.1312388.n4.nabble.com/Is-there-an-easy-way-to-set-default-
>>> >> mapping-options-to-all-columns-of-some-GORM-class-td4210934.html
>>> >>>
>>> http://grails.1312388.n4.nabble.com/mongodb-plugin-and-quot-static-mapping-
>>> >>
>>> version-false-quot-why-does-the-quot-version-quot-key-is-adde-td4210920.html
>>>
>>> >>>
>>> http://grails.1312388.n4.nabble.com/Grails-resources-plugin-still-uses-
>>> >> deprecated-ConfigurationHolder-td4208027.html
>>> >>>
>>> http://grails.1312388.n4.nabble.com/grails-shell-will-raise-an-exception-
>>> >> while-trying-to-autocomplete-a-Map-td4205530.html
>>> >>>
>>> http://grails.1312388.n4.nabble.com/Can-t-upgrade-to-Grails-2-from-1-3-7-
>>> >> and-have-no-clue-all-requests-yields-to-404-status-td4178489.html
>>> >>> http://www.digipedia.pl/usenet/thread/14352/30474/
>>> >>>
>>> http://grails.1312388.n4.nabble.com/How-to-write-scripts-using-GORM-enabled-
>>> >> domain-classes-td3868599.html
>>> >>> (I've got only a suggestion to use another testing framework, but
>>> didn't
>>> >>> get a real answer to what I was asking for)
>>> >>>
>>> http://grails.1312388.n4.nabble.com/Grails-scripts-help-td3867976.html
>>> >>>
>>>
>>> >>>
>>> >>> Also, besides free time, I still need some more time experimenting
>>> with
>>> >>> Grails 2 before I can write the new article on the subject...
>>> >>>
>>> >>> Best,
>>> >>>
>>> >>> Rodrigo.
>>> >>
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> 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
>>>
>>>
>>>
>>>
>>> ------------------------------
>>> If you reply to this email, your message will be added to the
>>> discussion below:
>>>
>>> http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265612.html
>>> To unsubscribe from Grails development is really slow, click here.
>>> NAML<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>>
>>
>>
>> ------------------------------
>> View this message in context: Re: Grails development is really slow<http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265707.html>
>> Sent from the Grails - user mailing list archive<http://grails.1312388.n4.nabble.com/Grails-user-f1312389.html>at Nabble.com.
>>
>
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265909.html
> To unsubscribe from Grails development is really slow, click here<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4257651&code=cmFmZmFlbGVzZ2Fycm9AZ21haWwuY29tfDQyNTc2NTF8LTE3Njk1MDM5MDc=>
> .
> NAML<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>


--
View this message in context: http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265924.html
Sent from the Grails - user mailing list archive at Nabble.com.
Roberto Guerra
2012-01-05 15:40:59 UTC
Permalink
php != grails. You are going about it the wrong way. People picking up
different languages and frameworks expecting it to work like something
else. Hmmm, maybe I'll pick up Objective C expecting it feel like basic.

On Thu, Jan 5, 2012 at 9:36 AM, raffaele181188 <***@gmail.com>wrote:

> But Java itself is not such a smooth experience. My primary objective is
> find a language that feels like PHP, withouth being PHP :P
> and with a good framework for webapps. Grails seemed perfect, but I
> expected a smoother experience..
>
> 2012/1/5 xmly [via Grails] <[hidden email]<http://user/SendEmail.jtp?type=node&node=4265924&i=0>
> >
>
>> It is really hard to compare.
>>
>> But for JAVA people, Grails should the top choice.
>>
>>
>>
>> On Thu, Jan 5, 2012 at 6:33 AM, raffaele181188 <[hidden email]<http://user/SendEmail.jtp?type=node&node=4265909&i=0>
>> > wrote:
>>
>>> +1 for the anti virus checking. I won't be able to test it untile next
>>> Monday, but hopefully this will solve the problem
>>>
>>> Please undertand that even if RAM is very cheap I cannot buy and install
>>> it myself without explict admins consensus :(
>>> Also I remark that my monitors never show a RAM usage over 70%, so we
>>> are pretty far away from swap land
>>>
>>> I have to ask one more question. I have some background in PHP and I
>>> must say that the development lifecycle is very smooth.
>>> Now the new company I work for is mostly Java based, and I must say that
>>> developing (and deploying!) feels really slow compared to PHP
>>> If you have any experience in other dynamic languages frameworks (PHP,
>>> Ruby + Rails, Python, Scala), how do you compare those to
>>> Grails development? I'm talking about the "development speed", where the
>>> reference is the PHP cycle:
>>> 1. Edit file
>>> 2. Refresh the browser
>>> 3. (at deploy time) Copy files
>>>
>>> Raffaele
>>>
>>> 2012/1/5 Jason Davis [via Grails] <[hidden email]<http://user/SendEmail.jtp?type=node&node=4265707&i=0>
>>> >
>>>
>>> quick question... who gives a crap about rails or ruby, can we focus
>>>> on fixing the problem. Not replacing every stinking technology the OP
>>>> is using. lame...
>>>>
>>>> On Thu, Jan 5, 2012 at 7:06 AM, Jason Davis <[hidden email]<http://user/SendEmail.jtp?type=node&node=4265612&i=0>>
>>>> wrote:
>>>>
>>>> > quick question... who gives a shit about rails or ruby, can we focus
>>>> > on fixing the problem. Not replacing every stinking technology the OP
>>>> > is using. lame...
>>>> >
>>>> > On Thu, Jan 5, 2012 at 6:51 AM, Burt Beckwith <[hidden email]<http://user/SendEmail.jtp?type=node&node=4265612&i=1>>
>>>> wrote:
>>>>
>>>> >> Sorry for cherry-picking into a long email and a long thread, but
>>>> your
>>>> >> Rails/Grails bug comparison is very weak. You reported two simple
>>>> Rails bugs
>>>> >> that were each fixed with a single line of code, and are comparing
>>>> these to
>>>> >> Grails issues that are a significantly more involved.
>>>> >>
>>>> >> Burt
>>>> >>
>>>> >> On Thursday, January 05, 2012 11:17:45 AM Rodrigo Rosenfeld Rosas
>>>> wrote:
>>>> >>> Hi virtualeyes,
>>>> >>>
>>>> >>> Em 04-01-2012 19:51, virtualeyes escreveu:
>>>> >>> > ... The reality is that Grails
>>>> >>> > is in fact absurdly fast to restart, faster than or as fast as,
>>>> cough-
>>>> >> cough,
>>>> >>> > Rails.
>>>> >>>
>>>> >>> I have no idea where you did take your estimates from. In my PC,
>>>> Grails
>>>> >>> takes from 36 to 40s to boot an empty app, while JRuby on Rails
>>>> takes
>>>> >>> about 16s and Rails itself (on CRuby) takes a single second. I
>>>> guess you
>>>> >>> were talking about using the interactive console for booting the
>>>> Grails
>>>> >>> app. In that case, for an empty app, it takes about 2 seconds here,
>>>> >>> which is still a bit slower than vanilla Rails, but certainly much
>>>> >>> faster than JRuby on Rails.
>>>> >>>
>>>> >>> But anyway, I'm not really much concerned about the time required
>>>> to
>>>> >>> boot the application as long as I only have to do it once. My main
>>>> gripe
>>>> >>> with Grails 1.3.7 is that it would reboot after each little change
>>>> to my
>>>> >>> domain classes and other source files, and that took a huge time.
>>>> >>>
>>>> >>> Now, with Grails 2, even without the interactive console, the user
>>>> >>> experience is much better as I don't need to often reboot the
>>>> >>> application. The interactive console just makes Grails even more
>>>> >>> responsive. But in the expense of subtle bugs that will show up
>>>> when
>>>> >>> using the interactive console that wouldn't be present otherwise...
>>>> >>>
>>>> >>> The main disadvantage of a slow bootup time (in any
>>>> >>> framework/environment) is that it makes running your integration
>>>> tests
>>>> >>> slower. While using Rspec for writing tests for Rails, one can use
>>>> Spork
>>>> >>> that will take a similar approach to the one taken from Grails
>>>> >>> interactive console, that will make tests run much faster.
>>>> >>>
>>>> >>> So, that article that you mentioned is certainly out-of-date and I
>>>> need
>>>> >>> to rewrite it when I find some time. I'll write a new one and add a
>>>> >>> deprecation note on that one when I'm done for keeping the old
>>>> comments.
>>>> >>>
>>>> >>> My main gripe with Grails currently is that I find it very hard to
>>>> debug
>>>> >>> and find what is causing troubles in my application setup. I often
>>>> have
>>>> >>> to create a fresh Grails app and gradually copy my files to there
>>>> until
>>>> >>> I find the source of the problem.
>>>> >>>
>>>> >>> The Grails error messages don't give me a single clue about the
>>>> problem
>>>> >>> most of the times. That is not to say that I have no more issues
>>>> with
>>>> >>> Grails. I don't like it in many ways, but I find the over-complex
>>>> black
>>>> >>> magic behind Grails the one that takes be most of the time when I'm
>>>> >>> trying to identify some issues.
>>>> >>>
>>>> >>> Also, I find that the Grails community has poor support when
>>>> compared
>>>> >>> with the Rails and Ruby one. I have lots of unanswered messages in
>>>> this
>>>> >>> list where I point to buggy scenarios or plugins.
>>>> >>>
>>>> >>> For, example, I've filled two bugs in the Rails issues system last
>>>> year,
>>>> >>> and both were fixed and commited in less than an hour:
>>>> >>>
>>>> >>> https://github.com/rails/rails/issues/4054
>>>> >>> https://github.com/rails/rails/issues/4067
>>>> >>>
>>>> >>> In the other side, here are some bugs (or feature requests) I've
>>>> >>> reported to the Grails JIRA:
>>>> >>>
>>>> >>> http://jira.grails.org/browse/GRAILS-8568
>>>> >>> http://jira.grails.org/browse/GRAILS-8567
>>>> >>> http://jira.grails.org/browse/GPCONSOLE-3
>>>>
>>>> >>> http://jira.grails.org/browse/GRAILS-8539 (I'm the only one
>>>> >>> participating on this one, for example)
>>>> >>> http://jira.grails.org/browse/GRAILS-8485
>>>> >>> http://jira.grails.org/browse/GRAILS-7792 (feature request)
>>>> >>> http://jira.grails.org/browse/GRAILS-3303 (closed as won't fix,
>>>> although
>>>> >>> I think it could be fixed...)
>>>> >>> https://github.com/SpringSource/grails-data-mapping/issues/18
>>>> >>>
>>>> >>> Unanswered messages in this list:
>>>> >>>
>>>> >>>
>>>> http://grails.1312388.n4.nabble.com/Strange-issue-with-Grails-2-and-find-
>>>> >> with-closure-td4222761.html
>>>> >>>
>>>> http://grails.1312388.n4.nabble.com/mongodb-and-hibernate-are-not-playing-
>>>> >> well-together-td4222229.html
>>>> >>> this wasn't answered. It was just told me to not report bugs in the
>>>> dev
>>>> >>> mailing list, but I didn't get any reply in the user's list too
>>>> >>>
>>>> http://grails.1312388.n4.nabble.com/MongoDB-and-multiple-databases-not-
>>>> >> talking-about-replication-td4210794.html
>>>> >>> just a minor part of the message was answered
>>>> >>>
>>>> http://grails.1312388.n4.nabble.com/Is-there-an-easy-way-to-set-default-
>>>> >> mapping-options-to-all-columns-of-some-GORM-class-td4210934.html
>>>> >>>
>>>> http://grails.1312388.n4.nabble.com/mongodb-plugin-and-quot-static-mapping-
>>>> >>
>>>> version-false-quot-why-does-the-quot-version-quot-key-is-adde-td4210920.html
>>>>
>>>> >>>
>>>> http://grails.1312388.n4.nabble.com/Grails-resources-plugin-still-uses-
>>>> >> deprecated-ConfigurationHolder-td4208027.html
>>>> >>>
>>>> http://grails.1312388.n4.nabble.com/grails-shell-will-raise-an-exception-
>>>> >> while-trying-to-autocomplete-a-Map-td4205530.html
>>>> >>>
>>>> http://grails.1312388.n4.nabble.com/Can-t-upgrade-to-Grails-2-from-1-3-7-
>>>> >> and-have-no-clue-all-requests-yields-to-404-status-td4178489.html
>>>> >>> http://www.digipedia.pl/usenet/thread/14352/30474/
>>>> >>>
>>>> http://grails.1312388.n4.nabble.com/How-to-write-scripts-using-GORM-enabled-
>>>> >> domain-classes-td3868599.html
>>>> >>> (I've got only a suggestion to use another testing framework, but
>>>> didn't
>>>> >>> get a real answer to what I was asking for)
>>>> >>>
>>>> http://grails.1312388.n4.nabble.com/Grails-scripts-help-td3867976.html
>>>> >>>
>>>>
>>>> >>>
>>>> >>> Also, besides free time, I still need some more time experimenting
>>>> with
>>>> >>> Grails 2 before I can write the new article on the subject...
>>>> >>>
>>>> >>> Best,
>>>> >>>
>>>> >>> Rodrigo.
>>>> >>
>>>> >>
>>>> >>
>>>> ---------------------------------------------------------------------
>>>> >> 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
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------
>>>> If you reply to this email, your message will be added to the
>>>> discussion below:
>>>>
>>>> http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265612.html
>>>> To unsubscribe from Grails development is really slow, click here.
>>>> NAML<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>>>
>>>
>>>
>>> ------------------------------
>>> View this message in context: Re: Grails development is really slow<http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265707.html>
>>> Sent from the Grails - user mailing list archive<http://grails.1312388.n4.nabble.com/Grails-user-f1312389.html>at Nabble.com.
>>>
>>
>>
>>
>> ------------------------------
>> If you reply to this email, your message will be added to the
>> discussion below:
>>
>> http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265909.html
>> To unsubscribe from Grails development is really slow, click here.
>> NAML<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>
>
> ------------------------------
> View this message in context: Re: Grails development is really slow<http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265924.html>
> Sent from the Grails - user mailing list archive<http://grails.1312388.n4.nabble.com/Grails-user-f1312389.html>at Nabble.com.
>



--
*The Journey Is The Reward.*
Gavin Yue
2012-01-05 15:47:41 UTC
Permalink
I have used Grails for almost 2 years. Before I have done two project using
PHP/ZendFramework.
My personal feeling is that Grails is easy to start, but hard to master it.
Grails is actually a collection of several famous tools:
Spring/Hibernate/...
If you really want to understand what happened under the hood, you have to
know each of them very well.
So if your learning sequence is like: Servelet/JSP/JDBC ->
Struts/Spring/ORM ->Groovy/Grails, then you would feel Wow.... But
reversed learning cycle would be quite painful...

Based on what you said, I would recommend Python/Django, though Python3 is
a problem.


On Thu, Jan 5, 2012 at 7:36 AM, raffaele181188 <***@gmail.com>wrote:

> But Java itself is not such a smooth experience. My primary objective is
> find a language that feels like PHP, withouth being PHP :P
> and with a good framework for webapps. Grails seemed perfect, but I
> expected a smoother experience..
>
> 2012/1/5 xmly [via Grails] <[hidden email]<http://user/SendEmail.jtp?type=node&node=4265924&i=0>
> >
>
>> It is really hard to compare.
>>
>> But for JAVA people, Grails should the top choice.
>>
>>
>>
>> On Thu, Jan 5, 2012 at 6:33 AM, raffaele181188 <[hidden email]<http://user/SendEmail.jtp?type=node&node=4265909&i=0>
>> > wrote:
>>
>>> +1 for the anti virus checking. I won't be able to test it untile next
>>> Monday, but hopefully this will solve the problem
>>>
>>> Please undertand that even if RAM is very cheap I cannot buy and install
>>> it myself without explict admins consensus :(
>>> Also I remark that my monitors never show a RAM usage over 70%, so we
>>> are pretty far away from swap land
>>>
>>> I have to ask one more question. I have some background in PHP and I
>>> must say that the development lifecycle is very smooth.
>>> Now the new company I work for is mostly Java based, and I must say that
>>> developing (and deploying!) feels really slow compared to PHP
>>> If you have any experience in other dynamic languages frameworks (PHP,
>>> Ruby + Rails, Python, Scala), how do you compare those to
>>> Grails development? I'm talking about the "development speed", where the
>>> reference is the PHP cycle:
>>> 1. Edit file
>>> 2. Refresh the browser
>>> 3. (at deploy time) Copy files
>>>
>>> Raffaele
>>>
>>> 2012/1/5 Jason Davis [via Grails] <[hidden email]<http://user/SendEmail.jtp?type=node&node=4265707&i=0>
>>> >
>>>
>>> quick question... who gives a crap about rails or ruby, can we focus
>>>> on fixing the problem. Not replacing every stinking technology the OP
>>>> is using. lame...
>>>>
>>>> On Thu, Jan 5, 2012 at 7:06 AM, Jason Davis <[hidden email]<http://user/SendEmail.jtp?type=node&node=4265612&i=0>>
>>>> wrote:
>>>>
>>>> > quick question... who gives a shit about rails or ruby, can we focus
>>>> > on fixing the problem. Not replacing every stinking technology the OP
>>>> > is using. lame...
>>>> >
>>>> > On Thu, Jan 5, 2012 at 6:51 AM, Burt Beckwith <[hidden email]<http://user/SendEmail.jtp?type=node&node=4265612&i=1>>
>>>> wrote:
>>>>
>>>> >> Sorry for cherry-picking into a long email and a long thread, but
>>>> your
>>>> >> Rails/Grails bug comparison is very weak. You reported two simple
>>>> Rails bugs
>>>> >> that were each fixed with a single line of code, and are comparing
>>>> these to
>>>> >> Grails issues that are a significantly more involved.
>>>> >>
>>>> >> Burt
>>>> >>
>>>> >> On Thursday, January 05, 2012 11:17:45 AM Rodrigo Rosenfeld Rosas
>>>> wrote:
>>>> >>> Hi virtualeyes,
>>>> >>>
>>>> >>> Em 04-01-2012 19:51, virtualeyes escreveu:
>>>> >>> > ... The reality is that Grails
>>>> >>> > is in fact absurdly fast to restart, faster than or as fast as,
>>>> cough-
>>>> >> cough,
>>>> >>> > Rails.
>>>> >>>
>>>> >>> I have no idea where you did take your estimates from. In my PC,
>>>> Grails
>>>> >>> takes from 36 to 40s to boot an empty app, while JRuby on Rails
>>>> takes
>>>> >>> about 16s and Rails itself (on CRuby) takes a single second. I
>>>> guess you
>>>> >>> were talking about using the interactive console for booting the
>>>> Grails
>>>> >>> app. In that case, for an empty app, it takes about 2 seconds here,
>>>> >>> which is still a bit slower than vanilla Rails, but certainly much
>>>> >>> faster than JRuby on Rails.
>>>> >>>
>>>> >>> But anyway, I'm not really much concerned about the time required
>>>> to
>>>> >>> boot the application as long as I only have to do it once. My main
>>>> gripe
>>>> >>> with Grails 1.3.7 is that it would reboot after each little change
>>>> to my
>>>> >>> domain classes and other source files, and that took a huge time.
>>>> >>>
>>>> >>> Now, with Grails 2, even without the interactive console, the user
>>>> >>> experience is much better as I don't need to often reboot the
>>>> >>> application. The interactive console just makes Grails even more
>>>> >>> responsive. But in the expense of subtle bugs that will show up
>>>> when
>>>> >>> using the interactive console that wouldn't be present otherwise...
>>>> >>>
>>>> >>> The main disadvantage of a slow bootup time (in any
>>>> >>> framework/environment) is that it makes running your integration
>>>> tests
>>>> >>> slower. While using Rspec for writing tests for Rails, one can use
>>>> Spork
>>>> >>> that will take a similar approach to the one taken from Grails
>>>> >>> interactive console, that will make tests run much faster.
>>>> >>>
>>>> >>> So, that article that you mentioned is certainly out-of-date and I
>>>> need
>>>> >>> to rewrite it when I find some time. I'll write a new one and add a
>>>> >>> deprecation note on that one when I'm done for keeping the old
>>>> comments.
>>>> >>>
>>>> >>> My main gripe with Grails currently is that I find it very hard to
>>>> debug
>>>> >>> and find what is causing troubles in my application setup. I often
>>>> have
>>>> >>> to create a fresh Grails app and gradually copy my files to there
>>>> until
>>>> >>> I find the source of the problem.
>>>> >>>
>>>> >>> The Grails error messages don't give me a single clue about the
>>>> problem
>>>> >>> most of the times. That is not to say that I have no more issues
>>>> with
>>>> >>> Grails. I don't like it in many ways, but I find the over-complex
>>>> black
>>>> >>> magic behind Grails the one that takes be most of the time when I'm
>>>> >>> trying to identify some issues.
>>>> >>>
>>>> >>> Also, I find that the Grails community has poor support when
>>>> compared
>>>> >>> with the Rails and Ruby one. I have lots of unanswered messages in
>>>> this
>>>> >>> list where I point to buggy scenarios or plugins.
>>>> >>>
>>>> >>> For, example, I've filled two bugs in the Rails issues system last
>>>> year,
>>>> >>> and both were fixed and commited in less than an hour:
>>>> >>>
>>>> >>> https://github.com/rails/rails/issues/4054
>>>> >>> https://github.com/rails/rails/issues/4067
>>>> >>>
>>>> >>> In the other side, here are some bugs (or feature requests) I've
>>>> >>> reported to the Grails JIRA:
>>>> >>>
>>>> >>> http://jira.grails.org/browse/GRAILS-8568
>>>> >>> http://jira.grails.org/browse/GRAILS-8567
>>>> >>> http://jira.grails.org/browse/GPCONSOLE-3
>>>>
>>>> >>> http://jira.grails.org/browse/GRAILS-8539 (I'm the only one
>>>> >>> participating on this one, for example)
>>>> >>> http://jira.grails.org/browse/GRAILS-8485
>>>> >>> http://jira.grails.org/browse/GRAILS-7792 (feature request)
>>>> >>> http://jira.grails.org/browse/GRAILS-3303 (closed as won't fix,
>>>> although
>>>> >>> I think it could be fixed...)
>>>> >>> https://github.com/SpringSource/grails-data-mapping/issues/18
>>>> >>>
>>>> >>> Unanswered messages in this list:
>>>> >>>
>>>> >>>
>>>> http://grails.1312388.n4.nabble.com/Strange-issue-with-Grails-2-and-find-
>>>> >> with-closure-td4222761.html
>>>> >>>
>>>> http://grails.1312388.n4.nabble.com/mongodb-and-hibernate-are-not-playing-
>>>> >> well-together-td4222229.html
>>>> >>> this wasn't answered. It was just told me to not report bugs in the
>>>> dev
>>>> >>> mailing list, but I didn't get any reply in the user's list too
>>>> >>>
>>>> http://grails.1312388.n4.nabble.com/MongoDB-and-multiple-databases-not-
>>>> >> talking-about-replication-td4210794.html
>>>> >>> just a minor part of the message was answered
>>>> >>>
>>>> http://grails.1312388.n4.nabble.com/Is-there-an-easy-way-to-set-default-
>>>> >> mapping-options-to-all-columns-of-some-GORM-class-td4210934.html
>>>> >>>
>>>> http://grails.1312388.n4.nabble.com/mongodb-plugin-and-quot-static-mapping-
>>>> >>
>>>> version-false-quot-why-does-the-quot-version-quot-key-is-adde-td4210920.html
>>>>
>>>> >>>
>>>> http://grails.1312388.n4.nabble.com/Grails-resources-plugin-still-uses-
>>>> >> deprecated-ConfigurationHolder-td4208027.html
>>>> >>>
>>>> http://grails.1312388.n4.nabble.com/grails-shell-will-raise-an-exception-
>>>> >> while-trying-to-autocomplete-a-Map-td4205530.html
>>>> >>>
>>>> http://grails.1312388.n4.nabble.com/Can-t-upgrade-to-Grails-2-from-1-3-7-
>>>> >> and-have-no-clue-all-requests-yields-to-404-status-td4178489.html
>>>> >>> http://www.digipedia.pl/usenet/thread/14352/30474/
>>>> >>>
>>>> http://grails.1312388.n4.nabble.com/How-to-write-scripts-using-GORM-enabled-
>>>> >> domain-classes-td3868599.html
>>>> >>> (I've got only a suggestion to use another testing framework, but
>>>> didn't
>>>> >>> get a real answer to what I was asking for)
>>>> >>>
>>>> http://grails.1312388.n4.nabble.com/Grails-scripts-help-td3867976.html
>>>> >>>
>>>>
>>>> >>>
>>>> >>> Also, besides free time, I still need some more time experimenting
>>>> with
>>>> >>> Grails 2 before I can write the new article on the subject...
>>>> >>>
>>>> >>> Best,
>>>> >>>
>>>> >>> Rodrigo.
>>>> >>
>>>> >>
>>>> >>
>>>> ---------------------------------------------------------------------
>>>> >> 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
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------
>>>> If you reply to this email, your message will be added to the
>>>> discussion below:
>>>>
>>>> http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265612.html
>>>> To unsubscribe from Grails development is really slow, click here.
>>>> NAML<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>>>
>>>
>>>
>>> ------------------------------
>>> View this message in context: Re: Grails development is really slow<http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265707.html>
>>> Sent from the Grails - user mailing list archive<http://grails.1312388.n4.nabble.com/Grails-user-f1312389.html>at Nabble.com.
>>>
>>
>>
>>
>> ------------------------------
>> If you reply to this email, your message will be added to the
>> discussion below:
>>
>> http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265909.html
>> To unsubscribe from Grails development is really slow, click here.
>> NAML<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>
>
> ------------------------------
> View this message in context: Re: Grails development is really slow<http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4265924.html>
> Sent from the Grails - user mailing list archive<http://grails.1312388.n4.nabble.com/Grails-user-f1312389.html>at Nabble.com.
>
Rodrigo Rosenfeld Rosas
2012-01-05 16:15:12 UTC
Permalink
Em 05-01-2012 13:47, Gavin Yue escreveu:
> I have used Grails for almost 2 years. Before I have done two project
> using PHP/ZendFramework.
> My personal feeling is that Grails is easy to start, but hard to
> master it.
> Grails is actually a collection of several famous tools:
> Spring/Hibernate/...
> If you really want to understand what happened under the hood, you
> have to know each of them very well.
> *So if your learning sequence is like: Servelet/JSP/JDBC ->
> Struts/Spring/ORM ->Groovy/Grails, then you would feel Wow.... But
> reversed learning cycle would be quite painful...*

I strongly second that feeling.

> Based on what you said, I would recommend Python/Django, though
> Python3 is a problem.

And of course, I've already recommend Rails. Django doesn't use
migrations by default, just like Grails. I feel this is terribly wrong.
That was the main reason I've chosen Rails over Django or TurboGears
back in 2007 when I was back to web programming after a long time
working on embedded real-time systems with C/C++ while working on my
Master thesis on Robotics.

I didn't know Java, Ruby or Python at that time. Just Perl, C, C++ and
Delphi mostly. So, it wouldn't matter to me to use Python or Ruby since
I didn't know any of them. But I preferred the Rails approach and
specially the built-in migrations.

But I don't have strong experience with Django or TurboGears to give you
any meaningful comparison. But I have lots of Ruby/Rails experience to
recommend you that. It is much easier and faster to deploy too. And if
you're using Heroku, it is just a matter of "git push heroku prod", for
example. Even if you have your own servers, you can use tools like
Capistrano or Chef for easily automating your deploy.

Usually, I deploy my Grails application by rsyncing my war file to the
server with is slower than a git push. With Rails and Passenger I would
rather just git push and it would be much faster... Deploying is usually
faster too.

In the Java land, I had always have problems with regards to the web
container reloading of apps. There will always be memory leaks and after
some restarts of the application, it starts to become slower and it
won't allow more restarts after a certain amount and I'll have to
restart the container... Those things don't happen with Rails and
Passenger, for example. Actually, they're pretty particular to the Java
ecosystem.

But I don't think you have much of choice since your company is a
Java-based one... You shouldn't be looking for Django, I guess. Probably
your best alternatives would be JRuby on Rails, Play or Grails...

But I wouldn't go with Grails unless there are really Java experts in
your team that understand very well the frameworks used by Grails like
Spring and Hibernate.

Hope to have helped...

Cheers,

Rodrigo.

>
>
> On Thu, Jan 5, 2012 at 7:36 AM, raffaele181188
> <***@gmail.com <mailto:***@gmail.com>> wrote:
>
> But Java itself is not such a smooth experience. My primary
> objective is find a language that feels like PHP, withouth being
> PHP :P
> and with a good framework for webapps. Grails seemed perfect, but
> I expected a smoother experience..
>
> 2012/1/5 xmly [via Grails] <[hidden email]
> <http://user/SendEmail.jtp?type=node&node=4265924&i=0>>
>
> It is really hard to compare.
>
> But for JAVA people, Grails should the top choice.
>
Rodrigo Rosenfeld Rosas
2012-01-05 15:52:04 UTC
Permalink
Em 05-01-2012 11:51, Burt Beckwith escreveu:
> Sorry for cherry-picking into a long email and a long thread, but your
> Rails/Grails bug comparison is very weak. You reported two simple Rails bugs
> that were each fixed with a single line of code, and are comparing these to
> Grails issues that are a significantly more involved.

Sorry if it looked that way, Burt. That was not my intention.

I wasn't trying to compare the speed of fixing any issue by itself, but
I agree with you that I didn't make myself clear enough.

I was trying to say that I always get quick feedback from the Ruby/Rails
community.

I understand that some issues are just harder to fix than others.

But one of the issues I've reported with regards to the Grails console
plugin was really simple to fix (a broken CSS with a known solution) and
is still unfixed... And this would probably be a single-line fix too...

You might argue that this is not a priority bug to Grails and you would
be right. But the ones I've reported to Rails weren't priority ones too.
They're hardly used or someone would have reported them before me...

Cheers,

Rodrigo.

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

http://xircles.codehaus.org/manage_email
Danilo Tuler
2012-01-05 16:11:01 UTC
Permalink
> I was trying to say that I always get quick feedback from the Ruby/Rails
> community.
>
>


I think the reason is obvious. Rails community is much bigger.
Just compare [1] [2] [3] [4] [5].

It's not because rails users are more helpful than grails users.
And community is just one criteria to choose a framework.

[1] http://www.indeed.com/jobtrends/rails%2C+grails.html
[2] http://stackoverflow.com/questions/tagged/grails (5.534 questions)
[3] http://stackoverflow.com/questions/tagged/ruby-on-rails (59.608 questions)
[4] http://www.ohloh.net/p/grails
[5] http://www.ohloh.net/p/rails (http://www.ohloh.net/p/grails)

Peace out
-- Danilo
Rodrigo Rosenfeld Rosas
2012-01-05 16:50:59 UTC
Permalink
Em 05-01-2012 14:11, Danilo Tuler escreveu:
>> I was trying to say that I always get quick feedback from the Ruby/Rails
>> community.
> I think the reason is obvious. Rails community is much bigger.
>

You're simplifying things. It was always responsive since I knew Rails
in 2007. And it wasn't so popular those times...

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

http://xircles.codehaus.org/manage_email
Sebastien Blanc
2012-01-05 17:51:59 UTC
Permalink
As far as I know the subject of this thread is "Grails development is
really slow" and not "Grails Vs Rails" as Burt said. BTW , comparing those
is like Comparing peers and apples (translated from a dutch expression,
don't know if it makes any sense in english) : not the same stack, not the
same developer's profile , not the same clients ....


On Thu, Jan 5, 2012 at 5:50 PM, Rodrigo Rosenfeld Rosas <
***@yahoo.com.br> wrote:

> Em 05-01-2012 14:11, Danilo Tuler escreveu:
>
> I was trying to say that I always get quick feedback from the Ruby/Rails
>>> community.
>>>
>> I think the reason is obvious. Rails community is much bigger.
>>
>>
> You're simplifying things. It was always responsive since I knew Rails in
> 2007. And it wasn't so popular those times...
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/**manage_email<http://xircles.codehaus.org/manage_email>
>
>
>
Danilo Tuler
2012-01-05 18:03:24 UTC
Permalink
> BTW , comparing those is like Comparing peers and apples
>


I love peers. I hate apples.
Peers are juicier.

-- Danilo
Benjamin Klein
2012-01-05 18:09:02 UTC
Permalink
I think that you mean “pears.”

“peer” == a person with the same status or ability as another person

“pear” == a fruit

:)

--
b

On Jan 5, 2012, at 12:03 PM, Danilo Tuler wrote:

>> BTW , comparing those is like Comparing peers and apples
>
> I love peers. I hate apples.
> Peers are juicier.
>
> -- Danilo
>
Sebastien Blanc
2012-01-05 18:13:28 UTC
Permalink
OMG yes pear of course ! :-)


On Thu, Jan 5, 2012 at 7:09 PM, Benjamin Klein <***@silver-chalice.com>wrote:

> I think that you mean “pears.”
>
> “peer” == a person with the same status or ability as another person
>
> “pear” == a fruit
>
> :)
>
> --
> b
>
> On Jan 5, 2012, at 12:03 PM, Danilo Tuler wrote:
>
> BTW , comparing those is like Comparing peers and apples
>
> I love peers. I hate apples.
> Peers are juicier.
>
> -- Danilo
>
>
>
Danilo Tuler
2012-01-05 18:13:51 UTC
Permalink
> I think that you mean “pears.”
>
>


Riiight, pear :-)
I love pears and peers.

Non native english speaking :-)

-- Danilo
Sebastien Blanc
2012-01-05 18:20:16 UTC
Permalink
Yep, peer is the dutch spelling for pear , that's a reason why I made the
mistake

On Thu, Jan 5, 2012 at 7:13 PM, Danilo Tuler <***@gmail.com> wrote:

> I think that you mean “pears.”
>
> Riiight, pear :-)
> I love pears and peers.
>
> Non native english speaking :-)
>
> -- Danilo
>
>
Scott Eisenberg
2012-01-05 21:49:56 UTC
Permalink
I have to say as a PHP developer trying to move to Grails that I can sympathize with his various feelings.

1) I watch the list every day and see a number of questions - not just his - that go unanswered. Sometimes some round and round but they they just drop. It seems to me like a lot of the questions are simple answers that are just not documented well with another lot of questions being some serious grails voodoo that experts know about but kills newbies.

I can only assume that the Grails team is busy but I've often thought "they (Graeme, Peter, Burt) must know the answer off the top of their heads, why don't they just respond?" I would respond but most are beyond my knowledge.

2) The answer that you need to know Spring / Hibernate / etc to me is just crap. If you want to bring in experienced Java programmers to something rad-ier, then fine. If you want the PHP, .net and Rails people to come over, big mistake.

3) Every 6 months I try Grails again and within 5 hours of starting a project I hit some error that stops me cold. I have read the documentation about 10 times. I read the Gorm Gotchas. Now, I'm only moderately stupid (Ivy league degree in engineering + MBA from a top level school + 20 years development experience) so I know I should not be able to make this stuff work. But I managed to code a bunch of systems for my companies using Fortran, Java + JSP, Java + Generics + Frontman, & PHP but after 3 years of looking at Grails I'm still trying faces and noses, and books and authors just trying to get anything to work.

IM<not so>HO, the Grails team REALLY needs to respond to the pains of the newbies via doc and code simplification. The lack of attention to this is solely the reason why Grails remains so far back in the what's hot Google listings.

Seems to me like you have a few rabid perpetual newbies who are trying to let you all know that getting Grail to work is way too frustrating for us PHP'ers and we are implicitly offering to show you our pain. You'd we wiser to form some kind of on-line working group of newbies and keep fixing what roadblocks they run into (and iterating again with another round of newbies) until the roadblocks are but minor bumps in the road.

There's a LOT of doc written. It's a shame that the little bits missing, mess up the experience despite all that's been done.

Answering EVERY open question on the mailing list that someone else can't solve would be a GREAT first step.

I'm pretty convinced it's not the newbie's fault why grails is so hard get started with.

I've seen threads like this every few months or so. I know I'm pissing in the wind but what the hell.

PS Grails 2.0 is much better than the 1.x versions. There is always hope.

PPS I'm progressing down the path of learning Rails as a back-up. I have thoughts on what they do better.

Action Plan:
* Grails team dedicates one member (or all members) to make sure that every question asked on the listserv is answered. EVERY answer question drives a review of the doc to see what could be added to avoid the questions coming forward.
* Grails tram makes a committee of newbies who are actively trying to develop something real and have a real time dialog as to where they get stuck and immediately fixing the stuck-ness, particularly the documentation issues.
* Group actively tries to compare Rails v Grails and fix competitive disadvantages found. Rather than dismissing rails vs grails discussions, encourage them so long as they lead to Grails improvements. Designate a "Beat-Rails" evangelist from Spring to lead the effort.

On Jan 5, 2012, at 8:17 AM, Rodrigo Rosenfeld Rosas wrote:

> Hi virtualeyes,
>
> Em 04-01-2012 19:51, virtualeyes escreveu:
>> ... The reality is that Grails
>> is in fact absurdly fast to restart, faster than or as fast as, cough-cough,
>> Rails.
>
> I have no idea where you did take your estimates from. In my PC, Grails takes from 36 to 40s to boot an empty app, while JRuby on Rails takes about 16s and Rails itself (on CRuby) takes a single second. I guess you were talking about using the interactive console for booting the Grails app. In that case, for an empty app, it takes about 2 seconds here, which is still a bit slower than vanilla Rails, but certainly much faster than JRuby on Rails.
>
> But anyway, I'm not really much concerned about the time required to boot the application as long as I only have to do it once. My main gripe with Grails 1.3.7 is that it would reboot after each little change to my domain classes and other source files, and that took a huge time.
>
> Now, with Grails 2, even without the interactive console, the user experience is much better as I don't need to often reboot the application. The interactive console just makes Grails even more responsive. But in the expense of subtle bugs that will show up when using the interactive console that wouldn't be present otherwise...
>
> The main disadvantage of a slow bootup time (in any framework/environment) is that it makes running your integration tests slower. While using Rspec for writing tests for Rails, one can use Spork that will take a similar approach to the one taken from Grails interactive console, that will make tests run much faster.
>
> So, that article that you mentioned is certainly out-of-date and I need to rewrite it when I find some time. I'll write a new one and add a deprecation note on that one when I'm done for keeping the old comments.
>
> My main gripe with Grails currently is that I find it very hard to debug and find what is causing troubles in my application setup. I often have to create a fresh Grails app and gradually copy my files to there until I find the source of the problem.
>
> The Grails error messages don't give me a single clue about the problem most of the times. That is not to say that I have no more issues with Grails. I don't like it in many ways, but I find the over-complex black magic behind Grails the one that takes be most of the time when I'm trying to identify some issues.
>
> Also, I find that the Grails community has poor support when compared with the Rails and Ruby one. I have lots of unanswered messages in this list where I point to buggy scenarios or plugins.
>
> For, example, I've filled two bugs in the Rails issues system last year, and both were fixed and commited in less than an hour:
>
> https://github.com/rails/rails/issues/4054
> https://github.com/rails/rails/issues/4067
>
> In the other side, here are some bugs (or feature requests) I've reported to the Grails JIRA:
>
> http://jira.grails.org/browse/GRAILS-8568
> http://jira.grails.org/browse/GRAILS-8567
> http://jira.grails.org/browse/GPCONSOLE-3
> http://jira.grails.org/browse/GRAILS-8539 (I'm the only one participating on this one, for example)
> http://jira.grails.org/browse/GRAILS-8485
> http://jira.grails.org/browse/GRAILS-7792 (feature request)
> http://jira.grails.org/browse/GRAILS-3303 (closed as won't fix, although I think it could be fixed...)
> https://github.com/SpringSource/grails-data-mapping/issues/18
>
> Unanswered messages in this list:
>
> http://grails.1312388.n4.nabble.com/Strange-issue-with-Grails-2-and-find-with-closure-td4222761.html
> http://grails.1312388.n4.nabble.com/mongodb-and-hibernate-are-not-playing-well-together-td4222229.html this wasn't answered. It was just told me to not report bugs in the dev mailing list, but I didn't get any reply in the user's list too
> http://grails.1312388.n4.nabble.com/MongoDB-and-multiple-databases-not-talking-about-replication-td4210794.html just a minor part of the message was answered
> http://grails.1312388.n4.nabble.com/Is-there-an-easy-way-to-set-default-mapping-options-to-all-columns-of-some-GORM-class-td4210934.html
> http://grails.1312388.n4.nabble.com/mongodb-plugin-and-quot-static-mapping-version-false-quot-why-does-the-quot-version-quot-key-is-adde-td4210920.html
> http://grails.1312388.n4.nabble.com/Grails-resources-plugin-still-uses-deprecated-ConfigurationHolder-td4208027.html
> http://grails.1312388.n4.nabble.com/grails-shell-will-raise-an-exception-while-trying-to-autocomplete-a-Map-td4205530.html
> http://grails.1312388.n4.nabble.com/Can-t-upgrade-to-Grails-2-from-1-3-7-and-have-no-clue-all-requests-yields-to-404-status-td4178489.html
> http://www.digipedia.pl/usenet/thread/14352/30474/
> http://grails.1312388.n4.nabble.com/How-to-write-scripts-using-GORM-enabled-domain-classes-td3868599.html (I've got only a suggestion to use another testing framework, but didn't get a real answer to what I was asking for)
> http://grails.1312388.n4.nabble.com/Grails-scripts-help-td3867976.html
>
>
> Also, besides free time, I still need some more time experimenting with Grails 2 before I can write the new article on the subject...
>
> Best,
>
> Rodrigo.
>
>
> ---------------------------------------------------------------------
> 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
Jason Davis
2012-01-05 22:10:00 UTC
Permalink
I come from an almost exclusive java/swing background. No web apps at
all. So I don't know much about spring or hibernate to be honest. I
found grails really easy to get started with. I really don't
understand the complaints. I tried some web dev with php, using
CakePHP and no framwork at all. I hate PHP so no point in discussing
it anymore. I didnt find in anymore welcoming.

IRT unanswered posts... I wish our community was bigger and more
active in this regard. I have had good luck using stackoverflow.com.
I feel that grails allows really new people to get further than they
normally would. This makes for some wild, unintelligible questions on
the mailing list sometimes lol. Just knowing what the user is actually
asking is no easy task.

In the end I don't see where all this comparison helps anything. I'm
on this list to learn/help with grails/groovy. I really could care
less about how awesome rails/ruby is.

$.02

On Thu, Jan 5, 2012 at 2:49 PM, Scott Eisenberg <***@btrtrucks.com> wrote:
> I have to say as a PHP developer trying to move to Grails that I can sympathize with his various feelings.
>
> 1) I watch the list every day and see a number of questions - not just his - that go unanswered.  Sometimes some round and round but they they just drop.  It seems to me like a lot of the questions are simple answers that are just not documented well with another lot of questions being some serious grails voodoo that experts know about but kills newbies.
>
> I can only assume that the Grails team is busy but I've often thought "they (Graeme, Peter, Burt) must know the answer off the top of their heads, why don't they just respond?"  I would respond but most are beyond my knowledge.
>
> 2) The answer that you need to know Spring / Hibernate / etc to me is just crap.  If you want to bring in experienced Java programmers to something rad-ier, then fine.  If you want the PHP, .net and Rails people to come over, big mistake.
>
> 3) Every 6 months I try Grails again and within 5 hours of starting a project I hit some error that stops me cold.  I have read the documentation about 10 times.  I read the Gorm Gotchas.  Now, I'm only moderately stupid (Ivy league degree in engineering + MBA from a top level school + 20 years development experience) so I know I should not be able to make this stuff work.  But I managed to code a bunch of systems for my companies using Fortran, Java + JSP, Java + Generics + Frontman, & PHP but after 3 years of looking at Grails I'm still trying faces and noses, and books and authors just trying to get anything to work.
>
> IM<not so>HO, the Grails team REALLY needs to respond to the pains of the newbies via doc and code simplification.  The lack of attention to this is solely the reason why Grails remains so far back in the what's hot Google listings.
>
> Seems to me like you have a few rabid perpetual newbies who are trying to let you all know that getting Grail to work is way too frustrating for us PHP'ers and we are implicitly offering to show you our pain.  You'd we wiser to form some kind of on-line working group of newbies and keep fixing what roadblocks they run into (and iterating again with another round of newbies) until the roadblocks are but minor bumps in the road.
>
> There's a LOT of doc written.  It's a shame that the little bits missing, mess up the experience despite all that's been done.
>
> Answering EVERY open question on the mailing list that someone else can't solve would be a GREAT first step.
>
> I'm pretty convinced it's not the newbie's fault why grails is so hard get started with.
>
> I've seen threads like this every few months or so.  I know I'm pissing in the wind but what the hell.
>
> PS Grails 2.0 is much better than the 1.x versions.  There is always hope.
>
> PPS  I'm progressing down the path of learning Rails as a back-up.  I have thoughts on what they do better.
>
> Action Plan:
> * Grails team dedicates one member (or all members) to make sure that every question asked on the listserv is answered.  EVERY answer question drives a review of the doc to see what could be added to avoid the questions coming forward.
> * Grails tram makes a committee of newbies who are actively trying to develop something real and have a real time dialog as to where they get stuck and immediately fixing the stuck-ness, particularly the documentation issues.
> * Group actively tries to compare Rails v Grails and fix competitive disadvantages found.  Rather than dismissing rails vs grails discussions, encourage them so long as they lead to Grails improvements.  Designate a "Beat-Rails" evangelist from Spring to lead the effort.
>
> On Jan 5, 2012, at 8:17 AM, Rodrigo Rosenfeld Rosas wrote:
>
>> Hi virtualeyes,
>>
>> Em 04-01-2012 19:51, virtualeyes escreveu:
>>> ...  The reality is that Grails
>>> is in fact absurdly fast to restart, faster than or as fast as, cough-cough,
>>> Rails.
>>
>> I have no idea where you did take your estimates from. In my PC, Grails takes from 36 to 40s to boot an empty app, while JRuby on Rails takes about 16s and Rails itself (on CRuby) takes a single second. I guess you were talking about using the interactive console for booting the Grails app. In that case, for an empty app, it takes about 2 seconds here, which is still a bit slower than vanilla Rails, but certainly much faster than JRuby on Rails.
>>
>> But anyway, I'm not really much concerned about the time required to boot the application as long as I only have to do it once. My main gripe with Grails 1.3.7 is that it would reboot after each little change to my domain classes and other source files, and that took a huge time.
>>
>> Now, with Grails 2, even without the interactive console, the user experience is much better as I don't need to often reboot the application. The interactive console just makes Grails even more responsive. But in the expense of subtle bugs that will show up when using the interactive console that wouldn't be present otherwise...
>>
>> The main disadvantage of a slow bootup time (in any framework/environment) is that it makes running your integration tests slower. While using Rspec for writing tests for Rails, one can use Spork that will take a similar approach to the one taken from Grails interactive console, that will make tests run much faster.
>>
>> So, that article that you mentioned is certainly out-of-date and I need to rewrite it when I find some time. I'll write a new one and add a deprecation note on that one when I'm done for keeping the old comments.
>>
>> My main gripe with Grails currently is that I find it very hard to debug and find what is causing troubles in my application setup. I often have to create a fresh Grails app and gradually copy my files to there until I find the source of the problem.
>>
>> The Grails error messages don't give me a single clue about the problem most of the times. That is not to say that I have no more issues with Grails. I don't like it in many ways, but I find the over-complex black magic behind Grails the one that takes be most of the time when I'm trying to identify some issues.
>>
>> Also, I find that the Grails community has poor support when compared with the Rails and Ruby one. I have lots of unanswered messages in this list where I point to buggy scenarios or plugins.
>>
>> For, example, I've filled two bugs in the Rails issues system last year, and both were fixed and commited in less than an hour:
>>
>> https://github.com/rails/rails/issues/4054
>> https://github.com/rails/rails/issues/4067
>>
>> In the other side, here are some bugs (or feature requests) I've reported to the Grails JIRA:
>>
>> http://jira.grails.org/browse/GRAILS-8568
>> http://jira.grails.org/browse/GRAILS-8567
>> http://jira.grails.org/browse/GPCONSOLE-3
>> http://jira.grails.org/browse/GRAILS-8539 (I'm the only one participating on this one, for example)
>> http://jira.grails.org/browse/GRAILS-8485
>> http://jira.grails.org/browse/GRAILS-7792 (feature request)
>> http://jira.grails.org/browse/GRAILS-3303 (closed as won't fix, although I think it could be fixed...)
>> https://github.com/SpringSource/grails-data-mapping/issues/18
>>
>> Unanswered messages in this list:
>>
>> http://grails.1312388.n4.nabble.com/Strange-issue-with-Grails-2-and-find-with-closure-td4222761.html
>> http://grails.1312388.n4.nabble.com/mongodb-and-hibernate-are-not-playing-well-together-td4222229.html this wasn't answered. It was just told me to not report bugs in the dev mailing list, but I didn't get any reply in the user's list too
>> http://grails.1312388.n4.nabble.com/MongoDB-and-multiple-databases-not-talking-about-replication-td4210794.html just a minor part of the message was answered
>> http://grails.1312388.n4.nabble.com/Is-there-an-easy-way-to-set-default-mapping-options-to-all-columns-of-some-GORM-class-td4210934.html
>> http://grails.1312388.n4.nabble.com/mongodb-plugin-and-quot-static-mapping-version-false-quot-why-does-the-quot-version-quot-key-is-adde-td4210920.html
>> http://grails.1312388.n4.nabble.com/Grails-resources-plugin-still-uses-deprecated-ConfigurationHolder-td4208027.html
>> http://grails.1312388.n4.nabble.com/grails-shell-will-raise-an-exception-while-trying-to-autocomplete-a-Map-td4205530.html
>> http://grails.1312388.n4.nabble.com/Can-t-upgrade-to-Grails-2-from-1-3-7-and-have-no-clue-all-requests-yields-to-404-status-td4178489.html
>> http://www.digipedia.pl/usenet/thread/14352/30474/
>> http://grails.1312388.n4.nabble.com/How-to-write-scripts-using-GORM-enabled-domain-classes-td3868599.html (I've got only a suggestion to use another testing framework, but didn't get a real answer to what I was asking for)
>> http://grails.1312388.n4.nabble.com/Grails-scripts-help-td3867976.html
>>
>>
>> Also, besides free time, I still need some more time experimenting with Grails 2 before I can write the new article on the subject...
>>
>> Best,
>>
>> Rodrigo.
>>
>>
>> ---------------------------------------------------------------------
>> 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
Scott Eisenberg
2012-01-05 22:20:32 UTC
Permalink
I just think that Rails is the main competition (and to some degree inspiration) to Grails. I want Grails to be the preferred framework. To do that it must beat the competition. Therefore, it must be compared to know where it needs to improved.

Nothing is absolute, it's all relative.

PS I think all PHP frameworks are crap. That's why anyone wanting to grow beyond PHP will naturally look to Rails or Grails as a higher evolution. PHP without frameworks is easy to get things done; just typically doesn't really become OO type code.

On Jan 5, 2012, at 5:10 PM, Jason Davis wrote:

> I come from an almost exclusive java/swing background. No web apps at
> all. So I don't know much about spring or hibernate to be honest. I
> found grails really easy to get started with. I really don't
> understand the complaints. I tried some web dev with php, using
> CakePHP and no framwork at all. I hate PHP so no point in discussing
> it anymore. I didnt find in anymore welcoming.
>
> IRT unanswered posts... I wish our community was bigger and more
> active in this regard. I have had good luck using stackoverflow.com.
> I feel that grails allows really new people to get further than they
> normally would. This makes for some wild, unintelligible questions on
> the mailing list sometimes lol. Just knowing what the user is actually
> asking is no easy task.
>
> In the end I don't see where all this comparison helps anything. I'm
> on this list to learn/help with grails/groovy. I really could care
> less about how awesome rails/ruby is.
>
> $.02
>
> On Thu, Jan 5, 2012 at 2:49 PM, Scott Eisenberg <***@btrtrucks.com> wrote:
>> I have to say as a PHP developer trying to move to Grails that I can sympathize with his various feelings.
>>
>> 1) I watch the list every day and see a number of questions - not just his - that go unanswered. Sometimes some round and round but they they just drop. It seems to me like a lot of the questions are simple answers that are just not documented well with another lot of questions being some serious grails voodoo that experts know about but kills newbies.
>>
>> I can only assume that the Grails team is busy but I've often thought "they (Graeme, Peter, Burt) must know the answer off the top of their heads, why don't they just respond?" I would respond but most are beyond my knowledge.
>>
>> 2) The answer that you need to know Spring / Hibernate / etc to me is just crap. If you want to bring in experienced Java programmers to something rad-ier, then fine. If you want the PHP, .net and Rails people to come over, big mistake.
>>
>> 3) Every 6 months I try Grails again and within 5 hours of starting a project I hit some error that stops me cold. I have read the documentation about 10 times. I read the Gorm Gotchas. Now, I'm only moderately stupid (Ivy league degree in engineering + MBA from a top level school + 20 years development experience) so I know I should not be able to make this stuff work. But I managed to code a bunch of systems for my companies using Fortran, Java + JSP, Java + Generics + Frontman, & PHP but after 3 years of looking at Grails I'm still trying faces and noses, and books and authors just trying to get anything to work.
>>
>> IM<not so>HO, the Grails team REALLY needs to respond to the pains of the newbies via doc and code simplification. The lack of attention to this is solely the reason why Grails remains so far back in the what's hot Google listings.
>>
>> Seems to me like you have a few rabid perpetual newbies who are trying to let you all know that getting Grail to work is way too frustrating for us PHP'ers and we are implicitly offering to show you our pain. You'd we wiser to form some kind of on-line working group of newbies and keep fixing what roadblocks they run into (and iterating again with another round of newbies) until the roadblocks are but minor bumps in the road.
>>
>> There's a LOT of doc written. It's a shame that the little bits missing, mess up the experience despite all that's been done.
>>
>> Answering EVERY open question on the mailing list that someone else can't solve would be a GREAT first step.
>>
>> I'm pretty convinced it's not the newbie's fault why grails is so hard get started with.
>>
>> I've seen threads like this every few months or so. I know I'm pissing in the wind but what the hell.
>>
>> PS Grails 2.0 is much better than the 1.x versions. There is always hope.
>>
>> PPS I'm progressing down the path of learning Rails as a back-up. I have thoughts on what they do better.
>>
>> Action Plan:
>> * Grails team dedicates one member (or all members) to make sure that every question asked on the listserv is answered. EVERY answer question drives a review of the doc to see what could be added to avoid the questions coming forward.
>> * Grails tram makes a committee of newbies who are actively trying to develop something real and have a real time dialog as to where they get stuck and immediately fixing the stuck-ness, particularly the documentation issues.
>> * Group actively tries to compare Rails v Grails and fix competitive disadvantages found. Rather than dismissing rails vs grails discussions, encourage them so long as they lead to Grails improvements. Designate a "Beat-Rails" evangelist from Spring to lead the effort.
>>
>> On Jan 5, 2012, at 8:17 AM, Rodrigo Rosenfeld Rosas wrote:
>>
>>> Hi virtualeyes,
>>>
>>> Em 04-01-2012 19:51, virtualeyes escreveu:
>>>> ... The reality is that Grails
>>>> is in fact absurdly fast to restart, faster than or as fast as, cough-cough,
>>>> Rails.
>>>
>>> I have no idea where you did take your estimates from. In my PC, Grails takes from 36 to 40s to boot an empty app, while JRuby on Rails takes about 16s and Rails itself (on CRuby) takes a single second. I guess you were talking about using the interactive console for booting the Grails app. In that case, for an empty app, it takes about 2 seconds here, which is still a bit slower than vanilla Rails, but certainly much faster than JRuby on Rails.
>>>
>>> But anyway, I'm not really much concerned about the time required to boot the application as long as I only have to do it once. My main gripe with Grails 1.3.7 is that it would reboot after each little change to my domain classes and other source files, and that took a huge time.
>>>
>>> Now, with Grails 2, even without the interactive console, the user experience is much better as I don't need to often reboot the application. The interactive console just makes Grails even more responsive. But in the expense of subtle bugs that will show up when using the interactive console that wouldn't be present otherwise...
>>>
>>> The main disadvantage of a slow bootup time (in any framework/environment) is that it makes running your integration tests slower. While using Rspec for writing tests for Rails, one can use Spork that will take a similar approach to the one taken from Grails interactive console, that will make tests run much faster.
>>>
>>> So, that article that you mentioned is certainly out-of-date and I need to rewrite it when I find some time. I'll write a new one and add a deprecation note on that one when I'm done for keeping the old comments.
>>>
>>> My main gripe with Grails currently is that I find it very hard to debug and find what is causing troubles in my application setup. I often have to create a fresh Grails app and gradually copy my files to there until I find the source of the problem.
>>>
>>> The Grails error messages don't give me a single clue about the problem most of the times. That is not to say that I have no more issues with Grails. I don't like it in many ways, but I find the over-complex black magic behind Grails the one that takes be most of the time when I'm trying to identify some issues.
>>>
>>> Also, I find that the Grails community has poor support when compared with the Rails and Ruby one. I have lots of unanswered messages in this list where I point to buggy scenarios or plugins.
>>>
>>> For, example, I've filled two bugs in the Rails issues system last year, and both were fixed and commited in less than an hour:
>>>
>>> https://github.com/rails/rails/issues/4054
>>> https://github.com/rails/rails/issues/4067
>>>
>>> In the other side, here are some bugs (or feature requests) I've reported to the Grails JIRA:
>>>
>>> http://jira.grails.org/browse/GRAILS-8568
>>> http://jira.grails.org/browse/GRAILS-8567
>>> http://jira.grails.org/browse/GPCONSOLE-3
>>> http://jira.grails.org/browse/GRAILS-8539 (I'm the only one participating on this one, for example)
>>> http://jira.grails.org/browse/GRAILS-8485
>>> http://jira.grails.org/browse/GRAILS-7792 (feature request)
>>> http://jira.grails.org/browse/GRAILS-3303 (closed as won't fix, although I think it could be fixed...)
>>> https://github.com/SpringSource/grails-data-mapping/issues/18
>>>
>>> Unanswered messages in this list:
>>>
>>> http://grails.1312388.n4.nabble.com/Strange-issue-with-Grails-2-and-find-with-closure-td4222761.html
>>> http://grails.1312388.n4.nabble.com/mongodb-and-hibernate-are-not-playing-well-together-td4222229.html this wasn't answered. It was just told me to not report bugs in the dev mailing list, but I didn't get any reply in the user's list too
>>> http://grails.1312388.n4.nabble.com/MongoDB-and-multiple-databases-not-talking-about-replication-td4210794.html just a minor part of the message was answered
>>> http://grails.1312388.n4.nabble.com/Is-there-an-easy-way-to-set-default-mapping-options-to-all-columns-of-some-GORM-class-td4210934.html
>>> http://grails.1312388.n4.nabble.com/mongodb-plugin-and-quot-static-mapping-version-false-quot-why-does-the-quot-version-quot-key-is-adde-td4210920.html
>>> http://grails.1312388.n4.nabble.com/Grails-resources-plugin-still-uses-deprecated-ConfigurationHolder-td4208027.html
>>> http://grails.1312388.n4.nabble.com/grails-shell-will-raise-an-exception-while-trying-to-autocomplete-a-Map-td4205530.html
>>> http://grails.1312388.n4.nabble.com/Can-t-upgrade-to-Grails-2-from-1-3-7-and-have-no-clue-all-requests-yields-to-404-status-td4178489.html
>>> http://www.digipedia.pl/usenet/thread/14352/30474/
>>> http://grails.1312388.n4.nabble.com/How-to-write-scripts-using-GORM-enabled-domain-classes-td3868599.html (I've got only a suggestion to use another testing framework, but didn't get a real answer to what I was asking for)
>>> http://grails.1312388.n4.nabble.com/Grails-scripts-help-td3867976.html
>>>
>>>
>>> Also, besides free time, I still need some more time experimenting with Grails 2 before I can write the new article on the subject...
>>>
>>> Best,
>>>
>>> Rodrigo.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>


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

http://xircles.codehaus.org/manage_email
Octavian Covalschi
2012-01-05 22:43:10 UTC
Permalink
" PHP without frameworks is easy to get things done " - this might be
true, however how easy si to maintain those "done things" ? What about
quality?

I think some folks switching between technologies tend to think and code as
they're used to and from there are a lot of complaints...

No one has forbidden buying Grails books, there are plenty of good ones and
even more sample web apps...

When someone is coming to Grails world, he is coming to Java world... which
basically means:
- junit
- spring (not a must for grails, but helps a lot)
- hibernate
- ivy/maven/other dependency




On Thu, Jan 5, 2012 at 4:20 PM, Scott Eisenberg <***@btrtrucks.com>wrote:

> I just think that Rails is the main competition (and to some degree
> inspiration) to Grails. I want Grails to be the preferred framework. To
> do that it must beat the competition. Therefore, it must be compared to
> know where it needs to improved.
>
> Nothing is absolute, it's all relative.
>
> PS I think all PHP frameworks are crap. That's why anyone wanting to
> grow beyond PHP will naturally look to Rails or Grails as a higher
> evolution. PHP without frameworks is easy to get things done; just
> typically doesn't really become OO type code.
>
> On Jan 5, 2012, at 5:10 PM, Jason Davis wrote:
>
> > I come from an almost exclusive java/swing background. No web apps at
> > all. So I don't know much about spring or hibernate to be honest. I
> > found grails really easy to get started with. I really don't
> > understand the complaints. I tried some web dev with php, using
> > CakePHP and no framwork at all. I hate PHP so no point in discussing
> > it anymore. I didnt find in anymore welcoming.
> >
> > IRT unanswered posts... I wish our community was bigger and more
> > active in this regard. I have had good luck using stackoverflow.com.
> > I feel that grails allows really new people to get further than they
> > normally would. This makes for some wild, unintelligible questions on
> > the mailing list sometimes lol. Just knowing what the user is actually
> > asking is no easy task.
> >
> > In the end I don't see where all this comparison helps anything. I'm
> > on this list to learn/help with grails/groovy. I really could care
> > less about how awesome rails/ruby is.
> >
> > $.02
> >
> > On Thu, Jan 5, 2012 at 2:49 PM, Scott Eisenberg <***@btrtrucks.com>
> wrote:
> >> I have to say as a PHP developer trying to move to Grails that I can
> sympathize with his various feelings.
> >>
> >> 1) I watch the list every day and see a number of questions - not just
> his - that go unanswered. Sometimes some round and round but they they
> just drop. It seems to me like a lot of the questions are simple answers
> that are just not documented well with another lot of questions being some
> serious grails voodoo that experts know about but kills newbies.
> >>
> >> I can only assume that the Grails team is busy but I've often thought
> "they (Graeme, Peter, Burt) must know the answer off the top of their
> heads, why don't they just respond?" I would respond but most are beyond
> my knowledge.
> >>
> >> 2) The answer that you need to know Spring / Hibernate / etc to me is
> just crap. If you want to bring in experienced Java programmers to
> something rad-ier, then fine. If you want the PHP, .net and Rails people
> to come over, big mistake.
> >>
> >> 3) Every 6 months I try Grails again and within 5 hours of starting a
> project I hit some error that stops me cold. I have read the documentation
> about 10 times. I read the Gorm Gotchas. Now, I'm only moderately stupid
> (Ivy league degree in engineering + MBA from a top level school + 20 years
> development experience) so I know I should not be able to make this stuff
> work. But I managed to code a bunch of systems for my companies using
> Fortran, Java + JSP, Java + Generics + Frontman, & PHP but after 3 years of
> looking at Grails I'm still trying faces and noses, and books and authors
> just trying to get anything to work.
> >>
> >> IM<not so>HO, the Grails team REALLY needs to respond to the pains of
> the newbies via doc and code simplification. The lack of attention to this
> is solely the reason why Grails remains so far back in the what's hot
> Google listings.
> >>
> >> Seems to me like you have a few rabid perpetual newbies who are trying
> to let you all know that getting Grail to work is way too frustrating for
> us PHP'ers and we are implicitly offering to show you our pain. You'd we
> wiser to form some kind of on-line working group of newbies and keep fixing
> what roadblocks they run into (and iterating again with another round of
> newbies) until the roadblocks are but minor bumps in the road.
> >>
> >> There's a LOT of doc written. It's a shame that the little bits
> missing, mess up the experience despite all that's been done.
> >>
> >> Answering EVERY open question on the mailing list that someone else
> can't solve would be a GREAT first step.
> >>
> >> I'm pretty convinced it's not the newbie's fault why grails is so hard
> get started with.
> >>
> >> I've seen threads like this every few months or so. I know I'm pissing
> in the wind but what the hell.
> >>
> >> PS Grails 2.0 is much better than the 1.x versions. There is always
> hope.
> >>
> >> PPS I'm progressing down the path of learning Rails as a back-up. I
> have thoughts on what they do better.
> >>
> >> Action Plan:
> >> * Grails team dedicates one member (or all members) to make sure that
> every question asked on the listserv is answered. EVERY answer question
> drives a review of the doc to see what could be added to avoid the
> questions coming forward.
> >> * Grails tram makes a committee of newbies who are actively trying to
> develop something real and have a real time dialog as to where they get
> stuck and immediately fixing the stuck-ness, particularly the documentation
> issues.
> >> * Group actively tries to compare Rails v Grails and fix competitive
> disadvantages found. Rather than dismissing rails vs grails discussions,
> encourage them so long as they lead to Grails improvements. Designate a
> "Beat-Rails" evangelist from Spring to lead the effort.
> >>
> >> On Jan 5, 2012, at 8:17 AM, Rodrigo Rosenfeld Rosas wrote:
> >>
> >>> Hi virtualeyes,
> >>>
> >>> Em 04-01-2012 19:51, virtualeyes escreveu:
> >>>> ... The reality is that Grails
> >>>> is in fact absurdly fast to restart, faster than or as fast as,
> cough-cough,
> >>>> Rails.
> >>>
> >>> I have no idea where you did take your estimates from. In my PC,
> Grails takes from 36 to 40s to boot an empty app, while JRuby on Rails
> takes about 16s and Rails itself (on CRuby) takes a single second. I guess
> you were talking about using the interactive console for booting the Grails
> app. In that case, for an empty app, it takes about 2 seconds here, which
> is still a bit slower than vanilla Rails, but certainly much faster than
> JRuby on Rails.
> >>>
> >>> But anyway, I'm not really much concerned about the time required to
> boot the application as long as I only have to do it once. My main gripe
> with Grails 1.3.7 is that it would reboot after each little change to my
> domain classes and other source files, and that took a huge time.
> >>>
> >>> Now, with Grails 2, even without the interactive console, the user
> experience is much better as I don't need to often reboot the application.
> The interactive console just makes Grails even more responsive. But in the
> expense of subtle bugs that will show up when using the interactive console
> that wouldn't be present otherwise...
> >>>
> >>> The main disadvantage of a slow bootup time (in any
> framework/environment) is that it makes running your integration tests
> slower. While using Rspec for writing tests for Rails, one can use Spork
> that will take a similar approach to the one taken from Grails interactive
> console, that will make tests run much faster.
> >>>
> >>> So, that article that you mentioned is certainly out-of-date and I
> need to rewrite it when I find some time. I'll write a new one and add a
> deprecation note on that one when I'm done for keeping the old comments.
> >>>
> >>> My main gripe with Grails currently is that I find it very hard to
> debug and find what is causing troubles in my application setup. I often
> have to create a fresh Grails app and gradually copy my files to there
> until I find the source of the problem.
> >>>
> >>> The Grails error messages don't give me a single clue about the
> problem most of the times. That is not to say that I have no more issues
> with Grails. I don't like it in many ways, but I find the over-complex
> black magic behind Grails the one that takes be most of the time when I'm
> trying to identify some issues.
> >>>
> >>> Also, I find that the Grails community has poor support when compared
> with the Rails and Ruby one. I have lots of unanswered messages in this
> list where I point to buggy scenarios or plugins.
> >>>
> >>> For, example, I've filled two bugs in the Rails issues system last
> year, and both were fixed and commited in less than an hour:
> >>>
> >>> https://github.com/rails/rails/issues/4054
> >>> https://github.com/rails/rails/issues/4067
> >>>
> >>> In the other side, here are some bugs (or feature requests) I've
> reported to the Grails JIRA:
> >>>
> >>> http://jira.grails.org/browse/GRAILS-8568
> >>> http://jira.grails.org/browse/GRAILS-8567
> >>> http://jira.grails.org/browse/GPCONSOLE-3
> >>> http://jira.grails.org/browse/GRAILS-8539 (I'm the only one
> participating on this one, for example)
> >>> http://jira.grails.org/browse/GRAILS-8485
> >>> http://jira.grails.org/browse/GRAILS-7792 (feature request)
> >>> http://jira.grails.org/browse/GRAILS-3303 (closed as won't fix,
> although I think it could be fixed...)
> >>> https://github.com/SpringSource/grails-data-mapping/issues/18
> >>>
> >>> Unanswered messages in this list:
> >>>
> >>>
> http://grails.1312388.n4.nabble.com/Strange-issue-with-Grails-2-and-find-with-closure-td4222761.html
> >>>
> http://grails.1312388.n4.nabble.com/mongodb-and-hibernate-are-not-playing-well-together-td4222229.htmlthis wasn't answered. It was just told me to not report bugs in the dev
> mailing list, but I didn't get any reply in the user's list too
> >>>
> http://grails.1312388.n4.nabble.com/MongoDB-and-multiple-databases-not-talking-about-replication-td4210794.htmljust a minor part of the message was answered
> >>>
> http://grails.1312388.n4.nabble.com/Is-there-an-easy-way-to-set-default-mapping-options-to-all-columns-of-some-GORM-class-td4210934.html
> >>>
> http://grails.1312388.n4.nabble.com/mongodb-plugin-and-quot-static-mapping-version-false-quot-why-does-the-quot-version-quot-key-is-adde-td4210920.html
> >>>
> http://grails.1312388.n4.nabble.com/Grails-resources-plugin-still-uses-deprecated-ConfigurationHolder-td4208027.html
> >>>
> http://grails.1312388.n4.nabble.com/grails-shell-will-raise-an-exception-while-trying-to-autocomplete-a-Map-td4205530.html
> >>>
> http://grails.1312388.n4.nabble.com/Can-t-upgrade-to-Grails-2-from-1-3-7-and-have-no-clue-all-requests-yields-to-404-status-td4178489.html
> >>> http://www.digipedia.pl/usenet/thread/14352/30474/
> >>>
> http://grails.1312388.n4.nabble.com/How-to-write-scripts-using-GORM-enabled-domain-classes-td3868599.html(I've got only a suggestion to use another testing framework, but didn't
> get a real answer to what I was asking for)
> >>> http://grails.1312388.n4.nabble.com/Grails-scripts-help-td3867976.html
> >>>
> >>>
> >>> Also, besides free time, I still need some more time experimenting
> with Grails 2 before I can write the new article on the subject...
> >>>
> >>> Best,
> >>>
> >>> Rodrigo.
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
Muhammet S. AYDIN
2012-01-06 01:35:15 UTC
Permalink
i have written many times about this issue. grails is targeting existing
java developers. even a java beginner will get frustrated let alone a php,
python or ruby developer. i am a developer who uses php and python in his
daily job, built a start-up with ruby. grails disappointed me too many
times but i have not stopped trying and learning it. for example, when
building an application with turbogears/django/rails, if i need to dive in
the source i just browse their source codes in my browser but whenever i
wanted to dive in grails source i always got stuck. because i don't know
what is doing what. i fire up an ide and after tens of clicks and i get
frustrated. i stopped doing that.

how i stopped worrying and loved grails?

grails in my opinion is the next generation jvm web framework. it will
dominate the scene. imho, its only competitor is play framework. even
though i am not java developer, play was very easy for me to get started
and dive into its source. heck, i loved grails more. i just felt that way
and found more value in grails than anything else for the jvm.

here is the methodology i followed some years ago. i assume that you
already know the basic concepts of web programming and mvc. go ahead and
read in eric cartman's voice. :)

- fear do not.

- install grails and start a sample project.

- the goal is porting an existing app to grails from php/python/ruby.

- watch grails screencasts. <http://grails.org/Grails+Screencasts> (back in
my time, this was only 1 page, now it's 3 pages.)

- learn how grails controllers
work.<http://grails.org/doc/latest/guide/theWebLayer.html#controllers>

- how do i access my database, my tables? how do i map them to
classes?<http://grails.org/doc/latest/guide/GORM.html>

- let's see how do i port my views to
grails.<http://grails.org/doc/latest/guide/theWebLayer.html#gsp>

- problem, programmer?
- search stackoverflow, grails ml and google.
- look at the docs.
- ask in #grails in irc.freenode.net

- do not freak out, errors are your guide.

- can i map urls just like in
rails?<http://grails.org/doc/latest/guide/theWebLayer.html#urlmappings>

- how do i do things before or after my controller actions are
called?<http://grails.org/doc/latest/guide/theWebLayer.html#filters>

- how do i setup validation for my
models?<http://grails.org/doc/latest/guide/single.html#constraints>

- i need this table name to be different, this field to be a text. how do i
do it? <http://grails.org/doc/latest/guide/single.html#ormdsl>

- do not freak out, you are doing great.

- how do i access
session?<http://grails.org/doc/latest/ref/Servlet%20API/session.html>
i
need to build a simple authentication. spring-security is overkill.

- how do i change content
type?<http://grails.org/doc/latest/ref/Servlet%20API/response.html>i
just want to change it.

- how do i render
json?<http://grails.org/doc/latest/guide/theWebLayer.html#xmlAndJSON>i
want my response to be json.

- how do i deploy this?

as you see in the flow, porting an existing application from a similar tool
is a great way to learn grails. you already have the idea, you know the
concepts and you know your requirements. all you need to do is to ask the
right questions and find answers to them. learning as you go instead of
reading the docs from beginning to end is better. this is not where you
stop. when you develop another application, you will ask a lot more
different questions. you will face other challenges but you will be
learning as you go.

hope this helps to someone. do not fight grails. embrace it. love it. use
it. on something that has more memory than 512 mb. :)

2012/1/6 Octavian Covalschi <***@gmail.com>

> " PHP without frameworks is easy to get things done " - this might be
> true, however how easy si to maintain those "done things" ? What about
> quality?
>
> I think some folks switching between technologies tend to think and code
> as they're used to and from there are a lot of complaints...
>
> No one has forbidden buying Grails books, there are plenty of good ones
> and even more sample web apps...
>
> When someone is coming to Grails world, he is coming to Java world...
> which basically means:
> - junit
> - spring (not a must for grails, but helps a lot)
> - hibernate
> - ivy/maven/other dependency
>
>
>
>
> On Thu, Jan 5, 2012 at 4:20 PM, Scott Eisenberg <***@btrtrucks.com>wrote:
>
>> I just think that Rails is the main competition (and to some degree
>> inspiration) to Grails. I want Grails to be the preferred framework. To
>> do that it must beat the competition. Therefore, it must be compared to
>> know where it needs to improved.
>>
>> Nothing is absolute, it's all relative.
>>
>> PS I think all PHP frameworks are crap. That's why anyone wanting to
>> grow beyond PHP will naturally look to Rails or Grails as a higher
>> evolution. PHP without frameworks is easy to get things done; just
>> typically doesn't really become OO type code.
>>
>> On Jan 5, 2012, at 5:10 PM, Jason Davis wrote:
>>
>> > I come from an almost exclusive java/swing background. No web apps at
>> > all. So I don't know much about spring or hibernate to be honest. I
>> > found grails really easy to get started with. I really don't
>> > understand the complaints. I tried some web dev with php, using
>> > CakePHP and no framwork at all. I hate PHP so no point in discussing
>> > it anymore. I didnt find in anymore welcoming.
>> >
>> > IRT unanswered posts... I wish our community was bigger and more
>> > active in this regard. I have had good luck using stackoverflow.com.
>> > I feel that grails allows really new people to get further than they
>> > normally would. This makes for some wild, unintelligible questions on
>> > the mailing list sometimes lol. Just knowing what the user is actually
>> > asking is no easy task.
>> >
>> > In the end I don't see where all this comparison helps anything. I'm
>> > on this list to learn/help with grails/groovy. I really could care
>> > less about how awesome rails/ruby is.
>> >
>> > $.02
>> >
>> > On Thu, Jan 5, 2012 at 2:49 PM, Scott Eisenberg <***@btrtrucks.com>
>> wrote:
>> >> I have to say as a PHP developer trying to move to Grails that I can
>> sympathize with his various feelings.
>> >>
>> >> 1) I watch the list every day and see a number of questions - not just
>> his - that go unanswered. Sometimes some round and round but they they
>> just drop. It seems to me like a lot of the questions are simple answers
>> that are just not documented well with another lot of questions being some
>> serious grails voodoo that experts know about but kills newbies.
>> >>
>> >> I can only assume that the Grails team is busy but I've often thought
>> "they (Graeme, Peter, Burt) must know the answer off the top of their
>> heads, why don't they just respond?" I would respond but most are beyond
>> my knowledge.
>> >>
>> >> 2) The answer that you need to know Spring / Hibernate / etc to me is
>> just crap. If you want to bring in experienced Java programmers to
>> something rad-ier, then fine. If you want the PHP, .net and Rails people
>> to come over, big mistake.
>> >>
>> >> 3) Every 6 months I try Grails again and within 5 hours of starting a
>> project I hit some error that stops me cold. I have read the documentation
>> about 10 times. I read the Gorm Gotchas. Now, I'm only moderately stupid
>> (Ivy league degree in engineering + MBA from a top level school + 20 years
>> development experience) so I know I should not be able to make this stuff
>> work. But I managed to code a bunch of systems for my companies using
>> Fortran, Java + JSP, Java + Generics + Frontman, & PHP but after 3 years of
>> looking at Grails I'm still trying faces and noses, and books and authors
>> just trying to get anything to work.
>> >>
>> >> IM<not so>HO, the Grails team REALLY needs to respond to the pains of
>> the newbies via doc and code simplification. The lack of attention to this
>> is solely the reason why Grails remains so far back in the what's hot
>> Google listings.
>> >>
>> >> Seems to me like you have a few rabid perpetual newbies who are trying
>> to let you all know that getting Grail to work is way too frustrating for
>> us PHP'ers and we are implicitly offering to show you our pain. You'd we
>> wiser to form some kind of on-line working group of newbies and keep fixing
>> what roadblocks they run into (and iterating again with another round of
>> newbies) until the roadblocks are but minor bumps in the road.
>> >>
>> >> There's a LOT of doc written. It's a shame that the little bits
>> missing, mess up the experience despite all that's been done.
>> >>
>> >> Answering EVERY open question on the mailing list that someone else
>> can't solve would be a GREAT first step.
>> >>
>> >> I'm pretty convinced it's not the newbie's fault why grails is so hard
>> get started with.
>> >>
>> >> I've seen threads like this every few months or so. I know I'm
>> pissing in the wind but what the hell.
>> >>
>> >> PS Grails 2.0 is much better than the 1.x versions. There is always
>> hope.
>> >>
>> >> PPS I'm progressing down the path of learning Rails as a back-up. I
>> have thoughts on what they do better.
>> >>
>> >> Action Plan:
>> >> * Grails team dedicates one member (or all members) to make sure that
>> every question asked on the listserv is answered. EVERY answer question
>> drives a review of the doc to see what could be added to avoid the
>> questions coming forward.
>> >> * Grails tram makes a committee of newbies who are actively trying to
>> develop something real and have a real time dialog as to where they get
>> stuck and immediately fixing the stuck-ness, particularly the documentation
>> issues.
>> >> * Group actively tries to compare Rails v Grails and fix competitive
>> disadvantages found. Rather than dismissing rails vs grails discussions,
>> encourage them so long as they lead to Grails improvements. Designate a
>> "Beat-Rails" evangelist from Spring to lead the effort.
>> >>
>> >> On Jan 5, 2012, at 8:17 AM, Rodrigo Rosenfeld Rosas wrote:
>> >>
>> >>> Hi virtualeyes,
>> >>>
>> >>> Em 04-01-2012 19:51, virtualeyes escreveu:
>> >>>> ... The reality is that Grails
>> >>>> is in fact absurdly fast to restart, faster than or as fast as,
>> cough-cough,
>> >>>> Rails.
>> >>>
>> >>> I have no idea where you did take your estimates from. In my PC,
>> Grails takes from 36 to 40s to boot an empty app, while JRuby on Rails
>> takes about 16s and Rails itself (on CRuby) takes a single second. I guess
>> you were talking about using the interactive console for booting the Grails
>> app. In that case, for an empty app, it takes about 2 seconds here, which
>> is still a bit slower than vanilla Rails, but certainly much faster than
>> JRuby on Rails.
>> >>>
>> >>> But anyway, I'm not really much concerned about the time required to
>> boot the application as long as I only have to do it once. My main gripe
>> with Grails 1.3.7 is that it would reboot after each little change to my
>> domain classes and other source files, and that took a huge time.
>> >>>
>> >>> Now, with Grails 2, even without the interactive console, the user
>> experience is much better as I don't need to often reboot the application.
>> The interactive console just makes Grails even more responsive. But in the
>> expense of subtle bugs that will show up when using the interactive console
>> that wouldn't be present otherwise...
>> >>>
>> >>> The main disadvantage of a slow bootup time (in any
>> framework/environment) is that it makes running your integration tests
>> slower. While using Rspec for writing tests for Rails, one can use Spork
>> that will take a similar approach to the one taken from Grails interactive
>> console, that will make tests run much faster.
>> >>>
>> >>> So, that article that you mentioned is certainly out-of-date and I
>> need to rewrite it when I find some time. I'll write a new one and add a
>> deprecation note on that one when I'm done for keeping the old comments.
>> >>>
>> >>> My main gripe with Grails currently is that I find it very hard to
>> debug and find what is causing troubles in my application setup. I often
>> have to create a fresh Grails app and gradually copy my files to there
>> until I find the source of the problem.
>> >>>
>> >>> The Grails error messages don't give me a single clue about the
>> problem most of the times. That is not to say that I have no more issues
>> with Grails. I don't like it in many ways, but I find the over-complex
>> black magic behind Grails the one that takes be most of the time when I'm
>> trying to identify some issues.
>> >>>
>> >>> Also, I find that the Grails community has poor support when compared
>> with the Rails and Ruby one. I have lots of unanswered messages in this
>> list where I point to buggy scenarios or plugins.
>> >>>
>> >>> For, example, I've filled two bugs in the Rails issues system last
>> year, and both were fixed and commited in less than an hour:
>> >>>
>> >>> https://github.com/rails/rails/issues/4054
>> >>> https://github.com/rails/rails/issues/4067
>> >>>
>> >>> In the other side, here are some bugs (or feature requests) I've
>> reported to the Grails JIRA:
>> >>>
>> >>> http://jira.grails.org/browse/GRAILS-8568
>> >>> http://jira.grails.org/browse/GRAILS-8567
>> >>> http://jira.grails.org/browse/GPCONSOLE-3
>> >>> http://jira.grails.org/browse/GRAILS-8539 (I'm the only one
>> participating on this one, for example)
>> >>> http://jira.grails.org/browse/GRAILS-8485
>> >>> http://jira.grails.org/browse/GRAILS-7792 (feature request)
>> >>> http://jira.grails.org/browse/GRAILS-3303 (closed as won't fix,
>> although I think it could be fixed...)
>> >>> https://github.com/SpringSource/grails-data-mapping/issues/18
>> >>>
>> >>> Unanswered messages in this list:
>> >>>
>> >>>
>> http://grails.1312388.n4.nabble.com/Strange-issue-with-Grails-2-and-find-with-closure-td4222761.html
>> >>>
>> http://grails.1312388.n4.nabble.com/mongodb-and-hibernate-are-not-playing-well-together-td4222229.htmlthis wasn't answered. It was just told me to not report bugs in the dev
>> mailing list, but I didn't get any reply in the user's list too
>> >>>
>> http://grails.1312388.n4.nabble.com/MongoDB-and-multiple-databases-not-talking-about-replication-td4210794.htmljust a minor part of the message was answered
>> >>>
>> http://grails.1312388.n4.nabble.com/Is-there-an-easy-way-to-set-default-mapping-options-to-all-columns-of-some-GORM-class-td4210934.html
>> >>>
>> http://grails.1312388.n4.nabble.com/mongodb-plugin-and-quot-static-mapping-version-false-quot-why-does-the-quot-version-quot-key-is-adde-td4210920.html
>> >>>
>> http://grails.1312388.n4.nabble.com/Grails-resources-plugin-still-uses-deprecated-ConfigurationHolder-td4208027.html
>> >>>
>> http://grails.1312388.n4.nabble.com/grails-shell-will-raise-an-exception-while-trying-to-autocomplete-a-Map-td4205530.html
>> >>>
>> http://grails.1312388.n4.nabble.com/Can-t-upgrade-to-Grails-2-from-1-3-7-and-have-no-clue-all-requests-yields-to-404-status-td4178489.html
>> >>> http://www.digipedia.pl/usenet/thread/14352/30474/
>> >>>
>> http://grails.1312388.n4.nabble.com/How-to-write-scripts-using-GORM-enabled-domain-classes-td3868599.html(I've got only a suggestion to use another testing framework, but didn't
>> get a real answer to what I was asking for)
>> >>>
>> http://grails.1312388.n4.nabble.com/Grails-scripts-help-td3867976.html
>> >>>
>> >>>
>> >>> Also, besides free time, I still need some more time experimenting
>> with Grails 2 before I can write the new article on the subject...
>> >>>
>> >>> Best,
>> >>>
>> >>> Rodrigo.
>> >>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> 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
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>


--
Muhammet S. AYDIN
http://mengu.net
http://compector.com
Scott Eisenberg
2012-01-06 04:14:32 UTC
Permalink
I think to some degree you all are missing the point. IF you want a mass adoption framework, you need to make it easier for newbies. If you want to remain a niche framework, the you're right.

Frankly, what's missing in Grails is not a requirement to learn the underpinnings (Grails is good at hiding that) but to explain better and not hit stupid - and typically trivial - roadblocks.

I haven't seen anyone jump back with the response: "Great, let's do whatever we can to make the learning curve easier" so I can only assume that the community does not see this as any sort of priority. That's cool. Wrong, but cool.

PS I own at least 3 Grails books printed and 2 Kindle. Any Grails book is at least 2 years out of date. You gotta wonder why no one's written a Grails book since 2009. It's 'cause the framework is losing the battle for newbies!

If I were a VP of Product Management at Spring, I would be all over this adoption curve stuff. Who's running SpringSource anyway?



On Jan 5, 2012, at 5:43 PM, Octavian Covalschi wrote:

> " PHP without frameworks is easy to get things done " - this might be true, however how easy si to maintain those "done things" ? What about quality?
>
> I think some folks switching between technologies tend to think and code as they're used to and from there are a lot of complaints...
>
> No one has forbidden buying Grails books, there are plenty of good ones and even more sample web apps...
>
> When someone is coming to Grails world, he is coming to Java world... which basically means:
> - junit
> - spring (not a must for grails, but helps a lot)
> - hibernate
> - ivy/maven/other dependency
>
>
>
>
> On Thu, Jan 5, 2012 at 4:20 PM, Scott Eisenberg <***@btrtrucks.com> wrote:
> I just think that Rails is the main competition (and to some degree inspiration) to Grails. I want Grails to be the preferred framework. To do that it must beat the competition. Therefore, it must be compared to know where it needs to improved.
>
> Nothing is absolute, it's all relative.
>
> PS I think all PHP frameworks are crap. That's why anyone wanting to grow beyond PHP will naturally look to Rails or Grails as a higher evolution. PHP without frameworks is easy to get things done; just typically doesn't really become OO type code.
>
> On Jan 5, 2012, at 5:10 PM, Jason Davis wrote:
>
> > I come from an almost exclusive java/swing background. No web apps at
> > all. So I don't know much about spring or hibernate to be honest. I
> > found grails really easy to get started with. I really don't
> > understand the complaints. I tried some web dev with php, using
> > CakePHP and no framwork at all. I hate PHP so no point in discussing
> > it anymore. I didnt find in anymore welcoming.
> >
> > IRT unanswered posts... I wish our community was bigger and more
> > active in this regard. I have had good luck using stackoverflow.com.
> > I feel that grails allows really new people to get further than they
> > normally would. This makes for some wild, unintelligible questions on
> > the mailing list sometimes lol. Just knowing what the user is actually
> > asking is no easy task.
> >
> > In the end I don't see where all this comparison helps anything. I'm
> > on this list to learn/help with grails/groovy. I really could care
> > less about how awesome rails/ruby is.
> >
> > $.02
> >
> > On Thu, Jan 5, 2012 at 2:49 PM, Scott Eisenberg <***@btrtrucks.com> wrote:
> >> I have to say as a PHP developer trying to move to Grails that I can sympathize with his various feelings.
> >>
> >> 1) I watch the list every day and see a number of questions - not just his - that go unanswered. Sometimes some round and round but they they just drop. It seems to me like a lot of the questions are simple answers that are just not documented well with another lot of questions being some serious grails voodoo that experts know about but kills newbies.
> >>
> >> I can only assume that the Grails team is busy but I've often thought "they (Graeme, Peter, Burt) must know the answer off the top of their heads, why don't they just respond?" I would respond but most are beyond my knowledge.
> >>
> >> 2) The answer that you need to know Spring / Hibernate / etc to me is just crap. If you want to bring in experienced Java programmers to something rad-ier, then fine. If you want the PHP, .net and Rails people to come over, big mistake.
> >>
> >> 3) Every 6 months I try Grails again and within 5 hours of starting a project I hit some error that stops me cold. I have read the documentation about 10 times. I read the Gorm Gotchas. Now, I'm only moderately stupid (Ivy league degree in engineering + MBA from a top level school + 20 years development experience) so I know I should not be able to make this stuff work. But I managed to code a bunch of systems for my companies using Fortran, Java + JSP, Java + Generics + Frontman, & PHP but after 3 years of looking at Grails I'm still trying faces and noses, and books and authors just trying to get anything to work.
> >>
> >> IM<not so>HO, the Grails team REALLY needs to respond to the pains of the newbies via doc and code simplification. The lack of attention to this is solely the reason why Grails remains so far back in the what's hot Google listings.
> >>
> >> Seems to me like you have a few rabid perpetual newbies who are trying to let you all know that getting Grail to work is way too frustrating for us PHP'ers and we are implicitly offering to show you our pain. You'd we wiser to form some kind of on-line working group of newbies and keep fixing what roadblocks they run into (and iterating again with another round of newbies) until the roadblocks are but minor bumps in the road.
> >>
> >> There's a LOT of doc written. It's a shame that the little bits missing, mess up the experience despite all that's been done.
> >>
> >> Answering EVERY open question on the mailing list that someone else can't solve would be a GREAT first step.
> >>
> >> I'm pretty convinced it's not the newbie's fault why grails is so hard get started with.
> >>
> >> I've seen threads like this every few months or so. I know I'm pissing in the wind but what the hell.
> >>
> >> PS Grails 2.0 is much better than the 1.x versions. There is always hope.
> >>
> >> PPS I'm progressing down the path of learning Rails as a back-up. I have thoughts on what they do better.
> >>
> >> Action Plan:
> >> * Grails team dedicates one member (or all members) to make sure that every question asked on the listserv is answered. EVERY answer question drives a review of the doc to see what could be added to avoid the questions coming forward.
> >> * Grails tram makes a committee of newbies who are actively trying to develop something real and have a real time dialog as to where they get stuck and immediately fixing the stuck-ness, particularly the documentation issues.
> >> * Group actively tries to compare Rails v Grails and fix competitive disadvantages found. Rather than dismissing rails vs grails discussions, encourage them so long as they lead to Grails improvements. Designate a "Beat-Rails" evangelist from Spring to lead the effort.
> >>
> >> On Jan 5, 2012, at 8:17 AM, Rodrigo Rosenfeld Rosas wrote:
> >>
> >>> Hi virtualeyes,
> >>>
> >>> Em 04-01-2012 19:51, virtualeyes escreveu:
> >>>> ... The reality is that Grails
> >>>> is in fact absurdly fast to restart, faster than or as fast as, cough-cough,
> >>>> Rails.
> >>>
> >>> I have no idea where you did take your estimates from. In my PC, Grails takes from 36 to 40s to boot an empty app, while JRuby on Rails takes about 16s and Rails itself (on CRuby) takes a single second. I guess you were talking about using the interactive console for booting the Grails app. In that case, for an empty app, it takes about 2 seconds here, which is still a bit slower than vanilla Rails, but certainly much faster than JRuby on Rails.
> >>>
> >>> But anyway, I'm not really much concerned about the time required to boot the application as long as I only have to do it once. My main gripe with Grails 1.3.7 is that it would reboot after each little change to my domain classes and other source files, and that took a huge time.
> >>>
> >>> Now, with Grails 2, even without the interactive console, the user experience is much better as I don't need to often reboot the application. The interactive console just makes Grails even more responsive. But in the expense of subtle bugs that will show up when using the interactive console that wouldn't be present otherwise...
> >>>
> >>> The main disadvantage of a slow bootup time (in any framework/environment) is that it makes running your integration tests slower. While using Rspec for writing tests for Rails, one can use Spork that will take a similar approach to the one taken from Grails interactive console, that will make tests run much faster.
> >>>
> >>> So, that article that you mentioned is certainly out-of-date and I need to rewrite it when I find some time. I'll write a new one and add a deprecation note on that one when I'm done for keeping the old comments.
> >>>
> >>> My main gripe with Grails currently is that I find it very hard to debug and find what is causing troubles in my application setup. I often have to create a fresh Grails app and gradually copy my files to there until I find the source of the problem.
> >>>
> >>> The Grails error messages don't give me a single clue about the problem most of the times. That is not to say that I have no more issues with Grails. I don't like it in many ways, but I find the over-complex black magic behind Grails the one that takes be most of the time when I'm trying to identify some issues.
> >>>
> >>> Also, I find that the Grails community has poor support when compared with the Rails and Ruby one. I have lots of unanswered messages in this list where I point to buggy scenarios or plugins.
> >>>
> >>> For, example, I've filled two bugs in the Rails issues system last year, and both were fixed and commited in less than an hour:
> >>>
> >>> https://github.com/rails/rails/issues/4054
> >>> https://github.com/rails/rails/issues/4067
> >>>
> >>> In the other side, here are some bugs (or feature requests) I've reported to the Grails JIRA:
> >>>
> >>> http://jira.grails.org/browse/GRAILS-8568
> >>> http://jira.grails.org/browse/GRAILS-8567
> >>> http://jira.grails.org/browse/GPCONSOLE-3
> >>> http://jira.grails.org/browse/GRAILS-8539 (I'm the only one participating on this one, for example)
> >>> http://jira.grails.org/browse/GRAILS-8485
> >>> http://jira.grails.org/browse/GRAILS-7792 (feature request)
> >>> http://jira.grails.org/browse/GRAILS-3303 (closed as won't fix, although I think it could be fixed...)
> >>> https://github.com/SpringSource/grails-data-mapping/issues/18
> >>>
> >>> Unanswered messages in this list:
> >>>
> >>> http://grails.1312388.n4.nabble.com/Strange-issue-with-Grails-2-and-find-with-closure-td4222761.html
> >>> http://grails.1312388.n4.nabble.com/mongodb-and-hibernate-are-not-playing-well-together-td4222229.html this wasn't answered. It was just told me to not report bugs in the dev mailing list, but I didn't get any reply in the user's list too
> >>> http://grails.1312388.n4.nabble.com/MongoDB-and-multiple-databases-not-talking-about-replication-td4210794.html just a minor part of the message was answered
> >>> http://grails.1312388.n4.nabble.com/Is-there-an-easy-way-to-set-default-mapping-options-to-all-columns-of-some-GORM-class-td4210934.html
> >>> http://grails.1312388.n4.nabble.com/mongodb-plugin-and-quot-static-mapping-version-false-quot-why-does-the-quot-version-quot-key-is-adde-td4210920.html
> >>> http://grails.1312388.n4.nabble.com/Grails-resources-plugin-still-uses-deprecated-ConfigurationHolder-td4208027.html
> >>> http://grails.1312388.n4.nabble.com/grails-shell-will-raise-an-exception-while-trying-to-autocomplete-a-Map-td4205530.html
> >>> http://grails.1312388.n4.nabble.com/Can-t-upgrade-to-Grails-2-from-1-3-7-and-have-no-clue-all-requests-yields-to-404-status-td4178489.html
> >>> http://www.digipedia.pl/usenet/thread/14352/30474/
> >>> http://grails.1312388.n4.nabble.com/How-to-write-scripts-using-GORM-enabled-domain-classes-td3868599.html (I've got only a suggestion to use another testing framework, but didn't get a real answer to what I was asking for)
> >>> http://grails.1312388.n4.nabble.com/Grails-scripts-help-td3867976.html
> >>>
> >>>
> >>> Also, besides free time, I still need some more time experimenting with Grails 2 before I can write the new article on the subject...
> >>>
> >>> Best,
> >>>
> >>> Rodrigo.
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
Gavin Yue
2012-01-06 04:28:07 UTC
Permalink
For the newbies, maybe spring and hibernate are too complex.
And it is a blackbox that how grails integrates them.

On Thu, Jan 5, 2012 at 11:14 PM, Scott Eisenberg <***@btrtrucks.com>wrote:

> I think to some degree you all are missing the point. IF you want a mass
> adoption framework, you need to make it easier for newbies. If you want to
> remain a niche framework, the you're right.
>
> Frankly, what's missing in Grails is not a requirement to learn the
> underpinnings (Grails is good at hiding that) but to explain better and not
> hit stupid - and typically trivial - roadblocks.
>
> I haven't seen anyone jump back with the response: "Great, let's do
> whatever we can to make the learning curve easier" so I can only assume
> that the community does not see this as any sort of priority. That's cool.
> Wrong, but cool.
>
> PS I own at least 3 Grails books printed and 2 Kindle. Any Grails book
> is at least 2 years out of date. You gotta wonder why no one's written a
> Grails book since 2009. It's 'cause the framework is losing the battle for
> newbies!
>
> If I were a VP of Product Management at Spring, I would be all over this
> adoption curve stuff. Who's running SpringSource anyway?
>
>
>
> On Jan 5, 2012, at 5:43 PM, Octavian Covalschi wrote:
>
> " PHP without frameworks is easy to get things done " - this might be
> true, however how easy si to maintain those "done things" ? What about
> quality?
>
> I think some folks switching between technologies tend to think and code
> as they're used to and from there are a lot of complaints...
>
> No one has forbidden buying Grails books, there are plenty of good ones
> and even more sample web apps...
>
> When someone is coming to Grails world, he is coming to Java world...
> which basically means:
> - junit
> - spring (not a must for grails, but helps a lot)
> - hibernate
> - ivy/maven/other dependency
>
>
>
>
> On Thu, Jan 5, 2012 at 4:20 PM, Scott Eisenberg <***@btrtrucks.com>wrote:
>
>> I just think that Rails is the main competition (and to some degree
>> inspiration) to Grails. I want Grails to be the preferred framework. To
>> do that it must beat the competition. Therefore, it must be compared to
>> know where it needs to improved.
>>
>> Nothing is absolute, it's all relative.
>>
>> PS I think all PHP frameworks are crap. That's why anyone wanting to
>> grow beyond PHP will naturally look to Rails or Grails as a higher
>> evolution. PHP without frameworks is easy to get things done; just
>> typically doesn't really become OO type code.
>>
>> On Jan 5, 2012, at 5:10 PM, Jason Davis wrote:
>>
>> > I come from an almost exclusive java/swing background. No web apps at
>> > all. So I don't know much about spring or hibernate to be honest. I
>> > found grails really easy to get started with. I really don't
>> > understand the complaints. I tried some web dev with php, using
>> > CakePHP and no framwork at all. I hate PHP so no point in discussing
>> > it anymore. I didnt find in anymore welcoming.
>> >
>> > IRT unanswered posts... I wish our community was bigger and more
>> > active in this regard. I have had good luck using stackoverflow.com.
>> > I feel that grails allows really new people to get further than they
>> > normally would. This makes for some wild, unintelligible questions on
>> > the mailing list sometimes lol. Just knowing what the user is actually
>> > asking is no easy task.
>> >
>> > In the end I don't see where all this comparison helps anything. I'm
>> > on this list to learn/help with grails/groovy. I really could care
>> > less about how awesome rails/ruby is.
>> >
>> > $.02
>> >
>> > On Thu, Jan 5, 2012 at 2:49 PM, Scott Eisenberg <***@btrtrucks.com>
>> wrote:
>> >> I have to say as a PHP developer trying to move to Grails that I can
>> sympathize with his various feelings.
>> >>
>> >> 1) I watch the list every day and see a number of questions - not just
>> his - that go unanswered. Sometimes some round and round but they they
>> just drop. It seems to me like a lot of the questions are simple answers
>> that are just not documented well with another lot of questions being some
>> serious grails voodoo that experts know about but kills newbies.
>> >>
>> >> I can only assume that the Grails team is busy but I've often thought
>> "they (Graeme, Peter, Burt) must know the answer off the top of their
>> heads, why don't they just respond?" I would respond but most are beyond
>> my knowledge.
>> >>
>> >> 2) The answer that you need to know Spring / Hibernate / etc to me is
>> just crap. If you want to bring in experienced Java programmers to
>> something rad-ier, then fine. If you want the PHP, .net and Rails people
>> to come over, big mistake.
>> >>
>> >> 3) Every 6 months I try Grails again and within 5 hours of starting a
>> project I hit some error that stops me cold. I have read the documentation
>> about 10 times. I read the Gorm Gotchas. Now, I'm only moderately stupid
>> (Ivy league degree in engineering + MBA from a top level school + 20 years
>> development experience) so I know I should not be able to make this stuff
>> work. But I managed to code a bunch of systems for my companies using
>> Fortran, Java + JSP, Java + Generics + Frontman, & PHP but after 3 years of
>> looking at Grails I'm still trying faces and noses, and books and authors
>> just trying to get anything to work.
>> >>
>> >> IM<not so>HO, the Grails team REALLY needs to respond to the pains of
>> the newbies via doc and code simplification. The lack of attention to this
>> is solely the reason why Grails remains so far back in the what's hot
>> Google listings.
>> >>
>> >> Seems to me like you have a few rabid perpetual newbies who are trying
>> to let you all know that getting Grail to work is way too frustrating for
>> us PHP'ers and we are implicitly offering to show you our pain. You'd we
>> wiser to form some kind of on-line working group of newbies and keep fixing
>> what roadblocks they run into (and iterating again with another round of
>> newbies) until the roadblocks are but minor bumps in the road.
>> >>
>> >> There's a LOT of doc written. It's a shame that the little bits
>> missing, mess up the experience despite all that's been done.
>> >>
>> >> Answering EVERY open question on the mailing list that someone else
>> can't solve would be a GREAT first step.
>> >>
>> >> I'm pretty convinced it's not the newbie's fault why grails is so hard
>> get started with.
>> >>
>> >> I've seen threads like this every few months or so. I know I'm
>> pissing in the wind but what the hell.
>> >>
>> >> PS Grails 2.0 is much better than the 1.x versions. There is always
>> hope.
>> >>
>> >> PPS I'm progressing down the path of learning Rails as a back-up. I
>> have thoughts on what they do better.
>> >>
>> >> Action Plan:
>> >> * Grails team dedicates one member (or all members) to make sure that
>> every question asked on the listserv is answered. EVERY answer question
>> drives a review of the doc to see what could be added to avoid the
>> questions coming forward.
>> >> * Grails tram makes a committee of newbies who are actively trying to
>> develop something real and have a real time dialog as to where they get
>> stuck and immediately fixing the stuck-ness, particularly the documentation
>> issues.
>> >> * Group actively tries to compare Rails v Grails and fix competitive
>> disadvantages found. Rather than dismissing rails vs grails discussions,
>> encourage them so long as they lead to Grails improvements. Designate a
>> "Beat-Rails" evangelist from Spring to lead the effort.
>> >>
>> >> On Jan 5, 2012, at 8:17 AM, Rodrigo Rosenfeld Rosas wrote:
>> >>
>> >>> Hi virtualeyes,
>> >>>
>> >>> Em 04-01-2012 19:51, virtualeyes escreveu:
>> >>>> ... The reality is that Grails
>> >>>> is in fact absurdly fast to restart, faster than or as fast as,
>> cough-cough,
>> >>>> Rails.
>> >>>
>> >>> I have no idea where you did take your estimates from. In my PC,
>> Grails takes from 36 to 40s to boot an empty app, while JRuby on Rails
>> takes about 16s and Rails itself (on CRuby) takes a single second. I guess
>> you were talking about using the interactive console for booting the Grails
>> app. In that case, for an empty app, it takes about 2 seconds here, which
>> is still a bit slower than vanilla Rails, but certainly much faster than
>> JRuby on Rails.
>> >>>
>> >>> But anyway, I'm not really much concerned about the time required to
>> boot the application as long as I only have to do it once. My main gripe
>> with Grails 1.3.7 is that it would reboot after each little change to my
>> domain classes and other source files, and that took a huge time.
>> >>>
>> >>> Now, with Grails 2, even without the interactive console, the user
>> experience is much better as I don't need to often reboot the application.
>> The interactive console just makes Grails even more responsive. But in the
>> expense of subtle bugs that will show up when using the interactive console
>> that wouldn't be present otherwise...
>> >>>
>> >>> The main disadvantage of a slow bootup time (in any
>> framework/environment) is that it makes running your integration tests
>> slower. While using Rspec for writing tests for Rails, one can use Spork
>> that will take a similar approach to the one taken from Grails interactive
>> console, that will make tests run much faster.
>> >>>
>> >>> So, that article that you mentioned is certainly out-of-date and I
>> need to rewrite it when I find some time. I'll write a new one and add a
>> deprecation note on that one when I'm done for keeping the old comments.
>> >>>
>> >>> My main gripe with Grails currently is that I find it very hard to
>> debug and find what is causing troubles in my application setup. I often
>> have to create a fresh Grails app and gradually copy my files to there
>> until I find the source of the problem.
>> >>>
>> >>> The Grails error messages don't give me a single clue about the
>> problem most of the times. That is not to say that I have no more issues
>> with Grails. I don't like it in many ways, but I find the over-complex
>> black magic behind Grails the one that takes be most of the time when I'm
>> trying to identify some issues.
>> >>>
>> >>> Also, I find that the Grails community has poor support when compared
>> with the Rails and Ruby one. I have lots of unanswered messages in this
>> list where I point to buggy scenarios or plugins.
>> >>>
>> >>> For, example, I've filled two bugs in the Rails issues system last
>> year, and both were fixed and commited in less than an hour:
>> >>>
>> >>> https://github.com/rails/rails/issues/4054
>> >>> https://github.com/rails/rails/issues/4067
>> >>>
>> >>> In the other side, here are some bugs (or feature requests) I've
>> reported to the Grails JIRA:
>> >>>
>> >>> http://jira.grails.org/browse/GRAILS-8568
>> >>> http://jira.grails.org/browse/GRAILS-8567
>> >>> http://jira.grails.org/browse/GPCONSOLE-3
>> >>> http://jira.grails.org/browse/GRAILS-8539 (I'm the only one
>> participating on this one, for example)
>> >>> http://jira.grails.org/browse/GRAILS-8485
>> >>> http://jira.grails.org/browse/GRAILS-7792 (feature request)
>> >>> http://jira.grails.org/browse/GRAILS-3303 (closed as won't fix,
>> although I think it could be fixed...)
>> >>> https://github.com/SpringSource/grails-data-mapping/issues/18
>> >>>
>> >>> Unanswered messages in this list:
>> >>>
>> >>>
>> http://grails.1312388.n4.nabble.com/Strange-issue-with-Grails-2-and-find-with-closure-td4222761.html
>> >>>
>> http://grails.1312388.n4.nabble.com/mongodb-and-hibernate-are-not-playing-well-together-td4222229.htmlthis wasn't answered. It was just told me to not report bugs in the dev
>> mailing list, but I didn't get any reply in the user's list too
>> >>>
>> http://grails.1312388.n4.nabble.com/MongoDB-and-multiple-databases-not-talking-about-replication-td4210794.htmljust a minor part of the message was answered
>> >>>
>> http://grails.1312388.n4.nabble.com/Is-there-an-easy-way-to-set-default-mapping-options-to-all-columns-of-some-GORM-class-td4210934.html
>> >>>
>> http://grails.1312388.n4.nabble.com/mongodb-plugin-and-quot-static-mapping-version-false-quot-why-does-the-quot-version-quot-key-is-adde-td4210920.html
>> >>>
>> http://grails.1312388.n4.nabble.com/Grails-resources-plugin-still-uses-deprecated-ConfigurationHolder-td4208027.html
>> >>>
>> http://grails.1312388.n4.nabble.com/grails-shell-will-raise-an-exception-while-trying-to-autocomplete-a-Map-td4205530.html
>> >>>
>> http://grails.1312388.n4.nabble.com/Can-t-upgrade-to-Grails-2-from-1-3-7-and-have-no-clue-all-requests-yields-to-404-status-td4178489.html
>> >>> http://www.digipedia.pl/usenet/thread/14352/30474/
>> >>>
>> http://grails.1312388.n4.nabble.com/How-to-write-scripts-using-GORM-enabled-domain-classes-td3868599.html(I've got only a suggestion to use another testing framework, but didn't
>> get a real answer to what I was asking for)
>> >>>
>> http://grails.1312388.n4.nabble.com/Grails-scripts-help-td3867976.html
>> >>>
>> >>>
>> >>> Also, besides free time, I still need some more time experimenting
>> with Grails 2 before I can write the new article on the subject...
>> >>>
>> >>> Best,
>> >>>
>> >>> Rodrigo.
>> >>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> 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
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
Scott Eisenberg
2012-01-06 04:44:38 UTC
Permalink
I thought the point was by and large you didn't need to learn hibernate and spring to build most grails apps.

That's also NOT where newbies get stuck, except perhaps for the Gorman Gotchas.

It's often where the black box blows up and you get an ungodly stack trace that the newbie dies. Hmmm, black box explosions. Sounds dangerous. (I'm copyrighting that expression.)


On Jan 5, 2012, at 11:28 PM, Gavin Yue <***@gmail.com> wrote:

> For the newbies, maybe spring and hibernate are too complex.
> And it is a blackbox that how grails integrates them.
>
> On Thu, Jan 5, 2012 at 11:14 PM, Scott Eisenberg <***@btrtrucks.com> wrote:
> I think to some degree you all are missing the point. IF you want a mass adoption framework, you need to make it easier for newbies. If you want to remain a niche framework, the you're right.
>
> Frankly, what's missing in Grails is not a requirement to learn the underpinnings (Grails is good at hiding that) but to explain better and not hit stupid - and typically trivial - roadblocks.
>
> I haven't seen anyone jump back with the response: "Great, let's do whatever we can to make the learning curve easier" so I can only assume that the community does not see this as any sort of priority. That's cool. Wrong, but cool.
>
> PS I own at least 3 Grails books printed and 2 Kindle. Any Grails book is at least 2 years out of date. You gotta wonder why no one's written a Grails book since 2009. It's 'cause the framework is losing the battle for newbies!
>
> If I were a VP of Product Management at Spring, I would be all over this adoption curve stuff. Who's running SpringSource anyway?
>
>
>
> On Jan 5, 2012, at 5:43 PM, Octavian Covalschi wrote:
>
>> " PHP without frameworks is easy to get things done " - this might be true, however how easy si to maintain those "done things" ? What about quality?
>>
>> I think some folks switching between technologies tend to think and code as they're used to and from there are a lot of complaints...
>>
>> No one has forbidden buying Grails books, there are plenty of good ones and even more sample web apps...
>>
>> When someone is coming to Grails world, he is coming to Java world... which basically means:
>> - junit
>> - spring (not a must for grails, but helps a lot)
>> - hibernate
>> - ivy/maven/other dependency
>>
>>
>>
>>
>> On Thu, Jan 5, 2012 at 4:20 PM, Scott Eisenberg <***@btrtrucks.com> wrote:
>> I just think that Rails is the main competition (and to some degree inspiration) to Grails. I want Grails to be the preferred framework. To do that it must beat the competition. Therefore, it must be compared to know where it needs to improved.
>>
>> Nothing is absolute, it's all relative.
>>
>> PS I think all PHP frameworks are crap. That's why anyone wanting to grow beyond PHP will naturally look to Rails or Grails as a higher evolution. PHP without frameworks is easy to get things done; just typically doesn't really become OO type code.
>>
>> On Jan 5, 2012, at 5:10 PM, Jason Davis wrote:
>>
>> > I come from an almost exclusive java/swing background. No web apps at
>> > all. So I don't know much about spring or hibernate to be honest. I
>> > found grails really easy to get started with. I really don't
>> > understand the complaints. I tried some web dev with php, using
>> > CakePHP and no framwork at all. I hate PHP so no point in discussing
>> > it anymore. I didnt find in anymore welcoming.
>> >
>> > IRT unanswered posts... I wish our community was bigger and more
>> > active in this regard. I have had good luck using stackoverflow.com.
>> > I feel that grails allows really new people to get further than they
>> > normally would. This makes for some wild, unintelligible questions on
>> > the mailing list sometimes lol. Just knowing what the user is actually
>> > asking is no easy task.
>> >
>> > In the end I don't see where all this comparison helps anything. I'm
>> > on this list to learn/help with grails/groovy. I really could care
>> > less about how awesome rails/ruby is.
>> >
>> > $.02
>> >
>> > On Thu, Jan 5, 2012 at 2:49 PM, Scott Eisenberg <***@btrtrucks.com> wrote:
>> >> I have to say as a PHP developer trying to move to Grails that I can sympathize with his various feelings.
>> >>
>> >> 1) I watch the list every day and see a number of questions - not just his - that go unanswered. Sometimes some round and round but they they just drop. It seems to me like a lot of the questions are simple answers that are just not documented well with another lot of questions being some serious grails voodoo that experts know about but kills newbies.
>> >>
>> >> I can only assume that the Grails team is busy but I've often thought "they (Graeme, Peter, Burt) must know the answer off the top of their heads, why don't they just respond?" I would respond but most are beyond my knowledge.
>> >>
>> >> 2) The answer that you need to know Spring / Hibernate / etc to me is just crap. If you want to bring in experienced Java programmers to something rad-ier, then fine. If you want the PHP, .net and Rails people to come over, big mistake.
>> >>
>> >> 3) Every 6 months I try Grails again and within 5 hours of starting a project I hit some error that stops me cold. I have read the documentation about 10 times. I read the Gorm Gotchas. Now, I'm only moderately stupid (Ivy league degree in engineering + MBA from a top level school + 20 years development experience) so I know I should not be able to make this stuff work. But I managed to code a bunch of systems for my companies using Fortran, Java + JSP, Java + Generics + Frontman, & PHP but after 3 years of looking at Grails I'm still trying faces and noses, and books and authors just trying to get anything to work.
>> >>
>> >> IM<not so>HO, the Grails team REALLY needs to respond to the pains of the newbies via doc and code simplification. The lack of attention to this is solely the reason why Grails remains so far back in the what's hot Google listings.
>> >>
>> >> Seems to me like you have a few rabid perpetual newbies who are trying to let you all know that getting Grail to work is way too frustrating for us PHP'ers and we are implicitly offering to show you our pain. You'd we wiser to form some kind of on-line working group of newbies and keep fixing what roadblocks they run into (and iterating again with another round of newbies) until the roadblocks are but minor bumps in the road.
>> >>
>> >> There's a LOT of doc written. It's a shame that the little bits missing, mess up the experience despite all that's been done.
>> >>
>> >> Answering EVERY open question on the mailing list that someone else can't solve would be a GREAT first step.
>> >>
>> >> I'm pretty convinced it's not the newbie's fault why grails is so hard get started with.
>> >>
>> >> I've seen threads like this every few months or so. I know I'm pissing in the wind but what the hell.
>> >>
>> >> PS Grails 2.0 is much better than the 1.x versions. There is always hope.
>> >>
>> >> PPS I'm progressing down the path of learning Rails as a back-up. I have thoughts on what they do better.
>> >>
>> >> Action Plan:
>> >> * Grails team dedicates one member (or all members) to make sure that every question asked on the listserv is answered. EVERY answer question drives a review of the doc to see what could be added to avoid the questions coming forward.
>> >> * Grails tram makes a committee of newbies who are actively trying to develop something real and have a real time dialog as to where they get stuck and immediately fixing the stuck-ness, particularly the documentation issues.
>> >> * Group actively tries to compare Rails v Grails and fix competitive disadvantages found. Rather than dismissing rails vs grails discussions, encourage them so long as they lead to Grails improvements. Designate a "Beat-Rails" evangelist from Spring to lead the effort.
>> >>
>> >> On Jan 5, 2012, at 8:17 AM, Rodrigo Rosenfeld Rosas wrote:
>> >>
>> >>> Hi virtualeyes,
>> >>>
>> >>> Em 04-01-2012 19:51, virtualeyes escreveu:
>> >>>> ... The reality is that Grails
>> >>>> is in fact absurdly fast to restart, faster than or as fast as, cough-cough,
>> >>>> Rails.
>> >>>
>> >>> I have no idea where you did take your estimates from. In my PC, Grails takes from 36 to 40s to boot an empty app, while JRuby on Rails takes about 16s and Rails itself (on CRuby) takes a single second. I guess you were talking about using the interactive console for booting the Grails app. In that case, for an empty app, it takes about 2 seconds here, which is still a bit slower than vanilla Rails, but certainly much faster than JRuby on Rails.
>> >>>
>> >>> But anyway, I'm not really much concerned about the time required to boot the application as long as I only have to do it once. My main gripe with Grails 1.3.7 is that it would reboot after each little change to my domain classes and other source files, and that took a huge time.
>> >>>
>> >>> Now, with Grails 2, even without the interactive console, the user experience is much better as I don't need to often reboot the application. The interactive console just makes Grails even more responsive. But in the expense of subtle bugs that will show up when using the interactive console that wouldn't be present otherwise...
>> >>>
>> >>> The main disadvantage of a slow bootup time (in any framework/environment) is that it makes running your integration tests slower. While using Rspec for writing tests for Rails, one can use Spork that will take a similar approach to the one taken from Grails interactive console, that will make tests run much faster.
>> >>>
>> >>> So, that article that you mentioned is certainly out-of-date and I need to rewrite it when I find some time. I'll write a new one and add a deprecation note on that one when I'm done for keeping the old comments.
>> >>>
>> >>> My main gripe with Grails currently is that I find it very hard to debug and find what is causing troubles in my application setup. I often have to create a fresh Grails app and gradually copy my files to there until I find the source of the problem.
>> >>>
>> >>> The Grails error messages don't give me a single clue about the problem most of the times. That is not to say that I have no more issues with Grails. I don't like it in many ways, but I find the over-complex black magic behind Grails the one that takes be most of the time when I'm trying to identify some issues.
>> >>>
>> >>> Also, I find that the Grails community has poor support when compared with the Rails and Ruby one. I have lots of unanswered messages in this list where I point to buggy scenarios or plugins.
>> >>>
>> >>> For, example, I've filled two bugs in the Rails issues system last year, and both were fixed and commited in less than an hour:
>> >>>
>> >>> https://github.com/rails/rails/issues/4054
>> >>> https://github.com/rails/rails/issues/4067
>> >>>
>> >>> In the other side, here are some bugs (or feature requests) I've reported to the Grails JIRA:
>> >>>
>> >>> http://jira.grails.org/browse/GRAILS-8568
>> >>> http://jira.grails.org/browse/GRAILS-8567
>> >>> http://jira.grails.org/browse/GPCONSOLE-3
>> >>> http://jira.grails.org/browse/GRAILS-8539 (I'm the only one participating on this one, for example)
>> >>> http://jira.grails.org/browse/GRAILS-8485
>> >>> http://jira.grails.org/browse/GRAILS-7792 (feature request)
>> >>> http://jira.grails.org/browse/GRAILS-3303 (closed as won't fix, although I think it could be fixed...)
>> >>> https://github.com/SpringSource/grails-data-mapping/issues/18
>> >>>
>> >>> Unanswered messages in this list:
>> >>>
>> >>> http://grails.1312388.n4.nabble.com/Strange-issue-with-Grails-2-and-find-with-closure-td4222761.html
>> >>> http://grails.1312388.n4.nabble.com/mongodb-and-hibernate-are-not-playing-well-together-td4222229.html this wasn't answered. It was just told me to not report bugs in the dev mailing list, but I didn't get any reply in the user's list too
>> >>> http://grails.1312388.n4.nabble.com/MongoDB-and-multiple-databases-not-talking-about-replication-td4210794.html just a minor part of the message was answered
>> >>> http://grails.1312388.n4.nabble.com/Is-there-an-easy-way-to-set-default-mapping-options-to-all-columns-of-some-GORM-class-td4210934.html
>> >>> http://grails.1312388.n4.nabble.com/mongodb-plugin-and-quot-static-mapping-version-false-quot-why-does-the-quot-version-quot-key-is-adde-td4210920.html
>> >>> http://grails.1312388.n4.nabble.com/Grails-resources-plugin-still-uses-deprecated-ConfigurationHolder-td4208027.html
>> >>> http://grails.1312388.n4.nabble.com/grails-shell-will-raise-an-exception-while-trying-to-autocomplete-a-Map-td4205530.html
>> >>> http://grails.1312388.n4.nabble.com/Can-t-upgrade-to-Grails-2-from-1-3-7-and-have-no-clue-all-requests-yields-to-404-status-td4178489.html
>> >>> http://www.digipedia.pl/usenet/thread/14352/30474/
>> >>> http://grails.1312388.n4.nabble.com/How-to-write-scripts-using-GORM-enabled-domain-classes-td3868599.html (I've got only a suggestion to use another testing framework, but didn't get a real answer to what I was asking for)
>> >>> http://grails.1312388.n4.nabble.com/Grails-scripts-help-td3867976.html
>> >>>
>> >>>
>> >>> Also, besides free time, I still need some more time experimenting with Grails 2 before I can write the new article on the subject...
>> >>>
>> >>> Best,
>> >>>
>> >>> Rodrigo.
>> >>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> 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
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
bobbywarner
2012-01-06 07:19:15 UTC
Permalink
For those facing issues getting started with Grails, please take a look at my
screen-cast titled "Jump Into Grails 2.0" and let me know what you think.

http://www.bobbywarner.com/2012/01/05/jump-into-grails-2-0/

As you can see from the screen-cast, Grails is great for development and you
can be quite productive in a short amount of time.


Hope that helps!
Bobby

--
View this message in context: http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4268505.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
Peter Ledbrook
2012-01-06 09:41:58 UTC
Permalink
Scott,

> I thought the point was by and large you didn't need to learn hibernate and
> spring to build most grails apps.

I believe you should be able to get started with Grails without
knowing Hibernate or Spring, but you do need to learn them to gain the
full benefits of the framework - Spring in particular.

We do acknowledge that there are users coming from non-Java
backgrounds and we want to encourage them. The new stack trace format
introduced with Grails 2 was created in recognition that the standard
Java stack traces aren't particularly readable if you haven't been
working with them before. However, most active contributors have a
Java background, so we rely on community feedback and (more
importantly) contributions from the non-Java people.

If you can identify common issues that PHP developers encounter, then
please add them to a wiki page on grails.org or GitHub and point us to
it. That could serve as the basis for both introductory material for
non-Java developers and improvements in the documentation and the
framework itself. For example, Rodrigo and yourself have mentioned
that it's difficult when something goes wrong. So what are the common
errors and what makes them difficult to rectify? That's information
that we can work with.

On the mailing list front, if we can answer a question off the top of
our heads, we will. But most of those have already been answered by
others. Everything else tends to be more involved than it may appear.

Regards,

Peter

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

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

http://xircles.codehaus.org/manage_email
Ronny Løvtangen
2012-01-06 10:12:35 UTC
Permalink
On Jan 6, 2012, at 10:41 AM, Peter Ledbrook wrote:
>
> If you can identify common issues that PHP developers encounter, then
> please add them to a wiki page on grails.org or GitHub and point us to
> it. That could serve as the basis for both introductory material for
> non-Java developers and improvements in the documentation and the
> framework itself. For example, Rodrigo and yourself have mentioned
> that it's difficult when something goes wrong. So what are the common
> errors and what makes them difficult to rectify? That's information
> that we can work with.

One example that I've seen over and over on the mailing list, is users creating an application, installing a plugin, and running into "Unresolved dependency" because the plugin adds a dependency and mavenCentral() was not enabled by default in BuildConfig.groovy. For users coming from Maven-land, this is a no-brainer, but I can understand that for users coming from e.g. PHP, they'll have no clue what the problem is. To run into a problem like that the first day trying out Grails, must be really frustrating.
It is now fixed in Grails 2.0.0, so that's one less common error to run into :)

Ronny
Rodrigo Rosenfeld Rosas
2012-01-06 12:08:21 UTC
Permalink
Em 06-01-2012 07:41, Peter Ledbrook escreveu:
> ... For example, Rodrigo and yourself have mentioned
> that it's difficult when something goes wrong. So what are the common
> errors and what makes them difficult to rectify? That's information
> that we can work with.

Here is an example:

http://jira.grails.org/browse/GRAILS-8539

Here is the output I was getting after touching (without modifying) a
domain class:

ERROR errors.GrailsExceptionResolver - LazyInitializationException
occurred when processing request: [GET] /reloading/main/index
failed to lazily initialize a collection of role:
reloading.ShiroUser.permissions, no session or session was closed.
Stacktrace follows:
Message: failed to lazily initialize a collection of role:
reloading.ShiroUser.permissions, no session or session was closed
Line | Method
->> 77 | isPermitted in ShiroDbRealm$$ENK01yVc
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| 237 | isPermitted in org.apache.shiro.grails.RealmWrapper
| 58 | isPermitted . . . . in org.apache.shiro.grails.RealmAdapter
| 222 | isPermitted in
org.apache.shiro.authz.ModularRealmAuthorizer
| 113 | isPermitted . . . . in
org.apache.shiro.mgt.AuthorizingSecurityManager
| 151 | isPermitted in
org.apache.shiro.subject.support.DelegatingSubject
| 511 | accessControlMethod in ShiroGrailsPlugin$$ENK01dhI
| 245 | doCall in
ShiroGrailsPlugin$_closure3_closure24$$ENK01dhI
| 13 | doCall . . . . . . in
ShiroSecurityFilters$_closure1_closure2_closure3$$ENK01kSe
| 55 | doFilter in org.apache.shiro.grails.SavedRequestFilter
| 359 | executeChain . . . in
org.apache.shiro.web.servlet.AbstractShiroFilter
| 275 | call in
org.apache.shiro.web.servlet.AbstractShiroFilter$1
| 90 | doCall . . . . . . in
org.apache.shiro.subject.support.SubjectCallable
| 83 | call in ''
| 344 | execute . . . . . . in
org.apache.shiro.subject.support.DelegatingSubject
| 272 | doFilterInternal in
org.apache.shiro.web.servlet.AbstractShiroFilter
| 81 | doFilter . . . . . in
org.apache.shiro.web.servlet.OncePerRequestFilter
| 886 | runTask in
java.util.concurrent.ThreadPoolExecutor$Worker
| 908 | run . . . . . . . . in ''
^ 662 | run in java.lang.Thread


How could I associate that the reloading issue was related to my Vim
swap files?

That's the kind of hard-to-debug-black-magic I was talking about.

There's a lot happening behind the scenes that it gets really complicate
to understand what could be causing the issues.

Another example of message that I've got from Grails while trying the
mongodb plugin:

"No Hibernate Session bound to thread, and configuration does not allow
creation of non-transactional one here"

How could I know that the issue was being caused by the mongodb plugin?
The stacktrace didn't mention it either. I just knew because it was the
only change I've made to the application. When I changed this plugin by
mongodb-morphia I stopped getting this error in development mode after
touching some source file.

One more example: when I first tried to upgrade my app to Grails 2, I
kept getting 404 errors for all pages and not a single related
stacktrace even if I set the root level to debug. I had to create a new
app and gradually copy the files to there until I could identify what
the problem was. And it was caused by some script I had in the scripts
directory. How could I guess it would cause such problems?

This is the kind of issues I have with Grails and that will take me an
entire day of investigation while usually I can't count on anyone's help
in the mailing list and have to figure it out by myself...


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

http://xircles.codehaus.org/manage_email
Scott Eisenberg
2012-01-06 12:15:42 UTC
Permalink
OK. I'll take this an invitation to pair up and make things better. By another post, I see Rodrigo is game as well.

Why not start by a definitive answer to the question:

Why are their 2 repositories in the description?

Line 1 says "that anyone can request commit access to" the following: http://github.com/grails/grails-doc

Line 2 then immediately contradicts that by saying you should submit to pledbrooks's repository.

If #2, then give me commit access to your fork and tell me why we have 2 options.

On Jan 6, 2012, at 4:41 AM, Peter Ledbrook wrote:

> Scott,
>
>> I thought the point was by and large you didn't need to learn hibernate and
>> spring to build most grails apps.
>
> I believe you should be able to get started with Grails without
> knowing Hibernate or Spring, but you do need to learn them to gain the
> full benefits of the framework - Spring in particular.
>
> We do acknowledge that there are users coming from non-Java
> backgrounds and we want to encourage them. The new stack trace format
> introduced with Grails 2 was created in recognition that the standard
> Java stack traces aren't particularly readable if you haven't been
> working with them before. However, most active contributors have a
> Java background, so we rely on community feedback and (more
> importantly) contributions from the non-Java people.
>
> If you can identify common issues that PHP developers encounter, then
> please add them to a wiki page on grails.org or GitHub and point us to
> it. That could serve as the basis for both introductory material for
> non-Java developers and improvements in the documentation and the
> framework itself. For example, Rodrigo and yourself have mentioned
> that it's difficult when something goes wrong. So what are the common
> errors and what makes them difficult to rectify? That's information
> that we can work with.
>
> On the mailing list front, if we can answer a question off the top of
> our heads, we will. But most of those have already been answered by
> others. Everything else tends to be more involved than it may appear.
>
> Regards,
>
> Peter
>
> --
> Peter Ledbrook
> Grails Advocate
> SpringSource - A Division of VMware
>
> ---------------------------------------------------------------------
> 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
Rodrigo Rosenfeld Rosas
2012-01-06 12:50:42 UTC
Permalink
Em 06-01-2012 10:15, Scott Eisenberg escreveu:
> OK. I'll take this an invitation to pair up and make things better. By another post, I see Rodrigo is game as well.
>
> Why not start by a definitive answer to the question:
>
> Why are their 2 repositories in the description?
>
> Line 1 says "that anyone can request commit access to" the following: http://github.com/grails/grails-doc
>
> Line 2 then immediately contradicts that by saying you should submit to pledbrooks's repository.
>
> If #2, then give me commit access to your fork and tell me why we have 2 options.
>

Hi Scott, where are those lines you're talking about? But anyway, what
is the matter of having two options for contributing to Grails
documentation?

Sometimes, committing directly to the repository once you get commit
access is just simpler than opening a pull request. But if you're doing
a big refactoring or change, you'd be better advised to create a pull
request instead.

I don't know if this is stated anywhere, it is just my personal opinion
on the subject. By directly committing, it is unlikely to have issues
due to different pull requests conflicting, for example, and it makes
easier for one to contribute in top of another's contribution.

I think those methods are complementary and I don't see any problem in
allowing both flows...

Did I understand your question correctly?

> On Jan 6, 2012, at 4:41 AM, Peter Ledbrook wrote:
>
>> Scott,
>>
>>> I thought the point was by and large you didn't need to learn hibernate and
>>> spring to build most grails apps.
>> I believe you should be able to get started with Grails without
>> knowing Hibernate or Spring, but you do need to learn them to gain the
>> full benefits of the framework - Spring in particular.
>>
>> We do acknowledge that there are users coming from non-Java
>> backgrounds and we want to encourage them. The new stack trace format
>> introduced with Grails 2 was created in recognition that the standard
>> Java stack traces aren't particularly readable if you haven't been
>> working with them before. However, most active contributors have a
>> Java background, so we rely on community feedback and (more
>> importantly) contributions from the non-Java people.
>>
>> If you can identify common issues that PHP developers encounter, then
>> please add them to a wiki page on grails.org or GitHub and point us to
>> it. That could serve as the basis for both introductory material for
>> non-Java developers and improvements in the documentation and the
>> framework itself. For example, Rodrigo and yourself have mentioned
>> that it's difficult when something goes wrong. So what are the common
>> errors and what makes them difficult to rectify? That's information
>> that we can work with.
>>
>> On the mailing list front, if we can answer a question off the top of
>> our heads, we will. But most of those have already been answered by
>> others. Everything else tends to be more involved than it may appear.
>>
>> Regards,
>>
>> Peter


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

http://xircles.codehaus.org/manage_email
Scott Eisenberg
2012-01-06 13:03:46 UTC
Permalink
http://grails.org/doc/latest/guide/contributing.html Section 18.4

I don't care which is the right answer (alright, I think #1 is the right answer) but it needs to be clear which to try. Better still one option.

Corresponding Rails doc:

If you’re confident about your changes, you can push them yourself directly via docrails. docrails is a branch with an open commit policy and public write access. Commits to docrails are still reviewed, but that happens after they are pushed. docrails is merged with master regularly, so you are effectively editing the Ruby on Rails documentation.

If you are unsure of the documentation changes, you can create an issue in the Rails issues tracker on GitHub.

Simple answer there. Use docrails. "They are still reviewed", so nice that you (probably) can't screw up the doc. Gives comfort to go ahead.

One out, to use issues tracker if you are scared (given that docrails is reviewed I would remove that personally or change it to something like, if you don't use git then use the issues tracker…)

If Peter's branch the one that is reviewed more it could be stated that if you are unsure, use Peter's in that it is reviewed more, if sure go directly to #1. If that is indeed the rationale for 2 options.


On Jan 6, 2012, at 7:50 AM, Rodrigo Rosenfeld Rosas wrote:

> Em 06-01-2012 10:15, Scott Eisenberg escreveu:
>> OK. I'll take this an invitation to pair up and make things better. By another post, I see Rodrigo is game as well.
>>
>> Why not start by a definitive answer to the question:
>>
>> Why are their 2 repositories in the description?
>>
>> Line 1 says "that anyone can request commit access to" the following: http://github.com/grails/grails-doc
>>
>> Line 2 then immediately contradicts that by saying you should submit to pledbrooks's repository.
>>
>> If #2, then give me commit access to your fork and tell me why we have 2 options.
>>
>
> Hi Scott, where are those lines you're talking about? But anyway, what is the matter of having two options for contributing to Grails documentation?
>
> Sometimes, committing directly to the repository once you get commit access is just simpler than opening a pull request. But if you're doing a big refactoring or change, you'd be better advised to create a pull request instead.
>
> I don't know if this is stated anywhere, it is just my personal opinion on the subject. By directly committing, it is unlikely to have issues due to different pull requests conflicting, for example, and it makes easier for one to contribute in top of another's contribution.
>
> I think those methods are complementary and I don't see any problem in allowing both flows...
>
> Did I understand your question correctly?
>
>> On Jan 6, 2012, at 4:41 AM, Peter Ledbrook wrote:
>>
>>> Scott,
>>>
>>>> I thought the point was by and large you didn't need to learn hibernate and
>>>> spring to build most grails apps.
>>> I believe you should be able to get started with Grails without
>>> knowing Hibernate or Spring, but you do need to learn them to gain the
>>> full benefits of the framework - Spring in particular.
>>>
>>> We do acknowledge that there are users coming from non-Java
>>> backgrounds and we want to encourage them. The new stack trace format
>>> introduced with Grails 2 was created in recognition that the standard
>>> Java stack traces aren't particularly readable if you haven't been
>>> working with them before. However, most active contributors have a
>>> Java background, so we rely on community feedback and (more
>>> importantly) contributions from the non-Java people.
>>>
>>> If you can identify common issues that PHP developers encounter, then
>>> please add them to a wiki page on grails.org or GitHub and point us to
>>> it. That could serve as the basis for both introductory material for
>>> non-Java developers and improvements in the documentation and the
>>> framework itself. For example, Rodrigo and yourself have mentioned
>>> that it's difficult when something goes wrong. So what are the common
>>> errors and what makes them difficult to rectify? That's information
>>> that we can work with.
>>>
>>> On the mailing list front, if we can answer a question off the top of
>>> our heads, we will. But most of those have already been answered by
>>> others. Everything else tends to be more involved than it may appear.
>>>
>>> Regards,
>>>
>>> Peter
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
Ronny Løvtangen
2012-01-06 13:23:24 UTC
Permalink
On Jan 6, 2012, at 1:15 PM, Scott Eisenberg wrote:

> OK. I'll take this an invitation to pair up and make things better. By another post, I see Rodrigo is game as well.
>
> Why not start by a definitive answer to the question:
>
> Why are their 2 repositories in the description?
>
> Line 1 says "that anyone can request commit access to" the following: http://github.com/grails/grails-doc

No, it says that there is a public fork of http://github.com/grails/grails-doc that anyone can request commit access to. This public fork is http://github.com/pledbrook/grails-doc
But yes, this could be rewritten to be more clear

>
> Line 2 then immediately contradicts that by saying you should submit to pledbrooks's repository.
>
> If #2, then give me commit access to your fork and tell me why we have 2 options.
>
> On Jan 6, 2012, at 4:41 AM, Peter Ledbrook wrote:
>
>> Scott,
>>
>>> I thought the point was by and large you didn't need to learn hibernate and
>>> spring to build most grails apps.
>>
>> I believe you should be able to get started with Grails without
>> knowing Hibernate or Spring, but you do need to learn them to gain the
>> full benefits of the framework - Spring in particular.
>>
>> We do acknowledge that there are users coming from non-Java
>> backgrounds and we want to encourage them. The new stack trace format
>> introduced with Grails 2 was created in recognition that the standard
>> Java stack traces aren't particularly readable if you haven't been
>> working with them before. However, most active contributors have a
>> Java background, so we rely on community feedback and (more
>> importantly) contributions from the non-Java people.
>>
>> If you can identify common issues that PHP developers encounter, then
>> please add them to a wiki page on grails.org or GitHub and point us to
>> it. That could serve as the basis for both introductory material for
>> non-Java developers and improvements in the documentation and the
>> framework itself. For example, Rodrigo and yourself have mentioned
>> that it's difficult when something goes wrong. So what are the common
>> errors and what makes them difficult to rectify? That's information
>> that we can work with.
>>
>> On the mailing list front, if we can answer a question off the top of
>> our heads, we will. But most of those have already been answered by
>> others. Everything else tends to be more involved than it may appear.
>>
>> Regards,
>>
>> Peter
>>
>> --
>> Peter Ledbrook
>> Grails Advocate
>> SpringSource - A Division of VMware
>>
>> ---------------------------------------------------------------------
>> 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
Peter Ledbrook
2012-01-06 13:45:58 UTC
Permalink
> OK.  I'll take this an invitation to pair up and make things better.  By another post, I see Rodrigo is game as well.
>
> Why not start by a definitive answer to the question:
>
> Why are their 2 repositories in the description?
>
> Line 1 says "that anyone can request commit access to" the following:  http://github.com/grails/grails-doc
>
> Line 2 then immediately contradicts that by saying you should submit to pledbrooks's repository.
>
> If #2, then give me commit access to your fork and tell me why we have 2 options.

The second option has been a trial. It's proving particularly useful
for the user guide translations because multiple translators can see
what's happening without having to wait for pull requests to go
through.

The truth is, option 1 will always be there. But I'll look at
improving the docs around contributing to the docs.

To get access to the public repo, simply send a GitHub message to
'pledbrook' requesting access.

Peter

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

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

http://xircles.codehaus.org/manage_email
virtualeyes
2012-01-06 10:20:38 UTC
Permalink
There are tradeoffs to be made on every single stack.

You could go back to the LAMP stack, ultra-convenient rapid fire land o'
hacks, but, you are here. Why?

Well, clearly Grails provides something that the LAMP stack does not. Is
there a PHP version of GORM? No. Is there a PHP version of Groovy? heh, heh,
No.

Grails provides a complete package that is utterly compelling. Are there
limitations, bugs, annoyances? Yes, of course, but that does not surprise me
given the challenge in integrating Spring and Hibernate with Groovy a la
Rails, all the while adding new functionality and attempting to retain
backward compatibility -- a large undertaking for a handful of developers.
I am not at all surprised that the core team is not spending their days &
nights replying to everyone on the list.

Similarly, community members I suspect are generally Java devs who already
know the JVM ropes, and probably do not live on the list, just pop around if
they have a question, or see if there are any interesting threads, then back
to work.

Rails community may be different in this respect, I am not sure.

Unfortunately there aren't many viable web framework options out there. A
bold statement I know, but:

1) you can pretty much omit anything PHP-based because of PHP

2) M$ stack you have powerful C#/MVC3 combo, but then you deal with pricey
licensing and annoyances like crayon conventions (MyUpperCaseEverything),
boilerplate models, inability to easily print to console (ridiculous), and
working in Windows (as a Linux user, no thanks)

3) Python has Django, certainly some cool stuff there (nice out-of-the-box
admin) but Python is not a great language for creating DSLs, doing MOP (like
property interception), or easy bean building (Groovy beans are simply
awesome)

4) Ruby has Rails and this could be a viable option (I have yet to dive in)

5) Scala has Lift, Play, Spray, Blue Eyes, Scalatra and more. Scala also
has lousy reflection (making run time object creation, param binding, etc. a
major PITA), bloated null handling (Groovy's null safe operator is
wonderful), no elvis, and lacks an ORM solution anywhere close to GORM or
Rails' Active Record. Of course, Scala is fast and powerful with lots of
nice features. Again, tradeoffs to be made everywhere.

6) Haskell, Erlang, Clojure and friends have some cool web framework
offerings, but that is an entirely different paradigm, may be the future,
but a tough transition for OO'ers looking to build complex apps now.

I've probably missed a bunch in the above list but the general point is,
there is no perfect solution. Everyone needs to accumulate a certain degree
of knowledge (#1 familiarity with the language backing the framework) in
order to become proficient. I doubt anyone comes to Rails without knowing
Ruby and immediately starts kicking azz developing complex apps. Maybe, I'd
be shocked if that were the case; and if so, I'm outta here. Just
kidding...

It would be nice to see a bit more diversity in the Groovy framework
ecosystem: we have Grails and Gaelyk and...nothing else (Graffiti and Rat
Pack dead last I checked). One full stack powerhouse, and then a cool GAE
framework that is tied directly to Google. For quick & dirty stuff it would
be great if we had an active Grinatra, just simple routing layer with
Groovlet base running on container of one's choice and even an alternate
template engine like Scalate. Could be fun to hack around in, enjoy Groovy,
experiment.

--
View this message in context: http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4268869.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
Tomas Lin
2012-01-06 11:02:35 UTC
Permalink
>
> It would be nice to see a bit more diversity in the Groovy framework
> ecosystem: we have Grails and Gaelyk and...nothing else (Graffiti and Rat
> Pack dead last I checked). One full stack powerhouse, and then a cool GAE
> framework that is tied directly to Google. For quick & dirty stuff it would
> be great if we had an active Grinatra, just simple routing layer with
> Groovlet base running on container of one's choice and even an alternate
> template engine like Scalate. Could be fun to hack around in, enjoy Groovy,
> experiment.
>

There is now Caelyf which the Gaelyk port to CloudFoundry -
http://caelyf.cloudfoundry.com/

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

http://xircles.codehaus.org/manage_email
Peter Ledbrook
2012-01-06 11:15:52 UTC
Permalink
>> It would be nice to see a bit more diversity in the Groovy framework
>> ecosystem: we have Grails and Gaelyk and...nothing else (Graffiti and Rat
>> Pack dead last I checked). One full stack powerhouse, and then a cool GAE
>> framework that is tied directly to Google. For quick & dirty stuff it would
>> be great if we had an active Grinatra, just simple routing layer with
>> Groovlet base running on container of one's choice and even an alternate
>> template engine like Scalate. Could be fun to hack around in, enjoy Groovy,
>> experiment.
>>
>
> There is now Caelyf which the Gaelyk port to CloudFoundry -
> http://caelyf.cloudfoundry.com/

There is also a nascent Groovy API layer for vert.x:

https://github.com/purplefox/vert.x

which is a Node.js type platform for the JVM.

Peter

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

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

http://xircles.codehaus.org/manage_email
John Moore
2012-01-06 11:24:25 UTC
Permalink
There's also Gretty, as described here:

http://www.ibm.com/developerworks/library/j-javadev2-20/index.html?cmp=dw&cpb=dwjav&ct=dwnew&cr=dwnen&ccy=zz&csr=081811

Maybe not quite the same kind of thing, though.

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

http://xircles.codehaus.org/manage_email
virtualeyes
2012-01-06 13:19:52 UTC
Permalink
Just checked out Caelyf, awesome, looks like Laforge stripped out the GAE
specific hooks.

This could be an interesting test project. Anyone know if this will only
run on Cloud Foundry???

I have a a virtualization server that I could see running a small Caelyf
side project on, but don't want to be tied to CF...

--
View this message in context: http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4269341.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
Tomas Lin
2012-01-06 14:03:30 UTC
Permalink
It only works on cloud foundry because of the way it identifies Redis.

https://plus.google.com/114130972232398734985/posts/ZDEN8gypv1u

It could be possible to provide plugins that will handle other
providers like Heroku or Cloudbees.


On Fri, Jan 6, 2012 at 1:19 PM, virtualeyes <***@hotmail.com> wrote:
> Just checked out Caelyf, awesome, looks like Laforge stripped out the GAE
> specific hooks.
>
> This could be an interesting test project.  Anyone know if this will only
> run on Cloud Foundry???
>
> I have a a virtualization server that I could see running a small Caelyf
> side project on, but don't want to be tied to CF...
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4269341.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
>
>

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

http://xircles.codehaus.org/manage_email
Scott Eisenberg
2012-01-06 12:10:05 UTC
Permalink
I think your analysis is correct, except for #4. That's the real competitor here once you outgrow PHP and realize that Microsoft will charge you for everything. Django gets a look but it doesn't have the widespreadness of Rails.

Anyway, it's a good enough goal to outdo Rails to begin with :-)

On Jan 6, 2012, at 5:20 AM, virtualeyes wrote:

> There are tradeoffs to be made on every single stack.
>
> You could go back to the LAMP stack, ultra-convenient rapid fire land o'
> hacks, but, you are here. Why?
>
> Well, clearly Grails provides something that the LAMP stack does not. Is
> there a PHP version of GORM? No. Is there a PHP version of Groovy? heh, heh,
> No.
>
> Grails provides a complete package that is utterly compelling. Are there
> limitations, bugs, annoyances? Yes, of course, but that does not surprise me
> given the challenge in integrating Spring and Hibernate with Groovy a la
> Rails, all the while adding new functionality and attempting to retain
> backward compatibility -- a large undertaking for a handful of developers.
> I am not at all surprised that the core team is not spending their days &
> nights replying to everyone on the list.
>
> Similarly, community members I suspect are generally Java devs who already
> know the JVM ropes, and probably do not live on the list, just pop around if
> they have a question, or see if there are any interesting threads, then back
> to work.
>
> Rails community may be different in this respect, I am not sure.
>
> Unfortunately there aren't many viable web framework options out there. A
> bold statement I know, but:
>
> 1) you can pretty much omit anything PHP-based because of PHP
>
> 2) M$ stack you have powerful C#/MVC3 combo, but then you deal with pricey
> licensing and annoyances like crayon conventions (MyUpperCaseEverything),
> boilerplate models, inability to easily print to console (ridiculous), and
> working in Windows (as a Linux user, no thanks)
>
> 3) Python has Django, certainly some cool stuff there (nice out-of-the-box
> admin) but Python is not a great language for creating DSLs, doing MOP (like
> property interception), or easy bean building (Groovy beans are simply
> awesome)
>
> 4) Ruby has Rails and this could be a viable option (I have yet to dive in)
>
> 5) Scala has Lift, Play, Spray, Blue Eyes, Scalatra and more. Scala also
> has lousy reflection (making run time object creation, param binding, etc. a
> major PITA), bloated null handling (Groovy's null safe operator is
> wonderful), no elvis, and lacks an ORM solution anywhere close to GORM or
> Rails' Active Record. Of course, Scala is fast and powerful with lots of
> nice features. Again, tradeoffs to be made everywhere.
>
> 6) Haskell, Erlang, Clojure and friends have some cool web framework
> offerings, but that is an entirely different paradigm, may be the future,
> but a tough transition for OO'ers looking to build complex apps now.
>
> I've probably missed a bunch in the above list but the general point is,
> there is no perfect solution. Everyone needs to accumulate a certain degree
> of knowledge (#1 familiarity with the language backing the framework) in
> order to become proficient. I doubt anyone comes to Rails without knowing
> Ruby and immediately starts kicking azz developing complex apps. Maybe, I'd
> be shocked if that were the case; and if so, I'm outta here. Just
> kidding...
>
> It would be nice to see a bit more diversity in the Groovy framework
> ecosystem: we have Grails and Gaelyk and...nothing else (Graffiti and Rat
> Pack dead last I checked). One full stack powerhouse, and then a cool GAE
> framework that is tied directly to Google. For quick & dirty stuff it would
> be great if we had an active Grinatra, just simple routing layer with
> Groovlet base running on container of one's choice and even an alternate
> template engine like Scalate. Could be fun to hack around in, enjoy Groovy,
> experiment.
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4268869.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
>
>


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

http://xircles.codehaus.org/manage_email
Rodrigo Rosenfeld Rosas
2012-01-06 12:30:57 UTC
Permalink
Just complementing...

Em 06-01-2012 08:20, virtualeyes escreveu:
> ...
>
> 3) Python has Django, certainly some cool stuff there (nice out-of-the-box
> admin) but Python is not a great language for creating DSLs, doing MOP (like
> property interception), or easy bean building (Groovy beans are simply
> awesome)

It also has TurboGears, that also seems to be promising. But never
really tried neither Django or TurboGears...

> 4) Ruby has Rails and this could be a viable option (I have yet to dive in)

There are tons of other web frameworks in Ruby, while I think the most
popular are:
Sinatra - http://www.sinatrarb.com/
Cramp - http://cramp.in/ - Designed for better use by asynchronous
applications (read WebSockets and Server-Sent Events)
Merb - http://www.merbivore.com/
Padrino - http://www.padrinorb.com/
Ramaze - http://ramaze.net/

But I still find that Rails is the one pushing the web forward (and I'm
not talking only about Ruby frameworks here).

Rails isn't perfect either and I have my own list of shortcomings with
Rails, but it is still the best web framework I know about.

I'm planning to change the structure of my next article that, would
probably be called "How Grails is different from Rails".

Then I'm thinking in describing the pros and contras of each web
framework, besides the differences in style. But I'm avoiding doing so
for now cause I know it will require me a lot of time...

Continuing, I think you missed important frameworks for the JavaScript
language using Node.js:

Express:http://expressjs.com/
Geddy: http://geddyjs.org/


But it was a great list anyway :)
virtualeyes
2012-01-06 13:35:24 UTC
Permalink
Right, I said the list was incomplete.

I did totally miss the javascript side of the picture, that seems to be the
trend, moving toward client-side device-aware apps that only rely on the
server for authentication and data. Without CoffeeScript, however, I will
not take that route, pure javascript is painful...

At this point, if I had to choose a micro framework like Ruby's Sinatra, it
would be Scala Spray or Circumflex. Scala blows chunks in many respects
(Kotlin release in 4 days), but it is blazing fast relative to Ruby, and the
syntax is not drastically different than Groovy.

What keeps me on Grails is GORM, the ability to prototype a complex database
via crystal clear DSL still impresses. Also, I've invested the time in
learning the framework, so I have a better understanding of what can &
cannot be done, and when to workaround.

Anyway, polyglot is the future. Speaking of, what happened to Standalone
GORM? Not having that option is really getting in the way of my Scala REST
API with Scalate/CoffeeScript/LESS a la standalone GORM ;-)

--
View this message in context: http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4269384.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
Peter Ledbrook
2012-01-06 13:40:23 UTC
Permalink
> Anyway, polyglot is the future.  Speaking of, what happened to Standalone
> GORM? Not having that option is really getting in the way of my Scala REST
> API with Scalate/CoffeeScript/LESS a la standalone GORM ;-)

Michael Lawler appears to have got it working:

http://grails.1312388.n4.nabble.com/Grails-Doc-tp4096052p4213288.html

I suggest starting a new thread for this though.

Peter

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

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

http://xircles.codehaus.org/manage_email
Roberto Guerra
2012-01-05 22:23:58 UTC
Permalink
I second Jason Davis' comments. The comparisons are not helpful. Grails is
different from Rails and PHP. Its like comparing apples with oranges. Use
the right tool for the right job. If you come with a heavy Java background,
Grails is a breeze. If you come from a php,python,rails, etc.. background,
you should not try to develop in grails as if you were developing in php et
al. I think that is the main problems at times, and those persons normally
are the ones that get frustrated. So no matter how much you advice them,
they will still have gripes because it is not php, rails, python.. et al.
And that is also frustrating at times for those who try to help.

On Thu, Jan 5, 2012 at 4:10 PM, Jason Davis <***@openactive.org> wrote:

> I come from an almost exclusive java/swing background. No web apps at
> all. So I don't know much about spring or hibernate to be honest. I
> found grails really easy to get started with. I really don't
> understand the complaints. I tried some web dev with php, using
> CakePHP and no framwork at all. I hate PHP so no point in discussing
> it anymore. I didnt find in anymore welcoming.
>
> IRT unanswered posts... I wish our community was bigger and more
> active in this regard. I have had good luck using stackoverflow.com.
> I feel that grails allows really new people to get further than they
> normally would. This makes for some wild, unintelligible questions on
> the mailing list sometimes lol. Just knowing what the user is actually
> asking is no easy task.
>
> In the end I don't see where all this comparison helps anything. I'm
> on this list to learn/help with grails/groovy. I really could care
> less about how awesome rails/ruby is.
>
> $.02
>
> On Thu, Jan 5, 2012 at 2:49 PM, Scott Eisenberg <***@btrtrucks.com>
> wrote:
> > I have to say as a PHP developer trying to move to Grails that I can
> sympathize with his various feelings.
> >
> > 1) I watch the list every day and see a number of questions - not just
> his - that go unanswered. Sometimes some round and round but they they
> just drop. It seems to me like a lot of the questions are simple answers
> that are just not documented well with another lot of questions being some
> serious grails voodoo that experts know about but kills newbies.
> >
> > I can only assume that the Grails team is busy but I've often thought
> "they (Graeme, Peter, Burt) must know the answer off the top of their
> heads, why don't they just respond?" I would respond but most are beyond
> my knowledge.
> >
> > 2) The answer that you need to know Spring / Hibernate / etc to me is
> just crap. If you want to bring in experienced Java programmers to
> something rad-ier, then fine. If you want the PHP, .net and Rails people
> to come over, big mistake.
> >
> > 3) Every 6 months I try Grails again and within 5 hours of starting a
> project I hit some error that stops me cold. I have read the documentation
> about 10 times. I read the Gorm Gotchas. Now, I'm only moderately stupid
> (Ivy league degree in engineering + MBA from a top level school + 20 years
> development experience) so I know I should not be able to make this stuff
> work. But I managed to code a bunch of systems for my companies using
> Fortran, Java + JSP, Java + Generics + Frontman, & PHP but after 3 years of
> looking at Grails I'm still trying faces and noses, and books and authors
> just trying to get anything to work.
> >
> > IM<not so>HO, the Grails team REALLY needs to respond to the pains of
> the newbies via doc and code simplification. The lack of attention to this
> is solely the reason why Grails remains so far back in the what's hot
> Google listings.
> >
> > Seems to me like you have a few rabid perpetual newbies who are trying
> to let you all know that getting Grail to work is way too frustrating for
> us PHP'ers and we are implicitly offering to show you our pain. You'd we
> wiser to form some kind of on-line working group of newbies and keep fixing
> what roadblocks they run into (and iterating again with another round of
> newbies) until the roadblocks are but minor bumps in the road.
> >
> > There's a LOT of doc written. It's a shame that the little bits
> missing, mess up the experience despite all that's been done.
> >
> > Answering EVERY open question on the mailing list that someone else
> can't solve would be a GREAT first step.
> >
> > I'm pretty convinced it's not the newbie's fault why grails is so hard
> get started with.
> >
> > I've seen threads like this every few months or so. I know I'm pissing
> in the wind but what the hell.
> >
> > PS Grails 2.0 is much better than the 1.x versions. There is always
> hope.
> >
> > PPS I'm progressing down the path of learning Rails as a back-up. I
> have thoughts on what they do better.
> >
> > Action Plan:
> > * Grails team dedicates one member (or all members) to make sure that
> every question asked on the listserv is answered. EVERY answer question
> drives a review of the doc to see what could be added to avoid the
> questions coming forward.
> > * Grails tram makes a committee of newbies who are actively trying to
> develop something real and have a real time dialog as to where they get
> stuck and immediately fixing the stuck-ness, particularly the documentation
> issues.
> > * Group actively tries to compare Rails v Grails and fix competitive
> disadvantages found. Rather than dismissing rails vs grails discussions,
> encourage them so long as they lead to Grails improvements. Designate a
> "Beat-Rails" evangelist from Spring to lead the effort.
> >
> > On Jan 5, 2012, at 8:17 AM, Rodrigo Rosenfeld Rosas wrote:
> >
> >> Hi virtualeyes,
> >>
> >> Em 04-01-2012 19:51, virtualeyes escreveu:
> >>> ... The reality is that Grails
> >>> is in fact absurdly fast to restart, faster than or as fast as,
> cough-cough,
> >>> Rails.
> >>
> >> I have no idea where you did take your estimates from. In my PC, Grails
> takes from 36 to 40s to boot an empty app, while JRuby on Rails takes about
> 16s and Rails itself (on CRuby) takes a single second. I guess you were
> talking about using the interactive console for booting the Grails app. In
> that case, for an empty app, it takes about 2 seconds here, which is still
> a bit slower than vanilla Rails, but certainly much faster than JRuby on
> Rails.
> >>
> >> But anyway, I'm not really much concerned about the time required to
> boot the application as long as I only have to do it once. My main gripe
> with Grails 1.3.7 is that it would reboot after each little change to my
> domain classes and other source files, and that took a huge time.
> >>
> >> Now, with Grails 2, even without the interactive console, the user
> experience is much better as I don't need to often reboot the application.
> The interactive console just makes Grails even more responsive. But in the
> expense of subtle bugs that will show up when using the interactive console
> that wouldn't be present otherwise...
> >>
> >> The main disadvantage of a slow bootup time (in any
> framework/environment) is that it makes running your integration tests
> slower. While using Rspec for writing tests for Rails, one can use Spork
> that will take a similar approach to the one taken from Grails interactive
> console, that will make tests run much faster.
> >>
> >> So, that article that you mentioned is certainly out-of-date and I need
> to rewrite it when I find some time. I'll write a new one and add a
> deprecation note on that one when I'm done for keeping the old comments.
> >>
> >> My main gripe with Grails currently is that I find it very hard to
> debug and find what is causing troubles in my application setup. I often
> have to create a fresh Grails app and gradually copy my files to there
> until I find the source of the problem.
> >>
> >> The Grails error messages don't give me a single clue about the problem
> most of the times. That is not to say that I have no more issues with
> Grails. I don't like it in many ways, but I find the over-complex black
> magic behind Grails the one that takes be most of the time when I'm trying
> to identify some issues.
> >>
> >> Also, I find that the Grails community has poor support when compared
> with the Rails and Ruby one. I have lots of unanswered messages in this
> list where I point to buggy scenarios or plugins.
> >>
> >> For, example, I've filled two bugs in the Rails issues system last
> year, and both were fixed and commited in less than an hour:
> >>
> >> https://github.com/rails/rails/issues/4054
> >> https://github.com/rails/rails/issues/4067
> >>
> >> In the other side, here are some bugs (or feature requests) I've
> reported to the Grails JIRA:
> >>
> >> http://jira.grails.org/browse/GRAILS-8568
> >> http://jira.grails.org/browse/GRAILS-8567
> >> http://jira.grails.org/browse/GPCONSOLE-3
> >> http://jira.grails.org/browse/GRAILS-8539 (I'm the only one
> participating on this one, for example)
> >> http://jira.grails.org/browse/GRAILS-8485
> >> http://jira.grails.org/browse/GRAILS-7792 (feature request)
> >> http://jira.grails.org/browse/GRAILS-3303 (closed as won't fix,
> although I think it could be fixed...)
> >> https://github.com/SpringSource/grails-data-mapping/issues/18
> >>
> >> Unanswered messages in this list:
> >>
> >>
> http://grails.1312388.n4.nabble.com/Strange-issue-with-Grails-2-and-find-with-closure-td4222761.html
> >>
> http://grails.1312388.n4.nabble.com/mongodb-and-hibernate-are-not-playing-well-together-td4222229.htmlthis wasn't answered. It was just told me to not report bugs in the dev
> mailing list, but I didn't get any reply in the user's list too
> >>
> http://grails.1312388.n4.nabble.com/MongoDB-and-multiple-databases-not-talking-about-replication-td4210794.htmljust a minor part of the message was answered
> >>
> http://grails.1312388.n4.nabble.com/Is-there-an-easy-way-to-set-default-mapping-options-to-all-columns-of-some-GORM-class-td4210934.html
> >>
> http://grails.1312388.n4.nabble.com/mongodb-plugin-and-quot-static-mapping-version-false-quot-why-does-the-quot-version-quot-key-is-adde-td4210920.html
> >>
> http://grails.1312388.n4.nabble.com/Grails-resources-plugin-still-uses-deprecated-ConfigurationHolder-td4208027.html
> >>
> http://grails.1312388.n4.nabble.com/grails-shell-will-raise-an-exception-while-trying-to-autocomplete-a-Map-td4205530.html
> >>
> http://grails.1312388.n4.nabble.com/Can-t-upgrade-to-Grails-2-from-1-3-7-and-have-no-clue-all-requests-yields-to-404-status-td4178489.html
> >> http://www.digipedia.pl/usenet/thread/14352/30474/
> >>
> http://grails.1312388.n4.nabble.com/How-to-write-scripts-using-GORM-enabled-domain-classes-td3868599.html(I've got only a suggestion to use another testing framework, but didn't
> get a real answer to what I was asking for)
> >> http://grails.1312388.n4.nabble.com/Grails-scripts-help-td3867976.html
> >>
> >>
> >> Also, besides free time, I still need some more time experimenting with
> Grails 2 before I can write the new article on the subject...
> >>
> >> Best,
> >>
> >> Rodrigo.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>
>


--
*Brother let your heart be wounded
*
*And give no mercy to your fear*
Jason Davis
2012-01-05 22:42:39 UTC
Permalink
I'm not saying we should not look outside grails and java for ideas.
Just saying I don't think we need a team or weekly
discussion on how we are comparing to rails. Maybe a weekly meeting on
how we are fairing against web development trends and best practices.


On Thu, Jan 5, 2012 at 3:23 PM, Roberto Guerra <***@gmail.com> wrote:
> I second Jason Davis' comments. The comparisons are not helpful. Grails is
> different from Rails and PHP. Its like comparing apples with oranges. Use
> the right tool for the right job. If you come with a heavy Java background,
> Grails is a breeze. If you come from a php,python,rails, etc.. background,
> you should not try to develop in grails as if you were developing in php et
> al. I think that is the main problems at times, and those persons normally
> are the ones that get frustrated. So no matter how much you advice them,
> they will still have gripes because it is not php, rails, python.. et al.
> And that is also frustrating at times for those who try to help.
>
>
> On Thu, Jan 5, 2012 at 4:10 PM, Jason Davis <***@openactive.org> wrote:
>>
>> I come from an almost exclusive java/swing background. No web apps at
>> all. So I don't know much about spring or hibernate to be honest. I
>> found grails really easy to get started with. I really don't
>> understand the complaints. I tried some web dev with php, using
>> CakePHP and no framwork at all. I hate PHP so no point in discussing
>> it anymore. I didnt find in anymore welcoming.
>>
>> IRT unanswered posts... I wish our community was bigger and more
>> active in this regard. I have had good luck using stackoverflow.com.
>> I feel that grails allows really new people to get further than they
>> normally would. This makes for some wild, unintelligible questions on
>> the mailing list sometimes lol. Just knowing what the user is actually
>> asking is no easy task.
>>
>> In the end I don't see where all this comparison helps anything. I'm
>> on this list to learn/help with grails/groovy. I really could care
>> less about how awesome rails/ruby is.
>>
>> $.02
>>
>> On Thu, Jan 5, 2012 at 2:49 PM, Scott Eisenberg <***@btrtrucks.com>
>> wrote:
>> > I have to say as a PHP developer trying to move to Grails that I can
>> > sympathize with his various feelings.
>> >
>> > 1) I watch the list every day and see a number of questions - not just
>> > his - that go unanswered.  Sometimes some round and round but they they just
>> > drop.  It seems to me like a lot of the questions are simple answers that
>> > are just not documented well with another lot of questions being some
>> > serious grails voodoo that experts know about but kills newbies.
>> >
>> > I can only assume that the Grails team is busy but I've often thought
>> > "they (Graeme, Peter, Burt) must know the answer off the top of their heads,
>> > why don't they just respond?"  I would respond but most are beyond my
>> > knowledge.
>> >
>> > 2) The answer that you need to know Spring / Hibernate / etc to me is
>> > just crap.  If you want to bring in experienced Java programmers to
>> > something rad-ier, then fine.  If you want the PHP, .net and Rails people to
>> > come over, big mistake.
>> >
>> > 3) Every 6 months I try Grails again and within 5 hours of starting a
>> > project I hit some error that stops me cold.  I have read the documentation
>> > about 10 times.  I read the Gorm Gotchas.  Now, I'm only moderately stupid
>> > (Ivy league degree in engineering + MBA from a top level school + 20 years
>> > development experience) so I know I should not be able to make this stuff
>> > work.  But I managed to code a bunch of systems for my companies using
>> > Fortran, Java + JSP, Java + Generics + Frontman, & PHP but after 3 years of
>> > looking at Grails I'm still trying faces and noses, and books and authors
>> > just trying to get anything to work.
>> >
>> > IM<not so>HO, the Grails team REALLY needs to respond to the pains of
>> > the newbies via doc and code simplification.  The lack of attention to this
>> > is solely the reason why Grails remains so far back in the what's hot Google
>> > listings.
>> >
>> > Seems to me like you have a few rabid perpetual newbies who are trying
>> > to let you all know that getting Grail to work is way too frustrating for us
>> > PHP'ers and we are implicitly offering to show you our pain.  You'd we wiser
>> > to form some kind of on-line working group of newbies and keep fixing what
>> > roadblocks they run into (and iterating again with another round of newbies)
>> > until the roadblocks are but minor bumps in the road.
>> >
>> > There's a LOT of doc written.  It's a shame that the little bits
>> > missing, mess up the experience despite all that's been done.
>> >
>> > Answering EVERY open question on the mailing list that someone else
>> > can't solve would be a GREAT first step.
>> >
>> > I'm pretty convinced it's not the newbie's fault why grails is so hard
>> > get started with.
>> >
>> > I've seen threads like this every few months or so.  I know I'm pissing
>> > in the wind but what the hell.
>> >
>> > PS Grails 2.0 is much better than the 1.x versions.  There is always
>> > hope.
>> >
>> > PPS  I'm progressing down the path of learning Rails as a back-up.  I
>> > have thoughts on what they do better.
>> >
>> > Action Plan:
>> > * Grails team dedicates one member (or all members) to make sure that
>> > every question asked on the listserv is answered.  EVERY answer question
>> > drives a review of the doc to see what could be added to avoid the questions
>> > coming forward.
>> > * Grails tram makes a committee of newbies who are actively trying to
>> > develop something real and have a real time dialog as to where they get
>> > stuck and immediately fixing the stuck-ness, particularly the documentation
>> > issues.
>> > * Group actively tries to compare Rails v Grails and fix competitive
>> > disadvantages found.  Rather than dismissing rails vs grails discussions,
>> > encourage them so long as they lead to Grails improvements.  Designate a
>> > "Beat-Rails" evangelist from Spring to lead the effort.
>> >
>> > On Jan 5, 2012, at 8:17 AM, Rodrigo Rosenfeld Rosas wrote:
>> >
>> >> Hi virtualeyes,
>> >>
>> >> Em 04-01-2012 19:51, virtualeyes escreveu:
>> >>> ...  The reality is that Grails
>> >>> is in fact absurdly fast to restart, faster than or as fast as,
>> >>> cough-cough,
>> >>> Rails.
>> >>
>> >> I have no idea where you did take your estimates from. In my PC, Grails
>> >> takes from 36 to 40s to boot an empty app, while JRuby on Rails takes about
>> >> 16s and Rails itself (on CRuby) takes a single second. I guess you were
>> >> talking about using the interactive console for booting the Grails app. In
>> >> that case, for an empty app, it takes about 2 seconds here, which is still a
>> >> bit slower than vanilla Rails, but certainly much faster than JRuby on
>> >> Rails.
>> >>
>> >> But anyway, I'm not really much concerned about the time required to
>> >> boot the application as long as I only have to do it once. My main gripe
>> >> with Grails 1.3.7 is that it would reboot after each little change to my
>> >> domain classes and other source files, and that took a huge time.
>> >>
>> >> Now, with Grails 2, even without the interactive console, the user
>> >> experience is much better as I don't need to often reboot the application.
>> >> The interactive console just makes Grails even more responsive. But in the
>> >> expense of subtle bugs that will show up when using the interactive console
>> >> that wouldn't be present otherwise...
>> >>
>> >> The main disadvantage of a slow bootup time (in any
>> >> framework/environment) is that it makes running your integration tests
>> >> slower. While using Rspec for writing tests for Rails, one can use Spork
>> >> that will take a similar approach to the one taken from Grails interactive
>> >> console, that will make tests run much faster.
>> >>
>> >> So, that article that you mentioned is certainly out-of-date and I need
>> >> to rewrite it when I find some time. I'll write a new one and add a
>> >> deprecation note on that one when I'm done for keeping the old comments.
>> >>
>> >> My main gripe with Grails currently is that I find it very hard to
>> >> debug and find what is causing troubles in my application setup. I often
>> >> have to create a fresh Grails app and gradually copy my files to there until
>> >> I find the source of the problem.
>> >>
>> >> The Grails error messages don't give me a single clue about the problem
>> >> most of the times. That is not to say that I have no more issues with
>> >> Grails. I don't like it in many ways, but I find the over-complex black
>> >> magic behind Grails the one that takes be most of the time when I'm trying
>> >> to identify some issues.
>> >>
>> >> Also, I find that the Grails community has poor support when compared
>> >> with the Rails and Ruby one. I have lots of unanswered messages in this list
>> >> where I point to buggy scenarios or plugins.
>> >>
>> >> For, example, I've filled two bugs in the Rails issues system last
>> >> year, and both were fixed and commited in less than an hour:
>> >>
>> >> https://github.com/rails/rails/issues/4054
>> >> https://github.com/rails/rails/issues/4067
>> >>
>> >> In the other side, here are some bugs (or feature requests) I've
>> >> reported to the Grails JIRA:
>> >>
>> >> http://jira.grails.org/browse/GRAILS-8568
>> >> http://jira.grails.org/browse/GRAILS-8567
>> >> http://jira.grails.org/browse/GPCONSOLE-3
>> >> http://jira.grails.org/browse/GRAILS-8539 (I'm the only one
>> >> participating on this one, for example)
>> >> http://jira.grails.org/browse/GRAILS-8485
>> >> http://jira.grails.org/browse/GRAILS-7792 (feature request)
>> >> http://jira.grails.org/browse/GRAILS-3303 (closed as won't fix,
>> >> although I think it could be fixed...)
>> >> https://github.com/SpringSource/grails-data-mapping/issues/18
>> >>
>> >> Unanswered messages in this list:
>> >>
>> >>
>> >> http://grails.1312388.n4.nabble.com/Strange-issue-with-Grails-2-and-find-with-closure-td4222761.html
>> >>
>> >> http://grails.1312388.n4.nabble.com/mongodb-and-hibernate-are-not-playing-well-together-td4222229.html
>> >> this wasn't answered. It was just told me to not report bugs in the dev
>> >> mailing list, but I didn't get any reply in the user's list too
>> >>
>> >> http://grails.1312388.n4.nabble.com/MongoDB-and-multiple-databases-not-talking-about-replication-td4210794.html
>> >> just a minor part of the message was answered
>> >>
>> >> http://grails.1312388.n4.nabble.com/Is-there-an-easy-way-to-set-default-mapping-options-to-all-columns-of-some-GORM-class-td4210934.html
>> >>
>> >> http://grails.1312388.n4.nabble.com/mongodb-plugin-and-quot-static-mapping-version-false-quot-why-does-the-quot-version-quot-key-is-adde-td4210920.html
>> >>
>> >> http://grails.1312388.n4.nabble.com/Grails-resources-plugin-still-uses-deprecated-ConfigurationHolder-td4208027.html
>> >>
>> >> http://grails.1312388.n4.nabble.com/grails-shell-will-raise-an-exception-while-trying-to-autocomplete-a-Map-td4205530.html
>> >>
>> >> http://grails.1312388.n4.nabble.com/Can-t-upgrade-to-Grails-2-from-1-3-7-and-have-no-clue-all-requests-yields-to-404-status-td4178489.html
>> >> http://www.digipedia.pl/usenet/thread/14352/30474/
>> >>
>> >> http://grails.1312388.n4.nabble.com/How-to-write-scripts-using-GORM-enabled-domain-classes-td3868599.html
>> >> (I've got only a suggestion to use another testing framework, but didn't get
>> >> a real answer to what I was asking for)
>> >> http://grails.1312388.n4.nabble.com/Grails-scripts-help-td3867976.html
>> >>
>> >>
>> >> Also, besides free time, I still need some more time experimenting with
>> >> Grails 2 before I can write the new article on the subject...
>> >>
>> >> Best,
>> >>
>> >> Rodrigo.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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
>>
>>
>
>
>
> --
> Brother let your heart be wounded
> And give no mercy to your fear
>

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

http://xircles.codehaus.org/manage_email
Rob Elsner
2012-01-06 04:17:10 UTC
Permalink
> 1) I watch the list every day and see a number of questions - not just his - that go unanswered.  Sometimes some round and round but they they just drop.  It seems to me like a lot of the questions are simple answers that are just not documented well with another lot of questions being some serious grails voodoo that experts know about but kills newbies.

I try to contribute answers where I can, but often get frustrated at
the lack of research a lot of posters exhibit. Many of the harder
questions get lost (and I try to read every email or at least skim the
subject) by the noise of the easy problems that just show no drive to
solve on their own. There are a number of questions which come up
about one-to-many or many-to-many mappings that are solved quite well
by blog posts that can be found via searching.

Stackoverflow has an amazing amount of answers for the trivial
problems, and a lot of the ones I see here can be solved with a search
there or google, so it's just lazy developers looking to offload their
work on others.

That being said, Graeme, Burt, Luke and others are very responsive
when you submit specific, verifiable problems. They are 3 people
(identified, among others like Ian) among thousands trying to work and
filter the noise of the list.

I've done quite a few apps in Grails, and the most voodoo I've had to
research boils down to oddities with Hibernate (out of the Grails
team) or specific integration problems with the Spring framework.

I'd say that given the smaller size of the Grails community, the list
does fairly well answering questions which are clear, concise and
understandable. It does not do well troubleshooting someone elses
problem for them when no one can reproduce it.

Rob

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

http://xircles.codehaus.org/manage_email
Rob Elsner
2012-01-03 18:54:15 UTC
Permalink
Also if it spends a long time in the "Resolving Dependencies..." try
this nabble: http://grails.1312388.n4.nabble.com/Reducing-dependency-resolution-time-td3054479.html

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

http://xircles.codehaus.org/manage_email
raffaele181188
2012-01-03 19:23:46 UTC
Permalink
I think I don't have any dependency. At least, I have not explicitely added
one. I'm following a tutorial and I have 2 domains and 2 controllers.
BTW, I don't know how to decide if it spends time in dependency
resolution.. But I think it's more a lifecycle issue: it seems that Grails
is fired up each time and initializes all of its components

2012/1/3 robelsner [via Grails] <ml-node+***@n4.nabble.com>

> Also if it spends a long time in the "Resolving Dependencies..." try
> this nabble:
> http://grails.1312388.n4.nabble.com/Reducing-dependency-resolution-time-td3054479.html
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4258160.html
> To unsubscribe from Grails development is really slow, click here<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4257651&code=cmFmZmFlbGVzZ2Fycm9AZ21haWwuY29tfDQyNTc2NTF8LTE3Njk1MDM5MDc=>
> .
> NAML<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>


--
View this message in context: http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4258164.html
Sent from the Grails - user mailing list archive at Nabble.com.
Rodrigo Rosenfeld Rosas
2012-01-03 17:57:14 UTC
Permalink
Em 03-01-2012 15:11, raffaele181188 escreveu:
> Pentium Dual Core, 2GB RAM
> Windows Seven
> STS-2.8.1-RELEASE
> JDK7
> Grails 2.0RC1
> Groovy-1.8
>
> Grails development is very slow. Each time I create a domain/controller
> (either with the graphical wizard or by typing at the Grails shell) it takes
> half a minute to execute. Also, almost every change to groovy
> domain/controller files requires restarting the http server component ,
> otherwise weird things happen, ie I don't see my changes or MissingProperty
> and other funny exception are thrown. I stop catalina with the red square
> button, then I run-app (green "play" button) and everything works as
> expected, but MINUTES are passed! Also, the Grails app is clearly slow in
> outputting HTML and feels very laggy. All I have is 2 domains/controllers
> and, in-memory database and automatic scaffolding
>
> This must be a problem with my stack, because I can't believe that
> developing with Grails is so painful

Raffael, if you're new to Grails, I would suggest you to take a look at
JRuby on Rails. You'll probably have a much better user experience with it.

Grails is really painfully slow and can become very hard to debug in
certain cases... But you should be using Grails 2 final anyway instead
of Grails 2.0RC1.

The Grails interactive shell should you help you too. If you insist on
Grails, you should take some time to find out which plugin might be
creating issues for you with regards to automatic reloading of your classes.

It can take you a lot of time since Grails won't give you any hint about
what is going on, but it certainly worths if you find the culprit. I've
found recently issues with the mongodb plugin that was affecting the
automatic reloading feature and didn't give me a single clue.

I've also had issues due to using gVim with swap files enabled (default
config) as well with using different package from the default one in a
service.

So, while it is very time consuming, I would advise you to start with a
fresh Grails application and gradually copy your classes to this new
application until you see issues with reloading. That way you'll be able
to identify what is causing reloading issues for you.

Yeah, I know, unfortunately I don't know a better way of debugging such
issues. Let me know if you have some better tips for dealing with it.

Good luck,

Rodrigo.

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

http://xircles.codehaus.org/manage_email
Jason Davis
2012-01-03 18:03:42 UTC
Permalink
thats it, throw the baby out with the bath water ....

On Tue, Jan 3, 2012 at 10:57 AM, Rodrigo Rosenfeld Rosas
<***@yahoo.com.br> wrote:
> Em 03-01-2012 15:11, raffaele181188 escreveu:
>
>> Pentium Dual Core, 2GB RAM
>> Windows Seven
>> STS-2.8.1-RELEASE
>> JDK7
>> Grails 2.0RC1
>> Groovy-1.8
>>
>> Grails development is very slow. Each time I create a domain/controller
>> (either with the graphical wizard or by typing at the Grails shell) it
>> takes
>> half a minute to execute. Also, almost every change to groovy
>> domain/controller files requires restarting the http server component ,
>> otherwise weird things happen, ie I don't see my changes or
>> MissingProperty
>> and other funny exception are thrown. I stop catalina with the red square
>> button, then I run-app (green "play" button) and everything works as
>> expected, but MINUTES are passed! Also, the Grails app is clearly slow in
>> outputting HTML and feels very laggy. All I have is 2 domains/controllers
>> and, in-memory database and automatic scaffolding
>>
>> This must be a problem with my stack, because I can't believe that
>> developing with Grails is so painful
>
>
> Raffael, if you're new to Grails, I would suggest you to take a look at
> JRuby on Rails. You'll probably have a much better user experience with it.
>
> Grails is really painfully slow and can become very hard to debug in certain
> cases... But you should be using Grails 2 final anyway instead of Grails
> 2.0RC1.
>
> The Grails interactive shell should you help you too. If you insist on
> Grails, you should take some time to find out which plugin might be creating
> issues for you with regards to automatic reloading of your classes.
>
> It can take you a lot of time since Grails won't give you any hint about
> what is going on, but it certainly worths if you find the culprit. I've
> found recently issues with the mongodb plugin that was affecting the
> automatic reloading feature and didn't give me a single clue.
>
> I've also had issues due to using gVim with swap files enabled (default
> config) as well with using different package from the default one in a
> service.
>
> So, while it is very time consuming, I would advise you to start with a
> fresh Grails application and gradually copy your classes to this new
> application until you see issues with reloading. That way you'll be able to
> identify what is causing reloading issues for you.
>
> Yeah, I know, unfortunately I don't know a better way of debugging such
> issues. Let me know if you have some better tips for dealing with it.
>
> Good luck,
>
> Rodrigo.
>
>
> ---------------------------------------------------------------------
> 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
raffaele181188
2012-01-03 18:10:30 UTC
Permalink
2012/1/3 Jason Davis [via Grails] <ml-node+***@n4.nabble.com
>

> thats it, throw the baby out with the bath water ....

what do you mean?

Raffaele


--
View this message in context: http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4257904.html
Sent from the Grails - user mailing list archive at Nabble.com.
bobbywarner
2012-01-03 18:34:32 UTC
Permalink
Raffaele,

>> Pentium Dual Core, 2GB RAM
>> Windows Seven
2 GB is certainly not ideal, but it should be enough RAM to run Java.exe.
Can you execute other Java programs without issues?

>> STS-2.8.1-RELEASE
Stick to the command line for now so you can narrow it down. Especially
since you only have 2 GB of RAM.

>> JDK7
Can you try JDK 6 from Oracle to rule out any potential issues with JDK 7?

>> Grails 2.0RC1
Get the 2.0 Final version.

>> Groovy-1.8
You don't need to install Groovy, it comes bundled with Grails.


Thanks,
Bobby

--
View this message in context: http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4258002.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
raffaele181188
2012-01-03 18:42:44 UTC
Permalink
Tomorrow I'll do the tests and report the results - I'm at home now :)
But I have to say that 2GB *must be* enough to develop a webapp. It can't
see my disk swapping, and the system is truly responsive: I can even fire
up MS Word and editing a document while grails is running :) So there must
be something wrong in the components. I have two more questions:

I noticed STS comes with Groovy, but what if I want to use a "system"
Groovy compiler? (Bobby)

What is the intended way to run-app within STS? I thought the "run as"
button of STS was the only way :) but every time I click, it starts (?) a
new Grails instance (???) - at least, this is what appears on the console
(jstell)

Raffaele

2012/1/3 bobbywarner [via Grails] <ml-node+***@n4.nabble.com
>

> Raffaele,
>
> >> Pentium Dual Core, 2GB RAM
> >> Windows Seven
> 2 GB is certainly not ideal, but it should be enough RAM to run Java.exe.
> Can you execute other Java programs without issues?
>
> >> STS-2.8.1-RELEASE
> Stick to the command line for now so you can narrow it down. Especially
> since you only have 2 GB of RAM.
>
> >> JDK7
> Can you try JDK 6 from Oracle to rule out any potential issues with JDK 7?
>
> >> Grails 2.0RC1
> Get the 2.0 Final version.
>
> >> Groovy-1.8
> You don't need to install Groovy, it comes bundled with Grails.
>
>
> Thanks,
> Bobby
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4258002.html
> To unsubscribe from Grails development is really slow, click here<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4257651&code=cmFmZmFlbGVzZ2Fycm9AZ21haWwuY29tfDQyNTc2NTF8LTE3Njk1MDM5MDc=>
> .
> NAML<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>


--
View this message in context: http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4258041.html
Sent from the Grails - user mailing list archive at Nabble.com.
Gavin Yue
2012-01-03 18:57:44 UTC
Permalink
Before using any IDE, you had better try everything through command line
and text editor.

And if you want to use Grails as the main development environment, the best
IDE would be Intellj IDEA.



On Tue, Jan 3, 2012 at 10:42 AM, raffaele181188 <***@gmail.com>wrote:

> Tomorrow I'll do the tests and report the results - I'm at home now :)
> But I have to say that 2GB *must be* enough to develop a webapp. It can't
> see my disk swapping, and the system is truly responsive: I can even fire
> up MS Word and editing a document while grails is running :) So there must
> be something wrong in the components. I have two more questions:
>
> I noticed STS comes with Groovy, but what if I want to use a "system"
> Groovy compiler? (Bobby)
>
> What is the intended way to run-app within STS? I thought the "run as"
> button of STS was the only way :) but every time I click, it starts (?) a
> new Grails instance (???) - at least, this is what appears on the console
> (jstell)
>
> Raffaele
>
> 2012/1/3 bobbywarner [via Grails] <[hidden email]<http://user/SendEmail.jtp?type=node&node=4258041&i=0>
> >
>
>> Raffaele,
>>
>> >> Pentium Dual Core, 2GB RAM
>> >> Windows Seven
>> 2 GB is certainly not ideal, but it should be enough RAM to run Java.exe.
>> Can you execute other Java programs without issues?
>>
>> >> STS-2.8.1-RELEASE
>> Stick to the command line for now so you can narrow it down. Especially
>> since you only have 2 GB of RAM.
>>
>> >> JDK7
>> Can you try JDK 6 from Oracle to rule out any potential issues with JDK
>> 7?
>>
>> >> Grails 2.0RC1
>> Get the 2.0 Final version.
>>
>> >> Groovy-1.8
>> You don't need to install Groovy, it comes bundled with Grails.
>>
>>
>> Thanks,
>> Bobby
>>
>> ------------------------------
>> If you reply to this email, your message will be added to the
>> discussion below:
>>
>> http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4258002.html
>> To unsubscribe from Grails development is really slow, click here.
>> NAML<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>
>
> ------------------------------
> View this message in context: Re: Grails development is really slow<http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4258041.html>
> Sent from the Grails - user mailing list archive<http://grails.1312388.n4.nabble.com/Grails-user-f1312389.html>at Nabble.com.
>
Jason Davis
2012-01-03 19:29:23 UTC
Permalink
i know it r fact
http://img.photobucket.com/albums/v516/Offkorn/4chan/FactCat.png

On Tue, Jan 3, 2012 at 11:57 AM, Gavin Yue <***@gmail.com> wrote:
> Before using any IDE, you had better try everything through command line and
> text editor.
>
> And if you want to use Grails as the main development environment, the best
> IDE would be Intellj IDEA.
>
>
>
> On Tue, Jan 3, 2012 at 10:42 AM, raffaele181188 <***@gmail.com>
> wrote:
>>
>> Tomorrow I'll do the tests and report the results - I'm at home now :)
>> But I have to say that 2GB *must be* enough to develop a webapp. It can't
>> see my disk swapping, and the system is truly responsive: I can even fire up
>> MS Word and editing a document while grails is running :) So there must be
>> something wrong in the components. I have two more questions:
>>
>> I noticed STS comes with Groovy, but what if I want to use a "system"
>> Groovy compiler? (Bobby)
>>
>> What is the intended way to run-app within STS? I thought the "run as"
>> button of STS was the only way :) but every time I click, it starts (?) a
>> new Grails instance (???) - at least, this is what appears on the console
>> (jstell)
>>
>> Raffaele
>>
>> 2012/1/3 bobbywarner [via Grails] <[hidden email]>
>>>
>>> Raffaele,
>>>
>>> >> Pentium Dual Core, 2GB RAM
>>> >> Windows Seven
>>> 2 GB is certainly not ideal, but it should be enough RAM to run Java.exe.
>>>  Can you execute other Java programs without issues?
>>>
>>> >> STS-2.8.1-RELEASE
>>> Stick to the command line for now so you can narrow it down.  Especially
>>> since you only have 2 GB of RAM.
>>>
>>> >> JDK7
>>> Can you try JDK 6 from Oracle to rule out any potential issues with JDK
>>> 7?
>>>
>>> >> Grails 2.0RC1
>>> Get the 2.0 Final version.
>>>
>>> >> Groovy-1.8
>>> You don't need to install Groovy, it comes bundled with Grails.
>>>
>>>
>>> Thanks,
>>> Bobby
>>>
>>> ________________________________
>>> If you reply to this email, your message will be added to the discussion
>>> below:
>>>
>>> http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4258002.html
>>> To unsubscribe from Grails development is really slow, click here.
>>> NAML
>>
>>
>>
>> ________________________________
>> View this message in context: Re: Grails development is really slow
>> Sent from the Grails - user mailing list archive at Nabble.com.
>
>

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

http://xircles.codehaus.org/manage_email
Igor Sinev
2012-01-03 20:05:52 UTC
Permalink
Last week I invested like 20 EUR to buy a 2Gb RAM stick to get 3Gb in
total total on my 4 years old Windows XP notebook and that solved the
rest of the performance problems. Before that I had to reduce Xmx
settins for Grails and IDE and it turned out that it used to slow them
down considerably.
I am using Grails interactive mode as much as I can (but keep in mind
that some commands like install-plugin may not work properly in the
interactive mode).

Cheers,
Igor Sinev.

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

http://xircles.codehaus.org/manage_email
Jason Stell
2012-01-03 19:14:37 UTC
Permalink
I misunderstood about the *green "play" button* that you were clicking,
thinking you were talking about the tomcat service controller :)

Dump STS, especially since you're only playing with tutorial apps.

FWIW -- changes to domain objects will typically require an app reload and
DB update (I think this is still true in 2.0), but grails will detect this
automatically and there's no need to manually stop/start. Controller
changes, in my experience, are usually picked up transparently (outside of
a web flow, anyway). Service changes have been unreliably picked up
(depending on scope and whether they're transactional), but this may be
improved in 2.0 (I'll get there eventually).

Jason

On Tue, Jan 3, 2012 at 12:42 PM, raffaele181188 <***@gmail.com>wrote:

> Tomorrow I'll do the tests and report the results - I'm at home now :)
> But I have to say that 2GB *must be* enough to develop a webapp. It can't
> see my disk swapping, and the system is truly responsive: I can even fire
> up MS Word and editing a document while grails is running :) So there must
> be something wrong in the components. I have two more questions:
>
> I noticed STS comes with Groovy, but what if I want to use a "system"
> Groovy compiler? (Bobby)
>
> What is the intended way to run-app within STS? I thought the "run as"
> button of STS was the only way :) but every time I click, it starts (?) a
> new Grails instance (???) - at least, this is what appears on the console
> (jstell)
>
> Raffaele
>
> 2012/1/3 bobbywarner [via Grails] <[hidden email]<http://user/SendEmail.jtp?type=node&node=4258041&i=0>
> >
>
>> Raffaele,
>>
>> >> Pentium Dual Core, 2GB RAM
>> >> Windows Seven
>> 2 GB is certainly not ideal, but it should be enough RAM to run Java.exe.
>> Can you execute other Java programs without issues?
>>
>> >> STS-2.8.1-RELEASE
>> Stick to the command line for now so you can narrow it down. Especially
>> since you only have 2 GB of RAM.
>>
>> >> JDK7
>> Can you try JDK 6 from Oracle to rule out any potential issues with JDK
>> 7?
>>
>> >> Grails 2.0RC1
>> Get the 2.0 Final version.
>>
>> >> Groovy-1.8
>> You don't need to install Groovy, it comes bundled with Grails.
>>
>>
>> Thanks,
>> Bobby
>>
>> ------------------------------
>> If you reply to this email, your message will be added to the
>> discussion below:
>>
>> http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4258002.html
>> To unsubscribe from Grails development is really slow, click here.
>> NAML<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>
>
> ------------------------------
> View this message in context: Re: Grails development is really slow<http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4258041.html>
> Sent from the Grails - user mailing list archive<http://grails.1312388.n4.nabble.com/Grails-user-f1312389.html>at Nabble.com.
>
Rodrigo Rosenfeld Rosas
2012-01-03 18:12:53 UTC
Permalink
Hi Jason, could you point me out what are the advantages of Grails over
Rails? I'd be curious to listen to your opinion.

Em 03-01-2012 16:03, Jason Davis escreveu:
> throw the baby out with the bath water


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

http://xircles.codehaus.org/manage_email
Burt Beckwith
2012-01-03 18:38:20 UTC
Permalink
I'm saying this as a list subscriber (not as a SpringSource employee) but perhaps this list isn't the best place for yet another Grails/Rails comparison?

Burt

On Tuesday, January 03, 2012 04:12:53 PM Rodrigo Rosenfeld Rosas wrote:
> Hi Jason, could you point me out what are the advantages of Grails over
> Rails? I'd be curious to listen to your opinion.
>
> Em 03-01-2012 16:03, Jason Davis escreveu:
> > throw the baby out with the bath water


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

http://xircles.codehaus.org/manage_email
Roberto Guerra
2012-01-03 18:51:22 UTC
Permalink
On Tue, Jan 3, 2012 at 12:38 PM, Burt Beckwith <***@burtbeckwith.com>wrote:

> I'm saying this as a list subscriber (not as a SpringSource employee) but
> perhaps this list isn't the best place for yet another Grails/Rails
> comparison?
>
+1


>
> Burt
>
> On Tuesday, January 03, 2012 04:12:53 PM Rodrigo Rosenfeld Rosas wrote:
> > Hi Jason, could you point me out what are the advantages of Grails over
> > Rails? I'd be curious to listen to your opinion.
> >
> > Em 03-01-2012 16:03, Jason Davis escreveu:
> > > throw the baby out with the bath water
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>


--
*The Journey Is The Reward
*
raffaele181188
2012-01-03 18:09:09 UTC
Permalink
Thanks all for the fast replies. I'll try to change JDK and Grails version,
but I was looking for known issues :(

Rodrigo, big thanks for your suggestions. I looked at Rails, but Ruby is a
very foreign language and it will take long to be proficient with it. On
the other hand, Groovy syntax is very java-friendly, so for this project I
prefer the latter. Anyway your mails confirm that the choppiness is not a
general problem. I'll try Grails on the Ubuntu box and let you know

Raffaele

2012/1/3 rosenfeld [via Grails] <ml-node+***@n4.nabble.com>

> Em 03-01-2012 15:11, raffaele181188 escreveu:
>
> > Pentium Dual Core, 2GB RAM
> > Windows Seven
> > STS-2.8.1-RELEASE
> > JDK7
> > Grails 2.0RC1
> > Groovy-1.8
> >
> > Grails development is very slow. Each time I create a domain/controller
> > (either with the graphical wizard or by typing at the Grails shell) it
> takes
> > half a minute to execute. Also, almost every change to groovy
> > domain/controller files requires restarting the http server component ,
> > otherwise weird things happen, ie I don't see my changes or
> MissingProperty
> > and other funny exception are thrown. I stop catalina with the red
> square
> > button, then I run-app (green "play" button) and everything works as
> > expected, but MINUTES are passed! Also, the Grails app is clearly slow
> in
> > outputting HTML and feels very laggy. All I have is 2
> domains/controllers
> > and, in-memory database and automatic scaffolding
> >
> > This must be a problem with my stack, because I can't believe that
> > developing with Grails is so painful
>
> Raffael, if you're new to Grails, I would suggest you to take a look at
> JRuby on Rails. You'll probably have a much better user experience with
> it.
>
> Grails is really painfully slow and can become very hard to debug in
> certain cases... But you should be using Grails 2 final anyway instead
> of Grails 2.0RC1.
>
> The Grails interactive shell should you help you too. If you insist on
> Grails, you should take some time to find out which plugin might be
> creating issues for you with regards to automatic reloading of your
> classes.
>
> It can take you a lot of time since Grails won't give you any hint about
> what is going on, but it certainly worths if you find the culprit. I've
> found recently issues with the mongodb plugin that was affecting the
> automatic reloading feature and didn't give me a single clue.
>
> I've also had issues due to using gVim with swap files enabled (default
> config) as well with using different package from the default one in a
> service.
>
> So, while it is very time consuming, I would advise you to start with a
> fresh Grails application and gradually copy your classes to this new
> application until you see issues with reloading. That way you'll be able
> to identify what is causing reloading issues for you.
>
> Yeah, I know, unfortunately I don't know a better way of debugging such
> issues. Let me know if you have some better tips for dealing with it.
>
> Good luck,
>
> Rodrigo.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4257856.html
> To unsubscribe from Grails development is really slow, click here<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4257651&code=cmFmZmFlbGVzZ2Fycm9AZ21haWwuY29tfDQyNTc2NTF8LTE3Njk1MDM5MDc=>
> .
> NAML<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>


--
View this message in context: http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4257894.html
Sent from the Grails - user mailing list archive at Nabble.com.
Mark Fortner
2012-01-03 18:21:55 UTC
Permalink
AFAIK, Windows 7 has problems running with 2GB of memory. I believe a
minimum of 4GB is recommended. The Grails FAQ also lists JVM arguments
with suggested heap settings: http://www.grails.org/FAQ

Hope this helps,

Mark


On Tue, Jan 3, 2012 at 10:09 AM, raffaele181188 <***@gmail.com>wrote:

> Thanks all for the fast replies. I'll try to change JDK and Grails
> version, but I was looking for known issues :(
>
> Rodrigo, big thanks for your suggestions. I looked at Rails, but Ruby is a
> very foreign language and it will take long to be proficient with it. On
> the other hand, Groovy syntax is very java-friendly, so for this project I
> prefer the latter. Anyway your mails confirm that the choppiness is not a
> general problem. I'll try Grails on the Ubuntu box and let you know
>
> Raffaele
>
> 2012/1/3 rosenfeld [via Grails] <[hidden email]<http://user/SendEmail.jtp?type=node&node=4257894&i=0>
> >
>
>> Em 03-01-2012 15:11, raffaele181188 escreveu:
>>
>> > Pentium Dual Core, 2GB RAM
>> > Windows Seven
>> > STS-2.8.1-RELEASE
>> > JDK7
>> > Grails 2.0RC1
>> > Groovy-1.8
>> >
>> > Grails development is very slow. Each time I create a domain/controller
>> > (either with the graphical wizard or by typing at the Grails shell) it
>> takes
>> > half a minute to execute. Also, almost every change to groovy
>> > domain/controller files requires restarting the http server component ,
>> > otherwise weird things happen, ie I don't see my changes or
>> MissingProperty
>> > and other funny exception are thrown. I stop catalina with the red
>> square
>> > button, then I run-app (green "play" button) and everything works as
>> > expected, but MINUTES are passed! Also, the Grails app is clearly slow
>> in
>> > outputting HTML and feels very laggy. All I have is 2
>> domains/controllers
>> > and, in-memory database and automatic scaffolding
>> >
>> > This must be a problem with my stack, because I can't believe that
>> > developing with Grails is so painful
>> Raffael, if you're new to Grails, I would suggest you to take a look at
>> JRuby on Rails. You'll probably have a much better user experience with
>> it.
>>
>> Grails is really painfully slow and can become very hard to debug in
>> certain cases... But you should be using Grails 2 final anyway instead
>> of Grails 2.0RC1.
>>
>> The Grails interactive shell should you help you too. If you insist on
>> Grails, you should take some time to find out which plugin might be
>> creating issues for you with regards to automatic reloading of your
>> classes.
>>
>> It can take you a lot of time since Grails won't give you any hint about
>> what is going on, but it certainly worths if you find the culprit. I've
>> found recently issues with the mongodb plugin that was affecting the
>> automatic reloading feature and didn't give me a single clue.
>>
>> I've also had issues due to using gVim with swap files enabled (default
>> config) as well with using different package from the default one in a
>> service.
>>
>> So, while it is very time consuming, I would advise you to start with a
>> fresh Grails application and gradually copy your classes to this new
>> application until you see issues with reloading. That way you'll be able
>> to identify what is causing reloading issues for you.
>>
>> Yeah, I know, unfortunately I don't know a better way of debugging such
>> issues. Let me know if you have some better tips for dealing with it.
>>
>> Good luck,
>>
>> Rodrigo.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>> ------------------------------
>> If you reply to this email, your message will be added to the
>> discussion below:
>>
>> http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4257856.html
>> To unsubscribe from Grails development is really slow, click here.
>> NAML<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>
>
> ------------------------------
> View this message in context: Re: Grails development is really slow<http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4257894.html>
>
> Sent from the Grails - user mailing list archive<http://grails.1312388.n4.nabble.com/Grails-user-f1312389.html>at Nabble.com.
>
Jason Stell
2012-01-03 18:17:38 UTC
Permalink
Maybe I'm misinterpreting, but it seems that you're not using the standard
grails run-app command while developing. Why not? Are you rebuilding and
cycling tomcat for every change?
Running STS + any grails app + any browser is going to be truly painful on
2GB of RAM. I *strongly* suggest getting more RAM or doing your coding in
Notepad++ or something lightweight. You're probably living in swap space.

On Tue, Jan 3, 2012 at 11:11 AM, raffaele181188 <***@gmail.com>wrote:

> Pentium Dual Core, 2GB RAM
> Windows Seven
> STS-2.8.1-RELEASE
> JDK7
> Grails 2.0RC1
> Groovy-1.8
>
> Grails development is very slow. Each time I create a domain/controller
> (either with the graphical wizard or by typing at the Grails shell) it
> takes
> half a minute to execute. Also, almost every change to groovy
> domain/controller files requires restarting the http server component ,
> otherwise weird things happen, ie I don't see my changes or MissingProperty
> and other funny exception are thrown. I stop catalina with the red square
> button, then I run-app (green "play" button) and everything works as
> expected, but MINUTES are passed! Also, the Grails app is clearly slow in
> outputting HTML and feels very laggy. All I have is 2 domains/controllers
> and, in-memory database and automatic scaffolding
>
> This must be a problem with my stack, because I can't believe that
> developing with Grails is so painful
>
> --
> View this message in context:
> http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4257651.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
>
>
>
Jeff Brown
2012-01-03 18:30:34 UTC
Permalink
On Tue, Jan 3, 2012 at 11:11 AM, raffaele181188
<***@gmail.com> wrote:
> Pentium Dual Core, 2GB RAM
> Windows Seven
> STS-2.8.1-RELEASE
> JDK7
> Grails 2.0RC1
> Groovy-1.8
>
> Grails development is very slow. Each time I create a domain/controller
> (either with the graphical wizard or by typing at the Grails shell) it takes
> half a minute to execute.

Are you talking about the time it takes to do something like
create-controller? If so, something is definitely wrong. 30 seconds
is way out of the window of what is expected. On my machine
create-controller is a a sub-second operation from within the Grails
2.0 interactive console.



jb
--
Jeff Brown
SpringSource
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/

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

http://xircles.codehaus.org/manage_email
raffaele181188
2012-01-03 18:45:56 UTC
Permalink
>
> Are you talking about the time it takes to do something like
> create-controller? If so, something is definitely wrong. 30 seconds
> is way out of the window of what is expected. On my machine
> create-controller is a a sub-second operation from within the Grails
> 2.0 interactive console.
>
Yes. 30 seconds is unacceptable :) moreover, it seems that every change to
domain/controller requires a restart of catalina and this is very strange.
Without restarting, I get MissingPropertyExceptions and other weird things.
I remark that my app is not a "real" app: I am only coding after a tutorial
I am reading, and all I have is 2 domains and 2 controllers


--
View this message in context: http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4258058.html
Sent from the Grails - user mailing list archive at Nabble.com.
Jeff Brown
2012-01-04 00:17:32 UTC
Permalink
On Tue, Jan 3, 2012 at 12:45 PM, raffaele181188
<***@gmail.com> wrote:
>> Are you talking about the time it takes to do something like
>> create-controller?  If so, something is definitely wrong.  30 seconds
>> is way out of the window of what is expected.  On my machine
>> create-controller is a a sub-second operation from within the Grails
>> 2.0 interactive console.
>
> Yes. 30 seconds is unacceptable :)

Here is a look at how long create-controller takes on my machine:
http://s3.amazonaws.com/jeffscreencasts/createController.mov



jb

--
Jeff Brown
SpringSource
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/

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

http://xircles.codehaus.org/manage_email
raffaele181188
2012-01-04 17:44:04 UTC
Permalink
I tried to switch JDK and Grails version, but it didn't make any difference.
Plus, I tried a sample RoR project (Ruby is said to be less hungry of RAM
than Groovy) and it's very slow, too
Maybe you're right and my machine is not enough to run confortably these
tools - even if I think it's more a matter of CPU (Pentium Dual Core) than
RAM.
Maybe it's just Windows - I use Linux whenever I deal with tools intended
to run on *nix platforms, but my current company works exclusively on MS
platforms. Unfortunately I couldn't try STS on my Ubuntu box because Grails
extension installation fails with an obscure resource not found error.

I didn't try to tell IDEs apart, because that's how I like web development
to be done. I don't want to memorize all sorts of commands for code
generation, deploying, compiling, version control, and so on.

Thanks you all
Raffaele

2012/1/4 Jeff Brown-3 [via Grails] <
ml-node+***@n4.nabble.com>

> On Tue, Jan 3, 2012 at 12:45 PM, raffaele181188
> <[hidden email] <http://user/SendEmail.jtp?type=node&node=4259284&i=0>>
> wrote:
> >> Are you talking about the time it takes to do something like
> >> create-controller? If so, something is definitely wrong. 30 seconds
> >> is way out of the window of what is expected. On my machine
> >> create-controller is a a sub-second operation from within the Grails
> >> 2.0 interactive console.
> >
> > Yes. 30 seconds is unacceptable :)
>
> Here is a look at how long create-controller takes on my machine:
> http://s3.amazonaws.com/jeffscreencasts/createController.mov
>
>
>
>
> jb
>
> --
> Jeff Brown
> SpringSource
> http://www.springsource.com/
>
> Autism Strikes 1 in 166
> Find The Cause ~ Find The Cure
> http://www.autismspeaks.org/
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4259284.html
> To unsubscribe from Grails development is really slow, click here<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4257651&code=cmFmZmFlbGVzZ2Fycm9AZ21haWwuY29tfDQyNTc2NTF8LTE3Njk1MDM5MDc=>
> .
> NAML<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>


--
View this message in context: http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4262137.html
Sent from the Grails - user mailing list archive at Nabble.com.
Kris De Volder
2012-01-04 19:40:02 UTC
Permalink
Hi Rafaelle,

> What is the intended way to run-app within STS? I thought the "run as" button of STS was the only way :) but every time I click, it starts (?) a new Grails instance (???) - at least, this is what appears on the console

There are several ways. The two that go via UI menus (rather than
typing commands) are the menus:

1) "Run as >> Grails Command (run-app)"
To run just like the "run-app" command, using an embedded tomcat instance.
2) "Run as >> Run on Server"
To run on the TcServer instance that is setup and visible in the
STS "Servers" tab in the workspace.

For quicker turn-around using number 1) is best. And you shouldn't
have to re-run/restart for every little change you make. In Grails 2.0
most/many changes will be picked-up automatically.
So it is recommended to mostly leave the app running and just reload
pages in your web browser.

Number 2 allows you to run on the tc server instance. Mainly you'd
want to do that to use spring-insight. But you won't get as good
support for dynamic reloading and starting/stopping the server is
indeed quite time consuming.

> Unfortunately I couldn't try STS on my Ubuntu box because Grails extension installation fails with an obscure resource not found error.

We could try to look into that if you want. It shouldn't be a problem
to install STS + grails tooling in Ubuntu. I'm using Ubuntu 10.04
myself and don't have issues with it. (2Gb does seem low to me, I've
got 8Gb, you probably don't need that, but I'd recommend a minimum of
4Gb. I'd also recommend you install Sun JVM instead of open JDK, for
example the fast reloading support in grails may not work reliably
with non-sun JVM. Also I'd recommend sticking with 32bit OS,
especially if you haven't got a large amount of memory.

If you want to try again setting up in Ubuntu... feel free to contact
me on Skype (kdvolder). I'll try to help you setup the tools if you
want.

Kris

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

http://xircles.codehaus.org/manage_email
Akira Ikeda
2012-01-05 04:00:47 UTC
Permalink
My old mbpro core solo 2 Gb ram was barely usable and the limit of 2 GB by the cpu was the reason i upgraded to another machine.
I recommend you to do the following :

- Open some utility to see the cpu - ram usage (Resource control panel)
- Don't know how this can affect windows 7 but try disabling all the fancy UI, you'll get a windows 2k look but performance should be better
- Antivirus software could be slowing down the ide / tomcat / db
- Use the ide only to edit, to other things use the shell, learning the basic commands is essential and will help you later on other situations. You can use aliases on your shell to help speed typing

Some years ago when i was forced to use a windows machine those were the things that i did, win2k looks like a '80 UI but all windows UI have a stupid and ugly look anyway. If you can, switch to linux with a lightweight window manager like enlightenment or window maker.


On Jan 5, 2012, at 2:44 AM, raffaele181188 wrote:

> I tried to switch JDK and Grails version, but it didn't make any difference.
> Plus, I tried a sample RoR project (Ruby is said to be less hungry of RAM than Groovy) and it's very slow, too
> Maybe you're right and my machine is not enough to run confortably these tools - even if I think it's more a matter of CPU (Pentium Dual Core) than RAM.
> Maybe it's just Windows - I use Linux whenever I deal with tools intended to run on *nix platforms, but my current company works exclusively on MS platforms. Unfortunately I couldn't try STS on my Ubuntu box because Grails extension installation fails with an obscure resource not found error.
>
> I didn't try to tell IDEs apart, because that's how I like web development to be done. I don't want to memorize all sorts of commands for code generation, deploying, compiling, version control, and so on.
>
> Thanks you all
> Raffaele
>
> 2012/1/4 Jeff Brown-3 [via Grails] <[hidden email]>
> On Tue, Jan 3, 2012 at 12:45 PM, raffaele181188
> <[hidden email]> wrote:
> >> Are you talking about the time it takes to do something like
> >> create-controller? If so, something is definitely wrong. 30 seconds
> >> is way out of the window of what is expected. On my machine
> >> create-controller is a a sub-second operation from within the Grails
> >> 2.0 interactive console.
> >
> > Yes. 30 seconds is unacceptable :)
>
> Here is a look at how long create-controller takes on my machine:
> http://s3.amazonaws.com/jeffscreencasts/createController.mov
>
>
>
>
> jb
>
> --
> Jeff Brown
> SpringSource
> http://www.springsource.com/
>
> Autism Strikes 1 in 166
> Find The Cause ~ Find The Cure
> http://www.autismspeaks.org/
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
>
> If you reply to this email, your message will be added to the discussion below:
> http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4259284.html
> To unsubscribe from Grails development is really slow, click here.
> NAML
>
>
> View this message in context: Re: Grails development is really slow
> Sent from the Grails - user mailing list archive at Nabble.com.
Sam Carr
2012-01-05 09:12:18 UTC
Permalink
I upgraded my Macbook Pro from 4GB to 8GB RAM recently and it makes a world of difference to me. STS uses a LOT of memory, and it creeps up over time. Grails doesn't exactly sip memory either, but when memory is so cheap (that 8GB RAM cost just £40 from Crucial) it's a false economy to muddle along without maxing out your machine for RAM. Grails' memory usage compared to other frameworks does not concern me especially, but it'll depend on your exact circumstances I suppose.

FWIW I run grails interactive mode from the command line and run-app from within there whilst developing code in STS, rather than using STS to fire up grails. Most changes are picked up automatically so I don't have to restart, but a quick exit / run-app in grails restarts within a couple of seconds. I understand that this is a pretty common way of working. I agree with those calling for more explicit guidance for newbies in these sorts of simple practicalities, especially since STS is the de facto Grails IDE that many will start with.

Sam

On 5 Jan 2012, at 04:00, Akira Ikeda wrote:

> My old mbpro core solo 2 Gb ram was barely usable and the limit of 2 GB by the cpu was the reason i upgraded to another machine.
> I recommend you to do the following :
>
> - Open some utility to see the cpu - ram usage (Resource control panel)
> - Don't know how this can affect windows 7 but try disabling all the fancy UI, you'll get a windows 2k look but performance should be better
> - Antivirus software could be slowing down the ide / tomcat / db
> - Use the ide only to edit, to other things use the shell, learning the basic commands is essential and will help you later on other situations. You can use aliases on your shell to help speed typing
>
> Some years ago when i was forced to use a windows machine those were the things that i did, win2k looks like a '80 UI but all windows UI have a stupid and ugly look anyway. If you can, switch to linux with a lightweight window manager like enlightenment or window maker.

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

http://xircles.codehaus.org/manage_email
Terry Tompkins
2012-01-03 18:30:42 UTC
Permalink
As someone else suggested, the 2gb of memory might be the issue. STS is eclipse-based, so a sizable chunk of memory will go to that before your app ever starts up. If you'd like to test the low memory theory, make sure STS is not even loaded into memory when you test running the grails app from a command line. If it performs any better, then it is likely a memory issue. You might also check your free disk space - if you are low in disk, then the system will perform poorly. Also see if you have any other background processes (such as a browser with a large number of tabs/windows open).
I have run grails apps on comparable hardware and the performance was better than you described so there should be a way to improve things.

-terry

Sent from my IBM Blue Gene/P Supercomputer.

On Jan 3, 2012, at 12:11 PM, raffaele181188 <***@gmail.com> wrote:

> Pentium Dual Core, 2GB RAM
> Windows Seven
> STS-2.8.1-RELEASE
> JDK7
> Grails 2.0RC1
> Groovy-1.8
>
> Grails development is very slow. Each time I create a domain/controller
> (either with the graphical wizard or by typing at the Grails shell) it takes
> half a minute to execute. Also, almost every change to groovy
> domain/controller files requires restarting the http server component ,
> otherwise weird things happen, ie I don't see my changes or MissingProperty
> and other funny exception are thrown. I stop catalina with the red square
> button, then I run-app (green "play" button) and everything works as
> expected, but MINUTES are passed! Also, the Grails app is clearly slow in
> outputting HTML and feels very laggy. All I have is 2 domains/controllers
> and, in-memory database and automatic scaffolding
>
> This must be a problem with my stack, because I can't believe that
> developing with Grails is so painful
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4257651.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
>
>
>

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

http://xircles.codehaus.org/manage_email
raffaele181188
2012-01-03 18:48:27 UTC
Permalink
2012/1/3 Terry Tompkins [via Grails] <
ml-node+***@n4.nabble.com>

> As someone else suggested, the 2gb of memory might be the issue. STS is
> eclipse-based, so a sizable chunk of memory will go to that before your app
> ever starts up. If you'd like to test the low memory theory, make sure STS
> is not even loaded into memory when you test running the grails app from a
> command line. If it performs any better, then it is likely a memory issue.
> You might also check your free disk space - if you are low in disk, then
> the system will perform poorly. Also see if you have any other background
> processes (such as a browser with a large number of tabs/windows open).
> I have run grails apps on comparable hardware and the performance was
> better than you described so there should be a way to improve things.
>
I'll do the tests ASAP, anyway 2GB are not so bad :) I can successfully and
smoothly develop Android application with this configuration. Obviously one
can't expect the speed of light from this machine, but 2GB are definetly
2GB :)

Raffaele


--
View this message in context: http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4258069.html
Sent from the Grails - user mailing list archive at Nabble.com.
raffaele181188
2012-01-06 11:23:41 UTC
Permalink
when I mentioned PHP I didn't mean to fire up yet another language and
framework war :) I was just asking if grails can deliver a smooth
development experience like PHP ' s, but was only referring to the edit
file -> reload the browser -> instantly see the change cycle. I used PHP
with and without web frameworks quite a lot and I never liked it, so that's
not the point. On the Java land the process feels quite slow and scattered
because Java is compiled - unless you use tools like JRebel but I never
tried it myself. I thought that every scripting language could feel
"lightweight" like PHP in that very sense, but on my machine grails really
is not, as I detailed before. For example I like the play! way of
transparently compile things, but play is Java eheh. Eventually my question
is if grails is (will be) able to deliver that kind of experience. I'm not
really interested in other languages / frameworks here :)

Raffaele
------------------------------
Da: virtualeyes [via Grails]
Inviato: 06/01/2012 11:20
A: raffaele181188
Oggetto: Re: Grails development is really slow

There are tradeoffs to be made on every single stack.

You could go back to the LAMP stack, ultra-convenient rapid fire land o'
hacks, but, you are here. Why?

Well, clearly Grails provides something that the LAMP stack does not. Is
there a PHP version of GORM? No. Is there a PHP version of Groovy? heh,
heh, No.

Grails provides a complete package that is utterly compelling. Are there
limitations, bugs, annoyances? Yes, of course, but that does not surprise
me given the challenge in integrating Spring and Hibernate with Groovy a la
Rails, all the while adding new functionality and attempting to retain
backward compatibility -- a large undertaking for a handful of developers.
I am not at all surprised that the core team is not spending their days &
nights replying to everyone on the list.

Similarly, community members I suspect are generally Java devs who already
know the JVM ropes, and probably do not live on the list, just pop around
if they have a question, or see if there are any interesting threads, then
back to work.

Rails community may be different in this respect, I am not sure.

Unfortunately there aren't many viable web framework options out there. A
bold statement I know, but:

1) you can pretty much omit anything PHP-based because of PHP

2) M$ stack you have powerful C#/MVC3 combo, but then you deal with pricey
licensing and annoyances like crayon conventions (MyUpperCaseEverything),
boilerplate models, inability to easily print to console (ridiculous), and
working in Windows (as a Linux user, no thanks)

3) Python has Django, certainly some cool stuff there (nice out-of-the-box
admin) but Python is not a great language for creating DSLs, doing MOP
(like property interception), or easy bean building (Groovy beans are
simply awesome)

4) Ruby has Rails and this could be a viable option (I have yet to dive in)

5) Scala has Lift, Play, Spray, Blue Eyes, Scalatra and more. Scala also
has lousy reflection (making run time object creation, param binding, etc.
a major PITA), bloated null handling (Groovy's null safe operator is
wonderful), no elvis, and lacks an ORM solution anywhere close to GORM or
Rails' Active Record. Of course, Scala is fast and powerful with lots of
nice features. Again, tradeoffs to be made everywhere.

6) Haskell, Erlang, Clojure and friends have some cool web framework
offerings, but that is an entirely different paradigm, may be the future,
but a tough transition for OO'ers looking to build complex apps now.

I've probably missed a bunch in the above list but the general point is,
there is no perfect solution. Everyone needs to accumulate a certain degree
of knowledge (#1 familiarity with the language backing the framework) in
order to become proficient. I doubt anyone comes to Rails without knowing
Ruby and immediately starts kicking azz developing complex apps. Maybe,
I'd be shocked if that were the case; and if so, I'm outta here. Just
kidding...

It would be nice to see a bit more diversity in the Groovy framework
ecosystem: we have Grails and Gaelyk and...nothing else (Graffiti and Rat
Pack dead last I checked). One full stack powerhouse, and then a cool GAE
framework that is tied directly to Google. For quick & dirty stuff it would
be great if we had an active Grinatra, just simple routing layer with
Groovlet base running on container of one's choice and even an alternate
template engine like Scalate. Could be fun to hack around in, enjoy Groovy,
experiment.

------------------------------
If you reply to this email, your message will be added to the discussion
below:
http://grails.1312388.n4.nabble.com/Grails-development-is-really-slow-tp4257651p4268869.html
To unsubscribe from Grails development is really slow, click
here<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4257651&code=cmFmZmFlbGVzZ2Fycm9AZ21haWwuY29tfDQyNTc2NTF8LTE3Njk1MDM5MDc=>
.
NAML<http://grails.1312388.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>


--
View this message in context: http://grails.1312388.n4.nabble.com/R-Grails-development-is-really-slow-tp4269020p4269020.html
Sent from the Grails - user mailing list archive at Nabble.com.
Loading...