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.
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.
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)
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.
What is a fragment
Fragment is actually a p2 runnable repository with some additional files. A runnable repository is an undocumented* feature of p2. It can be created by calling repo2runnable application with -flagAsRunnable argument, f.e.:
./eclipse -application org.eclipse.equinox.p2.repository.repo2runnable -source org.eclipse.epp.mpc-519e70b90429c4fa2a14b35ab8bb6907519cb101/org.eclipse.epp.mpc.site/target/site -destination /tmp/p2/installed3 -flagAsRunnable
The runnable repository has already bundles and features in a runnable shape, and they will not be copied into Eclipse installation when installed (this is the reason why "-flagAsRunnable" is undocumented - results of using it are very surprising to the end user). Additionally, the fragment must contain two additional files: fragment.info and fragment.profile.
It is a file of the format of bundles.info. Each of lines should contain one bundle (not feature, not source bundle, but OSGi bundle to be loaded):
<bundle symbolic name>,<bundle version>,<path to bundle>,<start-level>,<auto-start>
The path to the bundle may be relative or absolute. The fragment.info is read by a simpleconfigurator at Eclipse startup, and bundles from it are loaded into OSGi.