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 frontend
- 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
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.
- Why are we including packages in our driver that we plan to deprecate? We haven't published any release yet and anything developed that should be scratched can just be removed. Remember, public API contracts don't apply when a release is being developed (i.e. If we create something in iteration x that we think is not necessary, then we can just have it removed in iteration x+1).
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
Hubert's response here