Difference between revisions of "Equinox/p2/P2 Fragments"
(Created page with "= P2 Fragments = '''NOTE 1:''' What is written here, is a really, really last resort. You should try other approaches first, and be really, really sure that they will not wor...") |
(→P2 Fragments) |
||
| Line 1: | Line 1: | ||
= P2 Fragments = | = P2 Fragments = | ||
| − | '''NOTE 1:''' What is written here, is a really, really last resort. You should try other approaches first, and be really, really sure that they will not work for you. | + | '''NOTE 1:''' What is written here, is a really, really last resort. You should try other approaches first, and be really, really sure that they will not work for you. <br/> |
'''NOTE 2:''' This functionality is present in Eclipse Luna since N20131219-2000. | '''NOTE 2:''' This functionality is present in Eclipse Luna since N20131219-2000. | ||
Revision as of 05:01, 20 December 2013
Contents
P2 Fragments
NOTE 1: What is written here, is a really, really last resort. You should try other approaches first, and be really, really sure that they will not work for you.
NOTE 2: This functionality is present in Eclipse Luna since N20131219-2000.
Background
It is very important in some Linux systems to be able to verify integrity of the installation because of security reasons. This goal was achieved by making the Eclipse installation read-only just after it was copied to the system, and launching it in a shared configuration mode by regular users. It did worked very well. However, problems were appearing as more and more Eclipse plugins/features was available via the Linux repositories. It was nearly impossible to install things into a read-only Eclipse, while keeping it's integrity checked. One solution to that problem was adopting dropins, but the problem with the dropins was that one wrong plugin could effectively prevent all dropins bundles from being loaded, giving almost no information about what went wrong. Although things got much better in Eclipse Kepler, the lack of dropins diagnosis and its "unpredictability" (it is predictable, it just doesn't help you if something goes wrong) is still a huge pain if you want to deploy large Eclipse stack divided into read-only components.
Solution requirements
The alternative solution key requirements were:
- be able to load bundles from specified location, with no startup overhead (dropins resolution could take as much as 30 sec at Eclipse startup)
- always attempt to load all bundles (key point for diagnosis - OSGi will report wiring errors)
Using fragments
In order to get fragments working properly, you need to ensure that following requirements are met:
- Base Eclipse product installation is read-only (otherwise Eclipse will start correctly, but will be in inconsistent state, and attempts to install things using UI will likely break things).
- Base Eclipse product contains important bundles already started (declarative services). This requirement is met for the SDK by default.
- Eclipse needs to be configured explicitly to use fragments by passing -Dp2.fragments=<path to fragments>[,<path to fragments>] property to JVM.
- Fragments need to be read-only. If you miss that step, you will see Migration Installation wizard appearing again and again.