JAR subtraction from webapp WEB-INF/lib / forcing 'provided' on a list of artifacts

[bimargulies]

I have a webapp that runs in Jetty and Tomcat. To make it run cleanly in
JBoss, I need to subtract some jar files from the dependency graph.

Unless I'm confused, this is going to take a lot of  POM XML, because those
jars are in the graph of several of my dependencies.

So, I'm wondering: is there any other declarative mechanism for forcing
'provided' scope? Can dependencyManagement do this?

Alternatively, is there some large hammer to be had at the point of WAR
packaging that would allow me to filter?

[Jesse Farinacci]

Hi Benson,

On Wed, Nov 4, 2009 at 8:03 AM, Benson Margulies <bimargulies@...> wrote:

> I have a webapp that runs in Jetty and Tomcat. To make it run cleanly in
> JBoss, I need to subtract some jar files from the dependency graph.
>
> Unless I'm confused, this is going to take a lot of  POM XML, because those
> jars are in the graph of several of my dependencies.
>
> So, I'm wondering: is there any other declarative mechanism for forcing
> 'provided' scope? Can dependencyManagement do this?
>
> Alternatively, is there some large hammer to be had at the point of WAR
> packaging that would allow me to filter?
>

Just something I've been toying with in my mind, without doing any
sort of actual testing, is... Have the top level corporate pom define
all of these types of dependencies as scope=provided. Then have child
modules for each of the containers I could ever want to support (we
use Jetty and Tomcat both, and are being asked to evaluate Websphere).
These modules would have no actual code, but would be a set of
dependencies with different scopes depending on what the container
provides and what is required, to escalate the scope level beyond what
the corporate pom has in dependencyManagement. Profile activation
would then pull in one of these container modules which would trigger
transitive dependencies at the right scope.

-Jesse

--
There are 10 types of people in this world, those
that can read binary and those that can not.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[bimargulies]

The problem is that it's not quite 'corporate'. The problem is this: you can
build a webapp with CXF services that is self-contained on Jetty and tomcat.
Then, to get it to run on JBoss, you want to start subtracting. OK, well, a
profile that subtracts. If the profile can just use dependency-management to
mark these guys 'provided', fine.

On Wed, Nov 4, 2009 at 8:15 AM, Jesse Farinacci <jieryn@...> wrote:

> Hi Benson,
>
> On Wed, Nov 4, 2009 at 8:03 AM, Benson Margulies <bimargulies@...>
> wrote:
> > I have a webapp that runs in Jetty and Tomcat. To make it run cleanly in
> > JBoss, I need to subtract some jar files from the dependency graph.
> >
> > Unless I'm confused, this is going to take a lot of  POM XML, because
> those
> > jars are in the graph of several of my dependencies.
> >
> > So, I'm wondering: is there any other declarative mechanism for forcing
> > 'provided' scope? Can dependencyManagement do this?
> >
> > Alternatively, is there some large hammer to be had at the point of WAR
> > packaging that would allow me to filter?
> >
>
> Just something I've been toying with in my mind, without doing any
> sort of actual testing, is... Have the top level corporate pom define
> all of these types of dependencies as scope=provided. Then have child
> modules for each of the containers I could ever want to support (we
> use Jetty and Tomcat both, and are being asked to evaluate Websphere).
> These modules would have no actual code, but would be a set of
> dependencies with different scopes depending on what the container
> provides and what is required, to escalate the scope level beyond what
> the corporate pom has in dependencyManagement. Profile activation
> would then pull in one of these container modules which would trigger
> transitive dependencies at the right scope.
>
> -Jesse
>
> --
> There are 10 types of people in this world, those
> that can read binary and those that can not.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[Jesse Farinacci]

Benson,

On Wed, Nov 4, 2009 at 8:22 AM, Benson Margulies <bimargulies@...> wrote:
> The problem is that it's not quite 'corporate'. The problem is this: you can
> build a webapp with CXF services that is self-contained on Jetty and tomcat.
> Then, to get it to run on JBoss, you want to start subtracting. OK, well, a
> profile that subtracts. If the profile can just use dependency-management to
> mark these guys 'provided', fine.
>

Sorry, you've missed the point entirely. I have a top level
corporate-wide "super" POM which mostly just manages a giant
dependencyManagement section. You don't have to be a corporate user to
have something like this in place, all advanced Maven projects I've
ever encountered do this...

Anyhow, create separate modules like jetty-dependencies,
tomcat-dependencies, jboss-dependencies, which have all the correctly
scoped dependencies in them, perhaps you'd even want to attach some
m-enforcer-p checks to verify stage that nothing has slipped in. Then
use a profile to depend on the proper container-dependencies module.

As for exclusions, I'm really not sure what kind of things would be
causing problems.. Can you give an example?

-Jesse

--
There are 10 types of people in this world, those
that can read binary and those that can not.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[bimargulies]

I see, if you mean a set of profiles, each with a dependencyManagement
that makes some things 'provided', then I'm following, and that is
what I need.

On Wed, Nov 4, 2009 at 8:32 AM, Jesse Farinacci <jieryn@...> wrote:

> Benson,
>
> On Wed, Nov 4, 2009 at 8:22 AM, Benson Margulies <bimargulies@...> wrote:
>> The problem is that it's not quite 'corporate'. The problem is this: you can
>> build a webapp with CXF services that is self-contained on Jetty and tomcat.
>> Then, to get it to run on JBoss, you want to start subtracting. OK, well, a
>> profile that subtracts. If the profile can just use dependency-management to
>> mark these guys 'provided', fine.
>>
>
> Sorry, you've missed the point entirely. I have a top level
> corporate-wide "super" POM which mostly just manages a giant
> dependencyManagement section. You don't have to be a corporate user to
> have something like this in place, all advanced Maven projects I've
> ever encountered do this...
>
> Anyhow, create separate modules like jetty-dependencies,
> tomcat-dependencies, jboss-dependencies, which have all the correctly
> scoped dependencies in them, perhaps you'd even want to attach some
> m-enforcer-p checks to verify stage that nothing has slipped in. Then
> use a profile to depend on the proper container-dependencies module.
>
> As for exclusions, I'm really not sure what kind of things would be
> causing problems.. Can you give an example?
>
> -Jesse
>
> --
> There are 10 types of people in this world, those
> that can read binary and those that can not.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jesse Farinacci]

Hi Benson,

On Wed, Nov 4, 2009 at 8:39 AM, Benson Margulies <bimargulies@...> wrote:
> I see, if you mean a set of profiles, each with a dependencyManagement
> that makes some things 'provided', then I'm following, and that is
> what I need.
>

No, that isn't what I mean. I would have a profile for each container
I was interested in supporting. That profile would add a dependency
(not dependencyManagement) on the corresponding module
${container}-dependencies. This module would specifically depend on
whatever it needed. I suspect this could be handled within the profile
itself, but I am a module-happy kind of guy.. :-)

As far as exclusions go, there is no way to ban a dependency at the
top level. You must list exclusions manually, for each dependency. I
believe that Maven 3 may be attempting to remedy this.

-Jesse

--
There are 10 types of people in this world, those
that can read binary and those that can not.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[bimargulies]

Ah, I can't use your suggestion. CXF itself has all these dependencies
that have to be trimmed for some containers. I'll just have to make
all the exclusions.

On Wed, Nov 4, 2009 at 8:49 AM, Jesse Farinacci <jieryn@...> wrote:

> Hi Benson,
>
> On Wed, Nov 4, 2009 at 8:39 AM, Benson Margulies <bimargulies@...> wrote:
>> I see, if you mean a set of profiles, each with a dependencyManagement
>> that makes some things 'provided', then I'm following, and that is
>> what I need.
>>
>
> No, that isn't what I mean. I would have a profile for each container
> I was interested in supporting. That profile would add a dependency
> (not dependencyManagement) on the corresponding module
> ${container}-dependencies. This module would specifically depend on
> whatever it needed. I suspect this could be handled within the profile
> itself, but I am a module-happy kind of guy.. :-)
>
> As far as exclusions go, there is no way to ban a dependency at the
> top level. You must list exclusions manually, for each dependency. I
> believe that Maven 3 may be attempting to remedy this.
>
> -Jesse
>
> --
> There are 10 types of people in this world, those
> that can read binary and those that can not.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Tomas-35]

We do something like this in a profile:

                    <!-- Generate JBoss artifact -->
                    <!--
                        We generate another war with 'jboss' classifier,
                        excluding some jars from WEB-INF/lib
                    -->
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-war-plugin</artifactId>
                        <executions>
                            <execution>
                                <id>jboss-war</id>
                                <phase>package</phase>
                                <goals>
                                    <goal>war</goal>
                                </goals>
                                <configuration>
                                    <classifier>jboss</classifier>
                                    <packagingExcludes>WEB-INF/lib/xml-apis-*.jar,WEB-INF/lib/jsf-api-*.jar,WEB-INF/lib/jsf-impl-*.jar</packagingExcludes>
                                </configuration>
                            </execution>
                        </executions>
                    </plugin>

It's not pretty, but it works.
HTH,
Tomás




________________________________
From: Benson Margulies <bimargulies@...>
To: Maven Users List <users@...>
Sent: Wed, November 4, 2009 3:25:39 PM
Subject: Re: JAR subtraction from webapp WEB-INF/lib / forcing 'provided' on a  list of artifacts

Ah, I can't use your suggestion. CXF itself has all these dependencies
that have to be trimmed for some containers. I'll just have to make
all the exclusions.

On Wed, Nov 4, 2009 at 8:49 AM, Jesse Farinacci <jieryn@...> wrote:

> Hi Benson,
>
> On Wed, Nov 4, 2009 at 8:39 AM, Benson Margulies <bimargulies@...> wrote:
>> I see, if you mean a set of profiles, each with a dependencyManagement
>> that makes some things 'provided', then I'm following, and that is
>> what I need.
>>
>
> No, that isn't what I mean. I would have a profile for each container
> I was interested in supporting. That profile would add a dependency
> (not dependencyManagement) on the corresponding module
> ${container}-dependencies. This module would specifically depend on
> whatever it needed. I suspect this could be handled within the profile
> itself, but I am a module-happy kind of guy.. :-)
>
> As far as exclusions go, there is no way to ban a dependency at the
> top level. You must list exclusions manually, for each dependency. I
> believe that Maven 3 may be attempting to remedy this.
>
> -Jesse
>
> --
> There are 10 types of people in this world, those
> that can read binary and those that can not.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[bimargulies]

BIngo! Thanks!

On Wed, Nov 4, 2009 at 5:27 PM, Tomas Pollak <tomas_pollak@...> wrote:

> We do something like this in a profile:
>
>                    <!-- Generate JBoss artifact -->
>                    <!--
>                        We generate another war with 'jboss' classifier,
>                        excluding some jars from WEB-INF/lib
>                    -->
>                    <plugin>
>                        <groupId>org.apache.maven.plugins</groupId>
>                        <artifactId>maven-war-plugin</artifactId>
>                        <executions>
>                            <execution>
>                                <id>jboss-war</id>
>                                <phase>package</phase>
>                                <goals>
>                                    <goal>war</goal>
>                                </goals>
>                                <configuration>
>                                    <classifier>jboss</classifier>
>                                    <packagingExcludes>WEB-INF/lib/xml-apis-*.jar,WEB-INF/lib/jsf-api-*.jar,WEB-INF/lib/jsf-impl-*.jar</packagingExcludes>
>                                </configuration>
>                            </execution>
>                        </executions>
>                    </plugin>
>
> It's not pretty, but it works.
> HTH,
> Tomás
>
>
>
>
> ________________________________
> From: Benson Margulies <bimargulies@...>
> To: Maven Users List <users@...>
> Sent: Wed, November 4, 2009 3:25:39 PM
> Subject: Re: JAR subtraction from webapp WEB-INF/lib / forcing 'provided' on a  list of artifacts
>
> Ah, I can't use your suggestion. CXF itself has all these dependencies
> that have to be trimmed for some containers. I'll just have to make
> all the exclusions.
>
> On Wed, Nov 4, 2009 at 8:49 AM, Jesse Farinacci <jieryn@...> wrote:
>> Hi Benson,
>>
>> On Wed, Nov 4, 2009 at 8:39 AM, Benson Margulies <bimargulies@...> wrote:
>>> I see, if you mean a set of profiles, each with a dependencyManagement
>>> that makes some things 'provided', then I'm following, and that is
>>> what I need.
>>>
>>
>> No, that isn't what I mean. I would have a profile for each container
>> I was interested in supporting. That profile would add a dependency
>> (not dependencyManagement) on the corresponding module
>> ${container}-dependencies. This module would specifically depend on
>> whatever it needed. I suspect this could be handled within the profile
>> itself, but I am a module-happy kind of guy.. :-)
>>
>> As far as exclusions go, there is no way to ban a dependency at the
>> top level. You must list exclusions manually, for each dependency. I
>> believe that Maven 3 may be attempting to remedy this.
>>
>> -Jesse
>>
>> --
>> There are 10 types of people in this world, those
>> that can read binary and those that can not.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...