Pourquoi le plugin maven eclipse brise-t-il le plugin maven jetty?

Question

Je voudrais avoir le plugin Eclipse Maven régénèrent mon .classpath chaque fois qu'une construction est exécuté, et je l'ai fait en utilisant la configuration suivante:

<!-- 
     Generate a new .classpath each time the build is run, but don't try 
     to download sources or javadocs 
    --> 
    <profile> 
     <id>elipse-update</id> 
     <activation> 
      <file> 
       <exists>.classpath</exists> 
      </file> 
     </activation> 
     <build> 
      <plugins> 
       <plugin> 
        <artifactId>maven-eclipse-plugin</artifactId> 
        <executions> 
         <execution> 
          <phase>generate-sources</phase> 
          <goals> 
           <goal>eclipse</goal> 
          </goals> 
          <configuration> 
           <downloadSources>false</downloadSources> 
           <downloadJavadocs>false</downloadJavadocs> 
          </configuration> 
         </execution> 
        </executions> 
       </plugin> 
      </plugins> 
     </build> 
    </profile> 

Pour une raison quelconque, cela provoque le plugin jetée maven à l'échec avec des erreurs ClassNotFoundException (il se plaint de toutes sortes de classes Spring qui ne sont pas là). Bien sûr, cela n'a pas fonctionné quand je n'ai pas installé le plugin maven eclipse. Voici un exemple de ce dont je parle:

$ mvn jetty:run 
[INFO] Scanning for projects... 
... 
[INFO] Starting jetty 6.1.22 ... 
2010-02-11 20:53:08.984:INFO::jetty-6.1.22 
2010-02-11 20:53:09.109:WARN::Could not instantiate listener org.springframework.web.context.ContextLoaderListener 
java.lang.ClassNotFoundException: org.springframework.web.context.ContextLoaderListener 
     at java.net.URLClassLoader$1.run(URLClassLoader.java:200) 
     at java.security.AccessController.doPrivileged(Native Method) 
     at java.net.URLClassLoader.findClass(URLClassLoader.java:188) 
     at java.lang.ClassLoader.loadClass(ClassLoader.java:306) 
     at org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195) 
     at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255) 
     at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274) 
     at org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214) 
     at java.lang.ClassLoader.loadClass(ClassLoader.java:251) 

Bien sûr, si je supprime cette section plugin Eclipse, je peux courir jetée comme prévu:

$ mvn jetty:run 
[INFO] Scanning for projects... 
... 
Feb 11, 2010 8:55:28 PM org.springframework.web.context.ContextLoader initWebApplicationContext 
INFO: Root WebApplicationContext: initialization completed in 1672 ms 
2010-02-11 20:55:28.687:INFO::Started SelectChannelConnector@0.0.0.0:8080 
[INFO] Started Jetty Server 
[INFO] Starting scanner at interval of 5 seconds. 

Quelques choses que je sais:

• Oui, j'active uniquement ce profil si le chemin .classpath est présent. Cela semble contre-intuitif, mais j'ai une raison: J'ai un autre profil qui s'active quand .classpath est absent ce qui exécute le plugin eclipse avec les options pour télécharger le code source et javadocs mis à vrai. Je ne veux pas que cela se produise à chaque build, donc j'ai créé une configuration de plugin séparée pour quand le classpath est déjà là.
• Oui, je pourrais simplement créer des propriétés qui contiennent les valeurs des options que je souhaite changer au lieu de spécifier à nouveau la configuration complète du plugin. Dans ce cas, je voudrais simplement définir une propriété eclipse.downloadSources sur true ou false en fonction de la présence du classpath et avoir une seule définition de plugin dans la section de construction standard.

Un conseil? C'est un problème étrange.

Merci, LES

Answer 1

Je soupçonne que le plugin Maven Eclipse mess fait du classpath woodo qui affecte le plugin jetty plus tard.

Mais pour être honnête, ce n'est pas une manière très courante d'utiliser le plugin Eclipse, du moins pas à ma connaissance. La plupart des gens ne l'incluent pas dans leur construction, ils l'exécutent juste quand le POM a changé et ceci ne se produit généralement pas chaque build. De plus, toucher le .classpath confond Eclipse si je me souviens bien et force une reconstruction propre du projet ce qui est assez ennuyeux. Donc, à la fin, et je suis désolé pour cela, cela semble introduire plus de désagréments que d'avantages. Vous pouvez essayer d'ouvrir un Jira issue cependant.

Answer 2

Vous ne voulez pas vraiment exécuter le maven-plugin Eclipse sur chaque build quand il y a un cadeau .classpath. Je ne peux pas vous dire exactement ce qu'il fait aux classpaths, mais ce n'est pas la façon dont il est destiné à être utilisé. L'hypothèse est que lorsque vous l'exécutez, vous exécutez uniquement eclipse: eclipse (ou un autre objectif).

Pourquoi voulez-vous continuer à le faire fonctionner?