Hello there,
I asked this question on
ivy-u...@ant.apache.org<mailto:ivy-u...@ant.apache.org> but without much
response, so I thought I'd give dev@ant.apache.org<mailto:dev@ant.apache.org> a
try:
Is there a way to make ivy:install install transitive dependencies that are
defined within a private configuration?
Let me explain why I want this feature, or at least a way around the current
behaviour.
Consider that I am developing a module. It has several artefacts published via
public configurations and some private configurations which are used for
dependency resolution as part of the build. Here is an example:
<configurations>
<conf name="build" visibility="private"/>
<conf name="docs"/>
<conf name="binaries"/>
</configurations>
<publications>
<artifact name="readme" ext="txt" type="text" conf="docs"/>
<artifact name="foo" ext="dll" type="library" conf="binaries"/>
</publications>
<dependencies>
<dependency org="myorg" name="bar" rev="latest.integration">
<conf name="build" mapped="libs"/>
</dependency>
</dependencies>
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?
Looking at the code it seems possible to avoid this issue by passing "false" as
the value of shouldBePublic to the IvyNode.handleConfiguration function,
however tracing back through the function calls I eventually end up in
ResolveEngine.fetchDependencies / doFetchDependencies functions which, during a
resolve, will call VisitNode.loadData sometimes hardcoding the value of
shouldBePublic to false sometimes to true.
Regards
Jonathan
