solution 1
----------------
try... standard OO principles to encapsulate the depedency you wish to mask
and use excludes to keep it from the war
e.g.
war -> b -> a
gives you
war(a,b)
to
war -> c -> (exlude a) b ->a
gives you
war(c,b)
c can be a jar or even just a pom project, jars are better cause you end up
with the pom.properties which can be useful for knowing exactly what a
deployed war contains
Personally I've only had trouble with the provided target. The key failing for
me is that a war should theoretically be portable and as such you don't know
whats provided until later... And really you should be able to bundle all you
libraries as the container reads bottom up... commons logging breaks this
though which is why i use slf4j
solution 2
--------------
produce the war (a) as an underlay by excluding all the jars from it...
<groupId>a.b.c</groupId>
<artifactid>a.b.c.web</artifactId>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<archiveClasses>true</archiveClasses>
<classifier>underlay/classifier>
<warSourceExcludes>WEB-INF/lib/*.jar</warSourceExcludes>
</configuration>
<executions>
<execution>
<goals>
<goal>war</goal>
</goals>
</execution>
</executions>
</plugin>
create a new war for the specific target e.g. tomcat that depends upon the
underlay + its primary jar (needed for transitions)
<groupId>a.b.c</groupId>
<artifactId>a.b.c.web.tomcat</artifactId>
<dependencies>
<dependency>
<groupId>a.b.c</groupId>
<artifactid>a.b.c.web</artifactId>
<version>X</version>
</dependency>
<dependency>
<groupId>a.b.c</groupId>
<artifactid>a.b.c.web</artifactId>
<version>X</version>
<classifier>underlay</classifier>
</dependency>
</dependencies>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<warSourceExcludes>WEB-INF/lib/***provided jar name
here***.jar</warSourceExcludes>
</configuration>
<executions>
<execution>
<goals>
<goal>war</goal>
</goals>
</execution>
</executions>
</plugin>
On Wednesday 26 September 2007 04:24, aldana wrote:
> hi,
>
> i am deploying an axis2 app to tomcat. i need some libraries for compile
> time but do not need to package them because they are provided by
> webapp-container. that's why i use <scope>provided</scope>. in my case this
> is for instance:
>
> <dependency>
> <groupId>org.apache.ws.commons.neethi</groupId>
> <artifactId>neethi</artifactId>
> <version>2.0</version>
> <optional>true</optional>
> <scope>provided</scope>
> </dependency>
>
>
> neethi gets excluded in package-phase but very unfortunately the transitive
> dependencies from neethi get included :( this is not what i want: when
> marking a dependency as provided of course transitive dependencies should
> not be included either for they are provided from container already...
>
> what am i doing wrong? is there another way to achieve this or do i
> misunderstand the use of scope-provided?
>
> thanks.
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
