[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [virgo-dev] Build System and .classpath files
- From: Patsy Phelan <pphelan@xxxxxxxx>
- Date: Thu, 15 Jul 2010 16:17:56 +0100
- Delivered-to: firstname.lastname@example.org
Yes, I would agree completely with you on the comments below.
Whenever ivy.jar get updated we are most definitely toasted. Alas, at
the time it was the best (possibly only option we had) with the limited
knowledge of the build system we had.
On Thu, 2010-07-15 at 08:01 -0700, Glyn Normington 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:
> > 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