ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Duffin <pduf...@volantis.com>
Subject Re: Branch Management
Date Wed, 15 Apr 2009 08:07:57 GMT
Not sure what a default branch would give you, BTW you can already 
specify a default branch globally and for specific modules.

In terms of the second example, which is the one that really concerns me 
I want it to fail because there is a problem with my dependencies.

e.g. say for artifact S at version 1.2 (from which the other two are 
branched) I have:

public interface Sample {
    String getName();
}

And in version 1.2 ORANGE I have:

public interface Sample {
    String getName();
    int getSize();
}

And in version 1.2 APPLE I have:

public interface Sample {
    String getName();
    double getRatio();
}

And then in artifact X 1.0 ORANGE (which depends on S 1.2 ORANGE) I have

public class Foo {
     public void display(Sample s) {
         System.out.println(s.getName() + " " + s.getSize());
     }
}

And in artifact Y 2.2 APPLE (which depends on S 1.2 APPLE) I have

public class Bar {
     public double calculate(double length, Sample s) {
         return length * s.getRatio()
     }
}

And then in my application I depend on X 1.0 ORANGE and Y 2.2 APPLE then 
I want the resolution to fail because there is no single version of 
artifact S that will satisfy both X 1.0 ORANGE and Y 2.2 APPLE without 
causing some runtime error.

Alan Chaney wrote:
> 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?
> 
> Alan
> 
> 
> 
> 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 
>>>> http://mvnrepository.com/artifact/org.apache.geronimo.specs/geronimo-activation_1.0.2_spec

>>>> 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!
>>
> 

Mime
View raw message