ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Oster" <>
Subject Publishing multiple artifacts with different patterns
Date Fri, 02 Oct 2009 17:44:58 GMT
I¹ve been successfully using Ivy on a very large project for quite some
time, but I¹m trying to fix a minor annoyance I¹ve had with respect to
publishing.  I have a filesystem resolver with a pattern like this:

Basically I have a directory for each revision, and some artifacts have
their revision in the filename, and some do not.

If I have multiple artifacts being published and I am using different
artifact patterns for them, things publish fine, but they all get published
with the top artifact pattern specified in my resolver.
For example, if I have  a project publishing some jar files with the
revision in the file name, and some schemas without, my publish task has
these children:
      <artifacts pattern="${basedir}/build/[artifact]-[revision].[ext]" />
      <artifacts pattern="${basedir}/schema/[artifact].[ext]" />

All of my artifacts get properly found and published, but they all show up
in the repository with the first artifact pattern specified in my resolver.
Is there some way to relate each publish task¹s nested artifact pattern to
an appropriate artifact pattern in the specified resolver?  The main reason
this causes issues is the consumer of these artifacts needs special handling
to convert them back.

I glanced at the code, and if I understand it correctly, this behavior seems
to come from the publish(..) method of the RespositoryResolver, namely these
lines of code:
 } else if (!getArtifactPatterns().isEmpty()) {
            destPattern = (String) getArtifactPatterns().get(0);

I¹m not sure how exactly I expect it to work, but it doesn¹t seem right to
ignore the indirect relationship between the pattern used to locate the
artifact locally, and publish it remotely.  I would imagine in most
scenarios there is a correlation between the two.  One suggestion I can
think of is if there is more than one pattern in the resolver, try to use
the one that has the most similar ³variables² as the pattern of the
artifact.  This wouldn¹t handle every possible scenario, but should deal
with what I would think would be a common is situation: specifying or not
specifying a revision.

The other idea I had was to allow one to name the patterns in the resolver,
and refer to them by name in the publish task, and fall back to the current
behavior if nothing was specified.
For example, in the resolver:
].[ext]" name=²revision-specified²/>
And in the publish list, something like:
      <artifacts pattern="${basedir}/build/[artifact]-[revision].[ext]"
resolverPatternName=²revision-specified² />
      <artifacts pattern="${basedir}/schema/[artifact].[ext]"
resolverPatternName=²non-revision-specified²  />

I think this would handle all possible situations, but it may be overly

Thoughts or suggestions?

Scott Oster

Software Research Institute
Center for IT Innovations in Healthcare

Senior Researcher
Department of Biomedical Informatics

The Ohio State University
Phone: (614) 293-9590

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