Build Packaging for COSMOS
A Proposal for organizing downloads for COSMOS
This proposal is in the DISCUSSION state. When a decision has been reached, this proposal will be in the CLOSED state.
Currently, the zip files on the download page is organized by subprojects. I suggest grouping by adoption scenarios which is more meaningful for end users.
- COSMOS Demo
- This is the zip file that users will download to understand what COSMOS is and whether it's useful for their project. The zip file should include a deployable application that can demonstrate most of the features of COSMOS.
- This zip file can include:
- Management domain
- one or more example data managers and/or MDRs
- Web front end
- install guide and any necessary offline documentation
- COSMOS SDK
- This zip file will be downloaded by adopters who want to extend the COSMOS framework. It's installed by unzipping on top of the eclipse install.
- It includes:
- OSGi bundles (plugins) to be installed in eclipse. They include dependencies required by the COSMOS framework and the web front end framework.
- Source code in the form of source plugins.
- Any tooling used for creating data managers and MDRs.
- The SDK will require some prerequisites, such as WTP for web development.
- Eclipse-based tooling
- Some functions provided by COSMOS are tooling used in eclipse, in the form of eclipse plugins. This zip file contains plugins to be installed on the target platform. (i.e. unzip on top of eclipse install)
- The toolings include:
- SML editor and validator
- WSDM Tooling
- Help files
The first cut of the repackaging looks good but here are some ambiguities that we should address:
- As mentioned before, demo is not the best word to describe what is included in the package. The term demo indicates a set of examples that needs a platform to run on. It's misleading to include our runtime code in a package called demo. A better name is perhaps "COSMOS Runtime + Samples"
- To first time visitors, it's unclear what the difference between SDK and the demo package are. For example, is SDK = Demo + additional code or is it just additional code that still requires the demo package? Please see below for an alternative way of repackaging the driver.
- It's confusing to first time COSMOS users to use standard names as part of a package name. Almost all first time users wouldn't have a clue what SML is.
Here's an alternative repackaging suggestion:
"COSMOS Framework with Samples" (for end users)
- Management domain/broker
- Data manager samples
- Web-based UI client
"COSMOS Eclipse Tooling" (for developers)
- SML tooling
- Data manager toolkit (future enhancement)
- WSDM tooling
- SDK code required for users to develop their own data mangers
<mdw> I like the "COSMOS Framework with Samples" idea--this seems like a good first pass at organization.
I'm assuming that there is associated documentation with each of these. We may want to have a link to an overview or getting started section so someone could look at these and decide if they want to download or not
The COSMOS eclipse tooling should be also be available via an update manager site. </mdw>
Hubert's response here
I still think we need a separate package for the SML validation and SMLIF editor. Grouping this under the Eclipse tooling umbrella is not much better than grouping based on COSMOS subprojects. SML has nothing to do with WSDM tooling or CMDBf framework and it's not a good idea to group them in one package just because they are built as eclipse plugins.
I would not worry about using terms as SML, WSDM etc on package names. If users don't know what SML is they can read the description or simply ignore that package.I assume the download page has for every package a short description on what it contains, how to use it and any other useful information. A short tutorial, viewlet,etc would also help here.