Community
Participate
Working Groups
Currently the user has to go through a series of error-prone steps to create a stand-alone RCP application (see the manual steps at http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui-home/rcp- proposal/rcp_tutorial/tutorial1.html). This would be a good place to have an export wizard, similar to "Deployable plug-ins and fragments" wizard except it would: - copy the startup.jar - copy all required plug-ins referenced directly or indirectly by the main application plug-in (list determined automatically) - (optionally) create a batch file/shell script that would invoke java on the startup jar with the correct application name and classpath
This is a "must-have" for 3.0 in my opinion.
Wassim, it seems that pde build has all the necessary bits and pieces that you need to do a good export tool. The export has to be done in two steps: 1) Build all the plugins that are to be compiled (and only those, see notes below). 2) Package the app using the package script generator. For the building phase there is a trick. If the user export a feature or a set of plugins in which some of them are not compiled you only want to compile the one that needs to be compiled (ie: you don't want to ask pde build to generate a build script for them). From a non pde-ui guy point of view, it seems to me that this could be done from someone from the community! (what about you guys in the cc list ;-))
cc Jeff because he likes to stay on top of these things.
Presentation-wise, we would this wizard to be as useful as possible for its specific purpose. Yet, we don't want it to duplicate the existing Plug-in Export wizard. So I'm soliciting suggestions from the people who are asking for this feature as to what they would like the RCP export wizard to look like. What plug-ins should show up in the viewer (workspace or all)? Should there be quick selection buttons (e.g. "Select Main RCP Plugins", "Select Optional RCP Plug-ins" etc.) Considering the time left in 3.0, please provide feedback ASAP, so that the wizard would be most useful to you.
What comes to my mind for 3.0: Present all (non-binary) plug-in projects in workspace -- similar to the plug-in/frament export right now. One selects the ones belonging to the RCP app, i.e. "ones own code"; option to only export the binary or binary & source. An option to export all dependent plug-ins (e.g. necessary org.eclipse.*** plug-ins) -- this is enabled by default. An option to export startup.jar -- also enabled by default. One selects the platforms for which a startup script will be generated (multi-select); for all scripts one selects the "main" class, i.e. the one for the -application parameter; the name could be configurable -- by default a script for the development platform will be generated; implementation note: maybe only one UNIX and one Windows script are necessary for all platforms. The script will be similar to this (below is a bare-bones script for Win 98): @@@@ echo off start javaw -cp startup.jar org.eclipse.core.launcher.Main -application org.example.RcpApplication %* @@@@ One has the option to either export to a directory structure, e.g. /rcp_app /rcp_app/plugins/<all selected and dependent plugins> /rcp_app/startup.jar /rcp_app/run.bat (<= generated startup-script for Windows) /rcp_app/run.sh (<= generated startup-script for UNIX's) Or a ZIP containing the directory structure above. @@@@ Post 3.0 there could be an application builder instead of a startup-script--e.g. an *.exe will be generated.
Clarification for the above: >>for all scripts one selects the "main" class One selects the "main" class once and will be applied to all scripts.
Thanks Sebastian. As for how to launch the RCP app, we plan to do it the right way in 3.0. i.e. with eclipse.exe, config.ini and the rest of it. No special scripts would be needed. Also one thing that the wizard will include is a "Validate" button that will be used to validate the set of plug-ins that the user selects to make sure they will actually make up a valid product before they export. For this, PDE will use the Core Resolver to make sure all requirements for the plug-ins have been met for the product to function properly. This is always necessary/useful when users are in charge of hand-picking plug- ins.
I was envisioning right clicking on the project, selecting Export > RCP Application, and getting something similar to the Plug-ins page for a run-time workbench launch configuration when you've selected Choose plug-ins and fragments to launch from the list. You select one (or more) plug-ins that you want to definitely include (some from the Workspace and some from the External Plug-ins list), click Add Required Plug-ins to have it figure out which additional ones are needed for dependencies, and then click Finish and it copies all those to the deployment directory/zip file/self-extracting exe/etc.. This is a very plug-in centric view though. If you're going to use eclipse.exe and config.ini then you're probably going to want to have it be feature-based instead of plug-in based. As long as it doesn't complicate the initial RCP developer experience that's ok. Ideally I'd like to be able to create a sample RCP application and deploy it to my local machine using all the default options and run it within a minute or less. For non-default options, the wizards should let you easily change all the commonly customized things like the splash bitmap, window icon, about box text, and help page start.
>If you're going to use eclipse.exe and config.ini then you're probably going >to want to have it be feature-based instead of plug-in based. As long as it >doesn't complicate the initial RCP developer experience that's ok. Actually, the runtime is feature-agnostic. Feature is a Platform/Update concept, and not needed in this story. As long as PDE creates a config.ini file containing the list of plug-ins and their start levels, the runtime would be happy.
You don't need a primary feature any more for branding?
Branding can now be done declaratively thanks to the org.eclipse.core.runtime.products extension point. There are some examples of this in the platform or equinox newsgroup.
The "export" or "deploy" RCP app wizard is nice. There are two scenarios: 1) update in the target: in this case you really need to be producing a set of features in the target. 2) update not in the target: in this case you are choosing plugins I believe this function is powerful for the ongoing development (e.g., iterative develop/test cycles). Of course, the regular (and amazing) PDE self- hosting style test cycle should also be enabled. There is also a need for basic getting started wizard (e..,g New RCP app). This would ask people questions like - do you want a plugin - do you want an app - define the product - do you want a splash (where is it) - do you want branding (page that allows you to ste the window image, text etc etc) - if yes, gen an extension with all the right stuff - "components" to include - eg.., base, help, update, etc We do not have features for these but you can see there are reasonable groupings. People should be able to refine the groups but start easily by choosing whole groups - do you want update in the target - if yes, gen a feature with all the right stuff these are the basics. Going on from here there could be more things that allow one to setup the UI in the app etc.
Sounds like you need two RCP export wizards then, one for deployable plug-ins and one for deployable features (including their plug-ins), because automatic update is something a number of RCP app developers will be interested in. I think this is a likely scenario: when getting started a new RCP developer won't use features, but then when they get the program working somebody will say 'ok, now make it updatable'.
>Branding can now be done declaratively thanks to the >org.eclipse.core.runtime.products extension point. Cool!
I agree that having update in there is an important scenario but feel we need to ensure it is not locked in (either acutally or by omission of tooling) perhaps you just end up running the same wizard twice. The first time you don't select update and happily develop along. Then you go to ship and really wish you had update. So run the wizard again and this time say yes to update. Then you have an opportunity to either id the features you want or have the wizard create a feature after you have defined the plugins you want.
When I've seen people trying to package their own RCP app, the most difficulty they have is with determining the set of required plugins, and in debugging this when they inevitably get it wrong (the log output we get when plugins are missing is hard to follow). So I think having something like the launch config page where it lets you choose the main plugins and their prerequisites is essential. There's also often confusion as to which other files are required, how to configure product branding (product name, splash screen, window icon, about dialog text and image, etc.). Having some support for generating these would be a great help. I agree that Update will be a common optional component, and even if the app isn't using the update manager, they may want to allow plugins to be layed down manually and be picked up by the app, so it would be nice if it was easy to have org.eclipse.update.configurator as an optional component (with or without the update manager). One problem we face with Update is that it contributes some UI that is specific to the IDE (the actions in the Help menu). But that's a separate issue. I also think it's important that this not be just a one-off wizard. It will be an iterative process over the development of the app, and developers will want to keep (re)generating their app. They shouldn't have to re-enter info each time. There should be support for multiple simultaneous apps (i.e. it's not sufficient to just remember the last entered values in a wizard). Again, the launch configs dialog is a good example to follow.
I would like to thank everybody who made suggestions. They are all along the same vision, which makes me comfortable that we are all on the same page, especially considering the time constraint. One thing that I do NOT see happening is a two-wizard solution: one that is feature-driven and one that is plug-in driven. Two wizards that are doing almost the same thing is not the answer. Before you know it, Eclipse would have as many wizards as WSAD. One wizard would be sufficient: you can build the product and have the option (checkbox) to wrap plug-ins in a feature or not. As for Nick's very last suggestion, I definitely did not see that one coming. "There should be support for multiple simultaneous apps (i.e. it's not sufficient to just remember the last entered values in a wizard). Again, the launch configs dialog is a good example to follow." How many wizards in Eclipse do that? 0 I'm not sure the launch config dialog should/could be used as an example for how an RCP export wizard should be implemented. The LCD is not even a wizard. It is not a preference page either. In fact, I don't even know what is. A hybrid of some sort<g> The task at hand is to create a wizard. We would like to remain consistent of what the definition of a wizard is. I guess I'm missing the link how the concept of an export wizard and the concept of an LCD meet.
Whether you call the LCD a wizard or dialog isn't really important. The important aspect of it is that it lets you create multiple objects (launch configs) that capture the interesting state so the user doesn't have to reenter it each time. It might be worth evaluating some of the other IDEs out there to see how they do deploy. Although I agree time is short. If this is not feasible in the time remaining, and we can only support deploying a single app, then the wizard should at least remember the last values entered so that the user doesn't have to enter them each time. This will definitely be an iterative process.
A different approach to remember values would be building an ANT-Skript ... like several other wizards do.
I would like to add a user perspective here. Some my points are probably duplicate. I am building an application on top of Eclipse M8. What I wanted but could no achive yet: 1- Create a plugin of my own with its own perpective/views 2- Create a primary feature for branding (Splash Screen, Appication Icon and Name, etc) 3- Deploy my product 4- Have a launcher included in the deployment that starts the Eclipse with my product with its perpective. It will nice to pick an name and icon for the launcher. It will be great if I can achive all of this with a single wizard. So far I have not seen a working example and documentation on how to do this. Eclipse M8 still has the feature project. I am not sure is this by design. It seems that there is no use for it.
By the way, would it be possible that this export/deploy wizard creates Mac OSX application bundle ? It would be even greater if the generated application bundle could include all of eclipse's stuffs (instead of having separates directories for plugins and features as it is now in the current Mac distribution of Eclipse), but I don't know to what extent it is possible with the current architecture of RCP.
Olivier, it would be great if you could contribute some code in this area. We don't know much about Mac application bundles and what is involved in making them. I mean, we know hoave to make the standard Eclipse ones but once you open the box and try making random user defined ones I suspect it gets more complicated.
Much to the disappointment and heartbreak of everybody on the cc list, this item is going to be deferred to 3.1. Coming up with a product-quality wizard that addresses all the requests and points made above simply and realistically cannot be done in the time remaining in the M9 cycle. We are already past feature-freeze and it cannot be done in 2 or 3 days. It would take 2-3 weeks. Since there is life after 3.0, we look forward to providing such a great feature in 3.1.
I am not such an expert in this area, however I have to find a solution for my own RCP app which is intended to primarily run on Mac OSX. I see that this item is deferred to 3.1 so I'll perhaps have some extra time to find out how to do it. In that case I'll surely contribute my code.
This is indeed disappointing news but maybe it's an opportunity too. May I suggest starting a mini-project like we did with org.eclipse.ui.internal.r21presentation for an RCP export wizard that several people can contribute to? Although it wouldn't necessarily be an officially supported part of 3.0 it would be available in the same time frame and be targeted for inclusion at the next release opportunity. I know you'll need to get PMC approval and all that, but what do you think?
The feature must not cause us to delay R3.0 ship date. On the other hand, if it is created outside of the official build (as an optional download perhaps) and worked on beyond the R3.0 date (i.e. over summer months), it will provide desired function for people who need it and incremental improvement based on feedback.
That what I had in mind; can you or Wassim champion this with the PMC? I will contribute (code, feedback) to such a project if created and I'm sure there are a few others that can do the same. Kevin H set up a couple people as temporary committers on the r21presentation project and I thought that worked out pretty well, maybe you could get him to do the same for this. Then you or Wassim or someone else on the team could seed the project with some kind of skeleton wizard (that sounds kind of creepy doesn't it) and we could have at it.
I'm also in favour of making this a "sanctioned" skunkworks project. In the meantime, if we can pull together a list of manual steps needed to deploy an RCP app, that would be good. I would like to add such an entry to the RCP FAQ. Wassimm, do you have the cycles to sketch out such a list?
Not at this time.
Got some reading to do to catch up here...
I'm putting together a document that explains how to leverage the functions provided by pde to export RCP apps. You can find it at: http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/pde-build- home/articles/export%20rcp%20apps/article.html?rev=HEAD&content-type=text/html All comments are welcome.
Pascal's article is also linked to from the RCP FAQ, available off of the RCP home page: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui-home/rcp/index.html
Resurrecting for 3.1 After some recent discussions, we decided to have an LCD-like dialog for all the deployment activities in Eclipse, so that users can save multiple configurations of each export type. The plug-in/feature export wizards will go away and will move in there. The new RCP app export will be done there in two flavors (feature-based and plugin -based). Also, the dialog will house JDT-related exports (e.g Application export on Mac).
Another use case would be deploying a program that is based on SWT or SWT/JFace. This would be without plug-ins, just copying the swt jars and dlls/sos and hooking everything up. A future enhancement needed for RCP exports, which I'm not requesting yet but I'd like to keep in mind, is the ability to generate a native launch program with the right icon and title. Changing the icon/title is a laborious process at least on Windows involving editing resources and rebuilding a C program.
The SWT/JFace request is also included in this effort and will be addressed by the JDT team, I believe.
cc Andre as he might be interested in this discussion.
Any update on this? Do you need a prototype or something to get things started?
Thanks. I have a good enough idea of what people want to get things started. I am waiting for PMC feedback on a couple of issues.
Added myself to cc list
An update: I will be working on a prototype during the post-3.1M4 part of December (ie. during the lame duck session of Eclipse development :-) It will be available for public viewing in early January. Thanks for everybody's input. It will all be taken into account in the solution we are coming up with.
Wassim, any news?
It will be in 3.1M5
Will it generate an Ant script?
For a fully automatic build and test cycle we would need an ant task similar to pde.exportfeatures (e.g. pde.exportrcpapplication). This task should be able to run synchronously, since we want to perform some tasks after the export. This was already submitted for pde.exportfeatures and pde.exportplugins at https://bugs.eclipse.org/bugs/show_bug.cgi?id=58413
For all the ant task related issues, please open a separate feature request, as this bug report will not encompass it.
Added bug 84065 for ant support.
Modifying the summary to reflect the actual scope, solution and implementation. A wizard would be insufficient for many reasons listed above. Therefore, we are providing a fancy editor that will allow you to compose your product and define all aspects (eg. branding, content, config.ini) etc. From within the editor, you will be able to do a one-click export.
and now for the four most beautiful words ever uttered: "The editor is ready". And if I may say so, it's a nice piece of work ;-) It will be in previews starting with today's I-build. Please take a look at it, especially if you or someone you know are doing an RCP-related activity (tutorial/talk/BOF) at EclipseCon. The entire RCP product export story is based around a *.product file. Use the Product Configuration wizard (bug 73818) to create the file. In the file itself, you can manage all aspects of your product from the basic definition to the content to branding. You have the option to build a feature-based or a plugin-based product. The overview page also serves as launching points to test and package the product. Will keep the bug report open for the next few days as we will be adding a couple of advanced enhancements and some polishing. Some time in the next week or so, I'll whip up a document to be posted on the PDE/UI home page detailing an end-to-end scenario of how to create/test/package a product.
Added a new section to allow users to specify program/vm arguments for the <launcher>.ini file. Fixed wrapping layout issues. For more enhancements, please open separate bug reports to be considered individually. Marking as fixed.
Created attachment 18477 [details] Product editor patch for overview page ui
Created attachment 18478 [details] Product editor overview page ui image - alt format
Not sure of the protocol here but here goes... I've played with the RCP product editor a bit, and have made it do what it wants to do; at the same time I've not been happy with the UI. So, while on the plane back from EclipseCon, and in need of some practical UI Forms experience, I fiddled the product editor UI, specifically the Overview page. I tried ColumnLayout a bit, to get the four defs (product id, name, appl id, and config) to bounce from two to one column, but it was painful to watch at times. Settled on a 2 column grid with layout control that makes the fields a bit wider for better data entry/visual display. Also made the test/launch section a twistie - as I think long term most will migrate to the launch dialog once a launch config as been created. Patch and image of same attached. The patch was based on the v20050301 tagged version of the pde.ui plug-in.
>at the same time I've not been happy with the UI. From your screenshot, I am assuming you are referring to the field where you enter the zip file name. I don't like it either, however this will go away soon. All this build info will be taken out of the editor shortly into a wizard as we are planning to add more export options etc. (bug 85153) With that problem out of the way, I think the current layout is more esthetically pleasing than the alternative suggested in comment 51.
Created attachment 18480 [details] Normal sized editor UI overlaid on maximized editor display Yes, the Browse button was one issue; that and half the time when I clicked on the export link it just scrolled right. But the other big problem I had with the rest of the UI was that I could not see the full value of the product id or application id in the dropdown list. They were always smaller than the id, and seemed to start part way through the value. Even when I maximized the editor they did not show the values, they were still starting several chars in and I had to touch each one (and then press home) to get the full id visible in the dropdown. See attachment where the maximized size and then the standard size are shown. The standard size is shown in the Java perspective after a reset (and workbench window is full screen). So... I think there is a need to tweak something to get the dropdown values legible.
this is a problem with SWT's CCombo (bug 55074).
