Bugzilla – Full Text Bug Listing
| Summary: | Create a all platforms in one download | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Pascal Rapicault <pascal> |
| Component: | Releng | Assignee: | Platform-Releng-Inbox <platform-releng-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | birsan, clongfield, dev, ed.burnette, jean-michel_lemieux, jed.anderson, jeffmcaffer, n.a.edgar |
| Version: | 3.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
|
Description
Pascal Rapicault
I think we will need to look at legal requirements. There should not be any issues. Each of the plug-ins and features are self- contained with their own legal documentation and at this stage, all the platforms use the same default license. *** Bug 76725 has been marked as a duplicate of this bug. *** I hear this request a lot. With a Swing application it's pretty trivial, you just package the jar(s) and a little launcher script (maybe a .bat file for Windows and a /bin/sh script for Linux/Unix). Distributing a multi-platform RCP application is much harder currently. I do think a distinction should be made between full blown RCP applications and simpler non plug-in based applications that just use SWT (and optionally, JFace). The simpler configuration should help lower the barrier for Eclipse technology adoption even more. Bug 76725 has some more notes on this including a pointer to Jeff's proposal: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core- home/documents/deployment_packs.html Sorry for 3 posts in a row but I have a question after reading the Deployment Packs proposal. It says: "Further there is still a need for platform specific RCP SDK drops to carry the appropriate source." Am I reading this right that you think there needs to be *both* a unified multi-platform deployment package *and* 8 little platform specific packages? Why not have one Runtime package that contains all the runtime for all the platforms, and one SDK package that contains the contents of the Runtime package plus all the source for all the platforms, and get rid of all the other RCP packages? Yes, it would be much bigger than any one of the current RCP drops but smaller than the sum total (due to sharing of common ws, arch, and other plug-ins), and much easier for the multi-platform developer. And it would help unclutter the download page. In order to limit the number of download and reduce the confusion I think we want 9 downloads. The first 8 ones are what we have today has "RCP Runtime Binary". The 9th one is the "RCP SDK" including all the fragments for all the platforms with all the source and all the executable. The rationale for is: The RCP Binary would be comparable to the JRE for a given platform. It is just a building block that you get and you can run RCP apps against. The RCP Software Development Kit, given the multi-platform nature of RCP, should come with all the necessary artefacts for you to create an application for any platform supported by RCP. I don't think comment #7 works for two reasons: 1. You have to include an all-platforms download that does not include source. Presumably you don't want source and development doc in your commercial application download because of the extra space and because end users don't need the source. 2. I don't see the rationale for the 8 small downloads. The JRE isn't included in this (that's a discussion for another day). I'm thinking it should be like this: 1 SWT Runtime Binary (multi-platform combo package for deployment) 1 SWT SDK (adds source and programmer doc, is this needed? *) 1 RCP Runtime Binary (multi-platform combo package for deployment) 1 RCP SDK (adds source and programmer doc, is this needed? *) 1 Platform Runtime Binary (multi-platform combo package for deployment) 1 Platform SDK (adds source and programmer doc) 9 Eclipse SDK (one for each platform including source and programmer doc) *I'm not *really* sure you need all the SDK packages since presumably developers already have the Eclipse SDK or Platform SDK which includes all that. This would satisfy the initial request stated in this bugzilla entry. And also, I know it's not the primary concern but it would have the nice effect of reducing the number of packages on the download page from 67 to 27. The rationale for leaving the Eclipse SDK in single-platform downloads is that most people only develop on one platform (but deploy on many). You could argue that Platform SDK should remain in single-platform packages for the same reason. Or you could argue that Eclipse SDK should be 1 multi-platform package to reduce the downloads to 19. In my experience RCP apps are not based just on SWT. I tend to use SWT and just enough of the workbench to get the perspectives, views, editors, preferences, etc. So just an SWT based RCP distro isn't much help because you still have to go back and add in plugins by hand. I feel this could be better addressed by tooling and the Super RCP drop. Given the Super RCP drop the tool could perform all of the nasty cut/paste work required to assemble the distribution for any given platform/ws. This work is very PDE like, and I would assume that the final product would end up in the PDE. Also, it is important to note that RCP developers often distribute their own version of some of the workbench classes to filter out some of the root functionality in the workbench. Performing this overlay requires in-depth knowledge of the Eclipse classloading and I could see it being difficult for a novice Eclipse developer to get it right. A tool could recognize this situation and set up the classpaths accordingly. Finally, I think it is important to note that if we created a drop with all of the platform specific fragments a tool could use the drop together with a vanilla Eclipse drop to create the Super RCP drop. This might be the least bandwidth intensive solution because users will already have the vanilla Eclipse distribution installed. Jed, the problem you indicate of redefining some classes is interesting, but if we were to provide such a feature then it breaks the fact that eclipse is an integration platform given that any piece could be redefined. I think that some changes like that should be contributed back to the appropriate components. Note that you may want to enter a feature enhancement against Platform Runtime. Ed I think for now we should focus on the RCP case and on the Eclipse SDK (although we may want to do that later). I was using the JRE to do a parallel nothing more nothing less. I don't see why you need to have a RCP Binary (all platform), when you have a RCP SDK (all platform), since the first one can be derived from the second by PDE. Pascal, my friend, I completely agree. However, the time it take for a feature request, implementation and release is 6 months to a year. My previous clients had only three months! When you have no time you have no choice but to hack away. So I guess my point is that I agree with you academicly, but pratical issues force such garrish measures. so many comments, so little time... Observations - The runtime binaries are largely for show. They could be deleted - People tend to develop, test, debug on one machine. They expect to have source. - not everyone deploys - SWT only is interesting but not a mainline usecase just as OSGi only, etc etc is not. - Overlaying/hacking/changing Eclipse plugins is sometimes required but there are no plans to make/adjust tooling to directly support this. - the deployment pack (as I propose) contains ALL fragments, not just those interesting for RCP Conclusions: - ignore the RCP binary drops - RCP SDK drops stay as-is. They are used by developers to write, test, debug. - people interested in deploying (RCP or IDE) get the Deployment Pack Separate issue: - The current dowloads pages are a disaster. They grew without control and are in dire need of rework. Even a simple reorientation to pick a platform first then pick what you want helps alot. The problem is not the number of downloads but rather figuring out what you want. In most cases people know the platform (s) they need and so can narrow quite quickly. The real solution is some sort of smart tech where the user selects the platform and function they want and either the client or server figures out what to download. But that is for another day... The Deployment Packs proposal speaks in terms of using features to describe the platform-specific dependencies, which implies not only the use of org.eclipse.update.configurator, but a broader buy-in to the Eclipse Update mechanisms such as features. What if the RCP app does not want to use the eclipse feature mechanism, or use some other install/update technology? Is it possible to create a deployment pack independently of the feature mechanism? I see the problem as having two parts: 1) How to simplify the distribution of platform-specific fragments and other pieces outside of regular the plug-ins and fragments (startup.jar, eclipse.exe, etc.). 2) How to choose which platform-specific fragments should be part of the runtime configuration. These both need to be addressed. The proposal addresses (1) by putting them all in the same build. But using features and Update mechanisms is only one way to address (2). Pragmatically, I'm fine with having an Update-specific solution for now, but it would be nice if plug-ins and fragments could describe their own platform-specific constraints. A lightweight configurator (possibly built into the runtime -- see bug 66451) could then select the appropriate plug-ins and fragments at runtime. Was there some reason why we didn't originally make plug-ins and fragments self-describing? I can imagine that this was perhaps a conscious decision, since the same fragment can get reused in multiple configurations. For example, the org.eclipse.swt.motif fragment is used in the Aix, HPUX, Solaris and Linux Motif configurations. But would it be a bad idea to move this into the fragment's own manifest? e.g. ws="motif" os="aix|hpux|linux|solaris" (or better yet, omit the os attribute entirely). Pascal, The reason for having the source-less deployment package was so the
developer could simply unpack the deployment package, overlay their own plug-
ins and branding, and repackage it. It's low tech but it works, and having the
multi-platform deployment package simplifies the process greatly over what
they currently have to do.
I think you're thinking ahead a bit about PDE export wizards subsetting and
copying files automatically to populate a deployment directory. If those
wizards existed and they were smart enough to know what is source and what is
developer doc then you're right, you wouldn't need the source-less packages
because the wizards could derive it. Hmm.... taking your idea a step further,
all you would really need is a multi-platform combo package for the Eclipse
SDK since that contains everything, and all the subsets can be derived from it.
Jed, the SWT packages contain only SWT and SWT fragments, for use by programs
like Azureus which don't need plug-ins. The RCP packages contain all the Core
RCP plugins including Core Runtime, SWT and JFace and Workbench and so forth.
You don't need to add anything by hand if you stay within that set.
Jeff, SWT-only is a mainline usecase, trust me on this.
How can you write, test, and debug with only an RCP SDK drop? It doesn't have
a JDT.
...
I think it would be a good exercise to create some personaes (can't believe
I'm saying this) that typify the various categories of Eclipse users and
developers. Then you can design your packages to target these personaes as
appropriate. For example, one (call him "Phil") could be your typical Java
programmer who is only using Eclipse on one platform as an IDE for arbitrary
Java programs. Another one ("Henri") is leading a team developing a suite of
commercial closed-source RCP applications for deployment on multiple
architectures. "Oliver" is using SWT in a popular open source project as a
replacement for Swing and doesn't need any of the runtime. "Jim" is writing
plug-ins based largely on Swing components for external customers who already
have Eclipse, "Rose" is developing in-house plug-ins to extend the IDE and
only cares about Windows, and "Ed" is a loose cannon who spends all his time
reading -dev mailing lists and writing bugzilla updates (sorry, couldn't
resist :).
Nick, in the case described here, the features are only used at development time to drive PDE and simplify the way people describe the content of their product. In any case they are not shipped and therefore not used at runtime. This is the same technique than the one we are using today to build the RCP drops for eclipse (see http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.sdk- feature/features/). Nick (comment 13) The Deployment Pack as described has only one feature and that is for the launcher. This is more of as input to PDE build (which most easilly understands feature-based descriptions of what to build). There is no need to actually deploy the features or use update.confirgurator. Interestingly, it may be relevant to have at least more feature which captures all of the RCP plugins. This would essentially be as an example. For example, the feature that includes SWT is a pain to do as you have to enumerate every SWT fragment with OS qualifiers etc. As for having fragments be self-describing, yes, this could be interesting. The idea originally was that the decision to install a fragment was one thing and the behaviour another. In any event, if you give PDE build a set of features with all the right mark up, it will automagically create the right thing for each target platform. It is really quite wonderful but is still somewhat hard to get right. Ed (comment 14) Not sure if we are agreeing but the only new thing I am proposing is a single zip that contains ALL fragmetns for ALL platforms and NO source. People interested in deploying simply overlay this on their current target and deploy. This is true whether they are doing RCP, IDE, .... Other Eclipse components with fragments etc could do likewise. SWT-only: I agree that many people are interested in just SWT. RCP SDK: The Eclipse use of the term "SDK" is as "the wad of stuff you need when you are developing plugins for a particular configuration". It does NOT include/imply the tooling. It just happens that the most convenient path for people right now is for them to get the "Eclipse SDK" and run it. In fact, the model, to be extensible and consistent would have them download (sigh) the binary platform, JDT and PDE to create an IDE and then download the appropriate SDK for their needs (IDE, RCP, GEF, ...) and use that as their target. As for your users, only Henri will be interested in the Deployment Pack. Everyone else is either not deploying Eclipse bits or is deploying to people who already have Eclipse. Of course, Ed should be interested but... ;-) To support Jeff's comment about being harry - oh, I mean about only supporting Henry's use-case is that fundamentaly the Eclipse platform RCP is defined as: "The platform for building Eclipse based applications using the Eclipse Workbench." Other configurations, although technically possible and definitly interesting, aren't the current focus of the RCP and thus of this bug report. But as Jed has said, there may be real projects using only JFace and SWT but at some point they will want plug-ins :) The deployment pack would also benefit applications not using the workbench, for example, SWT + JFace + Runtime. Delta pack (deployment pack) available as if 3.1 M4 build: http://download.eclipse.org/downloads/drops/S-3.1M4-200412162000/eclipse-RCP- 3.1M4-delta-pack.zip |