[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [virgo-dev] Build System and .classpath files

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:

> Hi,
> 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"
> classname="org.apache.ivy.ant.EclipseClasspath"/>
> 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."
> depends="ivy.init">
>                <ivy:resolve  conf="test" />
>                <ivy:eclipse  conf="test" />
>        </target>
> 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,
> ~Patsy
>> 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.
> <EclipseClasspath.jad><ATT00001..txt>