Re: [virgo-dev] Build System and .classpath files

[Pete Carapetyan <pete@xxxxxxxxxxx>]

Please flame or ignore me as appropriate, if I'm missing the track entirely, but if this helps.....

If you are having to hacking the .classpath file, and you are speaking of the eclipse IDE .classpath file and you are using STS or even just eclipse with m2eclipse, then here you should never need more than this:

<classpath>

<classpathentry kind="src" output="target/classes" path="src/main/java"/>

<classpathentry kind="src" output="target/test-classes" path="src/test/java"/>

<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>

<classpathentry kind="con" path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/>

<classpathentry kind="output" path="target/classes"/>

</classpath>

This references the pom.xml, so you don't have to maintain two different sets of metadata. If only the manifest.mf and pom.xml could work together so easily.... (tycho may cure that eventually)

On Thu, Jul 15, 2010 at 10:01 AM, Glyn Normington <gnormington@xxxxxxxxxx> wrote:

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.

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

_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev