[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cross-project-issues-dev] How to have fun with RC1
|
Thanks Markus... starting to see clearer
:)
My current understanding is that upgrade Galileo product A
--> Helios product A will work.
Cross-product-upgrades, however (e.g. Galileo C++ EPP
package --> Helios RCP/RAP EPP Package) may fail because different products
make different assumptions about the collaboration of config.ini / eclipse.ini
with the features/bundles installed. For instance, if the Galileo C++ package
references an OSGi framework extension in its config.ini, which will get
uninstalled as part of the upgrade due to version conflicts (and because the
target product doesn't have that framework extension), it will likely
fail.
Would it make sense to try and hide any "product IU's" in
the install dialog that don't match the currently installed
product?
Thanks,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
direct
+43.662.457915.85 fax +43.662.457915.6
Hi Martin,
I wouldn't go out and announce that the upgrade
from Galileo to Helios is working in all cases. What I expect to work is that
someone with an unmodified Galileo EPP package can upgrade to Helios, and
according to my first tests this morning this scenario is working. If someone
modified one of the ini files by hand or did other weird modifications outside
of Eclipse control, it won't work of course.
This answers one of you
questions below: In Galileo, each and every package comes with the EPP
repository location enabled, i.e. the "product feature" that you mention below
is available in a repository known to each package. With Helios we are trying to
reduce the number of repositories visible to the end users and included the EPP
repository into the main Helios composite repository.
Regards,
Markus
On 21 May 2010 23:37, Oberhuber, Martin
<Martin.Oberhuber@xxxxxxxxxxxxx>
wrote:
Hi
all,
one thing
to especially keep an eye on when trying to upgrade from a
product based on
Galileo to a product based on Helios, is the Launcher.ini (eclipse.ini) and
config.ini files.
These files must be
considered part of the "product", e.g. the JEE package uses -vmargs
-Dosgi.requiredJavaVersion=1.5 which the Eclipse Platform (Eclipse SDK)
does not use. The expected content of both files has changed between Galileo
and Helios:
- In launcher.ini
(eclipse.ini), the --launcher.defaultAction openFile was
added
- also, the arguments to
-startup and --launcher.library flags need change
- In config.ini, the
equinox.use.ds=true flag was added
- also, the argument of
osgi.framework needs change
- In the JEE package, also an
jpa.equinox.weaving osgi framework extension was added
I'm wondering what the
strategy is for handling these two files on a major upgrade? Keeping the
old settings is wrong; some settings must change when I upgrade the Platform.
On the other hand, overriding all settings is also wrong. So, some kind of
merge is needed. Can this be expected to work? How is it expected to
work?
We discovered these issues
when accidentally trying to install the Eclipse SDK from the Helios Repo into
our commercial product, which uses a different osgi.configuration.area
setting. When trying to upgrade, all new bundles were installed into the
config area; but upon restart, the application bundle of our product was no
longer found.
We didn't dive into any details on this, and
solved the issue for now by disallowing an
installation / upgrade of the Eclipse SDK. Individual
bundles such as the JDT can still be installed /
updated. But I'd be rather careful with installing / updating the
Platform or especially the Eclipse SDK, which seems to "own" the Launcher in
Helios. To me, it looks like a major upgrade can only work if the "Product
feature" which contains the .ini files is available in the repo in an updated
form. Do we have a Repo for the EPP Product features available
yet?
I don't feel
like this observation is ready for filing a bug yet, but I thought I'd let
people know what _could_ be an issue here...
Thanks,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
direct
+43.662.457915.85 fax +43.662.457915.6
I have flipped that switch to make
RC1 content visible in the common repository, at http://download.eclipse.org/releases/helios/
There will now be RC1 and M7 content
available there. (I could add back M6 content too ... if anyone has any use
for it ... special tests they want to run with multiple composite repos.
Performance? Rollback? Let me know soon, say my Tuesday of next week?
Otherwise, I'll soon remove all the "old" (unused) milestone sub-repositories
to free up mirrors space. Remember that if someone starts with M6 or M7, they _might_ still not
see the most recent feature listed in a category (See bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=312169) but RC1
itself should show categories correctly. Now the fun part. I suggest
we all try upgrading a (non-production) version of a Galileo install, to
Helios. Just pick your favorite type
of package or install, and see what happens. As discussed in bug 303583 https://bugs.eclipse.org/bugs/show_bug.cgi?id=303583
this is a migration path that _should_ work.
For the first time, there are no platform limitations that are known to
prevent it. But, also as discussed
there, it has been decided not to
aggressively push that upgrade path ... or even, officially, "support" it
(it is just too new, to know how to
guarantee it, etc) ... but ... it would be good to know ahead of the release if there were big,
obvious problems in some areas ... or, if some users might have some success doing that type of upgrade. To
test, just add http://download.eclipse.org/releases/helios/
to your Galileo installation list of software
sites, and try update or install (depending on how your Galileo version was created). I'm really not sure what to expect here ... I think it
will either work like magic, or not work at all. but I do think it is good to know ahead of time.
Please document issues found in bug
303583 or ask here if questions.
Thanks,
_______________________________________________
cross-project-issues-dev
mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Markus Knauer
EclipseSource
### phone: +49 721
664 733 0 (GMT +2)
### fax: +49 721 664 733 29
###
web:
www.eclipsesource.comInnoopract
Informationssysteme GmbH
Stephanienstrasse 20, 76133 Karlsruhe
Germany
General Manager: Jochen Krause
Registered Office: Karlsruhe,
Commercial Register Mannheim HRB 107883