IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Maven Java Discussion :

Maven deploy, mais uniquement les .jar (pas les .war ou .ear)


Sujet :

Maven Java

  1. #1
    Candidat au Club
    Homme Profil pro
    Inscrit en
    Avril 2013
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Avril 2013
    Messages : 4
    Points : 4
    Points
    4
    Par défaut Maven deploy, mais uniquement les .jar (pas les .war ou .ear)
    Bonjour,

    Appliqué à un projet multi-modules, la commande deploy va envoyer sur le Nexus les binaires de chaque target, y compris les .war et .ear
    Je voudrais restreindre ce déploiement uniquement aux .jar car mes .war et .ear ne servent à personne alors qu'ils sont très volumineux (ils embarquent toutes leurs dépendances).

    Je cherche donc une option de la commande deploy, une configuration particulière des modules, ou un autre plugin de déploiement que deploy:deploy, qui me permettrait de limiter les binaires envoyés sur Nexus.

    Merci de votre aide.

  2. #2
    Membre chevronné
    Avatar de eulbobo
    Homme Profil pro
    Développeur Java
    Inscrit en
    Novembre 2003
    Messages
    786
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Novembre 2003
    Messages : 786
    Points : 1 993
    Points
    1 993
    Par défaut
    Techniquement, un war ou un ear n'a rien à faire dans un Nexus de toute façon.

    Configure tes artefacts war et ear en disant que tu ne veux pas les déployer dans leur pom.xml respectifs :
    Code XML : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-deploy-plugin</artifactId>
      <version>X.Y</version>
      <configuration>
        <skip>true</skip>
      </configuration>
    </plugin>
    Je ne suis pas mort, j'ai du travail !

  3. #3
    Rédacteur
    Avatar de romaintaz
    Homme Profil pro
    Java craftsman
    Inscrit en
    Juillet 2005
    Messages
    3 790
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Java craftsman
    Secteur : Finance

    Informations forums :
    Inscription : Juillet 2005
    Messages : 3 790
    Points : 7 275
    Points
    7 275
    Par défaut
    Citation Envoyé par eulbobo Voir le message
    Techniquement, un war ou un ear n'a rien à faire dans un Nexus de toute façon.
    Je ne suis pas d'accord.
    Je mets mes WAR dans le Nexus pour 2 raisons :

    Nous sommes tous semblables, alors acceptons nos différences !
    --------------------------------------------------------------
    Liens : Blog | Page DVP | Twitter
    Articles : Hudson | Sonar | Outils de builds Java Maven 3 | Play! 1 | TeamCity| CitConf 2009
    Critiques : Apache Maven

  4. #4
    Membre chevronné
    Avatar de eulbobo
    Homme Profil pro
    Développeur Java
    Inscrit en
    Novembre 2003
    Messages
    786
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Novembre 2003
    Messages : 786
    Points : 1 993
    Points
    1 993
    Par défaut
    Le war est ton application web compilée et packagée.
    Une fois dans ce format, elle ne peut normalement avoir qu'un seul usage : être déployée sur un serveur d'application.

    Je connais le concept du war qui est en dépendance avec un autre war, mais j'ai tendance à penser que c'est une horreur de conception. Accessoirement, ce n'est pas réellement une dépendance, mais plutôt une méthode pour "fusionner" deux war ensemble.
    Accessoirement, l'overlay utilise un concept de premier arrivé, premier servi, du coup tu as pas intérêt à avoir des fichiers identiques dans les deux war.



    Conserver les versions en prod, c'est plutôt le rôle de ton SCM, dans lequel tu crées un tag. Pour refaire un war, tu n'as qu'à récupérer le tag et relancer le packaging.
    J'ai connu trop de cas où quelqu'un a tenté de récupérer un war d'une ancienne version de prod pour faire un retour arrière et où ça a foiré lamentablement (surtout un cas mémorable de changement d'OS sur lequel Tomcat était installé...).
    Tous les cas où on a repackagé depuis un tag ont fonctionné sans problème (et avoir des builds toujours identiques depuis un tag, c'est quand même un des intérêts majeurs de Maven)
    Bref, c'est une fausse économie (il n'y a pas d'économie à éviter un build) et ça bouffe de la place pour pas grand chose sur ton nexus vu que ça embarque toutes les libs... J'espère que tu ne déploies pas trop souvent.
    Je ne suis pas mort, j'ai du travail !

  5. #5
    Candidat au Club
    Homme Profil pro
    Inscrit en
    Avril 2013
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Avril 2013
    Messages : 4
    Points : 4
    Points
    4
    Par défaut
    Citation Envoyé par eulbobo Voir le message
    Configure tes artefacts war et ear en disant que tu ne veux pas les déployer dans leur pom.xml respectifs :
    Code XML : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-deploy-plugin</artifactId>
      <version>X.Y</version>
      <configuration>
        <skip>true</skip>
      </configuration>
    </plugin>
    Merci, j'ai fait comme ça, même si ça ne m'a pas été utile de préciser ni le groupId ni la version, probablement implicites vu que c'est un plugin standard.

  6. #6
    Rédacteur
    Avatar de romaintaz
    Homme Profil pro
    Java craftsman
    Inscrit en
    Juillet 2005
    Messages
    3 790
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Java craftsman
    Secteur : Finance

    Informations forums :
    Inscription : Juillet 2005
    Messages : 3 790
    Points : 7 275
    Points
    7 275
    Par défaut
    Citation Envoyé par eulbobo Voir le message
    Le war est ton application web compilée et packagée.
    Une fois dans ce format, elle ne peut normalement avoir qu'un seul usage : être déployée sur un serveur d'application.

    Je connais le concept du war qui est en dépendance avec un autre war, mais j'ai tendance à penser que c'est une horreur de conception. Accessoirement, ce n'est pas réellement une dépendance, mais plutôt une méthode pour "fusionner" deux war ensemble.
    Accessoirement, l'overlay utilise un concept de premier arrivé, premier servi, du coup tu as pas intérêt à avoir des fichiers identiques dans les deux war.
    Je suis d'accord que ce n'est pas le cas le plus fréquent, mais ça peut arriver, pour partager des ressources communes (JS, CSS, images, etc.) entre 2 applications différentes par exemple. Alors oui, on peut aussi les partager via un JAR, mais bon, ce n'est pas toujours optimal...

    Citation Envoyé par eulbobo Voir le message
    Conserver les versions en prod, c'est plutôt le rôle de ton SCM, dans lequel tu crées un tag. Pour refaire un war, tu n'as qu'à récupérer le tag et relancer le packaging.
    On est complètement d'accord. Toute version partie en prod doit avoir été tagguée préalablement. Ne serait-ce que pour pouvoir avoir le code exact parti en prod, ou encore pouvoir tirer une branche depuis le tag (encore une fois, ça reste possible sans, en notant la révision SVN ou le dernier commit git avant la release, mais c'est moins propre).

    Citation Envoyé par eulbobo Voir le message
    J'ai connu trop de cas où quelqu'un a tenté de récupérer un war d'une ancienne version de prod pour faire un retour arrière et où ça a foiré lamentablement (surtout un cas mémorable de changement d'OS sur lequel Tomcat était installé...).
    Tous les cas où on a repackagé depuis un tag ont fonctionné sans problème (et avoir des builds toujours identiques depuis un tag, c'est quand même un des intérêts majeurs de Maven)
    Hum. Je ne suis pas convaincu. Là tu dis que ça a foiré parce que le binaire a été déployé sur un OS qui a changé depuis la mise en prod originelle. Mais si tu rebuildes depuis le tag, ça change quoi au juste ? Vu que ton OS a quand même changé, donc tu auras là aussi le problème avec un build refait depuis un tag, non ? Le problème ici n'est pas le binaire mais l'environnement directement.
    Et puis on pourrait aussi prétexter l'inverse : si tu buildes ton application en 2012 avec Maven 2.2, si tu rebuildes en 2015 avec un Maven 3.3, il n'est pas exclu qu'un comportement d'un plugin varie légèrement et que du coup ton binaire 2015 soit légèrement différent de 2012.

    A la limite, l'idéal serait de conserver une image Docker de toute ta release, comme ça tu as moins de surprise ;o)

    Citation Envoyé par eulbobo Voir le message
    Bref, c'est une fausse économie (il n'y a pas d'économie à éviter un build) et ça bouffe de la place pour pas grand chose sur ton nexus vu que ça embarque toutes les libs... J'espère que tu ne déploies pas trop souvent.
    Cela dépend des applications, plusieurs fois par semaine pour certaines d'entre elles. Mais admettons que tu as 2 releases par semaine, avec un package de 60M, ça te fait 6 - 7 Go par an... Si ton application est vraiment critique, on ne va pas dire que c'est excessif.

    Bref, pour conclure : le tag est le plus important. Garder son binaire de production sur Nexus, c'est un plus, mais pas forcément indispensable.
    Nous sommes tous semblables, alors acceptons nos différences !
    --------------------------------------------------------------
    Liens : Blog | Page DVP | Twitter
    Articles : Hudson | Sonar | Outils de builds Java Maven 3 | Play! 1 | TeamCity| CitConf 2009
    Critiques : Apache Maven

  7. #7
    Membre chevronné
    Avatar de eulbobo
    Homme Profil pro
    Développeur Java
    Inscrit en
    Novembre 2003
    Messages
    786
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Novembre 2003
    Messages : 786
    Points : 1 993
    Points
    1 993
    Par défaut
    Citation Envoyé par romaintaz Voir le message
    Je suis d'accord que ce n'est pas le cas le plus fréquent, mais ça peut arriver, pour partager des ressources communes (JS, CSS, images, etc.) entre 2 applications différentes par exemple. Alors oui, on peut aussi les partager via un JAR, mais bon, ce n'est pas toujours optimal...
    Je suis pas persuadé de l'intérêt de la chose, sauf si effectivement tu as plein d'applications différentes avec exactement la même structure et les mêmes principes qui se reposent sur le même jeu de resources communes...
    Mais dans ce cas, j'aurai tendance à conseiller de mettre en place une application web qui contient les ressources, et que toutes les autres applications se basent dessus pour récupérer ce dont elles ont besoin pour bosser -> si tu as besoin de changer le graphisme, tu changes à un seul endroit et tout est changé de partout en n'ayant à ne redéployer qu'une application !
    J'ai dit que j'étais pas convaincu?

    (je fais de la mauvaise foi exprès, je vois bien l'intérêt du truc, je trouve juste qu'il est très limité et un peu dangereux)


    Hum. Je ne suis pas convaincu. Là tu dis que ça a foiré parce que le binaire a été déployé sur un OS qui a changé depuis la mise en prod originelle. Mais si tu rebuildes depuis le tag, ça change quoi au juste ? Vu que ton OS a quand même changé, donc tu auras là aussi le problème avec un build refait depuis un tag, non ? Le problème ici n'est pas le binaire mais l'environnement directement.
    Le cas est pourtant simple : tu as une application web et plusieurs environnements différents qui ne sont pas tous architecturés de la même façon (arborescence de fichiers par exemple, linux ou windows, ...). La configuration de certains éléments se faisait à la compilation en filtrant les fichiers dans resources afin de faire coller les variables à l'environnement sur lequel tu déploies. Le remplacement des variables se faisait à partir d'un fichier de configuration propre à chaque installation (bref, on avait complètement rendu abstraite la configuration de déploiement pour pouvoir) : le war doit donc être compilé sur le serveur qui l'exécutera (plus précisement, sur le serveur de batch qui sait sur quelle instance de tomcat il doit se brancher. La magie de maven, tu lui dit deploy et il va te créer ton war et l'installer tout seul sur le bon tomcat)

    Problème? il y avait eu un changement dans les répertoires du serveur de prod (ce qui avait provoqué d'autres soucis, d'où le besoin de faire un retour arrière sur une version. On aide la DSI qui impose des changements.)... Le war contenait l'ancienne configuration... Paf...
    Je ne suis pas mort, j'ai du travail !

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 2
    Dernier message: 17/10/2014, 11h13
  2. Je suis admin, mais je n'ai pas les droits.
    Par Stegue dans le forum Windows 7
    Réponses: 9
    Dernier message: 09/11/2010, 14h44
  3. Réponses: 0
    Dernier message: 04/02/2009, 12h14
  4. Eclipse ne détecte pas les jars "jdom" que j'ai ajouté
    Par samia13 dans le forum Eclipse Java
    Réponses: 6
    Dernier message: 14/11/2007, 19h10

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo