Community
Participate
Working Groups
Not sure if this is a PDE build or UI problem (or user error). I want to create a product using only OSGi (org.eclipse.osgi) and a simple "Hello World" bundle. I started with a very simple plug-in project that has one class for its BundleActivator. The BundleActivator simply prints "Hello World!!" to the console (how creative :) Now I want to create a product which includes my bundle and starts it each time I launch the product. I created a new "Product Configuration". I then used the following steps - product configuration editor is opened. - I must pick an existing Product ID or create a new one. I created a new one. - I choose my simple hello world bundle as the defining plug-in. - This forces me to choose an application (but I don't really want an "eclipse" application here, so I just used the default org.eclipse.ant.core.antRunnter) - I'm not sure if this is by design or a bug but after that I was able to select an empty "" application in the dropdown box. I ended up with a Product ID but no Application or Product Name specified. - I then added org.eclipse.osgi and org.eclipse.osgi.helloworld plugins to the list of plug-ins that constitute the product. - I then created my own config.ini for the product using the following content #Product Runtime Configuration File osgi.bundles=org.eclipse.osgi.helloworld@2:start osgi.bundles.defaultStartLevel=4 eclipse.ignoreApp=true After this I was able to launch the product using the "Launch the product" link on the product configuration editor. But each time I launch the product it forces a plugin.xml file to be created in my hello world plug-in project. I will attach my hello world bundle with no plugin.xml file.
Created attachment 25861 [details] simple hello world product Open the /org.eclipse.osgi.helloworld/helloworld.product file and click on the "Launch the product" link. Notice a new plugin.xml file gets created in the helloworld project.
Tom, a new plugin.xml is created for your plugin by PDE because we have to generate an org.eclipse.core.runtime.products extension in your plugin.xml that corresponds to the one you declared in the .product file. Is there more to the story or does that answer your question?
This is related to plan item bug 106188. I was investigating how tools would react to a target that only included org.eclipse.osgi. In this scenario there is no core.runtime and therefore no extension registry. It is strange to have a org.eclipse.core.runtime.products extension in this situation. We will likely need some enhancements to both tools and osgi to make launching a standalone osgi framework easier for development and deployment. The good news is things almost work today as is. But I would prefer OSGi to have a "first class" launcher similar to the "Eclipse Application" launcher. Maybe something like "OSGi Application". This launcher would allow you to specify a set of bundles from the target and workspace and allow you to set the startlevel and start status (PDE used to have something like this at one point on the configuration tab). This information would be stored in the osgi.bundles property of the config.ini. This launcher would also not require you to pick an Eclipse application or product. An Eclipse application or product implies that your target has core.runtime. If that is the case then you would just use the regular "Eclipse Application" launcher.
Now I understand why you didn't want to associate an application with your product. So there is no bug in the product editor. It just doesn't (and was not meant to) support the pure OSGi story you want. Let's use this bug report to track the request for an OSGi application launcher. I will rename the bug report accordingly.
More details on what I would like to see in an OSGi Launcher. Main Tab - No need for "Workspace Data" - No need for "Program to Run" - Keep "Command Line Settings" Plug-ins Tab - Keep as is Configuration Tab - Keep as is, but it would be nice if the "Generate a config.ini file with default content" option would generate a proper config.ini which started all the bundles selected and set some additional properties needed to run osgi standalone. - Today if you don't have update.configurator selected in your choosen plugins then PDE will generate a config.ini with an osgi.bundles property which lists all the bundles selected. The OSGi Launcher would do the same thing except it would have a optional checkbox to start all the bundles in the target. I think this checkbox should be enabled by default in the OSGi Launcher. When checked the osgi.bundles property would contain bundle ids in the following form: <symbolic name>@4:start The generated config.ini would also have the following properties set: osgi.bundles.defaultStartLevel=4 eclipse.ignoreApp=true osgi.noShutdown=true Tracing Tab - Keep as is Environment Tab - Keep as is Source Tab - Keep as is Common Tab - Keep as is
Created attachment 27270 [details] New launcher The new launcher is almost finished. It won't be in for M2, as persisting/restoring the new Plug-ins tab is pretty challenging. Here is a sneak preview. It is so pretty. Tom, did I miss anything esthetically?
I would qualify this one of gorgeous
Looking good. I would recommend you replace the term "auto-start" with the new and improved "lazy-start" term. I assume the arguments and jre tabs are the standard Java application launcher tabs for specifying the JRE, VM arguments, program arguments etc. Is the Eclipse application launcher also going to use these standard Java application tabs? or is it going to still place this information on the old Main tab?
Now I am confused. I thought Auto-Start in this context referred to the @2:start in the config.ini, which is different from the Eclipse-LazyStart found in the manifest.mf??? The Eclipse Application launcher started using the standard Program Arguments tab as of today's builds. Check it out We now also support variable substitutions, etc. in our PDE launchers. The JRE tab is our own, because we still want people to modify the boot classpath. If were to use the JDT ones, we end up with two new tabs, one of which would be misleading for Eclipse/Equinox purposes.
Ahhh!! this is why the Eclipse-AutoStart header was such a bad name ;-) Wassim, you are correct auto-start in this context indicates if the bundle should be started (by using @2:start in the config.ini). I understand it now. Sorry for the confusion.
ok, the launcher will be in tomorrow's I-build. Tom, give it a whirl.
(In reply to comment #6) > Created an attachment (id=27270) [edit] > New launcher > Here is a sneak preview. It is so pretty. > Tom, did I miss anything esthetically? IMHO the tab "Plug-ins" is confusing. It should be renamed to "Bundles". That's what we are dealing with in the OSGi world. BTW, is there a separate project nature for pure OSGi bundles that arn't plug-ins? If yes those projects should be also visible in this tab.
>is there a separate project nature for pure OSGi bundles that arn't >plug-ins? plugin == bundle. That is how it has always been in Eclipse. What in your opinion distinguishes a "pure OSGi bundle" from a "plug-in"?
(In reply to comment #13) > >is there a separate project nature for pure OSGi bundles that arn't > >plug-ins? > > plugin == bundle. That is how it has always been in Eclipse. > What in your opinion distinguishes a "pure OSGi bundle" from a "plug-in"? I just meant to say that in the OSGi world the term "plug-in" is unknown. In Eclipse a plug-in is a bundle but in OSGi only bundles exists. Thus, if you want to give OSGi a first class presence you are attracting OSGi users not familar with the term "plug-in" (if they don't know anything about the Eclipse architecture).
Understood but the distinction is entirely artificial. Wassim's question is right on. When/how would PDE decide to use "plugin" vs. "Bundle"? There is no cue because they are the same thing. One thing we might do is make the new wizard label be something like New Plug-in/Bundle project so that OSGi focused people are attracted to the function.
