The mapped attribute is explained here: http://ant.apache.org/ivy/history/latest-milestone/ivyfile/dependency-conf.html It allows you to express dependency mappings without the need to use the "from this -> to this" notation.
I must admit that I am very surprised to hear that by convention the build configuration should be public. The Ivy documentation for configurations: http://ant.apache.org/ivy/history/latest-milestone/ivyfile/conf.html gives an example where both the core and compile configurations are private, this is analogous to what I am doing with my build configuration. Surely users of my module may be interested in the jars / libs / header files that I publish and even any transitive artefacts that they may require, but why would a user of my module be interested in the dependencies that I require to compile the artefacts? I am reluctant to modify and recompile our ivy.jar, this is bound to cause headaches when we upgrade in the future. However, reworking all our existing Ivy descriptors does not seem to be a good option either. I could look at the source code and potentially submit a patch for this feature, would this be something the community would be interested in? Jonathan Oulds Software Engineer / PSC - Drive Encryption McAfee, Inc. Direct: +44 (0)1273 669419 Web: www.mcafee.com -----Original Message----- From: Kirby Files [mailto:[email protected]] Sent: 02 August 2013 17:33 To: [email protected] Cc: Oulds, Jonathan Subject: Re: ivy:install [email protected] wrote on 08/02/2013 12:08 PM: > So I use the build configuration to pull the libs configuration from > the latest version of the myorg#bar module. This works fine for > building the module. However, sometimes I want to develop my module > while sitting on a plane with no access to my corporate Ivy > repository, the solution use ivy:install to create an "offline" > repository on my laptop before I leave the office. However > ivy:install does not want to pull dependencies for the private "build" > configuration which means the myorg#bar module is not installed. Is > there any way around this other than change all my private > configurations to public? I cannot see why ivy:install should pull private dependencies, even in this case. I am not familiar enough with the internals of the transitive resolution used by ivy:install to know how hard it would be to hack such a knob, but it would seem counter to any expectations. Really, the convention in both ivy and maven is that build configurations are public. You want to declare the required dependencies for building the project. I would use private configurations for optional tests, IvyDE-specific subsets, or perhaps various documentation-generation tasks. BTW, what is the implication of the "mapped" attribute of the conf element? I don't see that in the 2.3 documentation. Thanks, --- Kirby Files Software Architect Masergy Communications [email protected]
