On Thu, Jul 15, 2010 at 10:01 AM, Glyn Normington <gnormington@xxxxxxxxxx
Interesting - thanks.
The way we keep .classpath files in step is to use the "update dependency" script to change dependency version numbers.
A couple of comments on the approach below:
* In general, we try to avoid build targets modifying check-in artifacts as that can cause interference between developers and other issues. (We still regret the generated manifests which are checked in, typically we have to discard spurious changes before committing.)
* Hacking ivy.jar is fragile as it could easily break when ivy was upgraded.
On 15 Jul 2010, at 15:45, Patsy Phelan wrote:
> We had the same issues here but we modified the then "spring-build" to
> include a "eclipse" target which uses ant/ivy to resolve the
> dependencies and update the .classpath files for eclipse. At the our
> root level build (build-all) we can iterate all the sub-bundles and
> update the .classpath files.
> It did mean adding a new "task" into the ivy.jar that was present in the
> spring-build/lib directory. This was un-jar'd, goto the folder
> org/apache/ivy/ant, new class added, antlib.xml updated to reflect the
> new EclipseClasspath class, and re-jar'd again.
> I would have to look for the java file for the EclipseClasspath but in
> the meantime, I have attached the decompiled version of it.
> (EclipseClasspath.jad). It was build agains't the ivy jar we had so
> there was not much problems getting it to a class file.
> The antlib.xml file in the ivy.jar was updated to include this :
> <taskdef name="eclipse"
> Then some slight modification in the spring-build/common/common.xml to
> add a new target:
> <!-- Generate Eclipse .classpath file from ivy dependencies -->
> <target name="eclipse" description="Updates eclipse classpath."
> <ivy:resolve conf="test" />
> <ivy:eclipse conf="test" />
> At this point you can add this as a "depends" to other more complex
> targets. So for us this works quite well, the developers are used to
> "ant clean eclipse jar" and so into the GUIs they go. Of course,
> everywhere you see spring-build start to think virgo-build.
> Hope it helps,
>> It's even worse than that: we also index into the ivy cache in Eclipse
>> .classpath files and in some tests, for example
>> org.eclipse.virgo.web.test.SpringWebFlowWarTests in Virgo web.
virgo-dev mailing list