Reprise du message précédent :
han bien vu le coup de la map !
 
et oui en effet le getConstructor sert à rien...

c'est vraiment nécéssaire d'indiquer le nom des classes qui seront mappées par hibernate dans la déclaration du AnnotationSessionFactoryBean ??
 
je comprends pas l'intérêt si il y a déjà l'annotation @Entity

Il y a pas un truc pour choper les classes par package ?
 

Ce n'est pas parce que tu as @Entity que tu veux que ça soit forcement persisté (même si il y a de forte chance)

Bonsoir,
 
 
Vous conaissez une solution e-commerce genre magento mais pour java/java EE ?

Bonjour    
 
Une idée pour choper un taux de change en ligne?
 
Merci. a+

Question maven, je veux build un projet selon 3 profiles différents, et donc avoir 3 artifatcs.
Je défini <finalName>${project.artifactId}-${project.version}-${project.active-profile.id}</finalName>
 
Sauf que bien évidemment, c'est un exemple ici puisque ${project.active-profile.id} n'existe pas. Le ninternet conseille de créer pour chaque profil une variable tralala qui contiendra la valeur du suffixe, je trouve ça crado et redondant, l'id du profil m'allant très bien. Vous confirmez, autre chose ?

tu défini une variable dans le profile qui a pour valeur ${project.active-profile.id} ?  

bof, si tu demandes ce genre de trucs chez Sonatype par exemple, ils vont te dire de faire 3 projets. Je comprend leur démarche/mode de pensée, mais c'est juste pénible.
Perso je commence doucement à m'interesser a Gradle pour certains types de projets...

 
Ça limite pas mal l'intérêt des profiles quand même    

non, le profil (d'ou le nom) c'est pour configurer ton build suivant l'environment, pas pour commander le build. Un "mvn clean package" devrait produire le meme artifact partout, à tout moment. Forcer un profile avec -P, c'est "ok" pour des choses du genre "skip tests", "quick build" ou whatever, mais pas pour produire des artifacts differents. Idéalement, t'as un serveur de build qui fait les builds pour toi, pas un dev qui doit se souvenir quel profile activer suivant ce qu'il veut releaser.

Bin si je veux que mon serveur de build me génère X artifacts en fonction de X environnements différents, je fais comment ?

ben tu fais X projets.
L'environnement dont on parle quand on parle de "un profile pour un env différent", c'est l'environnement de BUILD, pas le TARGET.

Et: qqun a deja fait joujou avec javamail et imap ? Il semble que ce con mette le flag SEEN de mes mails a true systematiquement (pas pratique pour lister les mails non-lus, justement). Me semble qu'il y a une property pour éviter ce comportement, mais je remet pas la main dessus là.

X projets pour 3 variables qui changent dans un fichiers de conf, ça me parait stupide (le mode opératoire, je critique pas tes réponses hein ). D'autant que si je te suis bien J'aurais X projets sur Hudson, qui vont tous taper sur le même repo et pour lesquels j'appellerais des propriétés différentes au moyen de... profils ? J'ai l'impression qu'il me manque une brique là.

3 projets maven... probablement des sous projets d'un parent, donc possiblement 1 seul project dans ton CI.
J'ai qques trucs du genre ou les sous-projets (juste un pom) ne font que setter des properties dans le pom, et toute la config et tout le bordel se trouve dans le parent..

C'est pas Gizmo qui avait posé cette meme question sur imap y'a des mois ?

 
oui

 
oui

j'étais partis au début pour utiliser des profils

mais comme certains profils nécéssitaient des fichiers de config différent j'ai fait 1 projet normal qui build un package de dev, et 2 projets recette et prod qui dépendent du package dev, et qui sont en fait des overlays ne contenant que les fichiers qui sont différents (donc 3-4 fichiers).

du coup je génère le package de base $artifact qui s'installe dans le dépot maven
ensuite le build de prod et recette s'appuie sur $artifact et remplace que certains fichiers

ce qui est chiant c'est que ça impose de faire un build en plus, mais au final c'est nettement plus clair que des gérer des profils avec des variables qui rendent le pom.xml vite illisible

l'autre solution que j'utilisais passait quand même par les overlay, donc prod et recette étaient les packages que j'installais en premier dans maven, et le projet principal en héritait. Ca entraine un build de moins en général car ces fichiers changent pas souvent, mais ça augmente aussi les chances d'oublier de rebuilder et installer ces paquets, ce qui m'est déjà arrivé.

petite question sur l'utilisation d'un serveur tomcat avec eclipse
 
il y a la méthode par fichier de contexte dans le dossier de tomcat, l'avantage étant que le changement à chaud des classes et des jsp est bien géré
 
l'inconvénient c'est que pour faire ça il faut que le dossier WEB-INF/lib contienne les librairies et les classes dans WEB-INF/classes ce qui n'est pas le cas quand on a un projet maven
 
 
il y a la méthode par ajout de module dans le serveur tomcat par le plugin eclipse
l'inconvénient c'est que j'arrive pas à obtenir un changement des classes à chaud et des jsp sans que ça rédéploie toute l'appli

   
 
c-a-d ?

quand tu fais un mvn eclipse, le classpath du .project pointe sur les jar qui sont dans le dépot local maven et pas dans le WEB-INF/lib du projet. (ce dossier est vide)
et aussi le dossier output se trouve dans target/classes

mais j'ai trouvé la solution à mon problème, il faut cocher l'option "serve modules without publishing" et désactiver la publication automatique ainsi que le autoreload au niveau de la config du module, ça permet de changer les classes java et jsp à chaud dans éclipse en mode debug sans qu'il ai besoin de redéployer.

le plugins war, il crée un répertoire target/${artifactId}/ avec dedans le WEB-INF qui va bien (le répertoire classes et le répertoire lib)

bon les gens, un peu de sérieux, là.
 

ça n'a pas de rapport avec tomcat et la modification de classes à chaud

 
oui mais ça marche pas, je comprends pas pourquoi

 
Je suis pas très familier du concept de parent sous maven, j'ai fait quelques tests, l'arbo :
 
project
pom.xml => on va l'appeler pom racine
--src
--target
--site-a
----pom.xml
--site-b
----pom.xml
 
Dans le POM racine, j'ai les dépendances, la conf du build, des plugins en général. Pour info, c'est aussi mon projet tel qu'il était quand je me suis posé la question des profils.
Le POM des sites X défini le parent POM racine, ainsi que les propriétés en question. Comment à partir d'un POM fils je demande - proprement - de packager project-site-X, et donc de lancer les opérations de compil du parent et d'en "utiliser" le résultat ?
 
C'est de la question de noob, mais autant je capte la notion d'héritage des POM, autant la façon dont leur production est liée m'échappe.
 

 
Dans le principe ça rejoint ce qu'évoque --. Merci de ta réponse
 

ben tu demandes rien, tu buildes. soit tu buildes le tout (parent, site-a, site-b) depuis la racine ("reactor" ), soit tu buildes depuis un des sous projets.

bon ben je suis pas le seul à me poser la question:
http://stackoverflow.com/questions [...] n-iterable

wrappe.

Bon, désolé j'insiste, mais y'a un truc que je rate.

Si je veux que le parent <=> module fonctionne (i.e. déclencher le build à partir du POM racine), il me faut

<packaging>pom</packaging>
<modules>
    <module>site-a</module>
    ...
</modules>
<!-- Plus le reste, la liste des dépendances, la conf des plugins. Les sources sont aussi avec ce POM. -->

dans le parent et

<parent>
    <artifactId>project</artifactId>
    <groupId>group</groupId>
    <version>1.0</version>
</parent>
<!-- Et rien d'autre que les quelques properties en question. Le répertoire "site-x" (qui contient ce POM) n'a pas de sources ni rien d'autre. -->

pour les sites. Le hic, c'est que lorsque je lance les builds, les opérations partent bien dans les POM fils (je le vois bien à partir d'un fils lancer les opérations des plugins configurés à la racine par exemple), mais comme les sources sont sur le projet racine et que celui-ci a un packaging POM, elles sont ignorées. Résultat, dans les target des sites, je me retrouve par exemple avec un jar-with-dependencies qui contient toute les dépendances, mais pas les classes de mon projet. C'est ballot.

Les idées viennent à mesure que je rédige ce message : ou alors il me manque une brique. Un projet parent, et un module pour le code, puis X modules (sous modules du module code ou de la racine ?) pour chacun des sites ? Si c'est ça je ne vois pas comment les configurer...

Ha oui, en effet.
 

aneffé. 2 pistes:
- un module "partagé" (donc un 3e "child" dont dependent site-a et site-b)
- ou un hack à la mwinmwin:
 

• src/.. dans le parent

• dans le parent pom: build/sources/<directory>${basedir}/../src/main/java</directory>

... bon j'ai un doute en fait; ça marche pour les <resources> mais je sais plus si tu peux définir plusieurs dirs pour les sources. Dans tous les cas, si tu peux, un module séparé  pour le code partagé c'est mieux.

<packaging>pom</packaging>
<modules>
    <module>site-a</module>
    ...
</modules>
<!-- Plus le reste, la liste des dépendances, la conf des plugins. Les sources sont aussi avec ce POM. -->

<parent>
    <artifactId>project</artifactId>
    <groupId>group</groupId>
    <version>1.0</version>
</parent>
<!-- Et rien d'autre que les quelques properties en question. Le répertoire "site-x" (qui contient ce POM) n'a pas de sources ni rien d'autre. -->

c'est "normal" car pour chaque projet éclipse met les classes compilées que dans un seul dossier (le output dir)
 
dans le build path tu peux configurer un output folder spécifique pour chaque dossier de sources
mais si maven ne gère pas la configuration automatique alors c'est pas la peine
 
 
pour ma part je lance un maven externe en configurant des lanceurs dans les "outils externes"
j'aimerais savoir si je peux enchainer le lancement de plusieurs pom.xml de projets différents

Quelqu'un arrive à faire en sorte que CVS ignore le dossier /target ?

cvs l'enlève, mais si je rebuild alors il me remet le dossier et prétend qu'il est versionné

edit: bon un cvs release avec tortoise a résolu le problème

avec maven il y a moyen de cleaner le dossier de build du war, sans pour autant que maven vire toutes ses informations de cache qui sont stockées dans target ?

 
 
Je me retrouve avec :
project
-- pom
--project-jar
----pom
--site-a
----pom => qui ajoute le project-jar comme dépendance
 
Et apparemment, ça le fait. Ca m'ammène juste deux remarques :
- à propose de l'ordre des build "dispatchés, je suis pas sûr qu'il build bien la partie jar avant les sites X, ça peut être embêtant ;
- mon besoin de base c'était, grâce aux properties différentes selon les sites, de faire du flitering pour remplir un fichier properties commun. Ici, comme le filtering peut pas être fait sur un fichier de resource initialement présent dans le code du project-jar, j'ai mis un fichier de resources pas site, du coup les properties sont inutiles et j'ai donc juste un pom "vide" par site.
 
Merci à tous pour vos remarques ! Je suis quand même bluffé qu'un cas d'école comme ça ne se résolve pas plus facilement, c'est réellement particulier Maven....
 
 
 

 
http://maven.apache.org/plugins/ma [...] files.html
En jouant sur les excludes ?

L'ordre est déterminé par les dépendances.
 

si la seule diff entre site-a et site-b c'est un fichier de config a filtrer différement, tu peux le foutre dans le parent, avec l'astuce de sioux mentionnées plus haut, faire pointer un <resources> vers ../ (j'ai ça, ainsi qu'un <resources> qui pointe vers ../src/resources/${unePropertyDefinieDansLesChildren}/.. histoire de garder les configs proches l'unes de l'autre et donc d'avoir un seul dir avec toutes les configs, plus facile a gérer/comparer)

rm ?