Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "COSMOS SDD Minutes 08JAN14"
m |
m |
||
| Line 16: | Line 16: | ||
- Need set of rules for assembling the metadata and resolving conflicts (same set of data with different values) <br> | - Need set of rules for assembling the metadata and resolving conflicts (same set of data with different values) <br> | ||
- As the SDD is being created, validate that what has been created is syntactically correct. You may want to turn validation on or off. A plug-in rules engine could also be useful to validate user extensions that are allowed by the validation process. <br> | - As the SDD is being created, validate that what has been created is syntactically correct. You may want to turn validation on or off. A plug-in rules engine could also be useful to validate user extensions that are allowed by the validation process. <br> | ||
| + | - Next step would be creating the actual package: SDD, artifact onto "media" that would make it consumable. May need to include packaging in the SDD runtime and repository tools. <br> | ||
| + | - Tool must be able to be configured (where is data source, what rules are created, etc): basic administration of the tool parameters. For moving the tool for use in another department or product. These things will change: artifact inputs, location of SDD outputs, custom rules for creation and validation, SDD content constraints (per IU, CU, LU) | ||
Revision as of 15:00, 14 January 2008
Attendees: Jason Losh, Merrie Jensen, Jeff Hamm, Chris Mildebrandt, Mark Weitzel, Charlie Halloran, Mark McCraw(SAS), Josh Hester (SAS), Jimmy Molson (CA Prod Mgr), Jack Devine (CA), Robert DeMason(SAS)
Minutes: Working on logistics Iteration 10 is March/end June. Need to identify any dependencies among the project. Q(Jimmy): What is scope of Use cases? Just installation of COSMOS components? A(Mark): Scope is package authoring tooling & runtime of CL1 of the SDD spec plus examples. Maybe including installing pieces of Eclipse depending on how we line up with P2. This needs to be extensible so it can be expanded to add CL2 support when resources are available.
Start with Tools
- Work item: how to contribute code form both SAS and IBM
- Use case: normal development creates artifacts which reside somewhere. Need to create SDDs for these artifacts based on the build information. Build information can be metadata somewhere or introspected from the artifact itself.
- Separate use case: just introspect the artifact, especially in the case of a 3rd party component, and create as much of the SDD as possible.
- assume: 1 IU, LU, CU, and package descriptor per SDD. SDD means both, otherwise explicitly state it.
- Another use case: support for build systems beyond the popular rpn, msi, etc. so that metadata from those systems could be brought in.
- Need set of rules for assembling the metadata and resolving conflicts (same set of data with different values)
- As the SDD is being created, validate that what has been created is syntactically correct. You may want to turn validation on or off. A plug-in rules engine could also be useful to validate user extensions that are allowed by the validation process.
- Next step would be creating the actual package: SDD, artifact onto "media" that would make it consumable. May need to include packaging in the SDD runtime and repository tools.
- Tool must be able to be configured (where is data source, what rules are created, etc): basic administration of the tool parameters. For moving the tool for use in another department or product. These things will change: artifact inputs, location of SDD outputs, custom rules for creation and validation, SDD content constraints (per IU, CU, LU)