[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [virgo-dev] Build System and .classpath files
- From: Glyn Normington <gnormington@xxxxxxxxxx>
- Date: Thu, 15 Jul 2010 18:56:48 -0700
- Accept-language: en-US
- Acceptlanguage: en-US
- Delivered-to: email@example.com
- Thread-index: AcskiihC1BDhnFGRSLS7qK6UXn2hzg==
- Thread-topic: [virgo-dev] Build System and .classpath files
Thanks. I'm happy to debate switching from Ant/Ivy to Maven in the v3.0 timeframe if there are compelling reasons, but for now (2.x), I don't want to slow down the current small team of committers with non-essential build changes.
On 15 Jul 2010, at 17:04, Pete Carapetyan wrote:
Yes Glyn, I understand about ant and not maven. I'm pretty allergic to ant since 2005, though sometimes I'll fire an ant task from within Maven. I'd offer to help, but it sounds like ant might still be a religious choice, so I defer to wiser souls.
On Thu, Jul 15, 2010 at 10:46 AM, Glyn Normington <gnormington@xxxxxxxxxx<mailto:gnormington@xxxxxxxxxx>> wrote:
That's great for Maven and I appreciate you pointing it out, but it's not so great for Ant/Ivy which is what Virgo currently uses. ;-)
On 15 Jul 2010, at 16:36, Pete Carapetyan wrote:
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:
<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"/>
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<mailto:gnormington@xxxxxxxxxx><mailto:gnormington@xxxxxxxxxx<mailto: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.
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
virgo-dev mailing list