Acabou de sair do forno a nova versão do Grails, intitulada Grails 2.0!
Aqui podemos ver todas as alterações da nova versão
http://blog.springsource.org/2011/12/15/grails-2-0-released/
esta url podemos ver como migrar das versões anteriores
http://grails.org/doc/2.0.x/guide/gettingStarted.html#upgradingFromPreviousVersionsOfGrails
Uhuul! Agora é só testar né…
Eu já havia passado o “pente fino” na versão anterior, mas, como se diz no bom inglês: “here we go again”.
Abraço
Grails tem um defeito sério: depois que você o conhece, difícilmente vê graça nos outros 
mas sou suspeito pra falar 
opa ja vou baixar, to seguindo as aula dos kicolobo !!!
[quote=kicolobo]Grails tem um defeito sério: depois que você o conhece, difícilmente vê graça nos outros
mas sou suspeito pra falar :D[/quote]
Kiko,
Se fosse para voce apontar 3 defeitos no Grails , quais vc apontaria ?
ps: Estou pesquisando um framework BBB com uma curva média em java.
[quote=chun][quote=kicolobo]Grails tem um defeito sério: depois que você o conhece, difícilmente vê graça nos outros
mas sou suspeito pra falar :D[/quote]
Kiko,
Se fosse para voce apontar 3 defeitos no Grails , quais vc apontaria ?
ps: Estou pesquisando um framework BBB com uma curva média em java.[/quote]
Oi chun,
O primeiro eu não chamaria de defeito, mas tem bem mais a ver com a sua equipe (se for ruim): o fato de ser Groovy. Apesar de ser uma linguagem fantástica, que oferece uma produtividade monstruosa e facilita pra caramba a sua vida, se a sua equipe não quiser aprender Groovy, e forçar a barra programando como se fosse JSF ou Struts, seu projeto fracassa. Então, este é um ponto que deve ser levado em consideração.
Sim, você tem acesso a todo o seu código legado Java, mas se você tentar subverter o framework programando-o tal como faz em Java, a produtividade e qualidade simplesmente vai pro saco.
O segundo é a questão do reaproveitamento de código: se você escreve um plugin Grails, ele só vai ser de fato reaproveitado em outra aplicação Grails. Então neste caso você tem de ficar muito esperto quando estiver projetando a arquitetura do seu sistema. Se forem ser criados componentes reaproveitáveis, talvez a melhor alternativa seja uma das abaixo:
A terceira questão é o mau uso do framework buscando performance máxima. Fato: Groovy sempre vai ser mais lento que Java. É um erro muito comum as pessoas esperarem uma performance monstro em linguagens que não são Java e, com isto, se sentirem frustradas no futuro. Isto quer dizer que Grails seja lento? Nope, pelo contrário. Só que sempre você vai cair nesta questão se não levar em consideração este ponto.
Quarto problema: dependência de plugins (e isto ocorre em qualquer plataforma que os tenha). Muitas vezes você projeta sua aplicação dependente de um plugin terceirizado preso a uma versão antiga do Grails. Ai a questão da migração pra uma versão mais nova fica beeeeem complicada.
Eu já escrevi sobre isto ano passado neste post: http://www.itexto.net/devkico/?p=739
Kiko, desculpe a pergunta… mas creio q caso vc já tenha feito, suas opiniao serã muito interessante.
Por acaso vc já experimentou o PlayFramework? Qual foi a sua impressão?
Se sim, quais os motivos vc acredita valer a pena para preferir Graisl ao invés de Play?
[quote=Thiago Senna]Kiko, desculpe a pergunta… mas creio q caso vc já tenha feito, suas opiniao serã muito interessante.
Por acaso vc já experimentou o PlayFramework? Qual foi a sua impressão?
Se sim, quais os motivos vc acredita valer a pena para preferir Graisl ao invés de Play?[/quote]
Eu comecei a brincar com ele, mas não durou muito tempo. No caso, eu me lembro que no Play 1 você podia usar Groovy, no 2, não mais, ficou mais pra Scala né?
AVISO: tudo o que vou dizer daqui pra baixo tem alta probabilidade de ser bobagem
Minha impressão foi a seguinte: se na primeira versão te dão o Groovy, e na segunda te tiram, se você já escreveu uma aplicação grande, os caras quebraram sua perna. Como fica o código legado?
No caso do Grails eu nunca tive problemas com código legado. Conheço aplicações escritas no Grails pré 1.0 que foram sendo portadas com sucesso até a última versão do Grails (1.3.7). Claro, nestes casos há uma preocupação com os plugins excepcional.
Eu achei muito interessante no Play! o fato de não ser usado um servidor de aplicações. Por outro lado, eu gosto de poder usar um servidor como default, porque quando é desenvolvido um produto, é interessante a facilidade em fazer deploy na infra homologada do cliente. Sei que o Play! pode ser deployado num servidor padrão, mas visto que não é o procedimento padrão que os caras pregam, neste caso opto por pensar que sempre vai ser fora do servidor.
Por que usar Play! ao invés de Grails? hmm… difícil responder tanto esta pergunta quanto à contrárioa: "Por que usar Grails ao invés de Play!?"
No final das contas, é caso a caso. Se sua equipe já tem um conhecimento bacana de Java ou Scala, e quer se manter nestas linguagens, vai de Play!
Agora, se já curte Groovy e o stack completo oferecido pelo Grails, além do suporte forte da Spring Source/VMWare, vai de Grails
Acho que no frigir dos ovos tudo se resume às características específicas do projeto e, gostemos ou não, da adaptabilidade de cada um ao framework.
Valeu Kiko… é meio complicado mesmo afirmar qual é o melhor. Eu mesmo acabo sendo conservador optando pela linguagem java que já domino, mas por outro lado gosto e respeito muito o trabalho feito no Grails. Fora que assim como saiu o Grails 2.0 logo deve de sair o Play 2.0 (e que vai mudar muita coisa, posso estar falando bobagem, mas tb tenho a impressao que eles nao sao do tipo q mantem compatibilidade com versoes anteriores).
Sei lá, posso estar viajando, mas nos proximos anos acho q estes “frameworks 2.0” podem fazer muito barulho e mudar muita coisa, e no meu ver, os dois principais players que rodam em uma VM é o Grails e o Play.
Ae pessoal, para quem quiser aprender grails eu recomendo as vídeo-aulas do kikolobo. São muito legais e ele ensina groovy junto que é bem legal
[quote=kicolobo]Grails tem um defeito sério: depois que você o conhece, difícilmente vê graça nos outros
mas sou suspeito pra falar :D[/quote]
Culpa sua kiko. Se não eu nem tinha conhecido essa desgraça.
[quote=Thiago Senna]Valeu Kiko… é meio complicado mesmo afirmar qual é o melhor. Eu mesmo acabo sendo conservador optando pela linguagem java que já domino, mas por outro lado gosto e respeito muito o trabalho feito no Grails. Fora que assim como saiu o Grails 2.0 logo deve de sair o Play 2.0 (e que vai mudar muita coisa, posso estar falando bobagem, mas tb tenho a impressao que eles nao sao do tipo q mantem compatibilidade com versoes anteriores).
Sei lá, posso estar viajando, mas nos proximos anos acho q estes “frameworks 2.0” podem fazer muito barulho e mudar muita coisa, e no meu ver, os dois principais players que rodam em uma VM é o Grails e o Play.[/quote]
Sabe o que rola de bom também? Você pegar um framework de uma linguagem que não conhece e brincar com ele pra aprender a linguagem.
To fazendo isto com Clojure brincando com o Compojure, tá sendo muito bacana, mesmo sabendo que difícilmente (uma pena) não vai sair nada dali.
OUtro bacana foi brincar com o Lift pra aprender Scala
No final das contas, é legal aprender linguagens que talvez você nunca use porque te dão um ferramental teórico bacana pra lidar com outros problemas.
Opa, valeu!
Legal!!!
Uma aplicação Play 1.x não será compatível com a versão 2.
Estão reescrevendo todo o código para versão 2, inclusive na lista de discussão algumas pessoas deram a sugestão de dar outro nome para esta versão.
A preocupação com as aplicações Play 1.x é logo rebatida pelos mantenedores que eles próprios vivem do Play 1.x e não podem descontinuá-la tão cedo.