Community
Participate
Working Groups
For people who use DS in their applications or have any need to start things... it's currently painful to do so. Product Customization (Equinox Transforms) also suffers this fate. For 3.5, we need to allow the product editor to define startlevels along with maybe some other properties. As an example, 'osgi.framework.extensions' needs to be set to org.eclipse.equinox.transforms.hook for product customization.
cc'ng Andrew as this will affect PDE Build eventually
I can't find it atm, but there is a bug somewhere about us consolidating .product parsing into one place. Currently there are 3 consumers (p2, UI & build). We should do that first.
Bartosz, ready to tackle this? I have some ideas on how to do this. We should chat. By enabling this, we should make it fairly easy to finish the Equinox transforms integration into PDE :)
yup. we can discuss that whenever you have some time. sorry for delay.
So here is the idea. In the Configuration tab, where we display plug-ins or features, we modify it so we have table trees. For example, the plug-ins list, would look similar to what we now have in the OSGi Framework launch configuration (you can set start levels and set auto start). For features, we would list all the plug-ins under the features in a tree, and have this same level of start level or auto start tweakability. The next question is how we persist stuff. I'd envision a new element, let's say <configuration> within it, we would have a list of plug-ins and any potential properties they may have. <configuration> <plugin id="foo" startLevel="3" autostart="false"> ... </configuration> We can later expand the <configuration> element to include information about OSGi properties... needed for things like Equinox transforms... <property id="osgi.some.property" value="blah"> Do you have an idea of what I am picturing here Bartosz?
Here is a mylyn context to help you get started in the product model and editor.
Created attachment 108113 [details] mylyn/context/zip
Chris you can assign it to me :)
Created attachment 108188 [details] example of how I think it could look like (for plugins
There is one question waiting to be asked (I have no experience in feature based product). Couldn't we keep all together ? If we have feature all its plugins are listened as a children other plugins have no parents (cause life is brutal ;) ) Does it make any sense ? if not i have scenario for the new section <configuration> which can make it a bit confusing. starting with feature based product 1. set properties for some plugins 2. change to the plugin based product (ok product can reuse properties) 3. remove plugins from configuration (in such a case <configuration> section could be also cleaned for this plugins) 4. switch again to the feature based product (some properties are missing) we can make the same scenario another way around. I am not sayng it is a big problem but it can be confusing. on the other hand I think the new section solution be clean ( there is no additional work as would be in case of changing eg. <plugins> section) waiting for comments (especially on is this split to plugins/features really needed in this place)
Created attachment 108269 [details] text model implementation not tested (GUI in the next patch) but should be ok
Created attachment 108270 [details] mylyn/context/zip
Created attachment 108283 [details] small fixes
Created attachment 108385 [details] first view on my concept of gu
Created attachment 109836 [details] gui change
Created attachment 111676 [details] org.eclipse.pde.patch An updated patch. Still needs work.
This will go into M3 along with a various other amount of work to improve the product editor (ie., setting versions)
Seeing how there are 3 .product parsers, this would be a good time to figure out where we can put a common one that all 3 of ui, build and p2 can depend on.
Created attachment 117252 [details] org.eclipse.pde.patch Modified Bartosz's patch. Clean up. We're on our way to startlevel heaven. Things that need to be done still: 1) right now, we only support this on plug-in based product configs, need features 2) need to make launching and export work properly
Created attachment 117335 [details] org.eclipse.pde.patch All UI things related to setting start levels is done. I also laid down some initial code to start including versions on plug-ins within product definitions. The next step is to figure out launching and export (PDE Build). For the launching aspect, I'm considering adding the ability to modify start levels within Eclipse launch configurations.
dropped initial code to handle editing of start levels in the product editor. Adding support for launching now.
Created attachment 117405 [details] org.eclipse.pde.patch Phase 2 of start level work. Adding support to Eclipse Application launch configurations to tweak startlevels.
Chris, one thing I noticed is that it doesn't include the bundle version in the configuration element: <configurations> <plugin id="org.eclipse.core.runtime" autoStart="false" startLevel="0" /> </configurations> The bundle version should be included here as well, because the product could contain multiple versions of a non-singleton bundle. Let me know if I should enter a separate bug for this.
(In reply to comment #23) > Chris, one thing I noticed is that it doesn't include the bundle version in the > configuration element: > > <configurations> > <plugin id="org.eclipse.core.runtime" autoStart="false" startLevel="0" /> > </configurations> > > The bundle version should be included here as well, because the product could > contain multiple versions of a non-singleton bundle. Let me know if I should > enter a separate bug for this. > No need to enter a seperate bug. I'm still working on this feature. The UI needs to be slightly cleaned up and the launching needs to be aware of these changes. I expect to have this done next week. It's good to see that people are interested in this already. Do you have any other suggestions for managing start levels? Does an "START EVERYTHING" option seem useful for you ?
Hi, Does an "START EVERYTHING" option > seem useful for you ? > IMHO, this should not go in the meta data level, but in the UI instead, as it keeps the meta data more consistent (what should happen if you encounter something like : <configurations> <start-all-plugins /> <plugin id="org.eclipse.core.runtime" autoStart="false" startLevel="0" /> </configurations> for example), and at the end, it leads to the same result. Cheers, Jawher
Created attachment 119203 [details] org.eclipse.pde.patch An updated patch. Issues still exist when launching. This problem mostly stems with the LaunchPluginValidator.parsePlugins(...) method.... will investigate and start writing test cases for launching.
Hi! I'm using this feature with 3.5M4 for a RCP application, and it's great, but I think there are still some bugs (using product configuration based on plugins): * After configuring start levels and auto start, PDE does not always seem to apply these settings in the launch configuration (BTW: for launching Eclipse applications, there is no page for specifying start levels, right?), even after sync'ing on the Overview page * When closing and re-opening the product editor, the table containing plugins and start levels is empty, but when I look into the file with the XML editor, the settings are still there, but autostart has been reset to false (was configured as true) This behavior is somewhat painfull, as I'm experimenting with Equinox DS and my services are simply not showing up... Anyway, thanks for your work on this! Regards, Wolfgang
Thanks for the feedback Wolfgang. We're working on finishing this whole story for M5. Your services aren't showing up most likely due to start levels or Equinox DS not being started. For now, I recommend using a custom config.ini to tweak start levels until things are working from a self-hosting and export perspective.
Hi Chris! Thanks for your answer. Give me a ping, if you would like me to test anything or get a confirmation that everything is working as expected.
Created attachment 122351 [details] org.eclipse.pde.patch An updated patch with copyrights and changes. Still not there yet, EclipseApplicationLaunchConfiguration needs to be updated.
done. > 20090119 I appreciate testing on this week's i-build. On a side note, we have to redo the way PDE launches things... it's still too brittle now.
Hi Chris! (In reply to comment #31) > done. > > > 20090119 > > I appreciate testing on this week's i-build. I downloaded build I20090120-0920 (eclipse-SDK-I20090120-0920-linux-gtk.tar.gz), but the behavior is still the same: My .product file contains the following section: <configurations> <plugin id="de.myamc.fa.base" autoStart="true" startLevel="3" /> <plugin id="de.myamc.fa.core" autoStart="true" startLevel="2" /> <plugin id="org.eclipse.equinox.ds" autoStart="true" startLevel="1" /> </configurations> But when I open the .product file in the product editor, the configuration tab does show neither plugins nor autostart and runlevel. If I enter them (again), they are persisted to the .product filem but autostart is always false. This seems to be a UI problem only, as launching seems to work, the bundles in the <configurations> section are started correctly. Does the mentioned build already contain your latest patch? On a side note: since when are combo boxes (in forms) displayed with a bigger hight (e.g. launching tab, combo for execution environment)? On my Linux x86, GTK environment this looks rather ugly, like the combo boxes have been zoomed...
