[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ivy-user
Subject:    Re: How to define dependency in development stage?
From:       李超 <charlze () sohu ! com>
Date:       2011-06-07 1:23:34
Message-ID: 4DED7D96.20007 () sohu ! com
[Download RAW message or body]

Yes, I'm using Eclipse and ivyDE, but I didn't know the feature "Resolve 
in workspace" of ivyde (which is really a tragedy).
By enable this feature, I finally abandon the fussy process of switching 
between "develop-style ivy.xml" and "building-style ivy.xml". Thanks, 
Tim for your remind. :)

On 2011-6-3 12:53, Tim Brown wrote:
> Are you using IvyDE?
>
> You should be able to enable workspace resolution and use Eclipse
> compilation to skip 1&  2.
>
> I assume that 3 is some form of functional/component testing?
>
> How you're describing your process makes me question if you're
> properly unit testing B..
>
>
>
> On Jun 2, 2011, at 8:30 PM, "李超"<charlze@sohu.com>  wrote:
>
>> Hi guys,
>>
>> I'm developing two projects A and B. Project A depends on B, and B
>> depends on some 3rd libs. The dependency definition in the ivy file
>> of project A is:
>> <dependency org="..." name="B" rev="..." conf="compile-
>>> master,test,compile" changing="true"/>
>> Now I'm adding some new features to B and test these features with
>> testcases in project A. Every time when I test the modified source
>> codes of B, I have to do the following things:
>> 1. run the build.xml of B, to publish jar file of B to repository;
>> 2. resolve the ivy file of A to refresh the jar file of B;
>> 3. run the testcase to verify or debug the modification.
>>
>> For frequent modification of B, the test process becomes very time-
>> consuming. So my solution is:
>> Step 1: Comment out the dependency to B in ivy.xml of A;
>> Step 2: Add project B in A's build path(in Eclipse);
>> Step 3: Copy all dependencies of B to ivy.xml of A;
>> Step 4: When all features are tested, recover all the modification
>> in ivy file to origin state.
>>
>> But this solution has a big problem. If some colleagues
>> unintentionally commit these temporary ivy files into svn, they will
>> replace the right ivy files when other colleagues update their codes
>> and eventually lead some underlying errors.
>>
>> So if there is a better solution to this problem?
>> Thanks a lot!
[prev in list] [next in list] [prev in thread] [next in thread]