Alan Chaney wrote:
I have a setup with a chain repository which has a repository for jar
files used to build a set of war files (using a number of different
permutations). I publish the jar files into one element of the chain and
the war files into another. The war files are then made available via a
company-wide repository.
It so happens that one of the war files has the same name as a jar file.
You mean that org and module are the modules having completely different
artifacts? That doesn't seem like a good idea. You're meant to have
different module names for different ivy files (obviously ivy files
change over time (revision) and potentially branch, but they are still
the same logical module with the same artifacts).
As part of the build process for a JAR I resolve that jar in-line to get
the most recent build number. However, for some reason, the resolver
insists on returning the WAR file build number which happens to be
wildly different from the jar file and not what I want at all.
I tried to set the type="jar" in the retrieve (as below) but it makes no
difference. So then I looked a bit more closely and determined that
maybe I should try a static resolve mode with a limit on the version
number. But that doesn't work either! The resolve fails, and, sure
enough, the next thing that happens is that the buildnumber task uses
'latest.integration'.
"2.0-" doesn't match the documentation for version < 2.0 (is that what
you were trying?). I think you need:
"(,2.0["
(see
http://ant.apache.org/ivy/history/latest-release/ivyfile/dependency.html)
Is there a way of getting the buildnumber task to only consider
particular artifacts?
All artifacts for a ivy file have the same revision number anyway, so
I'm not sure that would help.
Of course, another way (apart from renaming the
jar which would not be very convenient) is to create a different
settings file which specifically points to the jar resolver, I suppose.
Why not rename the module rather than the jar? As far as I can tell, the
jar and the war are not part of the same module, so why give them the
same module name? The artifact names need not change in order to change
the module names.
I hope this helps - I may have missed the issue.
Tom
