You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Steve Prior <sp...@geekster.com> on 2011/07/24 17:12:04 UTC
container supplied jars excluded in ivy
I'm using Ivy to build libraries which can either be used from the command line
or incorporated into a webapp in a container such as Tomcat and am trying to
find an intelligent way to handle dependencies which need to be excluded from
the generated war file because they are supplied with Tomcat itself.
Example:
I've got project someLib which interacts with a MySQL database so it has a
dependency on the mysql java connector for the case when I launch a main program
in the library for command line use.
I've also got project someWebApp which adds a web UI on top of the someLib
functionality. Since my standard Tomcat installation manages the MySQL database
connection the mysql java connector should not be built into the war file
deployed to Tomcat. Also, while I need the servlet library to be able to
compile my webapp, I certainly should not include that in the built war file
under any circumstances.
It occurs to me that which jars are installed standard on the servers is a site
wide configuration and shouldn't really be the concern of the individual
projects. I was thinking of defining a war configuration which extends the
runtime configuration, but then excludes the artifacts which should not be built in.
Something along the general idea of this (though I don't know yet if placing
excludes is allowed here:
<configurations
confmappingoverride="true"
defaultconfmapping="compile->compile(default);
runtime->runtime(default)"
>
<conf name="runtime" extends="compile" />
<conf name="war" extends = "runtime" >
<exclude org="com.mysql" name="mysql-connector-java" />
</conf>
</configurations>
I've gotta believe I'm not the first person to want to do this, are there any
best practices out there? Do I appear to be heading in the right direction?
Thanks
Steve
Re: Question about excludes
Posted by Neil Miller <ne...@livewiremobile.com>.
Presumably you have a dependency like this somewhere:
<dependency org="org.slf4j" module="com.springsource.slf4j.api" rev="1.6.1"/>
in which case adding force="true" should work. Like so:
<dependency org="org.slf4j" module="com.springsource.slf4j.api" rev="1.6.1" force="true"/>
This gives tells the conflict manager (if it's willing to listen) that slf4j should be forced to 1.6.1.
See: http://ant.apache.org/ivy/history/latest-milestone/settings/conflict-managers.html
On 07/27/2011 07:17 AM, David Sills wrote:
> All:
>
> I have a project that has a dependency on slf4j. I'm generally using
> 1.6.1 (with my own patch to fix a bug), but one of my dependencies has a
> transitive dependency on 1.5.6. I cannot figure out how to get rid of
> this JAR file in the ivyIDE container. I am trying this:
>
> <exclude org="org.slf4j" module="com.springsource.slf4j.api"
> artifact="com.springsource.slf4j.api-1.5.6.jar" matcher="exact"/>
>
> The org and module correspond exactly to how the offending JAR file is
> stored in my repository. I know I have to be missing something, but I
> simply can't see it. Does anyone?
>
> I have tried:
>
> <exclude org="org.slf4j" module="com.springsource.slf4j.api"/>
>
> But of course that removes all versions of the JAR file, even the one I
> want to keep. Can someone explain why there is not a "rev" attribute in
> the exclude element? It would seem logical - don't take this revision of
> the library.
>
> Thanks!
>
> David Sills
>
>
RE: Question about excludes
Posted by David Sills <DS...@datasourceinc.com>.
All:
Many thanks for the replies. The force="true" idea didn't work (the
manager wasn't listening, I guess), but the override did.
David
-----Original Message-----
From: Tim Brown [mailto:tpbrown@gmail.com]
Sent: Wednesday, July 27, 2011 10:28 AM
To: ivy-user@ant.apache.org
Subject: Re: Question about excludes
I think you can use Override to force the transitive dependency to the
higher version.
http://ant.apache.org/ivy/history/2.0.0/ivyfile/override.html
~Sent from my mobile device. Please pardon any oddities :-)
On Jul 27, 2011, at 4:18 AM, David Sills <DS...@datasourceinc.com>
wrote:
> All:
>
> I have a project that has a dependency on slf4j. I'm generally using
> 1.6.1 (with my own patch to fix a bug), but one of my dependencies has
a
> transitive dependency on 1.5.6. I cannot figure out how to get rid of
> this JAR file in the ivyIDE container. I am trying this:
>
> <exclude org="org.slf4j" module="com.springsource.slf4j.api"
> artifact="com.springsource.slf4j.api-1.5.6.jar" matcher="exact"/>
>
> The org and module correspond exactly to how the offending JAR file is
> stored in my repository. I know I have to be missing something, but I
> simply can't see it. Does anyone?
>
> I have tried:
>
> <exclude org="org.slf4j" module="com.springsource.slf4j.api"/>
>
> But of course that removes all versions of the JAR file, even the one
I
> want to keep. Can someone explain why there is not a "rev" attribute
in
> the exclude element? It would seem logical - don't take this revision
of
> the library.
>
> Thanks!
>
> David Sills
>
Re: Question about excludes
Posted by Tim Brown <tp...@gmail.com>.
I think you can use Override to force the transitive dependency to the
higher version.
http://ant.apache.org/ivy/history/2.0.0/ivyfile/override.html
~Sent from my mobile device. Please pardon any oddities :-)
On Jul 27, 2011, at 4:18 AM, David Sills <DS...@datasourceinc.com> wrote:
> All:
>
> I have a project that has a dependency on slf4j. I'm generally using
> 1.6.1 (with my own patch to fix a bug), but one of my dependencies has a
> transitive dependency on 1.5.6. I cannot figure out how to get rid of
> this JAR file in the ivyIDE container. I am trying this:
>
> <exclude org="org.slf4j" module="com.springsource.slf4j.api"
> artifact="com.springsource.slf4j.api-1.5.6.jar" matcher="exact"/>
>
> The org and module correspond exactly to how the offending JAR file is
> stored in my repository. I know I have to be missing something, but I
> simply can't see it. Does anyone?
>
> I have tried:
>
> <exclude org="org.slf4j" module="com.springsource.slf4j.api"/>
>
> But of course that removes all versions of the JAR file, even the one I
> want to keep. Can someone explain why there is not a "rev" attribute in
> the exclude element? It would seem logical - don't take this revision of
> the library.
>
> Thanks!
>
> David Sills
>
Question about excludes
Posted by David Sills <DS...@datasourceinc.com>.
All:
I have a project that has a dependency on slf4j. I'm generally using
1.6.1 (with my own patch to fix a bug), but one of my dependencies has a
transitive dependency on 1.5.6. I cannot figure out how to get rid of
this JAR file in the ivyIDE container. I am trying this:
<exclude org="org.slf4j" module="com.springsource.slf4j.api"
artifact="com.springsource.slf4j.api-1.5.6.jar" matcher="exact"/>
The org and module correspond exactly to how the offending JAR file is
stored in my repository. I know I have to be missing something, but I
simply can't see it. Does anyone?
I have tried:
<exclude org="org.slf4j" module="com.springsource.slf4j.api"/>
But of course that removes all versions of the JAR file, even the one I
want to keep. Can someone explain why there is not a "rev" attribute in
the exclude element? It would seem logical - don't take this revision of
the library.
Thanks!
David Sills
Re: container supplied jars excluded in ivy
Posted by Steve Prior <sp...@geekster.com>.
> I can see how, given your situation, using excludes is a more general solution.
> I guess I'm fortunate not to be in that situation, though I'm glad to learn of
> the per-conf exclude at the <dependencies> level; I wasn't previously aware it
> could be used like that.
Yeah, I just found that <dependencies> level exclude this weekend after opening
this thread and it's a big step in the right direction. This feature is
apparently new to version 2.*. Would have been even better if the include
directive had worked there so I could externalize it.
I hope this discussion has/will help others work this out.
Steve
Re: container supplied jars excluded in ivy
Posted by Kirby Files <kf...@masergy.com>.
Steve,
Steve Prior wrote on 07/25/2011 11:24 PM:
> On 7/25/2011 10:39 PM, Kirby Files wrote:
>> To me, adding a bunch of dependencies, only to later exclude them, seems a
>> little backward (and awkward). If war is not a superset of runtime or
>> compile, then I wouldn't make it extend them. I'd create a base config, which
>> contains the minimal intersection of dependencies, and then add deps shared
>> by runtime and war to minimal, and those only needed by runtime to it:
>>
>> <conf name="war" extends="minimal" /> <conf name="runtime" extends="minimal"
>> />
>>
>> <dependency conf="runtime" org="javax.servlet" name="servlet-api"
>> rev="2.4"/> <dependency conf="minimal" org="com.geekster"
>> name="library.tvLib" rev="latest.integration"/>
>
> I considered that and agree with you at a philosophical level, but it didn't
> work when it scaled up. I had "library" projects which used hibernate and then
> webapps projects which would depend on them.
[...]
> So after having done it that way I come back around to my most recently proposed
> method:
>
> * library code provides compile and runtime confs, and the runtime conf provides
> anything that might be needed at runtime, container or not.
>
> * the actual webapp project project just needs to deal with compile and runtime
> configs from the library projects, and it's ONLY that last webapp ivy.xml which
> needs to have ANY concept of how your local Tomcat/container servers are loaded
> up with any shared libs or managed resources.
> At all convinced?
I can see how, given your situation, using excludes is a more general
solution. I guess I'm fortunate not to be in that situation, though
I'm glad to learn of the per-conf exclude at the <dependencies> level;
I wasn't previously aware it could be used like that.
Thanks,
---
Kirby Files
Software Architect
Masergy Communications, Inc.
kfiles@masergy.com
Re: container supplied jars excluded in ivy
Posted by Steve Prior <sp...@geekster.com>.
On 7/25/2011 10:39 PM, Kirby Files wrote:
> To me, adding a bunch of dependencies, only to later exclude them, seems a
> little backward (and awkward). If war is not a superset of runtime or
> compile, then I wouldn't make it extend them. I'd create a base config, which
> contains the minimal intersection of dependencies, and then add deps shared
> by runtime and war to minimal, and those only needed by runtime to it:
>
> <conf name="war" extends="minimal" /> <conf name="runtime" extends="minimal"
> />
>
> <dependency conf="runtime" org="javax.servlet" name="servlet-api"
> rev="2.4"/> <dependency conf="minimal" org="com.geekster"
> name="library.tvLib" rev="latest.integration"/>
I considered that and agree with you at a philosophical level, but it didn't
work when it scaled up. I had "library" projects which used hibernate and then
webapps projects which would depend on them. Now here was a concession - I tend
to have a minimal main class in my library projects which is used in development
for initial testing and to have around as a little utility later, others would
want runtime dependencies required for junit. The totally pure thing would be
to have that stuff which has a main() to be in a different project, so I'd
actually never have code which might run in a container sharing ivy confs with
code which might need command line runtime dependencies (the container driven
code shouldn't include mysql or mail for example). But doing so would be a pain
for code which is a little small to deserve it's own project.
Plus you'd have to deal with two sets of runtime dependency additions: container
based and non-container based:
My library project might use Hibernate, so now my library project ivy would have
to deal with:
* common runtime dependencies:
<dependency conf="runtime" org="org.apache.commons" name="commons-logging"
rev="1.1.1"/>
* container managed dependencies
-maybe nothing, this is when Tomcat supplies the MySQL connection)
* container doesn't manage dependencies
- your local Tomcat isn't mnaging the mysql connection, so include it anyway
* junit
- not running in a container so need mysql, and also need junit stuff
So you've got a library project which for compiles doesn't NEED to care whether
it's running in a container or not now needing to provide configs for situations
it shouldn't care about - that gets bad fast (guess how I found out). This gets
extra sticky when you start to deal with super libraries like Hibernate which
provide more than one jar which you may work around by providing an ivy.xml for
them which then needs to differentiate between compile and runtime (yes I ran
into this).
So after having done it that way I come back around to my most recently proposed
method:
* library code provides compile and runtime confs, and the runtime conf provides
anything that might be needed at runtime, container or not.
* the actual webapp project project just needs to deal with compile and runtime
configs from the library projects, and it's ONLY that last webapp ivy.xml which
needs to have ANY concept of how your local Tomcat/container servers are loaded
up with any shared libs or managed resources.
So while I agree that dependencies should always be added and not taken away, in
this casse I really think this is the better sacrifice (I like to code,hate to
screw with ivy.xml files).
At all convinced?
Steve
RE: container supplied jars excluded in ivy
Posted by Kirby Files <Kf...@masergy.com>.
To me, adding a bunch of dependencies, only to later exclude them, seems a little backward (and awkward). If war is not a superset of runtime or compile, then I wouldn't make it extend them. I'd create a base config, which contains the minimal intersection of dependencies, and then add deps shared by runtime and war to minimal, and those only needed by runtime to it:
<conf name="war"
extends="minimal"
/>
<conf name="runtime"
extends="minimal"
/>
<dependency conf="runtime" org="javax.servlet" name="servlet-api"
rev="2.4"/>
<dependency conf="minimal" org="com.geekster" name="library.tvLib"
rev="latest.integration"/>
Thanks,
---
Kirby Files
Software Architect
Masergy Communications
kfiles@masergy.com
________________________________________
From: Steve Prior [sprior@geekster.com]
Sent: Monday, July 25, 2011 9:18 PM
To: ivy-user@ant.apache.org
Subject: Re: container supplied jars excluded in ivy
> Odd, for me the inverse is true. I need the most things on my classpath at
> test time [servlet spec, junit], fewer at compile [servlet spec], and fewest
> at run time [just my war].
>
> Here's the snippet of my configurations, and their mapping. I use
> externalized configuration so there's added confs for configuration and
> externalized WSDLs..
>
> <configurations
> defaultconfmapping="runtime->runtime(*);config->config(*);test->runtime(*);compile->runtime(*)">
>
> <conf name="config" description="LCFG configuration templates
> associated with this module"/>
> <conf name="wsdl" description="WSDLs associated with this module"/>
>
> <conf name="runtime" extends="config,wsdl" description="anything
> necessary to run; bundled into EAR/WAR"/>
> <conf name="compile" extends="runtime" visibility="private"
> description="anything necessary to compile"/>
> <conf name="test" extends="compile" visibility="private"
> description="anything needed to run unit tests"/>
> </configurations>
Those configs still seem odd to me because for example when using Hibernate
there are certainly fewer jars required to compile than run (logging for example).
I thought about this war problem a lot and came up with:
defaultconfmapping="compile->compile(default);
runtime->runtime(default);
war->runtime(default)"
<conf name="war"
extends="runtime"
/>
Now I have removed all mention of a war configuration for everything that is not
actually a webapp (I tried it the other way and it was a mess). Here is one of
my new ivy.xml files:
<!DOCTYPE project>
<ivy-module version="2.0">
<info organisation="com.geekster" module="tv"/>
<configurations>
<include file="${ivy.settings.dir}/buildenv.ivy.configurations.xml"/>
</configurations>
<publications>
<artifact type="war" ext="war"/>
</publications>
<dependencies>
<dependency conf="compile" org="javax.servlet" name="servlet-api"
rev="2.4"/>
<dependency conf="compile" org="com.geekster" name="library.tvLib"
rev="latest.integration"/>
<dependency conf="compile" org="com.geekster" name="library.ajaxLib"
rev="latest.integration"/>
<dependency conf="compile" org="com.geekster"
name="library.hibernate_utils" rev="latest.integration"/>
<dependency conf="compile" org="org.hibernate" name="hibernate3"
rev="3.2.2.ga"/>
<dependency conf="compile" org="com.geekster" name="library.java_util"
rev="latest.integration"/>
<exclude conf="war" org="com.mysql" module="mysql-connector-java"/>
<exclude conf="war" org="javax.activation" module="activation"/>
<exclude conf="war" org="javax.mail" module="mail"/>
<exclude conf="war" org="javax.servlet" module="jsp-api" />
<exclude conf="war" org="javax.servlet" module="servlet-api" />
</dependencies>
</ivy-module>
The new thing for me is to add the block of excludes which strip out all of the
shared jars on my local Tomcat installations, but do so without needing to know
which dependency (if at all) brought them into the mix - this was a new trick I
just found out.
Now I REALLY wanted to be even a little more clever and put that block of
excludes in a file in my ivy.settings.dir and include them into place, but it
turns out the include directive isn't allowed there (nuts). That would have
been an especially deluxe solution since I could have had different include
files for different server setups in my environment (Tomcat, JBoss, whatever).
But at least I can standardize this block and rubber stamp it on my web project
ivy.xml's without having to think about it.
If anyone has some more fantastic tweaks I'm all EARs...
Steve
Re: container supplied jars excluded in ivy
Posted by Steve Prior <sp...@geekster.com>.
> Odd, for me the inverse is true. I need the most things on my classpath at
> test time [servlet spec, junit], fewer at compile [servlet spec], and fewest
> at run time [just my war].
>
> Here's the snippet of my configurations, and their mapping. I use
> externalized configuration so there's added confs for configuration and
> externalized WSDLs..
>
> <configurations
> defaultconfmapping="runtime->runtime(*);config->config(*);test->runtime(*);compile->runtime(*)">
>
> <conf name="config" description="LCFG configuration templates
> associated with this module"/>
> <conf name="wsdl" description="WSDLs associated with this module"/>
>
> <conf name="runtime" extends="config,wsdl" description="anything
> necessary to run; bundled into EAR/WAR"/>
> <conf name="compile" extends="runtime" visibility="private"
> description="anything necessary to compile"/>
> <conf name="test" extends="compile" visibility="private"
> description="anything needed to run unit tests"/>
> </configurations>
Those configs still seem odd to me because for example when using Hibernate
there are certainly fewer jars required to compile than run (logging for example).
I thought about this war problem a lot and came up with:
defaultconfmapping="compile->compile(default);
runtime->runtime(default);
war->runtime(default)"
<conf name="war"
extends="runtime"
/>
Now I have removed all mention of a war configuration for everything that is not
actually a webapp (I tried it the other way and it was a mess). Here is one of
my new ivy.xml files:
<!DOCTYPE project>
<ivy-module version="2.0">
<info organisation="com.geekster" module="tv"/>
<configurations>
<include file="${ivy.settings.dir}/buildenv.ivy.configurations.xml"/>
</configurations>
<publications>
<artifact type="war" ext="war"/>
</publications>
<dependencies>
<dependency conf="compile" org="javax.servlet" name="servlet-api"
rev="2.4"/>
<dependency conf="compile" org="com.geekster" name="library.tvLib"
rev="latest.integration"/>
<dependency conf="compile" org="com.geekster" name="library.ajaxLib"
rev="latest.integration"/>
<dependency conf="compile" org="com.geekster"
name="library.hibernate_utils" rev="latest.integration"/>
<dependency conf="compile" org="org.hibernate" name="hibernate3"
rev="3.2.2.ga"/>
<dependency conf="compile" org="com.geekster" name="library.java_util"
rev="latest.integration"/>
<exclude conf="war" org="com.mysql" module="mysql-connector-java"/>
<exclude conf="war" org="javax.activation" module="activation"/>
<exclude conf="war" org="javax.mail" module="mail"/>
<exclude conf="war" org="javax.servlet" module="jsp-api" />
<exclude conf="war" org="javax.servlet" module="servlet-api" />
</dependencies>
</ivy-module>
The new thing for me is to add the block of excludes which strip out all of the
shared jars on my local Tomcat installations, but do so without needing to know
which dependency (if at all) brought them into the mix - this was a new trick I
just found out.
Now I REALLY wanted to be even a little more clever and put that block of
excludes in a file in my ivy.settings.dir and include them into place, but it
turns out the include directive isn't allowed there (nuts). That would have
been an especially deluxe solution since I could have had different include
files for different server setups in my environment (Tomcat, JBoss, whatever).
But at least I can standardize this block and rubber stamp it on my web project
ivy.xml's without having to think about it.
If anyone has some more fantastic tweaks I'm all EARs...
Steve
Re: container supplied jars excluded in ivy
Posted by Tim Brown <tp...@gmail.com>.
>
> The order of your extends doesn't make sense to me because the runtime
> dependencies are a superset of the compile time, so you'd be overkill on the
> compile.
>
Odd, for me the inverse is true. I need the most things on my classpath at
test time [servlet spec, junit], fewer at compile [servlet spec], and fewest
at run time [just my war].
Here's the snippet of my configurations, and their mapping. I use
externalized configuration so there's added confs for configuration and
externalized WSDLs..
<configurations
defaultconfmapping="runtime->runtime(*);config->config(*);test->runtime(*);compile->runtime(*)">
<conf name="config" description="LCFG configuration templates
associated with this module"/>
<conf name="wsdl" description="WSDLs associated with this module"/>
<conf name="runtime" extends="config,wsdl" description="anything
necessary to run; bundled into EAR/WAR"/>
<conf name="compile" extends="runtime" visibility="private"
description="anything necessary to compile"/>
<conf name="test" extends="compile" visibility="private"
description="anything needed to run unit tests"/>
</configurations>
HTH,
~T
Re: container supplied jars excluded in ivy
Posted by Steve Prior <sp...@geekster.com>.
On 7/24/2011 12:51 PM, Tim Brown wrote:
> Hi Steve,
>
> I use confs to do this too, but flipped from what you show below.
>
> - runtime; everything that belongs in the war
> - compile; extends runtime and adds compile time deps
> - test; extends compile and adds test time deps
The order of your extends doesn't make sense to me because the runtime
dependencies are a superset of the compile time, so you'd be overkill on the
compile.
The trick here with the shared tomcat lib war is that the set math changes
direction - the compile time are the smallest, then generic runtime is bigger,
then cmdline runtime is the most, but then the war (container based) is a little
less. It's that change of direction that's the tricky part.
I still like the idea that the set of shared jars on the container is more of a
site local configuration rather than at the project level and that it is an
exclusion at the end which would make it less of a hassle to deal with in the
library definitions, I just don't know how it can be done in the config syntax.
Or I could be completely misguided...
Steve
Re: container supplied jars excluded in ivy
Posted by Tim Brown <tp...@gmail.com>.
Hi Steve,
I use confs to do this too, but flipped from what you show below.
- runtime; everything that belongs in the war
- compile; extends runtime and adds compile time deps
- test; extends compile and adds test time deps
~Sent from my mobile device. Please pardon any oddities :-)
On Jul 24, 2011, at 8:12 AM, Steve Prior <sp...@geekster.com> wrote:
> I'm using Ivy to build libraries which can either be used from the command line or incorporated into a webapp in a container such as Tomcat and am trying to find an intelligent way to handle dependencies which need to be excluded from the generated war file because they are supplied with Tomcat itself.
>
>
> Example:
>
> I've got project someLib which interacts with a MySQL database so it has a dependency on the mysql java connector for the case when I launch a main program in the library for command line use.
>
> I've also got project someWebApp which adds a web UI on top of the someLib functionality. Since my standard Tomcat installation manages the MySQL database connection the mysql java connector should not be built into the war file deployed to Tomcat. Also, while I need the servlet library to be able to compile my webapp, I certainly should not include that in the built war file under any circumstances.
>
> It occurs to me that which jars are installed standard on the servers is a site wide configuration and shouldn't really be the concern of the individual projects. I was thinking of defining a war configuration which extends the runtime configuration, but then excludes the artifacts which should not be built in.
>
> Something along the general idea of this (though I don't know yet if placing excludes is allowed here:
>
> <configurations
> confmappingoverride="true"
> defaultconfmapping="compile->compile(default);
> runtime->runtime(default)"
> >
> <conf name="runtime" extends="compile" />
>
> <conf name="war" extends = "runtime" >
> <exclude org="com.mysql" name="mysql-connector-java" />
> </conf>
> </configurations>
>
> I've gotta believe I'm not the first person to want to do this, are there any best practices out there? Do I appear to be heading in the right direction?
>
> Thanks
> Steve
Re: container supplied jars excluded in ivy
Posted by Archie Cobbs <ar...@dellroad.org>.
On Sun, Jul 24, 2011 at 10:12 AM, Steve Prior <sp...@geekster.com> wrote:
> It occurs to me that which jars are installed standard on the servers is a
> site wide configuration and shouldn't really be the concern of the
> individual projects. I was thinking of defining a war configuration which
> extends the runtime configuration, but then excludes the artifacts which
> should not be built in.
>
There may be a more clever way to do what you want... I've always handled
this the "manual" way, by retrieving all of the artifacts into a WEB-INF/lib
staging directory, and then deleting the ones I don't need.
-Archie
--
Archie L. Cobbs