ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: Configuration notation extension
Date Fri, 02 Nov 2007 07:57:01 GMT
On 11/1/07, John Rasmussen <> wrote:
> I'm looking for a more powerful notation of the conf attribute in the
> dependency tag in ivy.xml.
> A little introduction before the question:
> In some cases I define one or more "submodules" to an ivy module
>   (In most cases an ivy module is just one artifact(jar file)).
> Furthermore I have a number of ivy configurations defined for each
> module (the specific configurations are not relevant for the
> question):
> build          - configuration of artifacts needed to build the module.
> compile        - configuration of artifacts needed for another module
> to build with this module
> runtime        - configuration of artifacts needed for the module
> build at runtime.
> source         - configuration of artifacts java source
> documentation  - configuration of artifacts javadoc
> If a submodule is defined then another 4 configurations will be
> defined: <sub>-compile, <sub>-runtime, <sub>-source,
> <sub>-documentation
> Thus a dependency to submodule A in myModule looks:
> <dependency org="..." name="myModule" rev="..."
>    conf="build->subA-compile ; runtime->subA-runtime ;
> source->subA-source ; documentation->subA-documentation"/>
> which is kind of saying: I need build, runtime, source and
> documentation stuff from subModule A in myModule.
> Now for the question:
> Has anyone considered a notation to express the above conf in a shorter
> way?
> Or, handling submodules in another way (still having javadoc and javasrc)?
> I have considered some kind of macro notation, but I'm not sure, I
> like that idea...
> A (or more) macro could be defined in the <configuration> section,
> near the defaultconfmapping attribute and look like:
> "myMacro{x}=build->@{x}-compile ; runtime->@{x}-runtime ;
> source->{@}x-source ; documentation->@{x}-documentation"
> which gives a dependency as:
> <dependency org="..." name="myModule" rev="..."  conf="myMacro{subA}"/>
> Normally, we do not use submodules but split a module into a number of
> modules, and then add the dependencies.
> But sometimes it is hard to split a module, and then we create one or
> more submodules with "subparts of the module".
> Most modules have no submodule, hence setting
> defaultconfmapping="build->compile;runtime;source;documentation"
> means that it is not necessary to specify the conf attribute of the
> module dependency.
> I know some find the current notation of the conf attribute too
> complicated, though.

I understand your use case, and I'm not sure of the right answer to your
problem. I tihnk the macro solution shouldn't be too complex implement, and
is very flexible. I'm not sure if it adds complexity to the conf attribute,
since it doesn't add a new behavior to configuration mapping, it's just a
kind of shortcut, but underneath configuration mapping is still the same.
Well, with your example I'm not sure to understand what the @ stands for,
but this is a minor problem.

OTOH, I think your use case could be handled with another configuration
mapping enhancement. Some users already requested that for quite a long
time, the idea is to be able to combine configurations with binary
operators. ATM, when you have "confA -> confB,confC", you will get both
confB and confC of the dependency in confA. Some would like in some cases to
get an intersection of configurations rather than an union (sort of
combining confs with an AND rather than an OR. With such a feature, you
could simply add one conf per sub module (rather than one for each sub
module configuration) and one for the whole module. Then you would just have
to combine your default conf mapping AND the sub module conf. I'm not sure
how easy this is to understand and/or to implement, but I know some users
already thought at that as a more flexible to define their configuration


Thanks for a powerful tool.
> Regards
>   John Rasmussen

Xavier Hanin - Independent Java Consultant

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message