I've been taking a look at http://issues.collectionspace.org/browse/CSPACE-4137 and http://issues.collectionspace.org/browse/CSPACE-4138 with regards to the sorts of customizations I've been working on for the Walker. The cspace-config and UI paths look very promising. I'm a little unclear on some other parts, so thought I'd check on the following: First question -- I don't see anything related to schema changes on the services / Nuxeo side. Until now, with every release I've needed to copy our custom schema files into the local copy of the services code, and re-enter the new schema file data in core-types-contrib.xml and tenant-bindings.xml. Are either of those files stabilizing, or getting local files similar to core-local-settings.xml? Also, with every release and every change to one of our customized fields, I've been running `mvn clean install -DskipTests && ant undeploy deploy` from the services tree, then restarting both servers. Is that process still the same? Related to that, when upgrading between CSpace versions, I've been running 'ant create_db import' to be sure we're working with a clean DB. Is that still recommended practice from 1.8 on, or can we safely assume that we won't be missing any DB changes? I'd be happy to try out the App and UI customizations, but I'm not sure how to get a copy of the 1.8 code up and running locally before the tarballs are released. If this would be useful, are there any notes on the wiki about getting the prerelease code running? cheers, Joe

Hi Joe, Thanks for your great set of three questions, as always. A belated response, with apologies; we've had our "heads' down" a bit with work on v1.8 testing and bugfixing. 1. How do you make schema changes on the services / back-end / Nuxeo repository side in v1.8? > I don't see anything related to schema changes on > the services / Nuxeo side. Until now, with every release I've needed > to copy our custom schema files into the local copy of the services > code, and re-enter the new schema file data in core-types-contrib.xml > and tenant-bindings.xml. Are either of those files stabilizing, or > getting local files similar to core-local-settings.xml? The latter: the services are also getting 'local' (or per-tenant) files, starting with v1.8. Some background on v1.8 changes that impact customization, and an overview of these services changes, is appended at the end of this message, below. 2. Is running "mvn clean install ... ant deploy" from services is still the process to follow in v1.8? > Also, with every release and every change to one of our customized > fields, I've been running `mvn clean install -DskipTests && ant > undeploy deploy` from the services tree, then restarting both servers. > Is that process still the same? Yes. If you're creating extension schema - that is, parts of a record like Cataloging / CollectionObject, Intake, Media, etc., that contain your own custom fields - that is still the process. If you're customizing only a single record type, it's often feasible to run 'mvn clean install -DskipTests' just within the services module whose record type you're customizing; e.g. within services/collectionobject, services/intake, or services/media, which is faster than running it from the top of the services source code tree. You can then change the tenant bindings, as needed, to reflect that change to the schema, and run 'ant undeploy deploy' from the top of the services tree. As discussed further below, in v1.8 you can have a custom tenant bindings file for your tenant, and in that file you'll only need to specify the differences between your own tenant and a prototype tenant. 3. Is wiping and rebuilding databases still needed in v1.8? > Related to that, when upgrading between CSpace versions, I've been > running 'ant create_db import' to be sure we're working with a clean > DB. Is that still recommended practice from 1.8 on, or can we safely > assume that we won't be missing any DB changes? Release v1.8 introduces a significant change: defaulting to the PostgreSQL database system, while still optionally supporting MySQL. As a result, it will be desirable to go through this process at *least* once more, in v1.8. Documentation on *all* of this is coming, hopefully soon. There were a myriad of substantive changes in v1.8, which now require new or updated documents. We'll endeavor to keep the Talk list updated with news of significant new documentation, as it comes out. Aron P.S. Appended below is some background and summarization regarding your first question: about improvements in v1.8 in a deployer's ability to make and preserve customizations, and changes in the services, App, and UI layers to accommodate this. -- Overview of multi-tenancy changes in v1.8 A major initiative in release v1.8 was to provide significantly better support for multi-tenancy: the ability to offer multiple, customized deployments of CollectionSpace on a single host. This would make it possible, for instance, for a service provider, or a museum, association, or other non-governmental organization to provide a hosting service through which multiple museums or similar institutions could manage their collections, without having to run CollectionSpace on their own systems. This work also provides a significant side-benefit for all deployers: the ability to create a 'tenant' - a space in which you can make customizations for your own museum or similar institution - even if you will run CollectionSpace locally, on your own server. This can help insulate you and other deployers, at least to a degree, from ongoing changes to the source code and default configuration of the CollectionSpace system itself. (You'll still need to keep your customizations updated over time to reflect those ongoing changes, but at least they can reside within the source code trees and won't be "clobbered" by identically-named files with each new release.) Changes in the App and UI layers In CollectionSpace's front-end - the Application and UI layers - as you've noted, Chris Martin, Yura Zenevich, and other colleagues on the project team have made some exciting (to me, at least :-) and welcome changes in v1.8 to provide tenant-specific folders within the UI source code tree in which customized HTML templates, CSS stylesheets, JavaScript-provided behavioral changes, etc. can go, buttressed by the ability to serve these from the app layer. In addition, the app layer now has tenant-specific files to configure per-record and per-field behavior, for instance, as well as the hosts and paths for per-tenant storage of records and images. Chris's and Yura's write-up of these UI and App layer changes can be found here: Multi Tenancy in the UI & App http://wiki.collectionspace.org/x/qwBwB You can see a working example of a tenant with two minor but distinct differences from the default tenant, by looking at the src/main/webapp/tenants/lifesci folder in the UI source code tree, and the tomcat-main/src/main/resources/lifesci-tenant.xml file in the App layer source code tree. These changes include: * A Cataloging / CollectionObject record that features a repeatable row of custom fields for Determination History (i.e. scientific taxonomy identification). * A Taxon authority record type, accessible via an autocomplete field in that row of custom fields, as well as searchable via the Search boxes at upper right and on the Find and Edit page. Changes in the Services layer In the v1.8 services layer, you can have a custom tenant bindings file for your tenant (analogous to the v1.8 app layer custom config file for your tenant). That custom tenant bindings file is a 'delta' file: you'll need to specify only the *differences* between your own tenant and a prototype tenant, which contains a complete, default configuration, so your customizations can be sparse and easily viewed and understood. The 'delta' tenant bindings file will include some XML markup describing how your customizations will be merged with the default configuration. You can find an example of a 'delta' file that specifies that the 'lifesci' tenant is identical to other tenants, except for having an extra schema extension part for the Cataloging / CollectionObject record, here: <https://source.collectionspace.org/collection-space/src/services/trunk/services/common/src/main/cspace/config/services/tenants/lifesci/> While that example may be sufficient for your needs, it's also useful to know where you can find the reference document on that XML markup, describing how you can finely control how your per-tenant customizations are merged with the defaults: https://source.collectionspace.org/collection-space/src/sandbox/XMLMergeSample/XMLMerge-ReferenceDoc.pdf Another change that is being introduced in v1.8 is that of tenant-specific document types. Prior to this release, if you added a custom part to, say, the Cataloging / CollectionObject record, all tenants would 'get' that change as well. Now, you can not only have your own .xsd schema file for your custom record part, you also have your own core-types-contrib.xml, etc. An example of adding a custom schema extension as a new part to the Cataloging / CollectionObject record type, for the lifesci tenant, can be found here: <https://source.collectionspace.org/collection-space/src/services/trunk/services/common/src/main/cspace/config/services/tenants/lifesci/> <https://source.collectionspace.org/collection-space/src/services/trunk/services/collectionobject/3rdparty/nuxeo-platform-collectionobject-lifesci/src/main/resources/> This schema extension includes the set of custom fields that correspond to the repeatable row of custom fields for Determination History in the Cataloging record, in the App and UI layers, as mentioned above, as well as some additional fields that appear in the database, but currently are not exposed via the app and UI layers. On Thu, Jun 23, 2011 at 9:09 AM, Joe Slag <joe@slagwerks.com> wrote: > I've been taking a look at > http://issues.collectionspace.org/browse/CSPACE-4137 and > http://issues.collectionspace.org/browse/CSPACE-4138 with regards to > the sorts of customizations I've been working on for the Walker. The > cspace-config and UI paths look very promising. I'm a little unclear > on some other parts, so thought I'd check on the following: > > First question -- I don't see anything related to schema changes on > the services / Nuxeo side. Until now, with every release I've needed > to copy our custom schema files into the local copy of the services > code, and re-enter the new schema file data in core-types-contrib.xml > and tenant-bindings.xml. Are either of those files stabilizing, or > getting local files similar to core-local-settings.xml? > > Also, with every release and every change to one of our customized > fields, I've been running `mvn clean install -DskipTests && ant > undeploy deploy` from the services tree, then restarting both servers. > Is that process still the same? > > Related to that, when upgrading between CSpace versions, I've been > running 'ant create_db import' to be sure we're working with a clean > DB. Is that still recommended practice from 1.8 on, or can we safely > assume that we won't be missing any DB changes? > > I'd be happy to try out the App and UI customizations, but I'm not > sure how to get a copy of the 1.8 code up and running locally before > the tarballs are released. If this would be useful, are there any > notes on the wiki about getting the prerelease code running? > > cheers, > Joe > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >

Very informative! That clears up much of what I was wondering. Looking forward to taking the new code out for a spin. thanks, Joe On Wed, Jun 29, 2011 at 3:28 PM, Aron Roberts <aron@socrates.berkeley.edu> wrote: > Hi Joe, > >  Thanks for your great set of three questions, as always.  A belated > response, with apologies; we've had our "heads' down" a bit with work > on v1.8 testing and bugfixing. > >. . .