Comment étendre/personnaliser une guerre avec un autre projet

Question

Nous avons le scénario suivant notre projet:

• Une application Web de base emballé comme un fichier de guerre (appeler projet de base).
• La nécessité de "personnaliser" ou "étendre" l'application de base par client (appelez-le projet client). Cela inclut principalement nouvelles définitions de bean (nous utilisons Spring), ie. remplacement du service implémentations dans le core.war avec implémentations spécifiques au client.
• Nous voulons développer les projets de base et le client indépendamment
• Lorsque le projet client est développé, nous devons être en mesure d'exécuter/debug dans Eclipse (sur Tomcat) avec le projet de base comme une dépendance
• Lorsque le projet client est construit, le fichier de guerre qui en résulte «inclut» les projets de base et les projets clients. Donc, ce .war est la version spécifique au client de l'application

Je suis à la recherche de suggestions quant à la meilleure façon de le faire en termes d'outillage et de configuration de projet.

Nous utilisons actuellement Ant, mais nous voulons éviter d'être enterré dans plus de fourmis. Est-ce que quelqu'un a fait ça avec Maven?

J'ai vu beaucoup de messages sur la façon de construire une application web qui dépend d'une application Java, mais rien sur une application web en fonction d'une autre application web.

Merci!

Answer 1

Dans Eclipse, il existe une méthode WTP «native» pour ce faire. Il utilise principalement des dossiers liés et un petit hack dans le fichier .settings/org.eclipse.wst.common.component. Vous pouvez lire l'article à ce sujet au http://www.informit.com/articles/article.aspx?p=759232&seqNum=3 le chapitre intitulé «Diviser un module Web en plusieurs projets». Le problème avec ceci est que le dossier lié doit être relatif à certains path variable peut être défini dans l'onglet Fenêtre/Préférences/Général/Espace de travail/Ressources liées. Sinon, la définition du dossier lié (peut être trouvée dans le fichier .project dans la racine du projet) contiendra le chemin spécifique au poste de travail. La variable de chemin devrait pratiquement être la racine de l'espace de travail. Cette solution fonctionne parfaitement avec le protocole WTP, le déploiement et tout le reste fonctionne comme il se doit.

La deuxième solution consiste à utiliser ant pour cela. Oublie. Vous allez le regretter profondément.

La troisième solution consiste à utiliser maven pour cela. Vous pouvez oublier le confort de la publication WTP si vous ne faites pas quelques tours. Utilisez des superpositions de guerre comme d'autres suggérées. Veillez à installer les deux m2eclipse, m2eclipse extras. Il y a un plugin d'extension sorti récemment, qui peut vous aider. Décrit au this blog. Je n'ai pas essayé, mais ça a l'air ok. Quoi qu'il en soit, Maven n'a rien à voir avec les dossiers liés, donc je pense que même la première solution et cette overlay maven peuvent cohabiter si nécessaire.

En ce qui concerne les constructions sans tête, vous pouvez utiliser HeadlessEclipse pour la première solution. Il est mort (par moi) maintenant, mais fonctionne toujours :). Si vous utilisez le maven overlay + eclipse, les builds headless sont couverts par maven.

Answer 2

Sons comme Maven WAR overlay fait ce que vous voulez.

Answer 3

Ceci est un peu plus impliqué, mais à un niveau élevé, nous le faisons comme ci-dessous. Nous avons divisé l'ui de la plateforme de base en plusieurs modules de guerre basés sur les fonctionnalités (login-ui, catalog-mgmt-ui, etc.). Chacun de ces modules de base est personnalisable par l'équipe qui fait face au client.

Nous fusionnons tous ces modules pendant la construction en un seul module de guerre. Les règles de fusion sont basées sur le plugin d'assemblage de maven.

Answer 4

Vous démarrez généralement à partir du code source Java. WAR s n'incluent pas le code source Java, seulement les classes compilées sous WEB-INF/classes ou JAR s sous WEB-INF/libs.

Ce que je ferais est d'utiliser Maven et commencer un tout nouveau projet webapp vide avec elle: http://maven.apache.org/guides/mini/guide-webapp.html

Une fois que vous avez la nouvelle structure de projet vide, copiez le code source Java pour elle (src/main/java) et remplissez le liste des dépendances dans pom.xml.

Une fois que vous avez fait tout cela, vous pouvez utiliser mvn clean package pour créer un fichier standard WAR que vous pouvez déployer sur Tomcat.

Answer 5

Vous voudrez peut-être envisager de concevoir votre application de base avec des fonctionnalités enfichables basées sur des interfaces. Par exemple, dites que votre application de base a un concept d'objet User et qu'elle doit prendre en charge les tâches courantes basées sur l'utilisateur.Créez une interface UserStore;

public interface UserStore 
{ 
    public User validateUser(String username, String password) throws InvalidUserException; 
    public User getUser(String username); 
    public void addUser(User user); 
    public void deleteUser(User user); 
    public void updateUser(User user); 
    public List<User> listUsers(); 
} 

Vous pouvez ensuite coder votre application principale (logique de connexion, logique d'enregistrement, etc.) par rapport à cette interface. Vous souhaiterez peut-être fournir une implémentation par défaut de cette interface dans votre application de base, telle qu'un DatabaseUserStore qui serait effectivement un DAO.

Vous définissez ensuite le UserStore comme un haricot de printemps et l'injectez si nécessaire;

<bean id="userStore" class="com.mycorp.auth.DatabaseUserStore"> 
    <constructor-arg ref="usersDataSource"/> 
</bean> 

Ceci vous permet de personnaliser ou d'étendre l'application principale en fonction des besoins spécifiques du client. Si un client souhaite intégrer l'application de base à son serveur Active Directory, vous écrivez une classe LDAPUserStore qui implémente votre interface UserStore à l'aide de LDAP. Configurez-le en tant que bean Spring et empaquetez la classe personnalisée en tant que jar dépendant.

Il ne vous reste plus qu'une application de base que tout le monde utilise, ainsi qu'un ensemble d'extensions personnalisées que vous pouvez fournir et vendre séparément; diable, vous pouvez même avoir le client écrivent leurs propres extensions.