Seguinte: temos uma aplicação web que desenvolvemos pra uma empresa e continuamos o desenvolvimento adicionando novas funcionalidades eternamente. Agora essa mesma aplicação vai ser usada por outra empresa e também vamos desenvolver novas funcionalidades especificas pra essa empresa. A questão é: qual a melhor forma de controlar as versões? Tem coisas que vão ser comuns pras duas empresas, e outras que vão ser específicas pra cada uma.
Já usamos CVS, mas como organizar isso?
:arrow: Cria uma módulo pra cada empresa e pronto?
:arrow: Cria um móculo com a “aplicação base” e outros dois pra cada empresa extendendo essa aplicação (não sei como eu faria isso)?
:arrow: Cria um branch pra cada empresa?
:arrow: Faz uma aplicação só e restringe o acesso por permissão de usuários e vários ifs?
Obs: cada empresa tem seu ambiente de produção, elas não vão acessar o mesmo servidor.
[]'s
Rodrigo C. A.
Existem diversos padrões e problemas quanto a isso.
Utilizar uma base de código para cada impresa, fazendo itnegrações em código fonte, é uma péssima idéia, um ano vivie sse inferno.
Você pode criar uma aplicação altamente modular, e fazer com que o release de um cliente seja apenas um conjunto de módulos.
Bom texto:
Quais padrões?
Eu adoraria fazer isso. Mas até hoje não encontrei uma maneira decente de fazer isso numa aplicação web. Onde colocar os jars, os JSPs, templates e etc de cada módulo sem ter que misturar os módulos?
[]'s
Rodrigo C. A.
Se são funcionalidades específicas (que não fazem parte da aplicação como um todo) não tem porque ficar na aplicação genérica. Modularize a aplicação e adicione esses novos módulos conforme o necessário.
Na verdade, é possível que todas as aplicações tenham “todas” as funcionalidades, basta desenvolver um mecanismo de ativação/desativação delas (talvez uma simples configuração ou mapeamento possa ser utilizada).
Outra coisa, nada de .jar no SCM, use o Maven pra lidar com isso: http://maven.apache.org/
Use o Maven pra gerenciar todo o projeto :mrgreen:
Quite simple:
POJO: regra de negócio
DAO: Acesso a dados, pode ser customizado pelo cliente (aquelas convenções bizarras de nomenclatura)
JSP: Só a skin do cliente
Separe seus POJOs em componentes organizados pela funcionalidade, misture o uso de interfaces para uma camada se comunicar com a outra, bata com algumas factories ou um container IoC. Misture possibilidade de escrever scripts em Groovy a gosto.
Parece brincadeira (e é 
) mas a idéia é essa. Coloque suas regras de negócio em componentes formados por POJOs e considere o usod e um container IoC.
) mas a idéia é essa. Coloque suas regras de negócio em componentes formados por POJOs e considere o usod e um container IoC.