Hello,
config:
maven-eclipse-plugin 2.7
eclipse 3.4
We have a multiproject where the war module depends of EJB module.
On the WAR pom:
<dependency>
<groupId>jade.framework.showcase</groupId>
<artifactId>showcase-ejb</artifactId>
<version>${pom.version}</version>
<type>ejb</type>
</dependency>
When we run the task eclipse:clean eclipse:eclipse using the
eclipse-maven-plugin, the "java EE Module Dependencies" of the WAR eclipse
project is missing the dependency to the EJB module. We have add the check box
by hand ( project properties/ java EE Module Dependencies/ check the checkbox
of the ejb module), which is a bit of a pain.
This java EE dependence is important for the Webapp to work when run on our
Eclipse configured Tomcat server.
I couldn't find any plugin option to switch this on automatically.
Thanks for your help.
antonio
-----Message d'origine-----
De : Benson Margulies [mailto:[email protected]]
Envoyé : mardi, 3. novembre 2009 11:53
À : PAROLINI Antonio; Maven Users List
Objet : Re: tracking down jetty/tomcat dependencies
I'm still wishing that someone could help me figure out just what is on the
classpath inside of tomcat:run.
To a first approximation, jetty:run and tomcat:run had the same problem.
However, I was a able to cure it in jetty and not in tomcat. It LOOKS as if
tomcat is depending on an old version of Xalan.
On Fri, Oct 30, 2009 at 5:16 AM, Benson Margulies <[email protected]>wrote:
> I wrote it up on the mojo user list once I got a clearer picture, but here
> goes again.
>
> The code calls DocumentBuilderFactory and SchemaFactory to parse an XML
> file to DOM with schema validation. Run in the plugins, it fails with an
> impossible validation error (a claim that a valid attribute is invalid). The
> backtrace shows a combination of xerces and JDK classes. I have xerces in
> the webapp's class path.
>
> The same code works fine, with or without xerces, run as a pojo or a junit
> test.
>
> If I try to use 100% Xerces by referring to their implementation classes
> (DocumentBuilderImpl and XMLSchemaFactory) it still fails in the plugins.
>
> The problem goes away if I use the new JAXP 1.4 APIs to force the use of
> Xerces.
>
> I reason as follows: in a live copy of tomcat or jetty, the 'system'
> classpath is whatever jars are sitting in the containers system library
> directory. When these plugins deploy a webapp, they don't have a system
> library directory. They instead have whatever classpath maven invokes them
> with, based on their declared dependencies and the transitive closure that
> reaches into plexus and such. There could easily be some ancient xml-apis
> jar in there, or some other source of interference, which I am not
> preempting in my webapp.
>
> If dependency:tree worked for a plugin classpath, then I might be able to
> figure out the real source of the problem and fix it by tinkering with
> dependencies on the plugin. But I can't figure out how to get a full tree
> for maven-tomcat-plugin (e.g.).
>
>
> On Thu, Oct 29, 2009 at 10:32 PM, Brett Randall <[email protected]>wrote:
>
>> On Fri, Oct 30, 2009 at 6:45 AM, Benson Margulies <[email protected]
>> >wrote:
>>
>> > I've got code that works fine when run as a pojo and fails when run in a
>> > webapp, either via tomcat:run or jetty:run. I suspect, because I can't
>> > think
>> > of anything else, that there is detritus in the 'system' classpaths of
>> > these
>> > containers. However, mvn dependency:tree does not tell me much about the
>> > maven-jetty-plugin. Neither does dependency:resolve-plugins.
>> >
>> > Is there some way to get a clearer view of this question?
>> >
>>
>> What is the mode of failure?
>>
>> Brett
>>
>
>
