Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "SDD Runtime Design Discussion Artifacts"
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | |||
| − | |||
| − | The first goal that we are attempting to do is to validate the Change Analyzer (CA) output against the requirements of resolution to make sure that we have the correct data and that the data makes the links necessary between the elements in the SDD to perform validation. To that end, I have included the current AnalyzedSDD.xml as well as the FlattenedSDD.xml. These are files that are generated by the CA. | + | [For those interested in participating in the COSMOS Runtime Design Discussions, I thought it would be better to send out the following information in order for to get everyone on the same page. Hopefully this will allow us to make forward progress a lot quicker. |
| + | |||
| + | Attached you will find the [[cosmos_sdd.xml]] and [[cosmos_spd.xml]]. These files represent the first ( well maybe the 3rd or 4th ) attempt at describing the COSMOS install. We have scaled it down in order to try and get a simpler example with the minimum resources and requirements defined. | ||
| + | |||
| + | The first goal that we are attempting to do is to validate the Change Analyzer (CA) output against the requirements of resolution to make sure that we have the correct data and that the data makes the links necessary between the elements in the SDD to perform validation. To that end, I have included the current [[AnalyzedSDD.xml]] as well as the [[FlattenedSDD.xml]]. These are files that are generated by the CA. | ||
Our goal in the Change Resolver, and the runtime in general, is to use the internal memory representations of the AnalyzedSDD from the CA as input. Also, we want to have one definitive source of output from the CA hence the reason for looking at the AnalyzedSDDOutput classes. | Our goal in the Change Resolver, and the runtime in general, is to use the internal memory representations of the AnalyzedSDD from the CA as input. Also, we want to have one definitive source of output from the CA hence the reason for looking at the AnalyzedSDDOutput classes. | ||
| Line 10: | Line 12: | ||
So I would encourage each of you to get the latest CA code from CVS and run it against the cosmos_sdd.xml provided here and see that you get the same AnalyzedSDD content as we have been getting. Once there, we can discuss whether or not these problems as described above are actually problems and when/if we solve them. I think getting to this point will provide a better understanding of the runtime requirements of analysis and resolution, and then bring on more discussions of how resolution is performed, how the profile module is designed, and how we leverage the P2 framework in conjunction with all of these efforts. | So I would encourage each of you to get the latest CA code from CVS and run it against the cosmos_sdd.xml provided here and see that you get the same AnalyzedSDD content as we have been getting. Once there, we can discuss whether or not these problems as described above are actually problems and when/if we solve them. I think getting to this point will provide a better understanding of the runtime requirements of analysis and resolution, and then bring on more discussions of how resolution is performed, how the profile module is designed, and how we leverage the P2 framework in conjunction with all of these efforts. | ||
| + | |||
| + | [[Dec 10 Discussion]] | ||
Latest revision as of 16:59, 10 December 2008
[For those interested in participating in the COSMOS Runtime Design Discussions, I thought it would be better to send out the following information in order for to get everyone on the same page. Hopefully this will allow us to make forward progress a lot quicker.
Attached you will find the cosmos_sdd.xml and cosmos_spd.xml. These files represent the first ( well maybe the 3rd or 4th ) attempt at describing the COSMOS install. We have scaled it down in order to try and get a simpler example with the minimum resources and requirements defined.
The first goal that we are attempting to do is to validate the Change Analyzer (CA) output against the requirements of resolution to make sure that we have the correct data and that the data makes the links necessary between the elements in the SDD to perform validation. To that end, I have included the current AnalyzedSDD.xml as well as the FlattenedSDD.xml. These are files that are generated by the CA.
Our goal in the Change Resolver, and the runtime in general, is to use the internal memory representations of the AnalyzedSDD from the CA as input. Also, we want to have one definitive source of output from the CA hence the reason for looking at the AnalyzedSDDOutput classes.
So currently, we are seeing a couple of problems in the fact that some of the Variables are missing default values and we are losing references to what conditions they apply to. It appears that for ConditionalDerivedVariables (which you can find in the AnalyzedSDD.xml at the bottom), the default values as specified by the Expression tags in the SDD are missing. Also, you will notice that each of the installRoot1 and installRoot2 id values have no uniqueResourceReferenceId so we have no way of knowing which installRoot definition goes with which condition. We think these are either bugs in the xst transformations or that these values were not necessary in the original goal of the CA so they were never added.
So I would encourage each of you to get the latest CA code from CVS and run it against the cosmos_sdd.xml provided here and see that you get the same AnalyzedSDD content as we have been getting. Once there, we can discuss whether or not these problems as described above are actually problems and when/if we solve them. I think getting to this point will provide a better understanding of the runtime requirements of analysis and resolution, and then bring on more discussions of how resolution is performed, how the profile module is designed, and how we leverage the P2 framework in conjunction with all of these efforts.