Hi all, I'm looking at recent examples of how the lifesci tenant is merging schema extension configuration in the app layer and it seems that there is a new approach to this practice? For instance, the previous manner was to have all domain-procedure-{procedurename}.xml files in a tenant folder, and these files would contain the domain-specific (or local-specific, if need be) schema extension configurations. These domain files were automatically merged with their respective base-procedure-{procedurename}.xml files and that was good. Now it appears there are examples of the same domain- files, but now prefixed with {tenantname}- or {domainname}- along with a merge attribute in the {tenantname}-tenant.xml file, e.g. <include src="base-collectionobject.xml,naturalhistory-collectionobject.xml" merge="xmlmerge.properties" /> found in lifesci-tenant.xml. Is this the new practice for schema extension configuration? https://github.com/collectionspace/application/tree/v2.4/tomcat-main/src/main/resources/tenants/lifesci - Jesse

Hi Jesse, Yes, this is a new way of doing app layer configuration. The old way should still work, but I'm guessing it will be deprecated at some point. The new way uses the same xmlmerge process that's used for tenant-bindings in the services layer. This means you can modify fields that are defined in the base file without recreating the entire field in your domain file (for example, to change options, or add an autocomplete vocab). The defaults/xmlmerge.properties file defines how the merge happens. If it doesn't work for something you want to do, you can point to a different properties file that you create in your tenant folder. The output of the xmlmerge goes into tomcat/temp, so you can see what's happening. There are lots of examples at https://github.com/cspace-deployment/application/tree/ucjeps_2.3/tomcat-main/src/main/resources (ucjeps-tenant.xml) and https://github.com/cspace-deployment/application/tree/pahma_2.4/tomcat-main/src/main/resources (pahma-tenant.xml). I've been updating the defaults/xmlmerge.properties file when I find that it doesn't handle something that I think will be commonly done by all the deployers. Ray On Jun 11, 2012, at 9:06 AM, Jesse Martinez wrote: > Hi all, > > I'm looking at recent examples of how the lifesci tenant is merging > schema extension configuration in the app layer and it seems that > there is a new approach to this practice? > > For instance, the previous manner was to have all > domain-procedure-{procedurename}.xml files in a tenant folder, and > these files would contain the domain-specific (or local-specific, if > need be) schema extension configurations. These domain files were > automatically merged with their respective > base-procedure-{procedurename}.xml files and that was good. Now it > appears there are examples of the same domain- files, but now prefixed > with {tenantname}- or {domainname}- along with a merge attribute in > the {tenantname}-tenant.xml file, e.g. <include > src="base-collectionobject.xml,naturalhistory-collectionobject.xml" > merge="xmlmerge.properties" /> found in lifesci-tenant.xml. > > Is this the new practice for schema extension configuration? > > https://github.com/collectionspace/application/tree/v2.4/tomcat-main/src/main/resources/tenants/lifesci > > - Jesse > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org