Por que não colocar tudo no mesmo projeto separando em packages e esquecer a zona de artifacts?

Alguns projetos tem a idéia de modulos como o Spring.
Imagine alguém baixando todos os projetos do Spring em um único jar sendo que ele so precisaria de uma parte do projeto.
Se o seu projeto não tem essa necessidade não crie os módulos e simplifique.

diegolovison:

Alguns projetos tem a idéia de modulos como o Spring.
Imagine alguém baixando todos os projetos do Spring em um único jar sendo que ele so precisa de um jar especifico.
Se o seu projeto não tem essa necessidade não crie os módulos e simplifique.

Estava falando mais da base de código de um sistema de uma empresa, mas talvez dê para extrapolar pra tudo.

Qual é o problema de baixar um jar enorme ao invés de um jar pequeno? Espaço em disco? Banda para fazer um download? Acho que não…

É melhor oferecer um jar único com tudo e o cara usa o que quiser e precisar.

Mas a vantagem não é para o cara, e sim para o desenvolvimento interno. Build e integração. Como falei, updates que pegam mais de um artifact são um pé no saco pra fazer sem quebrar tudo.

Acho que é uma questão de cada projeto e de cada time.
Em alguns projetos é melhor quebrar em outros não. :shock:

off topic:
seu blog é muito bom.

diegolovison:

Acho que é uma questão de cada projeto e de cada time.
Em alguns projetos é melhor quebrar em outros não. :shock:

A zona que vários módulos causam é tão grande que não vale a pena quebrar não… Pelo menos é o que parece… Vamos ver se alguém apresenta bons argumentos para o contrário… Deve ter porque tem muita gente fazendo isso… Ou talvez as pessoas continuam com atração fatal pela complexidade.

eu particularmente prefito o artifactory ao nexus, e também nunca trabalhei com GIT só com svn.
ao meu ver o problema é do profissional que as vezes não adota boas práticas.

ja trabalhei com gente que não gostava(ou não sabia) de usar dependency management do maven e a build era uma zona e eu mostrei como adotar a filosofia KISS pra eles no meio de toda a bagunça. no primeiro momento todo mundo falou que o que eu fazia não virava nada e depois todo mundo começou a fazer tb.

depois disso ficou mais facil organizar os códigos de cada módulo e de cada componente interno.

eu acho que sistemas complexos com bases de código muito grandes tem que ser quebrados em artefatos sim, pois é mais facil dar manutenção em um pedaço no que em um todo.
agora pra quebrar em artefatos , é preciso tem gente que saiba quebrar.

Eu nunca trabalhei com projetos muito grandes em Java e foi dessa forma simples que você fala que trabalhei, foi muito tranquilo desenvolvimento, evolução e manutenção. Mas gostaria de entender melhor o outro lado para fazer uma analogia à plataforma .NET que trabalho mais, pois sempre trabalhei com soluções muito grandes e na IDE Visual Studio é tudo muito tranquilo a organização para lidar com vários projetos relacionados. O trabalho flui que é uma beleza. Então se puder mostrar uma foto da “organização” complexa, assim seria mais fácil eu entender o que quer defender na prática, pois também sou contra a complexidade por preciosismo que mais atrapalha do que ajuda. Queria tipo esse print: http://www.ibm.com/developerworks/opensource/tutorials/os-ad-configureless/figure13.jpg (neste caso é o modo simples que você falou, queria visualizar o complexo).

Fala saoj, beleza?

Recentemente fiz uma grande atualização no Next, onde ao invés de um único projeto agora existem 21!!!

Essa separação foi feita por alguns motivos, primeiro que pessoas queriam utilizar determinadas funcionalidades, mas devido a dependencia de outras classes não era possível.

Segundo, pois separar em projetos te limita a usar determinada classe “sem querer”. Não é possível guardar todas as dependencias possíveis na cabeça. Tanto, que deu um bom trabalho reorganizar, pois algumas dependencias “inválidas” estavam presentes.

Também tem a vantagem de outro alguém mexer num módulo e ficar contido nele.

No meu caso, não existe nenhum problema em usar tantos projetos. Até ficou mais organizado e fácil.

Porém, não uso maven!!!

Os projetos são simples, seguem a mesma estrutura, e tem um único build.xml que serve para todos os projetos.
Quem controla a dependencia e a compilacao é o eclipse.

Para download das dependencias uso ivy.

Isso soh faz sentido quando voce possui diferentes equipes ou diferentes ciclos de entrega para cada artifact. Por exemplo, no projeto onde estou trabalhando agora, um dos modulos requer downtime a cada atualizacao. Por conta disso foi necessario extrair uma API e esta eh mantida separadamente e permite que outras equipes atualizem seus modulos mais frequentemente e com menor risco.

Isso soh faz sentido quando voce possui diferentes equipes ou diferentes ciclos de entrega para cada artifact. Por exemplo, no projeto onde estou trabalhando agora, um dos modulos requer downtime a cada atualizacao. Por conta disso foi necessario extrair uma API e esta eh mantida separadamente e permite que outras equipes atualizem seus modulos mais frequentemente e com menor risco.

Boa resposta. O que eu vejo em quantidades assustadoras é pessoas quebrando tudo por que acham que fica mais isolado e bonito. Criam uma complexidade absurda para ter a ilusão de serem espertos pois conseguem gerenciar aos trancos e barrancos a complexidade que eles mesmo criaram. Tudo num projeto só é tão mais fácil que dá tristesa ver um build que ninguém entende.

Outro ponto é que empresas que tem como grande maioria de seus desenvolvedores pessoas ainda sem muita experiência em versionamento, pra evitar que 20 pessoas tenham que ficar fazendo commitando, atualizando e fazendo merge toda hora na mesma base de código, ou mesmo atualizando tudo, preferem separar projetos com grandes bases de código, e especializar equipes em algumas dessas partes, ai ninguém coloca a mão no brinquedo do outro e “teoricamente” o desenvolvimento flui melhor. Já vi muito esse esquema por empresas que passei.

[]s

Sim, mas isso é um tiro no pé.

Código comitado é código em produção. Disciplina é fundamental. O SVN não permite comitar coisas em conflito. Vc tem que resolver na hora. Já o GIT te permite fazer commits locais cheio de conflitos até que vc ou algum condenado tenha que fazer o push.

Ou assume-se a responsabilidade sobre os seus commits ou cria-se uma zona onde ninguém tem culpa de nada pois ninguém entende nada.

Triste ver que a maioria das empresas vai pelo caminha da complexidade, por inexperiência mas muitas vezes também por opção própria. Acreditam que complexidade é inevitável e que contratando condenados para gerenciá-la é o único jeito de tocar o business. Depois se espantam porque ninguém para no emprego. A verdade é que só maluco ou alguém que ganha muito tem saco para ficar lidando com bagunça. Ou não?

A complexidade nesse país chega a ser cultural… rsrsrs