2011-10-04 1 views
5

J'ai un projet avec un sous-module a:jar qui nécessite un ensemble différent de dépendances, selon la plateforme sur laquelle il est compilé. Le code est le même pour toutes les plateformes. Par exemple. sous Android, la bibliothèque httpcomponents est déjà fournie avec le système d'exploitation, alors que je dois l'inclure dans les versions pour les environnements J2SE. J'ai aussi un autre sous-module, qui assemble plusieurs sous-modules et leurs dépendances dans une archive. Comment est-ce que je peux configurer de manière fiable le sous-module d'assemblage, pour prendre tous les sous-modules compilés pour la plate-forme respective, et leurs dépendances appropriées pour cette plate-forme? J'ai essayé d'utiliser des profils pour créer a:jar:android et a:jar:j2se. Cependant, déclarer une dépendance à l'un d'entre eux entraînerait des dépendances étranges dans l'assemblage. Par exemple, le dependency:tree du projet d'assemblage inclurait parfois les dépendances sur a:jar:j2se (peu importe si j'ai déclaré utiliser le a:jar:android ou a:jar:j2se dans l'assemblage), et parfois l'autre. Il a changé (souvent) après que j'ai mis à jour les pots de a dans le dépôt local. La commutation dans le projet d'assemblage utilise également des profils.Construit pour différentes plates-formes la manière Maven

Je pourrais résoudre ce by applying the same dependencies to the assembly project's profiles tel que requis par le profil individuel des sous-modules. Mais comme je dois me répéter dans les POMs, il y a probablement un moyen plus maven-y d'y parvenir. Comme je suis assez nouveau pour maven, je me demande ce que c'est? Je ne veux pas dupliquer le code (ce serait même plus répétitif car le code reste le même) et je n'aime pas dupliquer certaines parties du POM, car les modifier en raison des mises à jour de version peut devenir compliqué.

Certains matériaux en béton: Dépendances de POM de a:jar:

<dependencies> 
    ..... 
    <dependency> 
     <groupId>org.apache.httpcomponents</groupId> 
     <artifactId>httpmime</artifactId> 
     <version>4.0.1</version> 
     <scope>compile</scope> 
     <!-- Exclusion in the common part, they are provided in the profiles from different sources --> 
     <exclusions> 
     <exclusion> 
      <groupId>org.apache.httpcomponents</groupId> 
      <artifactId>httpclient</artifactId> 
     </exclusion> 
     .... 
     </exclusions> 
    </dependency> 
    </dependencies> 
    <profiles> 
    <profile> 
     <id>android</id> 
     <dependencies> 
     <dependency> 
      <groupId>com.google.android</groupId> 
      <artifactId>android</artifactId> 
      <version>1.6_r2</version> 
      <scope>provided</scope> 
     </dependency> 
     </dependencies> 
    </profile> 
    <profile> 
     <id>java</id> 
     <dependencies> 
     <dependency> 
      <groupId>org.apache.httpcomponents</groupId> 
      <artifactId>httpclient</artifactId> 
      <version>4.0.1</version> 
      <scope>compile</scope> 
     </dependency> 
     <dependency> 
      <groupId>commons-codec</groupId> 
      <artifactId>commons-codec</artifactId> 
      <version>1.3</version> 
      <scope>compile</scope> 
     </dependency> 
     </dependencies> 
    </profile> 
    </profiles> 

Le projet d'assemblage (qui utilise l'Assemblée Plugin Maven) profils:

<profiles> 
    <profile> 
     <id>android</id>  
     <dependencies> 
     <dependency> 
      <groupId>a</groupId> 
      <artifactId>a</artifactId> 
      <version>${project.version}</version> 
      <classifier>android</classifier> 
      <type>jar</type> 
     </dependency> 
     <!-- Duplicate --> 
     <dependency> 
      <groupId>com.google.android</groupId> 
      <artifactId>android</artifactId> 
      <version>1.6_r2</version> 
      <scope>provided</scope> 
     </dependency> 
     <!-- Duplicate --> 
     </dependencies> 
    </profile> 
    <profile> 
     <id>java</id> 
     <dependencies> 
     <!-- Duplicate --> 
     <dependency> 
      <groupId>org.apache.httpcomponents</groupId> 
      <artifactId>httpclient</artifactId> 
      <version>4.0.1</version> 
      <scope>compile</scope> 
     </dependency> 
     <dependency> 
      <groupId>commons-codec</groupId> 
      <artifactId>commons-codec</artifactId> 
      <version>1.3</version> 
      <scope>compile</scope> 
     </dependency> 
     <!-- /Duplicate --> 
     <dependency> 
      <groupId>a</groupId> 
      <artifactId>a</artifactId> 
      <version>${project.version}</version> 
      <classifier>java</classifier> 
     <type>jar</type> 
     </dependency> 
     </dependencies> 
    </profile> 
    </profiles> 

je voudrais vous débarrasser de les déclarations de dépendances marquées.

Répondre

3

Il existe plusieurs solutions:

  1. Ces dépendances de sous-modules peuvent être déclarées « à condition », dans ce cas, dans un projet d'inclure la dépendance à la sous-module ainsi que des dépendances explicites une plate-forme n'a pas .

  2. Utilisez <exclusions> pour les dépendances inutiles. En utilisant (1) ou (2) ci-dessus, créez encore un autre sous-module "structurel" a-android: pom a-j2se: pom qui ne fait que décrire les dépendances, et utilise ces modules de vos projets.

+0

Donc, pour (3), "a-JSE: pom" hériterait de "a". Dans le pom de "a", je ne déclare aucune dépendance (ou seulement commune). Dans le projet d'assemblage je dépendrais de "a-jse: pom" - est-ce correct? Cela semble être un bon moyen ... – Stephan

+0

Oui, c'est vrai.Je pense que vous devez déclarer certaines des dépendances dans "a" parce qu'elles pourraient être nécessaires pour la compilation. C'est pourquoi vous devez faire (1) ou (2). Aussi, ne soyez pas confondu avec le mot "assembly", il n'a rien à voir avec "Maven Assembly Plugin". – kan

+0

J'ai mis à jour l'affichage original pour contenir plus de code concret. En ce moment j'essaie de comprendre comment "a" et "a-j2se" doivent hériter l'un de l'autre correctement. – Stephan

2

Vous pouvez ajouter un profil maven à pom et activer chaque profil en fonction du système d'exploitation. L'activation du profil prend en charge de telles options. Ensuite, dans chaque profil spécifique au système d'exploitation, vous pouvez répertorier les dépendances facultatives. Voici un article sur les profils ->http://maven.apache.org/guides/introduction/introduction-to-profiles.html

Dans votre cas, ce serait quelque chose comme ceci:

<profiles> 
    <profile> 
    <activation> 
     <os> 
     <family>Windows</family> 
     </os> 
    </activation> 
    <dependencies> 
     ... specific dependencies for Windows 
    </dependencies> 
    <plugins> 
     ... specific build plugins for Windows 
    </plugins> 
    </profile> 
    <profile> 
    <activation> 
     <os> 
     <family>unix</family> 
     </os> 
    </activation> 
    <dependencies> 
     ... specific dependencies for unix 
    </dependencies> 
    <plugins> 
     ... specific build plugins for unix 
    </plugins> 
    </profile> 
    <dependencies> 
    ... Common dependencies 
    <dependencies> 
    <plugins> 
    ... Common build plugins 
    </plugins> 
</profiles> 
+2

Le profil spécifique à l'OS n'est pas approprié ici. Cela dépend du système d'exploitation du serveur de construction, mais pas du système d'exploitation cible. De plus, il est très possible qu'il soit nécessaire de construire plusieurs projets pour plusieurs plateformes cibles simultanément. – kan

+0

@kan. Vous pouvez toujours générer des artefacts spécifiques au système d'exploitation (en fait, vous DEVEZ le faire si vous fournissez différents composants pour différents systèmes d'exploitation). En outre, lors de la création de la version, vous pouvez activer les profils par nom, afin de pouvoir créer tous les profils requis sur votre serveur CI, et uniquement ceux qui conviennent à votre environnement de développement sur votre machine dev. –

+0

Si vous souhaitez utiliser différents modules pour différents OS, vous pouvez créer un fichier pom.xml racine qui les inclura tous comme '' et tout compiler en même temps. Pour les profils, vous devez appeler maven plusieurs fois avec différents profils activés. – kan

Questions connexes