RE: [stellation-res] Repository Contents - Status Update

["Jonathan Gossage" <jgossage@xxxxxxxx>]

> -----Original Message-----
> From: stellation-res-admin@xxxxxxxxxxxxxxx
> [mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Jim Wright -
> IBM Research
> Sent: Sunday, September 14, 2003 3:51 PM
> To: stellation-res@xxxxxxxxxxxxxxx
> Subject: Re: [stellation-res] Repository Contents - Status Update
>
>
> At 08:10 PM 9/13/2003, Mark C. Chu-Carroll wrote:
>
> >On Friday, September 12, 2003, at 01:10 AM, Jim Wright - IBM
> Research wrote:
> >
> >>Per my email of Sept 10, I've been working on bringing
> >>the repository contents fully up to date.
> >... snip
> >Not to be overly rude, but.... What on *earth* are you smoking?
>
> Mark,
>
> Not to be overly rude, but maybe you should calm down a little.
>
>
> >Where do we *trash* /usr/local/bin?
>
> It's trashed in build-stell.xml (formerly build-core.xml).
> See the code related to the inst.bin variable.
> This code comes from a script originally written in July 2002,
> by _you_, and subsequently modified by Dave.  I first laid hands
> on it in January 2003.
>
> Blowing away /usr/local/bin _only occurs when the clean-install
> Ant target is used, so maybe you/we were just lucky.
>
> >Where on earth did you get the
> >idea that /usr/local/bin is something *new*?
>
> Not what I thought.  (I admit the use of the word 'now' in my original
> post was poorly chosen, but I'm aware /usr/local/bin has been used by
> lots of stuff for quite a while).
>
> >(The use of /usr/local/bin
> >for local binaries dates back to roughly *1997*. To my knowledge,
> >there has never been a distribution of linux that doesn't
> include binaries
> >in /usr/local/bin.
> >And if our build scripts had been blowing away /usr/local/bin,
> then I would
> >regularly have watched my machine die - because I run XFCE 4, installed
> >in /usr/local, binaries in /usr/local/bin - so my entire desktop would
> >have been
> >obliterated.
>
> Good thing you never ran
> $Ant -f build-stell.xml clean-install,
> in that case.
> I'm pretty sure you vetted the script in the first place, back in
> January, when
> I was called in to work on this.
>
> (Frankly, I'd expect you to be glad when I found and fixed a screwup
> of this nature........especially since it's been there for 9+ months
> without being noticed by you or anyone else....
> Try not to shoot the messenger next time, okay?)
>
>
> >Also, the Eclipse R3.0 stream supposedly *only* works on 1.4 level
> >JVMs. I double checked, and my linux box is running IBM Java 1.4.1,
> >Eclipse R3M3, with absolutely no problems.
>
> Well, I'm glad you're not having problems.  I was under the same
> impression
> w.r.t. R3.0, which is why I switched to a 1.4 level JVM in the
> first place.
> However, (on my freshly-installed RH9 system), I had tons of grief using
> the IBM 1.4.1 JVM with R3M3, and no trouble at all with the 1.3.1 level
> JVM.   Go figure.
>
> >So it's not strictly
> >a JVM issue - there's something environmental going on. Are
> >you sure that you don't have any lingering metadata?
>
> Yes.  My last test case was a totally virgin workspace (new directory,
> no Stellation projects or metadata at all).  I simply
> a) created a new workspace
> b) attempted to import binary projects for org.eclipse.core.XXX
> and required plugins.
>
> The import failed to build (.classpaths were not created),
> the Update Classpaths dialog was totally empty (when it
> should have listed about five projects which could be updated.)
>
> When I switched to the 1.3.1 JVM, and repeated the test (virgin
> folder, import eclipse.resource.XXX), it worked flawlessly.
> When I then copied over the stellation projects (__excluding___
> any .metadata), they built fine too.  Go figure.
>
> It _may_ be significant that the Eclipse R3 plan lists 1.4.0 JVMs
> for Linux, and I was using a 1.4.1 JVM.  Then again, that may
> be irrelevant.  I will test further when I get back on Tuesday.
> Or you can look into it and update the repo yourself, if you
> prefer.
>
> - Jim
>
If you are working with the Sun JVM's you do NOT want to go with 1.4.0.
Either the most current minor release of the 1.4.1 stream is usable, or the
1.4.2 beta is also usable. I use the 1.4.2 release because it has improved
debugger support.

Regards

Jonathan