Community
Participate
Working Groups
Some discussion on bug 236719. Currently when self-hosting (launching an Eclipse workbench from host) there is no p2 profile available. This means that p2 code that interacts with the profile (installing, updating, introspecting, etc.) does not function when self-hosting. If PDE can provision a profile during launch, p2 self-hosting should be possible. It will also allow PDE to use p2 to setup config.ini/bundles.info and other files, rather than having duplicating code. One major area of concern will be backwards compatibility. In PDE, users want to be able to build against and launch previous versions of Eclipse (based on the contents of the target platform). If we are using p2 to generate the configuration information, p2 may need to be provision in a backwards compatible way.
Will start investigating this in M3.
We could also help p2 work with older runtimes. This is one solution to the backwards compatibility problem.
*** Bug 253658 has been marked as a duplicate of this bug. ***
We aren't there for M5 yet... moving to M6
With the new target platform story, the best way to move forward with this may be to create an entirely new launch type. This launch type would require a fully provisioned target to launch. In any case this isn't going to happen in M6, and will likely not be done for 3.5.
*** Bug 269288 has been marked as a duplicate of this bug. ***
This is part of the plan for 3.6. The plan is to create a profile during the launch and install into that profile metadata for all the plug-ins being launched.
A couple issues encountered so far: 1) I have had to create my own profile registry instance so that the created profile is persisted in a place where the launched config will find it. This also prevents me from using api methods from the engine, as those methods require the profile to be valid in the standard profile registry. Pascal suggested that some of the work to have multiple instances of p2 running in the same VM could help this case. 2) PDE recreates all the configuration data on a restart. Recreating the profile on a restart will prevent some of the benefits of have a profile to test with. There are likely other issues working with a spoofed up profile. Will have to collect the most wanted use cases on the mailing list. 3) Noticed something odd about when we add the p2 data area that might explain bug 291783. We often don't end up setting the data area property at all. We need a specific data area so the spoofed profile gets found.
Created attachment 150028 [details] Work in progress This patch successfully creates a profile with metadata from the launched plug-ins. The profile is set as the default profile in the launched workbench and can be modified.
Created attachment 150029 [details] mylyn/context/zip
Created attachment 150309 [details] Fix This fix could arguably be ready enough to go in for M3. There are a couple of issues to consider: 1) The UI text calls it a 'P2 Profile'. We don't use p2 elsewhere in the UI. 2) It doesn't work when launching with a 3.4 target. The profile isn't found.
Created attachment 150386 [details] Updated fix Updates the UI text, cleans up some code, adds javadoc
Applied latest path to HEAD.
What happens with p2.inf files and this?
(In reply to comment #14) > What happens with p2.inf files and this? I believe the metadata generation happens before the p2.inf files would be considered. The metadata generation doesn't consider the p2.inf.
(In reply to comment #8) > A couple issues encountered so far: > > 1) I have had to create my own profile registry instance so that the created > profile is persisted in a place where the launched config will find it. This > also prevents me from using api methods from the engine, as those methods > require the profile to be valid in the standard profile registry. > > Pascal suggested that some of the work to have multiple instances of p2 running > in the same VM could help this case. This should now be possible. The basic API was in M3, but the fully functioning code is in the p2 API work branch. You can now instantiate an agent on an arbitrary location and obtain whatever services you need from that location (profile registry, etc). There is some documentation on this here: http://wiki.eclipse.org/Equinox/p2/Multiple_Agents
(In reply to comment #16) > http://wiki.eclipse.org/Equinox/p2/Multiple_Agents I <3 you John. I can now implement my dream of a global target bundle pool. The question is where to store it... thinking the user home directory... .eclipsetarget
that would be very cool. would be good to put it at ~/.eclipse/target or something. that is, not cluttering the user's home dir. We already have an "eclipse place". Great news on the self hosting...
