[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
_________________________________________________
Jim Wright
The Stellation project: Advanced SCM for Collaboration
<http://www.eclipse.org/stellation>
Pieceware group, Software Technology department.
IBM T.J. Watson Research Center
