[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [virgo-dev] Build System and .classpath files
|
Hi Dmitry,
We had some very limited experience with this around the time we
patched the ivy.jar. Basically we could not get it to work correctly but
it may have improved since then. One of our developers tried it out as
an option to fix our .classpath issues - didn't work well so we moved
onto the patch.
That said we have the maven vs. ivy debate in-house as well.
~Patsy
On Thu, 2010-07-15 at 11:59 -0400, Dmitry Sklyut wrote:
> http://ant.apache.org/ivy/ivyde/
>
>
> There is eclipse based ivyide - not sure how well it will play with
> virgo-build layout.
>
>
> Dmitry
>
> On Thu, Jul 15, 2010 at 11:46 AM, Glyn Normington
> <gnormington@xxxxxxxxxx> wrote:
> Hi Pete
>
> 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. ;-)
>
> Glyn
> 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:
>
> <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<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.
>
> 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<mailto:virgo-dev@xxxxxxxxxxx>
>
> https://dev.eclipse.org/mailman/listinfo/virgo-dev
>
> <ATT00001..txt>
>
> _______________________________________________
> virgo-dev mailing list
> virgo-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/virgo-dev
>
>
>
> _______________________________________________
> virgo-dev mailing list
> virgo-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/virgo-dev
