Utilizo plugins de acordo com a necessidade. Acredito que o uso deva ser moderado, pq assim como vc citou, embora a modularização seja uma excelente prática, a utilização de plugins não muito bem suportados acaba sendo um belo tiro no pé.
Ao escolher o plugin, sempre verifico a última versão, qual o percentual da comunidade que o utiliza, entre outras informações.
Atualmente prefiro somente os indispensáveis, como o Spring Security (E esse ainda dependendo da necessidade da aplicação, caso não existam níveis de permissão diferentes, não há necessidade de utilizar uma bomba atômica para matar uma formiga), Resources, JQuery...
[]'s
Opa, dar meu pitaco aqui.
O grande lance dos plugins é que eles aumentam sua produtividade ordens de magnitude. Claro: é um componente, alguém já fez o trabalho pra você. Isto é óbvio e não há muito o que ser dito.
Porém tem um lado negro nesta história: o plugin pode ser um elemento do seu projeto sobre o qual você não tem controle. Basicamente você não sabe de primeira mão o que rola lá dentro, e eu vejo pouquíssimas pessoas tendo a curiosidade de dar uma olhada no código fonte do que está sendo incluído no seu projeto.
Pra piorar ainda mais a situação, há plguins que simplesmente deixam de ser suportados. E não estou falando de plugins pouco usados. Vejam por exemplo o que ocorreu com o Acegi Plugin, que inicialmente era o mais usado plugin de segurança e que, do dia pra noite, parou de ser mantido, entrou em desuso e tudo mais.
Então, qual a solução pra isto: não suar plugins? Nâo. Isto é estúpido. Verificar se o último commit foi recente? Bobagem: tem código que é tão bem escrito que sofre realmente poucas alterações ou não precisa de novos recursos. Parece que não mas acontece muito, especialmente em engenharia, aonde trabalhei muitos anos, por exemplo.
Minha solução é simples, e é um guia bastante fácil de ser seguido.
1) Guarde o código fonte do seu plugin SEMPRE. Assim, caso suma do repositório principal (o que acontece e já ocorreu comigo) você pelo menos está seguro.
2) LEIA o plugin. Só pra lembrar, o plugin é uma aplicação Grails como outra qualquer. A diferença é que vai ser mesclada no código fonte do seu projeto.
3) Minimize o uso de plugins. Sim, isto mesmo. Vamos supor que você tenha na sua aplicação 398439847 de plugins. Cara: se precisar atualizar a versão do Grails, tenha certeza de que sua vida será um inferno. Então, antes de usar um plugin, eu sempre me pergunto o seguinte: que valor real isto trás pro meu projeto hein? Será que esta funcionaldiade que ele vai me fornecer, eu vou usar algo próximo de 80%? Se a resposta for não, talvez seja mais interessante estudar a possibilidade de eu mesmo implementar a funcionalidade, nem que seja literalmente copiando partes do código fonte do plugin que quero usar.
O importante é você ter controle sobre o código fonte que está no seu projeto. No caso do Grails, tem algo maravilhoso que difícilmente você encontra em outras plataformas: você pode ENTENDER o código fonte dos plugins porque é código similar ao que você já escreve normalmente, são as mesmas convenções.
Então, no final das contas, é isto aí. Ao usar plugins, basta seguir estas dicas.
Depois de varias dores de cabeça, comecei a tomar MUITO cuidado com os plugins.
Varios plugins vem com muita dependência, e que podem afetar o projeto
Já aconteceu de bugar do nada e descobrir que o plugin tinha dependencia de uma biblioteca 1.0.1 e o meu projeto da mesma biblioteca, só que 1.1.1
Se os plugins fizerem muita coisa e usarem outras biblitecas, tome cuidado (multifile uploader, bootstrap file upload, kickstart).
Se tiverem uma funcao especifica (resources, jquery, foundation, bootstrap, hibernate, etc) não costumam dar problema
Sempre acontece de um plugin entrar certinho para o que você quer, então use ué. Mas leia a documentação
E se o desenvolvedor decidir modularizar sua propria aplicação com a criação de diversos plugins de sua própria produção, isso possui algum impacto no desempenho?
Oi Ilmon,
nenhum impacto no desempenho.
@Mussato
No Grails 1.x, os plugins 'bem feitos' não deixam os jars embutidos (a maior causa de problemas nesta versão) mas deixam o próprio Grails resolver. Se o plugin tiver libs internas, o recomendado é utilizar a opção "in-place" e remover as libs que causam conflito.
A partir do Grails 2.0 este problema foi completamente resolvido com o Resources Plugin que já vem embutido. Ele também resolve dependências entre plugins (plugin que precisa de outro pra funcionar). Todo plugin mantido hoje *deve* suportar o Resources pois é a boa prática. Esta é outra dica pra verificar se o plugin está sendo suportado.
@Kico
O Acegi Plugin virou o Spring Security Plugin. Ele foi feito novamente seguindo boas práticas depois que a Spring comprou a G2X e renomeou o Acegi para Spring Security.
Verificar se tem commit de código está longe de ser bobagem. Todo bom plugin do Grails tem commits constantes. Se não tem é um sinal claro que o criador não está investindo tempo no plugin. Se ele é suportado, sempre irão surgir melhorias e extensões: criatividade para melhorar não falta.
@llmon
Como o Kico disse, não há nenhum impacto. Porque o plugin tem a mesma estrutura de um projeto Grails e no ato do build ele é mesclado em 1 só projeto. :-D
PS.: A arquitetura de plugins é fantástica. Não sei de onde o Graeme Rocher tirou a idéia, mas quem pensou nisso é um gênio. Simples e poderoso.
Alguns princípios que atualização de versão de plataforma/framework que pratico:
- Em desenvolvimento: atualizar imediatamente para as versões mais recentes.
- Se o sistema ou site for um produto (sistema para alguma vertical de indústria ou site que presta um serviço) e estiver em produção, negociar com a gerência de manutenção e evolução do produto uma agenda para atualização constante. O ideal é ter casos de testes funcionais para eliminar bugs de regressão, de preferência automatizados com Selenium ou Geb por exemplo.
- Se o sistema ou site for especialista (sistema pra um processo de negócio especifico da empresa ou site institucional), vai depender do contrato de manutenção. Se o contrato for longo (mais de 1 ano), vale a pena agendar atualizações para evitar que o sistema ou site 'quebre' futuramente. Caso contrário vale a máxima 'Não conserte o que não está quebrado'.