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, "李超"<char...@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!
