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

Hi,
 I would agree with Glyn on this. The build-system is well bedded in at
this stage and I suspect it would eat up time to go near it with a
ripple effect outwards. Any work there or major changes may have serious
impacts on Virgo timelines with little for it at the end of the day.


~Patsy

Declaration of ivy bias and hence no issues :

Ivy works really well for us, we have just transitioned a partner group
of developers over from maven and they are much happier at the moment. 


On Thu, 2010-07-15 at 09:05 -0700, Glyn Normington wrote:
> To be honest churning the build system makes me feel queasy at this stage in the project. I don't want to destabilise the 2.1.0 stream and I don't feel out current build solution is so bad (my ignorance of maven may help me in this).
> 
> Glyn
> On 15 Jul 2010, at 16:59, 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<mailto: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><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.
> 
> 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><mailto:virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx>>
> https://dev.eclipse.org/mailman/listinfo/virgo-dev
> 
> <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