Reprise du message précédent :

là je pense qu'il faut aller lire la spec, ça sent la morue ...

edit: ben ouais àvidemment ça passe dans la methode qui prend int

public class PouetTest {
    int x;

   @Test
    public void test() {
        pouet(x);
        pouet(1);
        int y = 4;
        pouet(y);
    }

   void pouet(int i) {
        System.out.println("Evidemment on est passé dans pouet(int) avec " + i);
    }

   void pouet(Integer i) {
        System.out.println("Merde, on est passé dans pouet(Integer) avec " + i);
    }
}

Sont pas aussi cons quand même.

import java.lang.Integer;
 
class Test {
    public static void main(String[] args) {
        final Test inst = new Test();
 
        inst.foo(inst.i);
        inst.foo((Integer)inst.i);
    }
 
    int i;
    Test() {}
    void foo(int var) {
        System.out.println("Int " + var);
    }
    void foo(Integer var) {
        System.out.println("Integer " + var);
    }
}

Nan mais je suis fatigué là, je pensais avoir ptet un cas particulier parce que mon int était pas initialisé mais zapan m'a rappelé qu'il était l'heure de rentrer.

Je débarque dans le Java et j'aurais une petite question à poser qui ne mérite sans doute pas un thread dédié
 
Je travaille sur un code dans lequel on sauvegarde des données à l'aide du package ZipFile et je me demande ce qui différencie une ZipEntry d'une autre. C'est uniquement la chaine de caractères qu'on passe au constructeur ? Auquel cas il faut faire attention à ne pas utiliser deux fois la même ? Ou il y a d'autres critères ?

http://download.oracle.com/javase/ [...] mmary.html ?

Oui je sais mais c'est pas franchement détaillé quoi

j'ai
- un projet A qui utilise spring 3.0 dans son pom en dépendance compile
- un projet B qui s'appuie sur spring 2.0 définis en dépendance compile
- un projet C qui s'appuie sur spring 2.0 définis en dépendance runtime
- B et C sont définis en dépendance de A dans le pom de A

- lors du eclipse:eclipse de A, B et C veulent remonter les dépendances spring, que je parviens à exclure
mais le jar spring 2.0 se retrouve quand même dans le class path à cause d'un des jar qui inclus la lib spring 2.0 à cause de la dépendance compile

Donc à priori c'est foutu et il faudrait tout migrer à la même version de spring aussi dans les dépendances non ?
En fait spring ne fonctionne pas correctement les annotations ne sont pas scannées etcetera, c'est pourtant une config qui fonctionne sur d'autres projets. Donc spring 2.0 semble prendre le pas sur le 3.0 au runtime.

<dependencyManagement>

John Gilbert « Jack » Layton, CP (né le 18 juillet 1950 à Montréal, Québec, mort le 22 août 2011 à Toronto, Ontario1) est un homme politique canadien, chef de l'opposition officielle à la Chambre des communes du Canada, du 2 mai 2011 à sa mort. Échevin et conseiller municipal de Toronto pendant les années 1980 et les années 1990, il était depuis 2003 le chef du Nouveau Parti démocratique du Canada (NPD), un parti politique considéré « de gauche » au Canada.
 
Fils d'un ministre progressiste-conservateur, Layton grandit à Hudson (Québec). Quand il arrive sur la scène publique municipale de Toronto, il est une des voix de gauche les plus fortes aux conseils municipal et métropolitain de la ville. En 1991, il se présente sans succès à la mairie de Toronto, mais devient plus tard chef de la Fédération canadienne des municipalités. En 2003, il est élu chef du NPD dès le premier tour. Sous sa chefferie, le NPD agrandit son appui de façon considérable : ses appuis doublent lors de l'élection de 2004 et il détient la balance du pouvoir sous Paul Martin. Layton est alors élu député de la circonscription de Toronto-Danforth. Le NPD obtient des amendements majeurs, de teneur social-démocrate, au budget de 2005, qui sera surnommé « le premier budget néo-démocrate », mais fait chuter le gouvernement libéral suite au scandale des commandites.
 
Le NPD obtient encore plus de gains en 2006 et 2008, frôlant ses sommets historiques des années 1980 sous le chef Ed Broadbent. Mais il coiffe de loin cette réussite en 2011, mettant fin de façon spectaculaire à sa faiblesse historique au Québec, gagnant 103 sièges et devenant l'opposition officielle. Ce succès électoral sans précédent fait de Jack Layton le chef qui a le mieux réussi de l'histoire du NPD. Moins de quatre mois après cette victoire, il meurt des suites d'un cancer, à l'âge de 61 ans.

+1

ils sont bien exclus au niveau maven, un mvn depency:tree me le confirme
j'ai l'impression que c'est la dépendance projet au niveau éclipse qui me les inclus dans le classpath

Merde, je pensais être dans le topic du presse papier à cause du commentaire de moinmoin

bon je sèche, je comprends d'ailleurs pas comment ça peut fonctionner

j'ai besoin d'avoir le projet en question en dépendance de mon projet, et ce au niveau d'éclipse, sinon j'ai des erreurs de compil

je pensais qu'avoir le jar du projet dans mon classpath suffirait pour que mon projet compile

EDIT1:
j'ai listé le clasppath avec
final java.lang.String list = java.lang.System.getProperty("java.class.path" );

et il me met toujours spring 2.0 dedans
je vois pas comment le bloquer, car mon depency tree lui me montre bien qu'il est pas inclus

et qui plus en plus il me colle deux version différente

C:\Documents and Settings\xxxxxxxxx\.m2\repository\org\springframework\spring\2.0.4\spring-2.0.4.jar
C:\Documents and Settings\xxxxxxxxx\.m2\repository\org\springframework\spring\2.0.8\spring-2.0.8.jar

mais peut être que ce que tu m'as indiqué permet de le faire, c'est juste que pour l'instant j'ai pas l'impression que c'est maven qui fait chier, mais plutot eclipse
qui met dans le classpath les dépendances des projets ouverts dont mon projet dépend.

EDIT2 : bon en fait eclipse:eclipse me rajoute des dépendances projet dans mon .project

 <projects>
    <project>projetB</project>
    <project>projetC</project>
  </projects>

alors que j'ai une dépendance classique dans mon pom sur des jars de ces projets qui sont installés dans le depot maven

Je voudrais qu'il m'ajoute les jars en "referenced libraries", mais eclipse référence directement les projets.
donc c'est forcément le plugin maven qui en est la cause
mais j'ai pas trouvé encore ce qui permet d'avoir une dépendance de jar et non de projet

ayé j'ai trouvé -Declipse.useProjectReferences=false !

edit: cependant quand je lance mon main eclipse inclu pas automatiquement le classpath du output folder, comment se fesse ?

edit2: 'tain c'est pas vrai, il m'exclu mon applicationContext.xml du classpath

edit3: ha tiens cette fois c'est pas eclipse c'est un collègue !!

edit4: mais qu'est ce qu'il a fait

edit5: allez hop ça vire

j'ai un autre soucis
j'ajoute ces dépedances

 
maven eclipse:eclipse semble bien les ajouter, y compris en regardant avec l'option debug -X , tout comme le mvn depency:tree , mais dans le .classpath généré, et donc dans les référenced libraries, point de aspectj.
 
si je fais un pom avec seulement ces deux libs, ça ne fonctionne pas non plus, pourtant j'ai déjà utilisé une config identique
 
edit :

ces 2 artefacts sont spécifiquement exclus par maven
ils sont malades de faire des trucs comme ça  

Du peu que je comprend c'est pas exclu, mais c'est ajdt (plugins eclipse), via ce mécanisme, qui prend la gestion de la partie aspect.  
http://maven.apache.org/plugins/ma [...] jects.html
 
 

ok mais spring utilise ces libs de façon classique sans ajdt

ici il faut mettre ajdtVersion=none pour obtenir le comportement par défaut
le comportement par défaut devrait être quand l'option ajdtVersion n'est utilisée nulle part

d'ailleurs un bug a été ouvert dessus http://jira.codehaus.org/browse/MECLIPSE-594

Question Maven 2 encore, j'ai un projet avec un POM parent et X modules. Je veux que les modules aient la même version que le parent direct, et ce automatiquement. Pour ça, il existe le plugin versions avec le goal update-child-modules, sauf que le goal ne fonctionne que sur invocation directe, je peux pas binder ça à une quelconque phase.
Ça me plait pas, je veux automatiser ça pour que si quelqu'un oublie de mettre à jour le numéro de version d'un des modules, ça ait quand même le comportement attendu.
 
Des idées ?

ben tu spécifies pas de <version> dans les enfants, dugenoux

ça n'a rien d'évident

 
Je me suis mal exprimé
Pour la version des modules OK, c'est ce que tu évoques, mais mon problème est - comme ma question ne l'indiquait pas - au niveau du setting du projet parent.
 
Soit parent :

<groupId>com.foo</groupId>
<artifactId>parent</artifactId>
<version>1.6.0-SNAPSHOT</version>
<modules>
    <module>child</module>
</modules>

 
Et le module child qui, si je veux qu'il retrouve ses petits, doit avoir la version du pom parent inscrite en dur :

<parent>
    <groupId>com.foo</groupId>
    <artifactId>parent</artifactId>
    <version>1.6.0-SNAPSHOT</version>
</parent>
<artifactId>child</artifactId>

 
J'ai essayé également en settant une property dans le parent, genre :

<properties>
        <submodules-version>1.6.0-SNAPSHOT</submodules-version>
    </properties>

 
Et ça fonctionne, sauf que pour bien faire, je voulais histoire de pas avoir la même info deux fois écrire :

<properties>
        <submodules-version>${project.version}</submodules-version>
    </properties>

Mais c'est là que ça coince, il faut la variable en dur sinon il ne résoud pas. D'où mon passage au plugin versions qui répond à mon besoin sans bricolage, mais que je ne peut binder au build.

je croyais que c'était toi qui avait posé la question
 
(et c'est qd meme l'exemple de base du reactor/multi-module dans la doc...)

je suis tjs pas sûr d'avoir compris ce que tu veux faire / pourquoi (y'avait une mouche dans mon croissant, du coup je suis pas bien réveillé), mais... si ton parent et ses "enfants" n'ont pas le meme lifecycle, je te conseillerais de... ben de pas en faire un reactor, justement.
S'ils ont le meme lc et que tout ce qui t'emmerde c'est d'avoir la version du parent dans les enfants... je comprend la frustration, mais y'a pas gd chose à y faire. Si le prob vient du moment ou tu changes de version, je suppute que c'est parce que tu n'utilises pas le release plugin pour faire tes releases ?

C'est exactement ça, et Maven 3 a une solution pour ça (kinda) avec le versionless parent submodules :

Sauf que Maven 2...
 
D'autant que le besoin est pas si exotique puisque le plugin se charge de cette tâche, c'est juste que je voudrais automatiser plutôt qu'avoir un simple assistant lors des changements de versions.

mais tu changes de version quand ?

Généralement post release, ça peut aussi arriver qu'on bascule de snapshot a snapshot + 1 directement (des cas particuliers où quelqu'un à mis le brin dans les dépendances).

et euh tu fais pas tes releases avec le plugin idoine ?

Nope, j'étais en train de jeter un œil. J'imagine donc que tu vas me dire que si je l'utliisais, c'est lui qui m'updaterait mes version en post release ? Donc en l'état, je suis fucké ?

oui, il ferait ça et plein d'autres choses. Pour peu que ton build soit stable et +/-reproductible (i.e si tu fais rien d'autres que "mvn clean deploy" quand tu releases), ça devrait te faciliter la vie, ET apporter des bonus
(genre a moins que tu te fasses chier a modifier les <scm> a la main quand tu releases, tu pourrais "checkout dependency into project"...)

 
C'est effectivement rien de plus que Hudson qui checkout les sources + clean deploy, donc je vais y réfléchir plus que sérieusement. Y'a un peu de taff quand même pour basculer tous les projets et surtout se familiariser avec le plugin.
 
Tu peux détailler le "checkout dependency into project", j'ai pas capté par contre
 

euh ouais j'ai tapé ça en vitesse.. en fait ça manque dans intellij, mais dans eclipse y'a ça: tu right-click une maven-dependency de ton projet, et y'a une option pour checkouter le projet et l'ajouter au workspace.
(vu que y'a les infos de scm dans le pom, qui est à coté du jar que mvn a téléchargé)
 
Sinon pour Hudson, c'est pas une mauvaise voie non plus, mais moi je penche vers l'addition des deux: en fait y'a un plugin hudson/jenkins qui fait la release. Et si je ne m'abuse il délègue au plugin maven:release, mais l'avantage étant que ça bloque pas ton poste et que c'est buildé sur le meme systeme que ton CI

Très bon, mais je suis efefctivement sous Intellij.
 

 
J'vais abuser et te demander le nom du plugin que tu utilises, y'en a 4 ou 5 qui se baladent avec des M2 Release et autre Release tout court.
 

http://youtrack.jetbrains.net/issue/IDEA-72871

j'utilise pas encore
je crois que c'est "m2 release" effectivement...

, merci pour toutes les infos.

bon piske t'es là. Je bute sur un probleme a la con avec intellij. Dans un projet avec une webapp, quand je fais "compile" sur une resource (un .ftl) qui se trouve dans un autre module, il la copie dans la webapp, mais pas dans le target/ du module en question (cfr logs), du coup la resource est pas reloadée (...long story).
 
Quand j'ouvre le meme module dans un projet indépendent de la webapp, alors la resource est copiée au bon endroit.  (et l'option est  "compile file", alors que dans le 1er projet, l'option en right click est "package file" )...

J'avions pas vu ta réponse, et je suis plus au taff.
A tout hasard, dans la conf du module qui pose problème, ton répertoire est bien identifié en tant que resources directory ?
Sur des projets avec submodules avec une arborescence un peu tordu, il m'a déjà fait des coups de ce type.

J'ai jamais vu de diff entre sources et resources dans idea? Sinon j'ai créé un topic sur leur forum; si ça t'intéresse, vu que tu connais mon nom tu devrais trouver

Oui, je parlais bien de les flagguer en tant que sources, excuse. D'un autre côté je viens de vérifier, et j'ai des projets où les ressources ne sont pas flaggées en source dans le menu Module Settings mais qui ont l’icône, donc je penche plus vers une mauvaise détection des arbo exotiques sur les projets mavenifiés.
Edit : je viens de lire ton topac, je comprend un peu mieux le truc et du coup, je pense que mes remarques sont complètement à côté de la plaque. A tout hasard et pour lever le doute là dessus, t'as essayé sur un projet Idea classique (i.e. sans support Maven, structure classique gérée par l'IDE) ?