ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Chaney <>
Subject Re: Branch Management
Date Thu, 09 Apr 2009 16:08:51 GMT
How about the concept of a default branch? As in the subversion 'trunk'. 
So, if no branch is specified, you assume the default. Since the "pass" 
and "fail" here in the conflict manager are used to select which 
artifacts are included in the resolution (ie classpath) isn't that what 
you want.

In your examples below, either ORANGE or APPLE might be the default, or 
they might both be branches from TRUNK?

Would that help resolve (hee hee) your problem?


Paul Duffin wrote:
> Alan,
>     I came to the same conclusion about the conflict manager, have 
> been looking at the source for Ivy to see how they work and how to 
> extend / modify them.
> Apart from ignoring or failing I can't see any other approach to 
> dealing with branches because as we use them they don't have any order 
> and by definition are conflicting, e.g. one branch has one change in 
> another branch has a different change in, so if both are needed by 
> another module then it is an error that can only be resolved by 
> merging the two together.
> So if you have the following revisions what should the behavior be:
> 1.1.0 branch ORANGE
> 1.1.0 branch APPLE
> 1.2
> Does this fail because revision 1.1.0 has two branches, or is it 
> assumed that 1.2 supersedes all 1.1.0 revisions and so works. My gut 
> feel is that it should work but that if I have.
> 1.1.0
> 1.2 branch ORANGE
> 1.2 branch APPLE
> Then it should fail. So the branch only affects the revision that was 
> selected by the conflict manager and does not affect the selection of 
> that revision.
> Alan Chaney wrote:
>> I find your comments very interesting, Paul, because I have similar 
>> issues with my projects.
>> It seems to me that one solution is to provide a custom conflict 
>> manager which does, in fact, check the branch. I don't believe that 
>> one exists.
>> I'd be interested in working on this with you because, as I said, 
>> I've got the same problem!
>> There appears to be an AbstractConflictManager in the 
>> org.apache.ivy.plugins.conflict package which is intended to be 
>> extended. The docs are a little terse on the exact details of using 
>> this. However, looking at the code from svn it appears the 
>> ModuleRevisionId is part of the IvyNode and this is accessible from the
>> resolveConflicts (which passes the parent and the conflicts to resolve)
>> In my case (which must be quite typical) I have a master library 
>> which has all the 3rd party jars in it. My own projects build 
>> intermediate jars which are resolved into final artifacts (actually 
>> currently all wars) I store the intermediate jars and wars in a 
>> 'working' and 'published' repository shared between developers.
>> It seems to me that these repositories would have to have a pattern 
>> which actually included the branch to ensure that a particular 
>> intermediate jar could be picked up and used with the right 
>> dependencies. I've considered but don't think 'confs' are the right 
>> way to go, because you want to be able to add/remove a version 
>> control branch without having to modify all the conf files - obvious 
>> really...
>> Interested in your feedback.
>> Regards
>> Alan Chaney
>> Paul Duffin wrote:
>>> There are three issues that I am trying to resolve here:
>>> 1) Simply to understand what it is intended for and how it works / 
>>> behaves, i.e. to satisfy my curiosity. I have looked at the code but 
>>> that only shows me how it behaves, which may be different from what 
>>> was intended and how it should behave.
>>> From the looks of the code the branch is just a part of the 
>>> ModuleRevisionId, can be used in patterns but otherwise nothing 
>>> really does anything else with it. The module setting does allow the 
>>> assignment of a default branch with a module and it can also be used 
>>> explicitly in dependencies.
>>> It seems to me that a conflict manager should check branch as well 
>>> as revision when attempting to resolve.
>>> 2) In our organisation we are maintaining a number of different 
>>> 'products' that have various dependencies on each other. Each 
>>> product has an architectural aspect as well as an implementation 
>>> aspect. The architecture is done in advance of implementation and it 
>>> may be that due to business decisions some work that is architected 
>>> is never implemented. At any one time there may be multiple pieces 
>>> of separate architecture outstanding (not yet approved into main 
>>> trunk), the same applies to implementation. Each piece of work is 
>>> done on its own branch before being committed to main trunk.
>>> Each aspect of the product is in its own Git repository, and the 
>>> implementation is split into open source and professional 
>>> repositories. We use a custom build based on top of our own home 
>>> grown build system built using Groovy / Ant / Ivy / Java.
>>> So it is a quite complicated structure and we are using Ivy to 
>>> organize the created artifacts to provide inter product dependencies.
>>> So if I have A:1.0:master (product A version 1.0 on branch master) 
>>> that depends on B:1.1:other and C:2.0:master and B:1.1:other depends 
>>> on C:2.0:other then when I build product A I have a conflict between 
>>> C:2.0:master and C:2.0:other.
>>> At the moment we encode the branch and version number into the Ivy 
>>> revision number so that Ivy detects a conflict but I was looking at 
>>> using Ivy branches instead and wanted to know what behavior Ivy 
>>> would have.
>>> Ideally I would like it so that Ivy would fail if I had the same 
>>> revision of an artifact from different branches.
>>> 3) We use many javax API specification JARs and need to compile 
>>> against them and also make them available to the open source 
>>> community. We use open source libraries that depend on different 
>>> implementation versions of the same specification version, e.g. 
>>> geronimo-activation_1.0.2_spec has according to 

>>> 3 implementation versions 1.0, 1.1 and 1.2. They also can depend on 
>>> different specification versions, e.g. geronimo-activation_1.1_spec.
>>> Geronimo as they are using Maven encode the specification version in 
>>> the  artifact id and use the artifact version for the 
>>> implementation. Unfortunately, this means that if I transitively 
>>> depend on both versions Ivy will treat them as different JARS so 
>>> they won't be in conflict but will cause all sorts of problems when 
>>> attempting to compile against and run.
>>> So what I was thinking was to use the specification version as the 
>>> Ivy revision and the implementation version as a branch. This would 
>>> have the same rules as above, i.e. fail if I had the same revision 
>>> of an artifact from different branches.
>>> Benjamin Damm wrote:
>>>> Branching is not a first-class concept in the ivy world, that I 
>>>> know if.
>>>> Is there an integration with your revision control that you're trying
>>>> out?  Here we just don't branch the ivy repository, that seems to be
>>>> common because the binary artifacts shouldn't change.
>>>> On Tue, 2009-04-07 at 12:12 +0100, Paul Duffin wrote:
>>>>> I have a couple of questions about branches in Ivy. I have 
>>>>> searched high and low for any information on it but cannot find it 
>>>>> either on mailing lists or on internet in general. Searching for 
>>>>> "ivy branch" brings up a lot of gardening references.
>>>>> Apologies if I have missed something obvious, or am just being 
>>>>> stupid but I can't get my head around this at the moment so would 
>>>>> appreciate any help you could give.
>>>>> What is the purpose of branches in Ivy? I presume they are related 
>>>>> to branches in version control systems but cannot find a concrete 
>>>>> example of how or why you would use them.
>>>>> How do they affect conflict resolution? e.g. say thanks to 
>>>>> transitive dependencies I have two modules, com.acme#dynamite;1.0 
>>>>> on branch1 and com.acme#dynamite;1.0 on branch2 is that a 
>>>>> conflict? I presume that it is. If so how is it resolved, in 
>>>>> favour of branch1, branch2 or neither it just fails.
> !DSPAM:49de1c16232383033718476!

View raw message