ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Rasmussen <>
Subject Re: Configuration notation extension
Date Thu, 15 Nov 2007 12:48:04 GMT

Xavier Hanin wrote:
> 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
> mapping.
I think the idea of intersection is a good idea, which in some way is
similar to use subsets.
Submodules can be handled with subsets in the following way.
Like you suggested a submodule-artifact is added to ONE configuration for
the submodule and the submodule-artifact is also added to the
"category"(build,runtime,...) configuration.
A proposal is to extend the conf mapping spec of the dependency tag in some
way like:
conf="subA{}"                        - Only use artifacts in configuration
subA, use defaultconfmapping
conf="subA{runtime}"              - Only use artifacts in configuration
subA, use confmapping "runtime"
conf="subA{runtime};subB{}"    - Artifacts in configuration subA, mapping
"runtime" and also artifacts in configuration subB using defaultconfmapping.
conf="subA+subB{runtime}"       - Only use artifacts in configuration subA
or subB, use confmapping "runtime"

That is the conf notation spec could be extended in some way like:
<configuration>+...+<configuration>{<mapping configuration spec without
subset notation>};...;<conf configuration spec>
The main idea is to apply a mapping configuration spec to a configuration (a
I think the '+' is no more important than "nice to have".

In ivy.xml terms the dependency module referenced above look like:
<configurations defaultconfmapping="build;runtime">
  <conf name="build"/>
  <conf name="runtime"/>
  <conf name="subA"/>
  <conf name="subB"/>
  <artifact name="subA-build" type="jar" conf="build,subA"/>
  <artifact name="subA-runtime" type="jar" conf="runtime,subA"/>
  <artifact name="subB-runtime" type="jar" conf="runtime,subB"/>

  / John

View this message in context:
Sent from the ivy-user mailing list archive at

View raw message