Bugzilla – Full Text Bug Listing
| Summary: | Reduce RCP application size | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Ed Burnette <ed.burnette> | ||||
| Component: | Runtime | Assignee: | platform-runtime-inbox <platform-runtime-inbox> | ||||
| Status: | RESOLVED WONTFIX | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | dj.houghton, gunnar, ian.leslie, jeffmcaffer, Jim.Adams, n.a.edgar, ob1.eclipse, pascal, xavier.mehaut | ||||
| Version: | 3.0 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Ed Burnette
Adding JM + NE to CC. What amazing power of the RCP! You can write an application in 3.5K! Oh, ok. So what do you think we could remove? The problem really is one of component granularity. Sure for this application we likely don't need Jobs support. An probably not progress monitoring. and maybe not... If we broke the system (whether at the UI or Core level) into a whole bunch of pieces then people could pick and choose what they want and get pretty small. Unfortunately, that presents other challenges. I fully support the goal. What we need to find is chunks of function that could reasonably factored out and then reincluded as required. We started looking at the runtime for some of this but there is not alot. Ideas are welcome. BTW, what would be a reasonable size? Remember at Eclipsecon, somebody asked about multiple RCP applications sharing the same Eclipse directory? That's the wrong question but maybe the right answer. Consider this: - When you want to run a .Net application you first have to install the .Net Framework version 1.x. - When you want to run a game you first have to install DirectX version 9.x. - When you want to run a Flash program you first have to install the viewer. - When you want to read pdf's, you first have to install Acrobat Reader. - When you want to run a Java program you first have to install a JRE. People are used to this and accept it. So how about this: - When you want to run an RCP application you have to install the RCP Framework version 3.x. This would be an eclipse.org official 5-10+MB download, would come with its own install program, and be redistributable (of course). To make it easier on end users it might need to include a JRE. To avoid "classpath hell", the RCP Framework would support side-by-side installation so you could have 3.0, 3.0.1, 3.1, 3.2, 4.0, etc. installed at the same time in different directories so they wouldn't interfere with each other. An RCP application would indicate if it wanted to run on a particular version number, the latest minor version update, or the latest version of any kind. If an RCP application has its own install program then it could check to see if the correct version of the Framework is installed and if not, run the Framework's installer. Plug-ins, updates, or other changes would *not* be installed in the Framework's directory in order that the Framework should remain in a pristine and predictable state. The RCP Framework would include all non-IDE non-resource plugins in the Platform Runtime and all native code, dlls, shared libraries, and platform specific code that an RCP application might need. This includes the core runtime of course, Platform UI, help system, etc. RCP apps would be 100% Java unless they needed something special like an ActiveX control. If you carry it a step further, the Eclipse SDK could be split into two parts - the RCP Framework and everything else. There would be one RCP Framework download for each platform (Windows, Linux, etc.) but only one Eclipse SDK package would be needed. Or you use update sites - the RCP Framework would be enough to use an update site to install any RCP application including the Eclipse IDE and 3rd party RCP apps. Changing the way the IDE is packaged is not the main point of this idea, however, just a possible byproduct. Here's another benefit. When the RCP Framework is installed it could set things up so that RCP applets (SWT based, JFace based, or maybe even Workbench based) could run in your favorite browser because all the native code is already installed. These applets could be very small because the bulk of the code is pre-installed. Java Web Start programs get much smaller too. With a self contained RCP Framework install, my 3.5K program would take 3.5K plus a little for its install code that checks for the framework's existence and sets up whatever configuration is needed to run the app with the proper framework. I've seen install programs that take as little as 10K. That's optional and up to the writer of the application, but in any case it would be a heck of a lot smaller than 5MB. What do you think? We could change this bugzilla entry into an enhancement request to create the RCP Framework if you like the idea. Thanks for the detailed proposal. In general I like the ideas. Much of what you describe is already how Elcipse works. See http://help.eclipse.org/help21/topic/org.eclipse.platform.doc.isv/reference/misc /eclipse-install.html for more details on installing "extension" products to a base Eclipse install. Some points: - JNLP sounds like fun and despite several people at EclipseCon saying they would like to contribute in that area, nothing concrete has materialized. I'm all for it but we have no time to lead that effort. We can do changes to allow it but have to be told what to do and why. - Including a JRE with the base Eclipse is problematic for a number of legal and other reasons. - Do you see the RCP install really requireing an "installer"? Unzip is not good enough? - Not sure about what plugins should be included in the base RCP. Things like Help really bulk up the download because they include Tomcat etc. - what are the details of getting an Eclipse install registered with a browser as available for an applet? Is that able to distinguish between versions of Eclipse installed? Summary: Yes! This is an interesting direction. Anything we can do to make Eclipse as an RCP easier, more intuitive/natural, ... is a good thing. Unzip is ok for developers but not for end users. Also with unzip there is not a standard place for the install to go or a way for an RCP application to find that place. The plug-in list would need to be looked at. Help only adds 2-3MB to the framework download so I don't think it's a big deal. Getting an install registered with the browser would need to be looked at but we know it's possible because the JRE install does it. On Windows you could use ActiveX object ids and choose a different one for different versions of the framework. The RCP Framework install package would be different from what we normally think of as "Eclipse" or even the "Platform Runtime Binary". The Platform Runtime Binary package (zip file) is close but it's intended for embedding/linking with other applications, not being a service which is installed by the user, then located and used by applications later. Also the Platform Runtime Binary package has all the IDE stuff in it. It's been a while since the last update; any more thoughts on this? I think the direction is good but not sure what concrete steps are needed over what we have/are doing now. Can you enumerate? See bug 82271 for some additional comments. The requirement we're currently struggling with is to never have any jar file installed in more than once place. To me it seems that it's not so much a problem with a single RCP app as it is for multiple ones installed independently, maybe by different people and companies. If you do things in the obvious way then that 6M is repeated for each app. If you have some kind of custom install program and a shared 'Base' framework then how do you locate the Base's install directory? What if you're not allowed to modify it (just like we're not allowed to modify the JRE)? What if the user wants to upgrade the Base? Have side-by-side installs with an easy way to switch between them? Combine the RCP apps in flexible ways? Etc.. I don't think we want to get into the installer business. Eclipse currently defines ways that native installers can discover existing installs etc. These techniques and others can be used to get the effect you are after (various product suites out there have been doing this for a while). We would be happy to consider patches on this one but we don't have the usecases/requirements to drive it. Seems pretty wide open. Created attachment 18190 [details]
Architecture for sharing an RCP install
Have a look at this. Unless somebody can come up with a better idea I'll be
proposing this architecture at EclipseCon. Comments welcome.
*** Bug 97807 has been marked as a duplicate of this bug. *** The runtime has been split in portions that can be inidividually consumed; bundles are JARed. While footprint is always a consideration and in the back of the mind (like the ongoing slow-burning discussion around splitting OSGi into a few bundles), it seems that reasonable progress has been made. As for the shared RCP architecture, some of it has been discussed in the P2 project, see http://wiki.eclipse.org/Equinox_p2_Shared_Install , http://wiki.eclipse.org/Equinox_p2_Shared_Install_Plan , and Equinox dev discussion. |