Hi, Scott Re: your e-mail from Friday, August 10, 2007 2:55 AM > To help organize my nightly build repositories, I'm using the following file > system layout:
> .../module/revision/build#/ivy.xml > So, for each revision, there is a sub folder for each nightly build. Scott, what I'm thinking about your use case is that your /revision/ is not really a real module revision. What I mean is that you are probably building nightly builds for, say, an upcoming "2.0" release. The revision of your builds then is not really "2.0". It is "build#". Revision in my mind is a number that uniquely identifies the build of a particular module. If build#-s in your case are naturally ordered, for example "20070810", "20070811", Ivy's latest strategy would work in conjunction with using branches. The layout would be something like .../[module]/[branch]/[revision]/ivy.xml Another option is not to use [branch] and number your builds using something like 2.0.nightly-20070810. Just some thoughts. You might need to adjust this approach for your repository. Also see http://incubator.apache.org/ivy/history/trunk/bestpractices.html that discusses these issues. > Unfortunatley, this doesn't seem to fit well with Ivy's Latest strategy > functionality. Following the dynamic resolution code path, it eventually > leads to "ResolverHelper.findAll(...)", which hard codes the partial pattern > matching to substitute all tokens except the revision token: > String partiallyResolvedPattern = > IvyPatternHelper.substitute(pattern, > ModuleRevisionId.newInstance(mrid, > IvyPatternHelper.getTokenString(IvyPatternHelper.REVISION_KEY)), artifact); > In my case, however, I need the latest strategy to be based on the build > number and not the revision. I've tried a few things to solve this: > 1. Change the repository pattern to > .../[module]/[version]/[revision]/ivy.xml. In other words, use an extra > attribute, "version", as the revision and, "revision" as the build number. > This works to a degree. The problems are that when I append the revisions > to my artifaces (artifact-revision.ext), I get the build number rather than > the actual revision. The second problem is that when I want to publish the > artifact in a release respository (i.e. promote the nightly build to release > status), I have to change all of the version attributes to revision > attributes, because the release repository doesn't have build numbers. That's similar to what I'm thinking, except that if you need to promote nightly "build#" to "2.0", only revision would change which Ivy supports in the publish target. You can simply ignore branches in the release repository. > 2. I tried creating a custom version matcher and latest strategy plugin. > This is a bit of a hack, since the resolver still resolved based on partial > match up to the revision token in the pattern. The Latest Strategy, in teh > sort method, takes each path found (.../module/revision/), finds all of the > children (../module/revision/build#), and adds them to the sort result. So, > the sort() method becomes overloaded to not just sort, but to find all of > the build number subfolders as well. In addition, due to architecture, it > has to do some casting from interface to concrete class from another > package, so it gets really ugly. I quickly threw out this option. > 3. The last option, which I didn't bother pursuing, was to write a custom > resolver and replace the findResourceUsingPattern(...) functionality of the > RepositoryResolver. This seemed like quite a bit of work and quite a bit of > code replication. > So, I'm stuck with the first option at the moment. Is there a better way? > If there was a way of extending the functionality of Ivy to provide this, > what would be the best approach? > Thanks. > Scott Dmitriy <1-127-441 @ICQ, DKroot @Skype> <DKroot1 @AIM, dkroot1_at_gmail_dot_com @Google Talk or @MSN, dk_root @Yahoo>
