Hi James and Derek, We are also playing with the design of a component library - it would be great if we can put our efforts towards a single tool the entire community can use.
There are a couple of things I'm not clear about - but I fear some of them are simply a lack of understanding about MSI/WiX. > - Nothing should ever be removed from the database. New components > and files should only be added as they are shipped. The database needs > to remember anything which you've shipped to ensure there are no collisions. Can you please elaborate on this requirement? Why is a history necessary? If a component changes and its GUID is accordingly changed, what collisions are possible? The way I see it, the primary role of a catalog can be reduced to 2 tasks: * Check if the filesystem currently, exactly matches the previous 'expansion' of a component. * If the file-system does not exactly match, generate new GUIDs and take a new snapshot of the current 'expansion' So I'm missing how the history is relevant to the tool (I see how the history is useful to the developer - hence I propose the database format be XML, suitable for use with their existing source control system) > - Components and files should be added to the database from the msi > files just prior to being shipped. This ensures that the guids and > identifiers which you care about in terms of the component rules are the ones > you are tracking. I had pictured the database being updated as the MSI is being built, rather than post build. I see that from a process POV, people may find it useful to be done post-build - but am I missing a reason it can't be done at build time, with the updated component database checked into source-control at the same time? I'm not sure of any details of the design James has come up with, but for the sake of discussion, I include our current thinking on the authoring (note that our interest is for an open source project with many thousand files). A 'component specification' describes components in terms of wildcard specifications. For example, below is an example of a 2 specifications (which is maintained in its own XML file) <Shadow xmlns="http://schemas.enfoldsystems.com/wix/shadow/catalog'> <!-- The component definitions --> <!-- ComponentGroup provides a logical "grouping" of components automatically. Child nodes specify the source of files (eg Manifest allows wildcards to be specified, but one can imagine other techniques) --> <ComponentGroup Id="Zope"> <Manifest style="component_per_directory"> <![CDATA[ # here is a 'manifest' specifying the files to collect. recursive-include $(env.BUILDPATH)/Products/*.py recursive-exclude .svn CVS ]]> </Manifest> </ComponentGroup> <ComponentGroup Id="Python"> ... </ComponentGroup> </Shadow> Note that the above is only the *specification* - the tool will need to process this specification and maintain the database with the hash values, file stat info etc for the expanded specification. Even though the resulting database is not designed to be human edited, I picture this database also being XML to make it friendly to source control. Below is an example WiX source file that references the catalog: <Wix xmlns="http://schemas.microsoft.com/wix/2003/01/wi"; xmlns:se='http://schemas.enfoldsystems.com/wix/shadow/expansion'> <!-- the 'se' namespace is (ab)used for the component catalog expansion. --> ... <Feature Id="ProductFeature" Level="1" Title="Core Product"> <!-- 'include' ComponentRef nodes for the catalog items --> <se:ComponentRefs Id="Python"/> <se:ComponentRefs Id="Zope"/> </Feature> ... <!-- 'include' the component definitions for the catalog items --> <se:ComponentDefs Id='Python'/> <se:ComponentDefs Id='Zope'/> </Wix> The extension 'simply' (ha!:) processes the tree, with anything in the 'se' namespace substituting information from the catalog. Our design does get a little more complex when thinking about how to add additional Wix elements to a file in the component specification (eg, shortcut to a .exe), but the above describes the gist of it. I'd appreciate all comments - including 'you are mad!' :) Am I making this too complex for its own good? Is there something obvious I have overlooked? Is your idea (James) anything like this? Cheers, Mark. ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
