[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [platform-update-dev] Point Releases vs. Integration Builds
|
Title: Message
Something worth trying is to install the updates into a
non-eclipse-standard plugin folder. I'm not sure if it makes things more/less
stable (and doubtfully will speed anything up), but it makes MY life easier
since by doing so, you're not cluttering up your default eclipse install (er.,
unpack) folder. Instead of pointing the plugins to be installed at
e:\eclipse3.0M8\eclipse (for example), I point them at
e:\eclipse-plugins\eclipse and they appear in there.
(This is of course related to the e:\eclipse\links\foo.link
file "undocumented feature" that I think really ought to be more explicitly
defined. Maybe leave a sample link file in the default unpack/install of
eclipse?)
HOWEVER... if you're installing more than one plugin/update at
a time, you have to ensure that each plugin points at the new folder -
initially, they all point at the default. Not sure if I like that behaviour -
I'd assumed that they'd all go into the same place, not into (potentially) 3
separate folders for 3 selected plugins. I guess the flexibility is nice, but it
wasn't the behaviour I would have expected. If I've lost everyone on what in
blazes I'm talking about I'll comp some screen shots and send 'em in. Point is,
I initially thought this was a bug (first time playing with the Update Manager)
and later today realized, no, it's not a bug, just an unexpected behaviour.
;-)
Thanks,
--
Nick Boldt :: Java Developer
Eclipse EMF and SDO Frameworks
Websphere Studio Development, Toronto Lab
8200 Warden Ave., Markham, Ontario, L6G 1C7.
o(ffc): 905/413/4308 || w(ork): codeslave@xxxxxxxxxx
D3/R8R/8200/MKM && Nick Boldt/Toronto/IBM@IBMCA
April 28, 2004 5:06 PM
To:
<platform-update-dev@xxxxxxxxxxx>
cc:
From: "Ed Burnette"
<Ed.Burnette@xxxxxxx>
Subject: RE: [platform-update-dev] Point Releases
vs. Integration Builds
I'm
going to try and use that test site (to update from last week's integration
build)...
...
One
thing I notice already is that it appears to be slower than getting the packaged
zip file from the main http download area. I thought I recalled some work done
to do parallel downloads for the updates, is that activated? It's only showing
one jar file at a time being downloaded.
...
Some
stats about KB/sec, total MB downloaded so far, and estimated time remaining
would be nice on the Install progress when it's downloading.
...
This
would be a good candidate for making into a background task, since it ties up
your Workbench window for an hour or so with a modal dialog. I'll use a
scheduled update at night next time.
...
The
test update site seems to lag the download site. For example the former has
200404280800 but the latter has 200404281424. Perhaps it's because the tests on
the '1424 version have not completed yet. Of course some of the tests on '0800
failed, so what's worse, pending or failed?
...
Ok
it's done installing '0800 and it says I need to restart the workbench. As a
test I tried doing just the Example Plug-ins feature first and it told me the
same thing. I thought that Update could do replacements dynamically now,
no?
...
Restart is done, and I got an error dialog that says
simply:
"Eclipse
c:\Program
Files\eclipse\configuration\1083185400707.log"
I edit
that file (not using Eclipse :0). Hmm.. it's pretty long so I won't post the
whole thing here but it starts with:
!SESSION Apr 28, 2004 16:50:01.722
---------------------------------------------
java.version=1.4.2_04
java.vendor=Sun
Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32,
NL=en_US
!ENTRY reference:file:c:/Program
Files/eclipse/plugins/org.eclipse.core.runtime_3.0.0/ 0 0 Apr 28, 2004
16:50:01.738
!MESSAGE FrameworkEvent.ERROR
!STACK
0
org.osgi.framework.BundleException: The bundle could not be resolved.
Reason: probably another version has been chosen
at
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:395)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:371)
at
org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1007)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:571)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:482)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:272)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:442)
at
org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:153)
at
org.eclipse.osgi.framework.eventmgr.EventThread$Queued.dispatchEvent(EventThread.java:56)
at
org.eclipse.osgi.framework.eventmgr.EventThread.run(EventThread.java:107)
!ENTRY
reference:file:c:/Program
Files/eclipse/plugins/org.eclipse.core.runtime_3.0.0.v20040426a/ 0 0 Apr 28,
2004 16:50:01.801
!MESSAGE FrameworkEvent.ERROR
!STACK
0
org.osgi.framework.BundleException: Exception in
org.eclipse.core.internal.runtime.PlatformActivator.start() of bundle
org.eclipse.core.runtime.
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:990)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:952)
at
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:408)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:371)
at
org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1007)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:571)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:482)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:272)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:442)
at
org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:153)
at
org.eclipse.osgi.framework.eventmgr.EventThread$Queued.dispatchEvent(EventThread.java:56)
at
org.eclipse.osgi.framework.eventmgr.EventThread.run(EventThread.java:107)
Nested
exception:
java.lang.NoClassDefFoundError:
org/eclipse/osgi/service/systembundle/EntryLocator
at
java.lang.ClassLoader.defineClass0(Native Method)
at
java.lang.ClassLoader.defineClass(Unknown Source)
at
org.eclipse.osgi.framework.internal.defaultadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:296)
...
Guess
it's back to zip files for now :( .
Hi Nick,
As long as features and plugins have
different versions from build to build, you can use the update manager to
upgrade. In particular, if your build is 2.0.0.build_id and the build_id is
lexicographically increasing, the you should be able to use update mgr.
However, the current eclipse builds have the
same versions (mostly 3.0.0, with some variations for ant, lucene, tomcat,
etc.) across the builds, so update mgr cannot be used to move from build to
build. There is a test site (http://update.eclipse.org/testUpdates) that has
integration builds with different feature and plugin versions
(3.0.0.<build_id> for features and 3.0.0.<cvs tag> for plugins),
There have been discussions in the
past and a to do item for post 3.0 to manage plugin and feature versions so
update manager can be used to move from build to build.
-Dorian
