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 Andy Piper <an...@bea.com> on 2007/08/14 13:36:53 UTC
Configurations really hard to understand
Every time I think I have understood configurations my more
sophisticated attempts to use them result in resolution errors in
ivy. I have been through the tutorial and the docs many times. Does
anyone have a good write-up of configuration usage other than the one
on the website?
In particular I am having problems with "default". This is implicitly
defined unless you create your own configurations. If I add my other
configuration how do I specify some of the dependencies to have the
default configuration? "default", "default->default"?
In particular lets say I have module A and module B. Both of these
have some shared dependencies that should be available at build-time
but not test time. My naive configuration would look something like this:
<configurations>
<conf name="test"/>
<conf name="default"/>
</configurations>
<dependencies defaultconf="default">
<dependency org="foo" name="bar" rev="1.0" conf="test->default"/>
<dependency org="foo" name="baz" rev="1.0"/>
</dependencies>
But this seems to do something subtly different to what I intend. In
particular the definition of foo.bar seems to require a definition of
the default configuration.
Any help or insights appreciated. Apologies for the somewhat random
stream of consciousness.
[Note I don't think the current configuration syntax is particularly
intuitive, but I'm not sure what I would suggest as an alternative.]
andy
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Configurations really hard to understand
Posted by Jing Xue <ji...@digizenstudio.com>.
Quoting Andy Piper <an...@bea.com>:
> In particular lets say I have module A and module B. Both of these
> have some shared dependencies that should be available at build-time
> but not test time. My naive configuration would look something like this:
>
> <configurations>
> <conf name="test"/>
> <conf name="default"/>
> </configurations>
> <dependencies defaultconf="default">
> <dependency org="foo" name="bar" rev="1.0" conf="test->default"/>
I believe in this case the "default" on the right hand side of ->
actually refers to the configuration "default" of foo.bar. Basically
what test->default says is the dependency on foo.bar should be
available for configuration "test" of this module, and transitively
whatever dependencies declared in the configuration "default" of
foo.bar should be satisfied as well.
> <dependency org="foo" name="baz" rev="1.0"/>
> </dependencies>
HTH.
--
Jing
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Re: Configurations really hard to understand
Posted by Xavier Hanin <xa...@gmail.com>.
On 8/16/07, Gilles Scokart <gs...@gmail.com> wrote:
>
> You can put :
>
> <configurations>
> <include file="${build.script.dir}/configurations.xml"/>
> </configurations>
>
> That works well when you want to have some configurations policies.
> It works when you want configurations like 'compile', 'runtime',
> 'test', (like maven, or extended with some others like 'interface',
> 'assembly').
>
> However, it doesn't work when you want to use configurations for
> 'feature scope'. For example, the ivy.xml of the ivy module has
> configuration like 'core', 'standalone', 'httpclient', 'oro'. For
> this type of configuration you can not include some standard
> configurations.
>
> I'm not sure if you can easily combine both style.
The configurations definition file inclusion works as a simple inclusion, so
you can define other configurations in the file in which you call the
include. To combine the configurations, you can use the extends feature, but
that's pretty much all. We have no way to allow other combinations like
intersections for instance. But this would go in a direction of adding
features and complexity, and the initial request was quite the opposite :-)
To simplify for those who prefer to avoid thinking about configurations
themselves, we could maybe include the configuration definitions and default
mapping we use for maven 2 poms as a file in the Ivy classpath, and make its
url available as a variable. Then you could use these configurations and
default mapping with something like:
<configurations>
<include file="${ivy.m2.configurations}"/>
</configurations>
This is pretty easy to do, would it be useful?
Xavier
> Gilles
>
>
> 2007/8/15, Matthias Kilian <ki...@outback.escape.de>:
> > On Wed, Aug 15, 2007 at 08:48:06PM +0200, Xavier Hanin wrote:
> > > Maybe configuration mapping is too difficult to understand... I agree
> that
> > > maven 2 scopes are easier to use for average users, at least until you
> reach
> > > their limitations (if ever).
> >
> > Well, I prefer to use my own configurations and arbitraty configuration
> > mappings, even if I *could* abuse maven2 scopes. And I'm pretty
> > sure that I've already some cases where I really need configuration
> > mappings, but I'd to check our Ivy repo to be sure. (I should write
> > a short survey of how we're using Ivy anyways, but that'll take
> > some time)
> >
> > > Therefore we should maybe provide a set of
> > > configurations and the associated mapping (something similar to maven
> 2
> > > scopes maybe), and still make it possible to use your own conf
> mapping. In
> > > this case users not needing specific things could almost ignore
> > > configuration mapping.
> > >
> > > What do you think?
> >
> > Would some kind of include mechanism for sets of default conf mappings
> > be feasible? Something like
> >
> > <dependencies defaultconfmappingset="${some_url_or_file}">
> > ...
> > </dependencies>
> >
> > ${some_url_or_file} then would define all the conf mappings used.
> >
> > Since configurations and conf mappings tend to be very policy-driven
> > (on a per-organisation or per-projectgroup base), this would give
> > maximum flexibility without hard-wiring some automagic stuff into
> > Ivy.
> >
> > Of course, this is just a rough idea; the available configurations
> > should be defined in ${some_url_or_file}, too, so the dependencies
> > element probably isn't the best place to include it.
> >
> > Ciao,
> > Kili
> >
> > --
> > Bad English is the international language ;)
> > -- Gerardo Santana Gómez Garrido in misc@openbsd.org
> >
>
>
> --
> Gilles SCOKART
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://incubator.apache.org/ivy/
http://www.xoocode.org/
Re: Configurations really hard to understand
Posted by Gilles Scokart <gs...@gmail.com>.
You can put :
<configurations>
<include file="${build.script.dir}/configurations.xml"/>
</configurations>
That works well when you want to have some configurations policies.
It works when you want configurations like 'compile', 'runtime',
'test', (like maven, or extended with some others like 'interface',
'assembly').
However, it doesn't work when you want to use configurations for
'feature scope'. For example, the ivy.xml of the ivy module has
configuration like 'core', 'standalone', 'httpclient', 'oro'. For
this type of configuration you can not include some standard
configurations.
I'm not sure if you can easily combine both style.
Gilles
2007/8/15, Matthias Kilian <ki...@outback.escape.de>:
> On Wed, Aug 15, 2007 at 08:48:06PM +0200, Xavier Hanin wrote:
> > Maybe configuration mapping is too difficult to understand... I agree that
> > maven 2 scopes are easier to use for average users, at least until you reach
> > their limitations (if ever).
>
> Well, I prefer to use my own configurations and arbitraty configuration
> mappings, even if I *could* abuse maven2 scopes. And I'm pretty
> sure that I've already some cases where I really need configuration
> mappings, but I'd to check our Ivy repo to be sure. (I should write
> a short survey of how we're using Ivy anyways, but that'll take
> some time)
>
> > Therefore we should maybe provide a set of
> > configurations and the associated mapping (something similar to maven 2
> > scopes maybe), and still make it possible to use your own conf mapping. In
> > this case users not needing specific things could almost ignore
> > configuration mapping.
> >
> > What do you think?
>
> Would some kind of include mechanism for sets of default conf mappings
> be feasible? Something like
>
> <dependencies defaultconfmappingset="${some_url_or_file}">
> ...
> </dependencies>
>
> ${some_url_or_file} then would define all the conf mappings used.
>
> Since configurations and conf mappings tend to be very policy-driven
> (on a per-organisation or per-projectgroup base), this would give
> maximum flexibility without hard-wiring some automagic stuff into
> Ivy.
>
> Of course, this is just a rough idea; the available configurations
> should be defined in ${some_url_or_file}, too, so the dependencies
> element probably isn't the best place to include it.
>
> Ciao,
> Kili
>
> --
> Bad English is the international language ;)
> -- Gerardo Santana Gómez Garrido in misc@openbsd.org
>
--
Gilles SCOKART
Re: Configurations really hard to understand
Posted by Xavier Hanin <xa...@gmail.com>.
On 8/15/07, Matthias Kilian <ki...@outback.escape.de> wrote:
>
> On Wed, Aug 15, 2007 at 08:48:06PM +0200, Xavier Hanin wrote:
> > Maybe configuration mapping is too difficult to understand... I agree
> that
> > maven 2 scopes are easier to use for average users, at least until you
> reach
> > their limitations (if ever).
>
> Well, I prefer to use my own configurations and arbitraty configuration
> mappings, even if I *could* abuse maven2 scopes. And I'm pretty
> sure that I've already some cases where I really need configuration
> mappings, but I'd to check our Ivy repo to be sure. (I should write
> a short survey of how we're using Ivy anyways, but that'll take
> some time)
The result of the survey would be very interesting, I hope you'll be able to
share it with the community.
Xavier
> Therefore we should maybe provide a set of
> > configurations and the associated mapping (something similar to maven 2
> > scopes maybe), and still make it possible to use your own conf mapping.
> In
> > this case users not needing specific things could almost ignore
> > configuration mapping.
> >
> > What do you think?
>
> Would some kind of include mechanism for sets of default conf mappings
> be feasible? Something like
>
> <dependencies defaultconfmappingset="${some_url_or_file}">
> ...
> </dependencies>
>
> ${some_url_or_file} then would define all the conf mappings used.
>
> Since configurations and conf mappings tend to be very policy-driven
> (on a per-organisation or per-projectgroup base), this would give
> maximum flexibility without hard-wiring some automagic stuff into
> Ivy.
>
> Of course, this is just a rough idea; the available configurations
> should be defined in ${some_url_or_file}, too, so the dependencies
> element probably isn't the best place to include it.
>
> Ciao,
> Kili
>
> --
> Bad English is the international language ;)
> -- Gerardo Santana Gómez Garrido in misc@openbsd.org
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://incubator.apache.org/ivy/
http://www.xoocode.org/
Re: Configurations really hard to understand
Posted by Matthias Kilian <ki...@outback.escape.de>.
On Wed, Aug 15, 2007 at 08:48:06PM +0200, Xavier Hanin wrote:
> Maybe configuration mapping is too difficult to understand... I agree that
> maven 2 scopes are easier to use for average users, at least until you reach
> their limitations (if ever).
Well, I prefer to use my own configurations and arbitraty configuration
mappings, even if I *could* abuse maven2 scopes. And I'm pretty
sure that I've already some cases where I really need configuration
mappings, but I'd to check our Ivy repo to be sure. (I should write
a short survey of how we're using Ivy anyways, but that'll take
some time)
> Therefore we should maybe provide a set of
> configurations and the associated mapping (something similar to maven 2
> scopes maybe), and still make it possible to use your own conf mapping. In
> this case users not needing specific things could almost ignore
> configuration mapping.
>
> What do you think?
Would some kind of include mechanism for sets of default conf mappings
be feasible? Something like
<dependencies defaultconfmappingset="${some_url_or_file}">
...
</dependencies>
${some_url_or_file} then would define all the conf mappings used.
Since configurations and conf mappings tend to be very policy-driven
(on a per-organisation or per-projectgroup base), this would give
maximum flexibility without hard-wiring some automagic stuff into
Ivy.
Of course, this is just a rough idea; the available configurations
should be defined in ${some_url_or_file}, too, so the dependencies
element probably isn't the best place to include it.
Ciao,
Kili
--
Bad English is the international language ;)
-- Gerardo Santana Gómez Garrido in misc@openbsd.org
RE: Configurations really hard to understand
Posted by "Loehr, Ruel" <rl...@pointserve.com>.
Shouldn't the servlet api just be a compile time need? I would try doing this:
//i make the servlet api a compile time dependency. At runtime, your servlet container should have it
//when you publish this module, you would need to publish the runtime configuration at minimum.
//i haven't used the defaultconfmapping before as an fyi, not sure what behavior that will change
<ivy-module version="1.0">
<info organisation="com.foo" module="coreTools"/>
<configurations defaultconfmapping="runtime->runtime(*)">
<conf name="runtime" description="Run Time dependencies"/>
<conf name="compile" description="compile time dependencies"/>
</configurations>
<dependencies>
<dependency org="javax.servlet" name="servlet-api" rev="2.4"
conf="compile"/>
</dependencies>
</ivy-module>
<ivy-module version="1.0">
<info organisation="com.foo" module="reports"/>
<configurations defaultconfmapping="compile->compile(*)">
<conf name="compile" description="Build Time dependencies"/>
</configurations>
<dependencies>
//here i say i want to use coretools in my compile configuration and I want to to use published runtime configuration (it should not have servelt api).
<dependency name="coreTools" rev="latest.integration" conf="compile->runtime"/>
.....
</ivy-module>
________________________________________
From: buzzterrier [terry.jeske@gmail.com]
Sent: Monday, June 02, 2008 2:29 PM
To: ivy-user@ant.apache.org
Subject: RE: Configurations really hard to understand
Thx Ruel,
I created a "runtime" conf on the servlet-api dependency on my coreTools
api. I then added coreTools api as a dependency in my web app, but gave it a
"compile" conf. Since the web app was using a "compile" configuration, I
thought that it would ignore the "runtime" dependency on coreTools api.
for example, here is the coreTools api:
<ivy-module version="1.0">
<info organisation="com.foo" module="coreTools"/>
<configurations defaultconfmapping="runtime->runtime(*)">
<conf name="runtime" description="Run Time dependencies"/>
</configurations>
<dependencies>
<dependency org="javax.servlet" name="servlet-api" rev="2.4"
conf="runtime"/>
</dependencies>
</ivy-module>
and here is the web app using a compile conf:
<ivy-module version="1.0">
<info organisation="com.foo" module="reports"/>
<configurations defaultconfmapping="compile->compile(*)">
<conf name="compile" description="Build Time dependencies"/>
</configurations>
<dependencies>
<dependency name="coreTools" rev="latest.integration" conf="compile"/>
.....
</ivy-module>
But building the reports module still pulls down servlet-api from coreTools.
[ivy:retrieve] confs: [compile]
[ivy:retrieve] found com.foo#coreTools;10 in projects
[ivy:retrieve] [10] com.foo#coreTools;latest.integration
[ivy:retrieve] found javax.servlet#servlet-api;2.4 in libraries
ruel loehr wrote:
>
> Yes, I struggled with it too at first.
>
> In my main project, I usually publish a directory config called runtime
> which just has the absolute necessary runtime dependencies.
>
> Then for any project which consumes my original one, I define a compile
> configuration which "eat" the runtime one.
>
> conf="compile->runtime"
>
>
>
--
View this message in context: http://www.nabble.com/Problem-with-host-name-over-https-tp12053693p17608947.html
Sent from the ivy-user mailing list archive at Nabble.com.
RE: Configurations really hard to understand
Posted by buzzterrier <te...@gmail.com>.
Thx Ruel,
I created a "runtime" conf on the servlet-api dependency on my coreTools
api. I then added coreTools api as a dependency in my web app, but gave it a
"compile" conf. Since the web app was using a "compile" configuration, I
thought that it would ignore the "runtime" dependency on coreTools api.
for example, here is the coreTools api:
<ivy-module version="1.0">
<info organisation="com.foo" module="coreTools"/>
<configurations defaultconfmapping="runtime->runtime(*)">
<conf name="runtime" description="Run Time dependencies"/>
</configurations>
<dependencies>
<dependency org="javax.servlet" name="servlet-api" rev="2.4"
conf="runtime"/>
</dependencies>
</ivy-module>
and here is the web app using a compile conf:
<ivy-module version="1.0">
<info organisation="com.foo" module="reports"/>
<configurations defaultconfmapping="compile->compile(*)">
<conf name="compile" description="Build Time dependencies"/>
</configurations>
<dependencies>
<dependency name="coreTools" rev="latest.integration" conf="compile"/>
.....
</ivy-module>
But building the reports module still pulls down servlet-api from coreTools.
[ivy:retrieve] confs: [compile]
[ivy:retrieve] found com.foo#coreTools;10 in projects
[ivy:retrieve] [10] com.foo#coreTools;latest.integration
[ivy:retrieve] found javax.servlet#servlet-api;2.4 in libraries
ruel loehr wrote:
>
> Yes, I struggled with it too at first.
>
> In my main project, I usually publish a directory config called runtime
> which just has the absolute necessary runtime dependencies.
>
> Then for any project which consumes my original one, I define a compile
> configuration which "eat" the runtime one.
>
> conf="compile->runtime"
>
>
>
--
View this message in context: http://www.nabble.com/Problem-with-host-name-over-https-tp12053693p17608947.html
Sent from the ivy-user mailing list archive at Nabble.com.
RE: Configurations really hard to understand
Posted by "Loehr, Ruel" <rl...@pointserve.com>.
Yes, I struggled with it too at first.
In my main project, I usually publish a directory config called runtime which just has the absolute necessary runtime dependencies.
Then for any project which consumes my original one, I define a compile configuration which "eat" the runtime one.
conf="compile->runtime"
________________________________________
From: buzzterrier [terry.jeske@gmail.com]
Sent: Monday, June 02, 2008 1:21 PM
To: ivy-user@ant.apache.org
Subject: Re: Configurations really hard to understand
I am new to Ivy coming over from Maven, and I too am having difficulty
figuring out configurations (glad I am not alone <g>). I like Xavier's
suggestion below about providing a set of mappings that are similar to
Maven's scopes. Did this idea get dropped? If so, perhaps you could update
the documentation to show how you would implemented a "provided" scoped
dependency in Ivy.
I have what should be a simple problem. We have an in-house commonToolsApi
that has a "provided" scoped dependency on servlet-api. I build and publish
this jar so it is available for other applications. We have a web app that
depends on commonToolsApi.jar. When I build the web app, servlet-api always
gets added to the lib directory. I know this should be trivial to fix using
configurations but after several attempts, it always gets add. Which means I
really don't understand what is going on. I realize that eventually the
light bulb will go off, but right now I feel pretty dim.<g>
Xavier Hanin wrote:
>
> Maybe configuration mapping is too difficult to understand... I agree that
> maven 2 scopes are easier to use for average users, at least until you
> reach
> their limitations (if ever). Therefore we should maybe provide a set of
> configurations and the associated mapping (something similar to maven 2
> scopes maybe), and still make it possible to use your own conf mapping. In
> this case users not needing specific things could almost ignore
> configuration mapping.
>
> What do you think?
>
> Xavier
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://incubator.apache.org/ivy/
> http://www.xoocode.org/
>
>
--
View this message in context: http://www.nabble.com/Problem-with-host-name-over-https-tp12053693p17607004.html
Sent from the ivy-user mailing list archive at Nabble.com.
Re: Configurations really hard to understand
Posted by buzzterrier <te...@gmail.com>.
I am new to Ivy coming over from Maven, and I too am having difficulty
figuring out configurations (glad I am not alone <g>). I like Xavier's
suggestion below about providing a set of mappings that are similar to
Maven's scopes. Did this idea get dropped? If so, perhaps you could update
the documentation to show how you would implemented a "provided" scoped
dependency in Ivy.
I have what should be a simple problem. We have an in-house commonToolsApi
that has a "provided" scoped dependency on servlet-api. I build and publish
this jar so it is available for other applications. We have a web app that
depends on commonToolsApi.jar. When I build the web app, servlet-api always
gets added to the lib directory. I know this should be trivial to fix using
configurations but after several attempts, it always gets add. Which means I
really don't understand what is going on. I realize that eventually the
light bulb will go off, but right now I feel pretty dim.<g>
Xavier Hanin wrote:
>
> Maybe configuration mapping is too difficult to understand... I agree that
> maven 2 scopes are easier to use for average users, at least until you
> reach
> their limitations (if ever). Therefore we should maybe provide a set of
> configurations and the associated mapping (something similar to maven 2
> scopes maybe), and still make it possible to use your own conf mapping. In
> this case users not needing specific things could almost ignore
> configuration mapping.
>
> What do you think?
>
> Xavier
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://incubator.apache.org/ivy/
> http://www.xoocode.org/
>
>
--
View this message in context: http://www.nabble.com/Problem-with-host-name-over-https-tp12053693p17607004.html
Sent from the ivy-user mailing list archive at Nabble.com.
Re: Configurations really hard to understand
Posted by Xavier Hanin <xa...@gmail.com>.
Maybe configuration mapping is too difficult to understand... I agree that
maven 2 scopes are easier to use for average users, at least until you reach
their limitations (if ever). Therefore we should maybe provide a set of
configurations and the associated mapping (something similar to maven 2
scopes maybe), and still make it possible to use your own conf mapping. In
this case users not needing specific things could almost ignore
configuration mapping.
What do you think?
Xavier
On 8/15/07, Loehr, Ruel <rl...@pointserve.com> wrote:
>
> I'll second that. I found it pretty confusing and honestly still am not
> 100% sure of how it works.
>
> -----Original Message-----
> From: Jeffrey Blattman [mailto:jeffrey.blattman@gmail.com]
> Sent: Wednesday, August 15, 2007 1:16 PM
> To: ivy-user@incubator.apache.org
> Subject: Re: Configurations really hard to understand
>
> i've never needed Ivy configurations. i need what maven has, and that's
> how i tried to apply it. i always understood configurations to be a
> generalized version of maven scopes as you are calling them. in fact i
> think i read that someone in the ivy docs.
>
> all i want to do is
>
> 1. define a config
> 2. be able to associate a config w/ a dependency
> 3. be able to reference the dependencies by config name in ivy:resolve,
> retrieve, cachpath, etc
>
> i.e., configs are just a grouping of dependencies.
>
> it just seems like configurations could be greatly simplified to do the
> above and still handle 98% of the use cases. you don't need to "->"
> syntax do this for example.
>
> Xavier Hanin wrote:
> > On 8/15/07, Jeffrey Blattman <je...@gmail.com> wrote:
> >
> >> i don't mean to rain on dmitry's great explanation, but i think this
> >> might be the crux of the problem. there is one way to do it on maven,
> >> and no one has any questions about it. i to was / am confused by
> >> configurations in Ivy.
> >>
> >
> >
> > Not sure to get what you are meaning. Do you mean that we should only
> > provide one way to specify configuration mapping, or that we should
> simply
> > not provide flexible configuration mapping as we do? Maven has no
> concept of
> > configuration, they have scopes which are predefined and do not allow
> things
> > as flexible as you can do with Ivy. But maybe providing an easy to use
> > configuration mapping in Ivy could help users who don't want to take
> care
> > about understanding the real flexibility of configurations.
> >
> > Xavier
> >
> > Dmitriy Korobskiy wrote:
> >
> >>> 2. How to specify this mapping? There are many ways in Ivy to do it.
> >>>
> >> Let's start
> >>
> >>> with explicit abbreviated mapping for each dependency:
> >>>
> >>>
> >>>
> >
> >
> >
> >
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://incubator.apache.org/ivy/
http://www.xoocode.org/
Re: Configurations really hard to understand
Posted by Xavier Hanin <xa...@gmail.com>.
On 8/15/07, Andy Piper <an...@bea.com> wrote:
>
> Yeah, so this is what I need too and am doing with virtual modules
> (with a <publications/> section. It feels a little contrived however,
> and I agree this particular use-case should be much simpler to
> define. The simple things should be easy and complicated things
> possible. Right now ivy configurations are very powerful, but not
> ever simple from my POV...
Do you see a way to make them simpler, besides better documentation? It's
difficult to see how complex conf mapping is from my POV (as being at the
origin of this concept), so I think an easier solution should better come
from the community.
Xavier
andy
>
> At 19:16 15/08/2007, Jeffrey Blattman wrote:
> >i've never needed Ivy configurations. i need what maven has, and
> >that's how i tried to apply it. i always understood configurations
> >to be a generalized version of maven scopes as you are calling them.
> >in fact i think i read that someone in the ivy docs.
> >
> >all i want to do is
> >
> >1. define a config
> >2. be able to associate a config w/ a dependency
> >3. be able to reference the dependencies by config name in
> >ivy:resolve, retrieve, cachpath, etc
> >
> >i.e., configs are just a grouping of dependencies.
> >
> >it just seems like configurations could be greatly simplified to do
> >the above and still handle 98% of the use cases. you don't need to
> >"->" syntax do this for example.
> >
> >Xavier Hanin wrote:
> >>On 8/15/07, Jeffrey Blattman <je...@gmail.com> wrote:
> >>
> >>>i don't mean to rain on dmitry's great explanation, but i think this
> >>>might be the crux of the problem. there is one way to do it on maven,
> >>>and no one has any questions about it. i to was / am confused by
> >>>configurations in Ivy.
> >>>
> >>
> >>
> >>Not sure to get what you are meaning. Do you mean that we should only
> >>provide one way to specify configuration mapping, or that we should
> simply
> >>not provide flexible configuration mapping as we do? Maven has no
> concept of
> >>configuration, they have scopes which are predefined and do not allow
> things
> >>as flexible as you can do with Ivy. But maybe providing an easy to use
> >>configuration mapping in Ivy could help users who don't want to take
> care
> >>about understanding the real flexibility of configurations.
> >>
> >>Xavier
> >>
> >>Dmitriy Korobskiy wrote:
> >>
> >>>>2. How to specify this mapping? There are many ways in Ivy to do it.
> >>>>
> >>>Let's start
> >>>
> >>>>with explicit abbreviated mapping for each dependency:
> >>>>
> >>>>
> >>>>
> >>
> >>
> >>
> >>
>
>
> Notice: This email message, together with any attachments, may contain
> information of BEA Systems, Inc., its subsidiaries and affiliated
> entities, that may be confidential, proprietary, copyrighted and/or
> legally privileged, and is intended solely for the use of the individual or
> entity named in this message. If you are not the intended recipient, and
> have received this message in error, please immediately return this by email
> and then delete it.
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://incubator.apache.org/ivy/
http://www.xoocode.org/
Re: Configurations really hard to understand
Posted by Andy Piper <an...@bea.com>.
Yeah, so this is what I need too and am doing with virtual modules
(with a <publications/> section. It feels a little contrived however,
and I agree this particular use-case should be much simpler to
define. The simple things should be easy and complicated things
possible. Right now ivy configurations are very powerful, but not
ever simple from my POV...
andy
At 19:16 15/08/2007, Jeffrey Blattman wrote:
>i've never needed Ivy configurations. i need what maven has, and
>that's how i tried to apply it. i always understood configurations
>to be a generalized version of maven scopes as you are calling them.
>in fact i think i read that someone in the ivy docs.
>
>all i want to do is
>
>1. define a config
>2. be able to associate a config w/ a dependency
>3. be able to reference the dependencies by config name in
>ivy:resolve, retrieve, cachpath, etc
>
>i.e., configs are just a grouping of dependencies.
>
>it just seems like configurations could be greatly simplified to do
>the above and still handle 98% of the use cases. you don't need to
>"->" syntax do this for example.
>
>Xavier Hanin wrote:
>>On 8/15/07, Jeffrey Blattman <je...@gmail.com> wrote:
>>
>>>i don't mean to rain on dmitry's great explanation, but i think this
>>>might be the crux of the problem. there is one way to do it on maven,
>>>and no one has any questions about it. i to was / am confused by
>>>configurations in Ivy.
>>>
>>
>>
>>Not sure to get what you are meaning. Do you mean that we should only
>>provide one way to specify configuration mapping, or that we should simply
>>not provide flexible configuration mapping as we do? Maven has no concept of
>>configuration, they have scopes which are predefined and do not allow things
>>as flexible as you can do with Ivy. But maybe providing an easy to use
>>configuration mapping in Ivy could help users who don't want to take care
>>about understanding the real flexibility of configurations.
>>
>>Xavier
>>
>>Dmitriy Korobskiy wrote:
>>
>>>>2. How to specify this mapping? There are many ways in Ivy to do it.
>>>>
>>>Let's start
>>>
>>>>with explicit abbreviated mapping for each dependency:
>>>>
>>>>
>>>>
>>
>>
>>
>>
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Configurations really hard to understand
Posted by Xavier Hanin <xa...@gmail.com>.
On 8/15/07, Jing Xue <ji...@digizenstudio.com> wrote:
>
>
> Quoting Jeffrey Blattman <je...@gmail.com>:
>
> > i've never needed Ivy configurations. i need what maven has, and that's
> > how i tried to apply it. i always understood configurations to be a
> > generalized version of maven scopes as you are calling them. in fact i
> > think i read that someone in the ivy docs.
> >
> > all i want to do is
> >
> > 1. define a config
> > 2. be able to associate a config w/ a dependency
> > 3. be able to reference the dependencies by config name in ivy:resolve,
> > retrieve, cachpath, etc
> >
> > i.e., configs are just a grouping of dependencies.
> >
> > it just seems like configurations could be greatly simplified to do the
> > above and still handle 98% of the use cases. you don't need to "->"
> > syntax do this for example.
>
> But indeed you don't _need_ to use "->" for those cases at all - not
> even in ivy. 8-) You could just emulate maven scopes with
> configurations of the same name. That's actually how ivy deals with
> pom.xml internally.
>
> Now, the "98%" part is what I am not sure about. 8-) The value of
> ivy's configuration system, to me, lies in:
>
> 1. the ability to organize dependencies into hierarchies by either the
> relevant build aspects or the relevant features, rather than one or a
> couple of predefined flattened "mix-them-all-up" classpaths, and
> 2. the ability to control how transitive dependencies are applied
> through the configuration mappings.
>
> Together they make ivy incredibly valuable in terms of preventing an
> exponentially exploding dependency graph.
I'm happy to see that this powerful feature is considered very valuable by
users :-) Thanks for sharing that with the community!
Xavier
Maven driven projects often
> end up with a very bloated "lib directory" for this very reason. If
> you want to see a real-life example, try and have commons-logging 1.1
> as a dependency without any mappings or manual excludes. 8-)
>
> --
> Jing Xue
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://incubator.apache.org/ivy/
http://www.xoocode.org/
Re: Configurations really hard to understand
Posted by Jing Xue <ji...@digizenstudio.com>.
Quoting Jeffrey Blattman <je...@gmail.com>:
> i've never needed Ivy configurations. i need what maven has, and that's
> how i tried to apply it. i always understood configurations to be a
> generalized version of maven scopes as you are calling them. in fact i
> think i read that someone in the ivy docs.
>
> all i want to do is
>
> 1. define a config
> 2. be able to associate a config w/ a dependency
> 3. be able to reference the dependencies by config name in ivy:resolve,
> retrieve, cachpath, etc
>
> i.e., configs are just a grouping of dependencies.
>
> it just seems like configurations could be greatly simplified to do the
> above and still handle 98% of the use cases. you don't need to "->"
> syntax do this for example.
But indeed you don't _need_ to use "->" for those cases at all - not
even in ivy. 8-) You could just emulate maven scopes with
configurations of the same name. That's actually how ivy deals with
pom.xml internally.
Now, the "98%" part is what I am not sure about. 8-) The value of
ivy's configuration system, to me, lies in:
1. the ability to organize dependencies into hierarchies by either the
relevant build aspects or the relevant features, rather than one or a
couple of predefined flattened "mix-them-all-up" classpaths, and
2. the ability to control how transitive dependencies are applied
through the configuration mappings.
Together they make ivy incredibly valuable in terms of preventing an
exponentially exploding dependency graph. Maven driven projects often
end up with a very bloated "lib directory" for this very reason. If
you want to see a real-life example, try and have commons-logging 1.1
as a dependency without any mappings or manual excludes. 8-)
--
Jing Xue
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
RE: Configurations really hard to understand
Posted by "Loehr, Ruel" <rl...@pointserve.com>.
I'll second that. I found it pretty confusing and honestly still am not
100% sure of how it works.
-----Original Message-----
From: Jeffrey Blattman [mailto:jeffrey.blattman@gmail.com]
Sent: Wednesday, August 15, 2007 1:16 PM
To: ivy-user@incubator.apache.org
Subject: Re: Configurations really hard to understand
i've never needed Ivy configurations. i need what maven has, and that's
how i tried to apply it. i always understood configurations to be a
generalized version of maven scopes as you are calling them. in fact i
think i read that someone in the ivy docs.
all i want to do is
1. define a config
2. be able to associate a config w/ a dependency
3. be able to reference the dependencies by config name in ivy:resolve,
retrieve, cachpath, etc
i.e., configs are just a grouping of dependencies.
it just seems like configurations could be greatly simplified to do the
above and still handle 98% of the use cases. you don't need to "->"
syntax do this for example.
Xavier Hanin wrote:
> On 8/15/07, Jeffrey Blattman <je...@gmail.com> wrote:
>
>> i don't mean to rain on dmitry's great explanation, but i think this
>> might be the crux of the problem. there is one way to do it on maven,
>> and no one has any questions about it. i to was / am confused by
>> configurations in Ivy.
>>
>
>
> Not sure to get what you are meaning. Do you mean that we should only
> provide one way to specify configuration mapping, or that we should
simply
> not provide flexible configuration mapping as we do? Maven has no
concept of
> configuration, they have scopes which are predefined and do not allow
things
> as flexible as you can do with Ivy. But maybe providing an easy to use
> configuration mapping in Ivy could help users who don't want to take
care
> about understanding the real flexibility of configurations.
>
> Xavier
>
> Dmitriy Korobskiy wrote:
>
>>> 2. How to specify this mapping? There are many ways in Ivy to do it.
>>>
>> Let's start
>>
>>> with explicit abbreviated mapping for each dependency:
>>>
>>>
>>>
>
>
>
>
Re: Configurations really hard to understand
Posted by Jeffrey Blattman <je...@gmail.com>.
i've never needed Ivy configurations. i need what maven has, and that's
how i tried to apply it. i always understood configurations to be a
generalized version of maven scopes as you are calling them. in fact i
think i read that someone in the ivy docs.
all i want to do is
1. define a config
2. be able to associate a config w/ a dependency
3. be able to reference the dependencies by config name in ivy:resolve,
retrieve, cachpath, etc
i.e., configs are just a grouping of dependencies.
it just seems like configurations could be greatly simplified to do the
above and still handle 98% of the use cases. you don't need to "->"
syntax do this for example.
Xavier Hanin wrote:
> On 8/15/07, Jeffrey Blattman <je...@gmail.com> wrote:
>
>> i don't mean to rain on dmitry's great explanation, but i think this
>> might be the crux of the problem. there is one way to do it on maven,
>> and no one has any questions about it. i to was / am confused by
>> configurations in Ivy.
>>
>
>
> Not sure to get what you are meaning. Do you mean that we should only
> provide one way to specify configuration mapping, or that we should simply
> not provide flexible configuration mapping as we do? Maven has no concept of
> configuration, they have scopes which are predefined and do not allow things
> as flexible as you can do with Ivy. But maybe providing an easy to use
> configuration mapping in Ivy could help users who don't want to take care
> about understanding the real flexibility of configurations.
>
> Xavier
>
> Dmitriy Korobskiy wrote:
>
>>> 2. How to specify this mapping? There are many ways in Ivy to do it.
>>>
>> Let's start
>>
>>> with explicit abbreviated mapping for each dependency:
>>>
>>>
>>>
>
>
>
>
Re: Configurations really hard to understand
Posted by Xavier Hanin <xa...@gmail.com>.
On 8/15/07, Jeffrey Blattman <je...@gmail.com> wrote:
>
> i don't mean to rain on dmitry's great explanation, but i think this
> might be the crux of the problem. there is one way to do it on maven,
> and no one has any questions about it. i to was / am confused by
> configurations in Ivy.
Not sure to get what you are meaning. Do you mean that we should only
provide one way to specify configuration mapping, or that we should simply
not provide flexible configuration mapping as we do? Maven has no concept of
configuration, they have scopes which are predefined and do not allow things
as flexible as you can do with Ivy. But maybe providing an easy to use
configuration mapping in Ivy could help users who don't want to take care
about understanding the real flexibility of configurations.
Xavier
Dmitriy Korobskiy wrote:
> >
> > 2. How to specify this mapping? There are many ways in Ivy to do it.
> Let's start
> > with explicit abbreviated mapping for each dependency:
> >
> >
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://incubator.apache.org/ivy/
http://www.xoocode.org/
Re: Configurations really hard to understand
Posted by Jeffrey Blattman <je...@gmail.com>.
i don't mean to rain on dmitry's great explanation, but i think this
might be the crux of the problem. there is one way to do it on maven,
and no one has any questions about it. i to was / am confused by
configurations in Ivy.
Dmitriy Korobskiy wrote:
>
> 2. How to specify this mapping? There are many ways in Ivy to do it. Let's start
> with explicit abbreviated mapping for each dependency:
>
>
Re: Configurations really hard to understand
Posted by David R Robison <dr...@openroadsconsulting.com>.
Thanks for the discussion, this really clarified the idea of
configurations for me. Thanks again, David
Xavier Hanin wrote:
> On 8/14/07, Dmitriy Korobskiy <dk...@gmail.com> wrote:
>
>> Hi, Andy
>> Re: your e-mail from Tuesday, August 14, 2007 7:36 AM
>>
>>
>>> Every time I think I have understood configurations my more
>>> sophisticated attempts to use them result in resolution errors in
>>> ivy. I have been through the tutorial and the docs many times. Does
>>> anyone have a good write-up of configuration usage other than the one
>>> on the website?
>>>
>> I think I grok Ivy configurations. I'll try to explain the gist of them
>> below.
>>
>
>
> Very good explanations Dmitriy, I wouldn't have done better myself. Just one
> thing to add about the syntax, the arrow (->) should be read as "depends on"
> or "is mapped to", it helps to remember what the left hand and right hand
> sides of the configuration mapping are for. For those who don't like this
> syntax, there's still the verbose syntax:
> <dependency org="foo" name="bar" rev="1.0" />
> <conf name="test">
> <mapped name="x"/>
> <mapped name="y"/>
> </conf>
> </dependency>
>
> Xavier
>
>
>> In particular I am having problems with "default". This is implicitly
>>
>>> defined unless you create your own configurations. If I add my other
>>> configuration how do I specify some of the dependencies to have the
>>> default configuration? "default", "default->default"?
>>>
>> It is important to keep in mind that configurations of your module are
>> *not*
>> automatically related to configurations of your dependencies. So, you
>> might have
>> configurations "test" and "default" in your module, "x","y" and "z" in "
>> foo.bar"
>> and only "default" in "foo.baz" (if, say, "foo.baz" does not have an Ivy
>> file
>> whatsoever).
>>
>> The crux of handling configurations is to understand configuration
>> mappings.
>> Configuration mappings should define for *each* dependency, how
>> configurations
>> of your module *map* to configurations of dependent modules. For example,
>> configuration "test" of your module maps to configurations of "x,y" of "
>> foo.bar"
>> and "default" of "foo.baz". There are two questions here:
>>
>> 1. What does it mean?
>> a) then you resolve "test" configuration of your module - аll the
>> artifacts
>> and dependencies for "x" and "y" configuration of "foo.bar" and "default"
>> of
>> "foo.baz" would be in the dep. graph
>> b) when a consuming (parent) module consumes configuration "test" of your
>> module
>> in a transitive way - ditto
>>
>> 2. How to specify this mapping? There are many ways in Ivy to do it. Let's
>> start
>> with explicit abbreviated mapping for each dependency:
>>
>> <dependencies>
>> <dependency org="foo" name="bar" rev="1.0" conf="test->x,y"/>
>> <dependency org="foo" name="baz" rev="1.0" conf="test->default"/>
>> </dependencies>
>>
>> Now, this specification can be optimized further in multiple ways:
>>
>> a. If *all* configurations are mapped to, say, "default" of "foo.baz",
>> it'd mean
>> "*->default" or "*->*". In that case the mapping could be omitted
>> altogether.
>>
>> b. The same mapping for multiple dependencies can be specified as
>> defaultconf:
>>
>> <dependencies defaultconf="test->x,y">
>> <dependency org="foo" name="bar" rev="1.0"/>
>> <dependency org="foo" name="baz" rev="1.0" conf="test->default"/>
>> </dependencies>
>>
>> c. There is also defaulconfmapping, but I'd not go there - let's leave it
>> for an
>> advanced course. :)
>>
>>
>>> In particular lets say I have module A and module B. Both of these
>>> have some shared dependencies that should be available at build-time
>>> but not test time. My naive configuration would look something like
>>>
>> this:
>>
>>
>>> <configurations>
>>> <conf name="test"/>
>>> <conf name="default"/>
>>> </configurations>
>>> <dependencies defaultconf="default">
>>> <dependency org="foo" name="bar" rev="1.0"
>>>
>> conf="test->default"/>
>>
>>> <dependency org="foo" name="baz" rev="1.0"/>
>>> </dependencies>
>>>
>>> But this seems to do something subtly different to what I intend. In
>>> particular the definition of foo.bar seems to require a definition of
>>> the default configuration.
>>>
>>> Any help or insights appreciated. Apologies for the somewhat random
>>> stream of consciousness.
>>>
>>> [Note I don't think the current configuration syntax is particularly
>>> intuitive, but I'm not sure what I would suggest as an alternative.]
>>>
>>> andy
>>>
>> I hope it helps.
>>
>> Dmitriy <1-127-441 @ICQ, DKroot @Skype>
>> <DKroot1 @AIM, dkroot1_at_gmail_dot_com @Google Talk or @MSN, dk_root
>> @Yahoo>
>>
>>
>>
>
>
>
--
David R Robison
Open Roads Consulting, Inc.
708 S. Battlefield Blvd., Chesapeake, VA 23322
phone: (757) 546-3401
e-mail: drrobison@openroadsconsulting.com
web: http://openroadsconsulting.com
blog: http://therobe.blogspot.com
book: http://www.xulonpress.com/book_detail.php?id=2579
Re: Configurations really hard to understand
Posted by Xavier Hanin <xa...@gmail.com>.
On 8/14/07, Dmitriy Korobskiy <dk...@gmail.com> wrote:
>
> Hi, Andy
> Re: your e-mail from Tuesday, August 14, 2007 7:36 AM
>
> > Every time I think I have understood configurations my more
> > sophisticated attempts to use them result in resolution errors in
> > ivy. I have been through the tutorial and the docs many times. Does
> > anyone have a good write-up of configuration usage other than the one
> > on the website?
>
> I think I grok Ivy configurations. I'll try to explain the gist of them
> below.
Very good explanations Dmitriy, I wouldn't have done better myself. Just one
thing to add about the syntax, the arrow (->) should be read as "depends on"
or "is mapped to", it helps to remember what the left hand and right hand
sides of the configuration mapping are for. For those who don't like this
syntax, there's still the verbose syntax:
<dependency org="foo" name="bar" rev="1.0" />
<conf name="test">
<mapped name="x"/>
<mapped name="y"/>
</conf>
</dependency>
Xavier
> In particular I am having problems with "default". This is implicitly
> > defined unless you create your own configurations. If I add my other
> > configuration how do I specify some of the dependencies to have the
> > default configuration? "default", "default->default"?
>
> It is important to keep in mind that configurations of your module are
> *not*
> automatically related to configurations of your dependencies. So, you
> might have
> configurations "test" and "default" in your module, "x","y" and "z" in "
> foo.bar"
> and only "default" in "foo.baz" (if, say, "foo.baz" does not have an Ivy
> file
> whatsoever).
>
> The crux of handling configurations is to understand configuration
> mappings.
> Configuration mappings should define for *each* dependency, how
> configurations
> of your module *map* to configurations of dependent modules. For example,
> configuration "test" of your module maps to configurations of "x,y" of "
> foo.bar"
> and "default" of "foo.baz". There are two questions here:
>
> 1. What does it mean?
> a) then you resolve "test" configuration of your module - аll the
> artifacts
> and dependencies for "x" and "y" configuration of "foo.bar" and "default"
> of
> "foo.baz" would be in the dep. graph
> b) when a consuming (parent) module consumes configuration "test" of your
> module
> in a transitive way - ditto
>
> 2. How to specify this mapping? There are many ways in Ivy to do it. Let's
> start
> with explicit abbreviated mapping for each dependency:
>
> <dependencies>
> <dependency org="foo" name="bar" rev="1.0" conf="test->x,y"/>
> <dependency org="foo" name="baz" rev="1.0" conf="test->default"/>
> </dependencies>
>
> Now, this specification can be optimized further in multiple ways:
>
> a. If *all* configurations are mapped to, say, "default" of "foo.baz",
> it'd mean
> "*->default" or "*->*". In that case the mapping could be omitted
> altogether.
>
> b. The same mapping for multiple dependencies can be specified as
> defaultconf:
>
> <dependencies defaultconf="test->x,y">
> <dependency org="foo" name="bar" rev="1.0"/>
> <dependency org="foo" name="baz" rev="1.0" conf="test->default"/>
> </dependencies>
>
> c. There is also defaulconfmapping, but I'd not go there - let's leave it
> for an
> advanced course. :)
>
> > In particular lets say I have module A and module B. Both of these
> > have some shared dependencies that should be available at build-time
> > but not test time. My naive configuration would look something like
> this:
>
> > <configurations>
> > <conf name="test"/>
> > <conf name="default"/>
> > </configurations>
> > <dependencies defaultconf="default">
> > <dependency org="foo" name="bar" rev="1.0"
> conf="test->default"/>
> > <dependency org="foo" name="baz" rev="1.0"/>
> > </dependencies>
>
> > But this seems to do something subtly different to what I intend. In
> > particular the definition of foo.bar seems to require a definition of
> > the default configuration.
>
> > Any help or insights appreciated. Apologies for the somewhat random
> > stream of consciousness.
>
> > [Note I don't think the current configuration syntax is particularly
> > intuitive, but I'm not sure what I would suggest as an alternative.]
>
> > andy
>
> I hope it helps.
>
> Dmitriy <1-127-441 @ICQ, DKroot @Skype>
> <DKroot1 @AIM, dkroot1_at_gmail_dot_com @Google Talk or @MSN, dk_root
> @Yahoo>
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://incubator.apache.org/ivy/
http://www.xoocode.org/
Re: Configurations really hard to understand
Posted by Dmitriy Korobskiy <dk...@gmail.com>.
Hi, Andy
Re: your e-mail from Tuesday, August 14, 2007 7:36 AM
> Every time I think I have understood configurations my more
> sophisticated attempts to use them result in resolution errors in
> ivy. I have been through the tutorial and the docs many times. Does
> anyone have a good write-up of configuration usage other than the one
> on the website?
I think I grok Ivy configurations. I'll try to explain the gist of them below.
> In particular I am having problems with "default". This is implicitly
> defined unless you create your own configurations. If I add my other
> configuration how do I specify some of the dependencies to have the
> default configuration? "default", "default->default"?
It is important to keep in mind that configurations of your module are *not*
automatically related to configurations of your dependencies. So, you might have
configurations "test" and "default" in your module, "x","y" and "z" in "foo.bar"
and only "default" in "foo.baz" (if, say, "foo.baz" does not have an Ivy file
whatsoever).
The crux of handling configurations is to understand configuration mappings.
Configuration mappings should define for *each* dependency, how configurations
of your module *map* to configurations of dependent modules. For example,
configuration "test" of your module maps to configurations of "x,y" of "foo.bar"
and "default" of "foo.baz". There are two questions here:
1. What does it mean?
a) then you resolve "test" configuration of your module - аll the artifacts
and dependencies for "x" and "y" configuration of "foo.bar" and "default" of
"foo.baz" would be in the dep. graph
b) when a consuming (parent) module consumes configuration "test" of your module
in a transitive way - ditto
2. How to specify this mapping? There are many ways in Ivy to do it. Let's start
with explicit abbreviated mapping for each dependency:
<dependencies>
<dependency org="foo" name="bar" rev="1.0" conf="test->x,y"/>
<dependency org="foo" name="baz" rev="1.0" conf="test->default"/>
</dependencies>
Now, this specification can be optimized further in multiple ways:
a. If *all* configurations are mapped to, say, "default" of "foo.baz", it'd mean
"*->default" or "*->*". In that case the mapping could be omitted altogether.
b. The same mapping for multiple dependencies can be specified as defaultconf:
<dependencies defaultconf="test->x,y">
<dependency org="foo" name="bar" rev="1.0"/>
<dependency org="foo" name="baz" rev="1.0" conf="test->default"/>
</dependencies>
c. There is also defaulconfmapping, but I'd not go there - let's leave it for an
advanced course. :)
> In particular lets say I have module A and module B. Both of these
> have some shared dependencies that should be available at build-time
> but not test time. My naive configuration would look something like this:
> <configurations>
> <conf name="test"/>
> <conf name="default"/>
> </configurations>
> <dependencies defaultconf="default">
> <dependency org="foo" name="bar" rev="1.0" conf="test->default"/>
> <dependency org="foo" name="baz" rev="1.0"/>
> </dependencies>
> But this seems to do something subtly different to what I intend. In
> particular the definition of foo.bar seems to require a definition of
> the default configuration.
> Any help or insights appreciated. Apologies for the somewhat random
> stream of consciousness.
> [Note I don't think the current configuration syntax is particularly
> intuitive, but I'm not sure what I would suggest as an alternative.]
> andy
I hope it helps.
Dmitriy <1-127-441 @ICQ, DKroot @Skype>
<DKroot1 @AIM, dkroot1_at_gmail_dot_com @Google Talk or @MSN, dk_root @Yahoo>