A follow up: is it necessary to use the is-extension="true" or generate-services-schema="true" attributes in the schema extension xml files? I've seen either used in prior examples. Thanks, - Jesse On Tue, Oct 29, 2013 at 5:31 PM, Jesse Martinez <mjesse@gmail.com> wrote: > This is great news, Aron and Ray. And the time now taken to build out a > schema extension has significantly decreased since tenant bindings are > autogenerated for the most part! :-) > > > > > On Tue, Oct 29, 2013 at 5:01 PM, Ray Lee <rhlee@berkeley.edu> wrote: > >> Hi Jesse, >> That's right, no need to create submodules in the services layer. To me >> that's at least as big a win as not having to edit tenant bindings. There >> was a lot of finicky configuration in those things. >> >> These are the times when you still have to touch services layer config >> after editing app layer config, that I've found: >> >> When creating a tenant, you still need to create a folder named with the >> tenant name, in services/common/src/main/cspace/config/services/tenants/. >> That folder needs to contain a file called <tenant >> name>-tenant-bindings.delta.xml. Core and lifesci have examples of that. >> >> If you're extending contacts, you still need to add tenant bindings by >> hand, because there's a bug that they're not being generated (CSPACE-6185<http://issues.collectionspace.org/browse/CSPACE-6185>). >> You now make those tenant binding changes in <tenant >> name>-tenant-bindings.delta.xml. The pahma_4.0 branch has an example of >> that. >> >> If you're using a separate repo for your tenant (i.e., not the nuxeo >> database), this is now configured in your settings.xml file in the app >> layer. But in the services layer, you need to add a repo config file in >> 3rdparty/nuxeo/nuxeo-server/5.5-HF07/config. The lifesci tenant has an >> example of that. >> >> Ray >> >> >> On Tue, Oct 29, 2013 at 1:37 PM, Aron Roberts <aronroberts@gmail.com>wrote: >> >>> > Is it now not necessary to create a submodule for a schema extension >>> within the service layer? I see that the xsd and supporting OSGI files are >>> now deprecated. >>> >>> Yes, that's my understanding. All of that is no longer necessary. >>> >>> In version 4.0, to make schema additions - adding one or more schemas >>> containing fields relevant to your museum or community of practice, >>> supplementing the standard set of fields in the 'common' (SPECTRUM-based) >>> schemas - much of the painstaking work that you formerly needed to do >>> within CollectionSpace's Services layer is simply GONE. Bye bye, no need >>> to do that ever again. >>> >>> Off the top of my head, if you're extending one of the standard record >>> types - objects (Cataloging/CollectionObjects), procedures, or authority >>> terms - you need only do this to add your extensions to both the App and >>> Services layers: >>> >>> * Make a few fairly simple changes in App layer config files to declare >>> the schema extension and its fields. (In its simplest form, adding a >>> single text field to a single record type, this can take just 4-5 lines of >>> markup: >>> https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/tenants/lifesci/lifesci-authority-person.xml#L18 >>> ) >>> * Build the App layer ('mvn clean install' from the top of the App layer >>> source code tree). This takes roughly 1 minute on a typical system. >>> * Run a Services Ant script to build the corresponding Services >>> artifacts, which include schemas (XSD files), Nuxeo document type >>> declarations, and service bindings (via 'run deploy_services_artifacts' >>> from within services/JaxRsServiceProvider). This takes roughly 20 seconds. >>> * Restart the CollectionSpace servers. >>> >>> And you're then nearly done. The remaining work is solely in the UI >>> layer, and for simple extensions, consists of: >>> >>> * Editing HTML templates in the UI layer to add your new fields where >>> you want them to go, on record editor pages, advanced search pages, and the >>> like. >>> * Editing the message bundle overlay file for your tenant, to add text >>> labels for those fields. >>> >>> Aron >>> >>> >>> On Tue, Oct 29, 2013 at 1:16 PM, Jesse Martinez <mjesse@gmail.com>wrote: >>> >>>> Thanks to all for these sources of info. Not having to update the >>>> tenant bindings file sure makes things more streamlined. >>>> >>>> I do have a few preliminary questions to ask, though. >>>> Is it now not necessary to create a submodule for a schema extension >>>> within the service layer? I see that the xsd and supporting OSGI files are >>>> now deprecated. >>>> At what times is it now necessary to update the service layer code base >>>> when editing/updating the app layer config files? >>>> >>>> Thanks, >>>> >>>> - Jesse >>>> >>>> >>>> On Mon, Oct 28, 2013 at 4:48 PM, Aron Roberts <aronroberts@gmail.com>wrote: >>>> >>>>> One more note: per-service, per-tenant bindings are now largely >>>>> generated from App layer configuration in version 4.0. This occurs when >>>>> you run 'ant deploy' (at the top of the services source code tree) or - >>>>> considerably quicker - 'deploy_services_artifacts' from within >>>>> services/JaxRsServiceProvider. >>>>> >>>>> Because these are now generated, service bindings have been removed >>>>> for many record types - objects, procedures, and authorities - from the >>>>> 'prototype' bindings file >>>>> (services/common/src/main/cspace/config/services/tenants/tenant-bindings-proto-unified.xml) >>>>> in the services source code tree in version 4.0. Remaining in that file >>>>> are a number of AuthN/AuthZ and utility record types. >>>>> >>>>> >>>>> On Mon, Oct 28, 2013 at 1:26 PM, Ray Lee <rhlee@berkeley.edu> wrote: >>>>> >>>>>> Hi Jesse, >>>>>> The 4.0 pahma app layer is here: >>>>>> https://github.com/cspace-deployment/application/commits/pahma_4.0 >>>>>> >>>>>> If you diff it against the pahma_3.3 branch, you'll see all the >>>>>> changes I made to do the upgrade. >>>>>> >>>>>> Thanks, >>>>>> Ray >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Oct 28, 2013 at 12:26 PM, Aron Roberts <aronroberts@gmail.com >>>>>> > wrote: >>>>>> >>>>>>> Ray's notes on upgrading from a version 3.3 system to a version 4.0 >>>>>>> system can be found in his detailed comments on this issue: >>>>>>> >>>>>>> http://issues.collectionspace.org/browse/PAHMA-933 >>>>>>> >>>>>>> In addition, the Lifesci tenant in version 4.0 demonstrates some >>>>>>> simple configuration changes and the use of schema extensions for the >>>>>>> Cataloging and Person records: >>>>>>> >>>>>>> >>>>>>> https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/tenants/lifesci/naturalhistory-collectionobject.xml >>>>>>> >>>>>>> >>>>>>> https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/tenants/lifesci/lifesci-authority-person.xml >>>>>>> >>>>>>> Aron >>>>>>> >>>>>>> >>>>>>> On Mon, Oct 28, 2013 at 11:05 AM, Richard Millet < >>>>>>> richard.millet@berkeley.edu> wrote: >>>>>>> >>>>>>>> Jesse, >>>>>>>> >>>>>>>> We're still working on updating the documentation to reflect the >>>>>>>> new configuration features in the v4.0 release. We're first updating the >>>>>>>> documentation for creating new v4.0 installations/deployments. Once that's >>>>>>>> finished, our next documentation task will be to create notes on porting >>>>>>>> pre-v4.0 deployments to v4.0. In the mean, let us know how we can best >>>>>>>> help. >>>>>>>> >>>>>>>> Ray has successfully upgraded at least one of the UC Berkeley >>>>>>>> instances to v4.0 -making him now the "world" expert on doing this. He may >>>>>>>> be able to send you some of his "raw" notes on how he did the upgrade. >>>>>>>> Between Aron, Ray, and myself, we should be able to answer most of your >>>>>>>> questions. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Richard >>>>>>>> >>>>>>>> Jesse Martinez <mjesse@gmail.com> >>>>>>>> Monday, October 28, 2013 10:11 AM >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I'm coming across some difficulties porting over development from >>>>>>>> pre-v4.0 to v4.0. Specifically, how to manage the great number of changes >>>>>>>> that occur in the tenant bindings files. Is there a guide that shows all >>>>>>>> the new mappings between the app and the service's tenant bindings? I can't >>>>>>>> get schema extensions to save in the gui and I'm not sure how to >>>>>>>> troubleshoot this issue. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> - Jesse >>>>>>>> _______________________________________________ >>>>>>>> Talk mailing list >>>>>>>> Talk@lists.collectionspace.org >>>>>>>> >>>>>>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk mailing list >>>>>>>> Talk@lists.collectionspace.org >>>>>>>> >>>>>>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk mailing list >>>>>>> Talk@lists.collectionspace.org >>>>>>> >>>>>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Talk mailing list >>>>> Talk@lists.collectionspace.org >>>>> >>>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>>> >>>>> >>>> >>> >> >

Hi Jesse, The is-extension="true" is necessary. The generate-services-schema="true" should already be on the base file, so it's not necessary. There's no harm in having it in the overlay because the merged file will end up the same (since the value is the same in the base file and the overlay), but since it doesn't do anything and is potentially confusing, I don't think it should be there. Which example did you see it in? Thanks, Ray On Tue, Oct 29, 2013 at 2:44 PM, Jesse Martinez <mjesse@gmail.com> wrote: > A follow up: > > is it necessary to use the is-extension="true" or > generate-services-schema="true" attributes in the schema extension xml > files? I've seen either used in prior examples. > > Thanks, > - Jesse > > > On Tue, Oct 29, 2013 at 5:31 PM, Jesse Martinez <mjesse@gmail.com> wrote: > >> This is great news, Aron and Ray. And the time now taken to build out a >> schema extension has significantly decreased since tenant bindings are >> autogenerated for the most part! :-) >> >> >> >> >> On Tue, Oct 29, 2013 at 5:01 PM, Ray Lee <rhlee@berkeley.edu> wrote: >> >>> Hi Jesse, >>> That's right, no need to create submodules in the services layer. To me >>> that's at least as big a win as not having to edit tenant bindings. There >>> was a lot of finicky configuration in those things. >>> >>> These are the times when you still have to touch services layer config >>> after editing app layer config, that I've found: >>> >>> When creating a tenant, you still need to create a folder named with the >>> tenant name, in services/common/src/main/cspace/config/services/tenants/. >>> That folder needs to contain a file called <tenant >>> name>-tenant-bindings.delta.xml. Core and lifesci have examples of that. >>> >>> If you're extending contacts, you still need to add tenant bindings by >>> hand, because there's a bug that they're not being generated ( >>> CSPACE-6185 <http://issues.collectionspace.org/browse/CSPACE-6185>). >>> You now make those tenant binding changes in <tenant >>> name>-tenant-bindings.delta.xml. The pahma_4.0 branch has an example of >>> that. >>> >>> If you're using a separate repo for your tenant (i.e., not the nuxeo >>> database), this is now configured in your settings.xml file in the app >>> layer. But in the services layer, you need to add a repo config file in >>> 3rdparty/nuxeo/nuxeo-server/5.5-HF07/config. The lifesci tenant has an >>> example of that. >>> >>> Ray >>> >>> >>> On Tue, Oct 29, 2013 at 1:37 PM, Aron Roberts <aronroberts@gmail.com>wrote: >>> >>>> > Is it now not necessary to create a submodule for a schema extension >>>> within the service layer? I see that the xsd and supporting OSGI files are >>>> now deprecated. >>>> >>>> Yes, that's my understanding. All of that is no longer necessary. >>>> >>>> In version 4.0, to make schema additions - adding one or more schemas >>>> containing fields relevant to your museum or community of practice, >>>> supplementing the standard set of fields in the 'common' (SPECTRUM-based) >>>> schemas - much of the painstaking work that you formerly needed to do >>>> within CollectionSpace's Services layer is simply GONE. Bye bye, no need >>>> to do that ever again. >>>> >>>> Off the top of my head, if you're extending one of the standard record >>>> types - objects (Cataloging/CollectionObjects), procedures, or authority >>>> terms - you need only do this to add your extensions to both the App and >>>> Services layers: >>>> >>>> * Make a few fairly simple changes in App layer config files to declare >>>> the schema extension and its fields. (In its simplest form, adding a >>>> single text field to a single record type, this can take just 4-5 lines of >>>> markup: >>>> https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/tenants/lifesci/lifesci-authority-person.xml#L18 >>>> ) >>>> * Build the App layer ('mvn clean install' from the top of the App >>>> layer source code tree). This takes roughly 1 minute on a typical system. >>>> * Run a Services Ant script to build the corresponding Services >>>> artifacts, which include schemas (XSD files), Nuxeo document type >>>> declarations, and service bindings (via 'run deploy_services_artifacts' >>>> from within services/JaxRsServiceProvider). This takes roughly 20 seconds. >>>> * Restart the CollectionSpace servers. >>>> >>>> And you're then nearly done. The remaining work is solely in the UI >>>> layer, and for simple extensions, consists of: >>>> >>>> * Editing HTML templates in the UI layer to add your new fields where >>>> you want them to go, on record editor pages, advanced search pages, and the >>>> like. >>>> * Editing the message bundle overlay file for your tenant, to add text >>>> labels for those fields. >>>> >>>> Aron >>>> >>>> >>>> On Tue, Oct 29, 2013 at 1:16 PM, Jesse Martinez <mjesse@gmail.com>wrote: >>>> >>>>> Thanks to all for these sources of info. Not having to update the >>>>> tenant bindings file sure makes things more streamlined. >>>>> >>>>> I do have a few preliminary questions to ask, though. >>>>> Is it now not necessary to create a submodule for a schema extension >>>>> within the service layer? I see that the xsd and supporting OSGI files are >>>>> now deprecated. >>>>> At what times is it now necessary to update the service layer code >>>>> base when editing/updating the app layer config files? >>>>> >>>>> Thanks, >>>>> >>>>> - Jesse >>>>> >>>>> >>>>> On Mon, Oct 28, 2013 at 4:48 PM, Aron Roberts <aronroberts@gmail.com>wrote: >>>>> >>>>>> One more note: per-service, per-tenant bindings are now largely >>>>>> generated from App layer configuration in version 4.0. This occurs when >>>>>> you run 'ant deploy' (at the top of the services source code tree) or - >>>>>> considerably quicker - 'deploy_services_artifacts' from within >>>>>> services/JaxRsServiceProvider. >>>>>> >>>>>> Because these are now generated, service bindings have been removed >>>>>> for many record types - objects, procedures, and authorities - from the >>>>>> 'prototype' bindings file >>>>>> (services/common/src/main/cspace/config/services/tenants/tenant-bindings-proto-unified.xml) >>>>>> in the services source code tree in version 4.0. Remaining in that file >>>>>> are a number of AuthN/AuthZ and utility record types. >>>>>> >>>>>> >>>>>> On Mon, Oct 28, 2013 at 1:26 PM, Ray Lee <rhlee@berkeley.edu> wrote: >>>>>> >>>>>>> Hi Jesse, >>>>>>> The 4.0 pahma app layer is here: >>>>>>> https://github.com/cspace-deployment/application/commits/pahma_4.0 >>>>>>> >>>>>>> If you diff it against the pahma_3.3 branch, you'll see all the >>>>>>> changes I made to do the upgrade. >>>>>>> >>>>>>> Thanks, >>>>>>> Ray >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Oct 28, 2013 at 12:26 PM, Aron Roberts < >>>>>>> aronroberts@gmail.com> wrote: >>>>>>> >>>>>>>> Ray's notes on upgrading from a version 3.3 system to a version 4.0 >>>>>>>> system can be found in his detailed comments on this issue: >>>>>>>> >>>>>>>> http://issues.collectionspace.org/browse/PAHMA-933 >>>>>>>> >>>>>>>> In addition, the Lifesci tenant in version 4.0 demonstrates some >>>>>>>> simple configuration changes and the use of schema extensions for the >>>>>>>> Cataloging and Person records: >>>>>>>> >>>>>>>> >>>>>>>> https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/tenants/lifesci/naturalhistory-collectionobject.xml >>>>>>>> >>>>>>>> >>>>>>>> https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/tenants/lifesci/lifesci-authority-person.xml >>>>>>>> >>>>>>>> Aron >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Oct 28, 2013 at 11:05 AM, Richard Millet < >>>>>>>> richard.millet@berkeley.edu> wrote: >>>>>>>> >>>>>>>>> Jesse, >>>>>>>>> >>>>>>>>> We're still working on updating the documentation to reflect the >>>>>>>>> new configuration features in the v4.0 release. We're first updating the >>>>>>>>> documentation for creating new v4.0 installations/deployments. Once that's >>>>>>>>> finished, our next documentation task will be to create notes on porting >>>>>>>>> pre-v4.0 deployments to v4.0. In the mean, let us know how we can best >>>>>>>>> help. >>>>>>>>> >>>>>>>>> Ray has successfully upgraded at least one of the UC Berkeley >>>>>>>>> instances to v4.0 -making him now the "world" expert on doing this. He may >>>>>>>>> be able to send you some of his "raw" notes on how he did the upgrade. >>>>>>>>> Between Aron, Ray, and myself, we should be able to answer most of your >>>>>>>>> questions. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Richard >>>>>>>>> >>>>>>>>> Jesse Martinez <mjesse@gmail.com> >>>>>>>>> Monday, October 28, 2013 10:11 AM >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I'm coming across some difficulties porting over development from >>>>>>>>> pre-v4.0 to v4.0. Specifically, how to manage the great number of changes >>>>>>>>> that occur in the tenant bindings files. Is there a guide that shows all >>>>>>>>> the new mappings between the app and the service's tenant bindings? I can't >>>>>>>>> get schema extensions to save in the gui and I'm not sure how to >>>>>>>>> troubleshoot this issue. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> - Jesse >>>>>>>>> _______________________________________________ >>>>>>>>> Talk mailing list >>>>>>>>> Talk@lists.collectionspace.org >>>>>>>>> >>>>>>>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Talk mailing list >>>>>>>>> Talk@lists.collectionspace.org >>>>>>>>> >>>>>>>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk mailing list >>>>>>>> Talk@lists.collectionspace.org >>>>>>>> >>>>>>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Talk mailing list >>>>>> Talk@lists.collectionspace.org >>>>>> >>>>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>>>> >>>>>> >>>>> >>>> >>> >> >

Thanks for the clarification, Ray. I see the attribute used in the lifesci tenant https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/tenants/lifesci/naturalhistory-collectionobject.xml On Tue, Oct 29, 2013 at 6:02 PM, Ray Lee <rhlee@berkeley.edu> wrote: > Hi Jesse, > The is-extension="true" is necessary. The generate-services-schema="true" > should already be on the base file, so it's not necessary. There's no harm > in having it in the overlay because the merged file will end up the same > (since the value is the same in the base file and the overlay), but since > it doesn't do anything and is potentially confusing, I don't think it > should be there. Which example did you see it in? > > Thanks, > Ray > > > On Tue, Oct 29, 2013 at 2:44 PM, Jesse Martinez <mjesse@gmail.com> wrote: > >> A follow up: >> >> is it necessary to use the is-extension="true" or >> generate-services-schema="true" attributes in the schema extension xml >> files? I've seen either used in prior examples. >> >> Thanks, >> - Jesse >> >> >> On Tue, Oct 29, 2013 at 5:31 PM, Jesse Martinez <mjesse@gmail.com> wrote: >> >>> This is great news, Aron and Ray. And the time now taken to build out a >>> schema extension has significantly decreased since tenant bindings are >>> autogenerated for the most part! :-) >>> >>> >>> >>> >>> On Tue, Oct 29, 2013 at 5:01 PM, Ray Lee <rhlee@berkeley.edu> wrote: >>> >>>> Hi Jesse, >>>> That's right, no need to create submodules in the services layer. To me >>>> that's at least as big a win as not having to edit tenant bindings. There >>>> was a lot of finicky configuration in those things. >>>> >>>> These are the times when you still have to touch services layer config >>>> after editing app layer config, that I've found: >>>> >>>> When creating a tenant, you still need to create a folder named with >>>> the tenant name, in >>>> services/common/src/main/cspace/config/services/tenants/. That folder needs >>>> to contain a file called <tenant name>-tenant-bindings.delta.xml. Core and >>>> lifesci have examples of that. >>>> >>>> If you're extending contacts, you still need to add tenant bindings by >>>> hand, because there's a bug that they're not being generated ( >>>> CSPACE-6185 <http://issues.collectionspace.org/browse/CSPACE-6185>). >>>> You now make those tenant binding changes in <tenant >>>> name>-tenant-bindings.delta.xml. The pahma_4.0 branch has an example of >>>> that. >>>> >>>> If you're using a separate repo for your tenant (i.e., not the nuxeo >>>> database), this is now configured in your settings.xml file in the app >>>> layer. But in the services layer, you need to add a repo config file in >>>> 3rdparty/nuxeo/nuxeo-server/5.5-HF07/config. The lifesci tenant has an >>>> example of that. >>>> >>>> Ray >>>> >>>> >>>> On Tue, Oct 29, 2013 at 1:37 PM, Aron Roberts <aronroberts@gmail.com>wrote: >>>> >>>>> > Is it now not necessary to create a submodule for a schema extension >>>>> within the service layer? I see that the xsd and supporting OSGI files are >>>>> now deprecated. >>>>> >>>>> Yes, that's my understanding. All of that is no longer necessary. >>>>> >>>>> In version 4.0, to make schema additions - adding one or more schemas >>>>> containing fields relevant to your museum or community of practice, >>>>> supplementing the standard set of fields in the 'common' (SPECTRUM-based) >>>>> schemas - much of the painstaking work that you formerly needed to do >>>>> within CollectionSpace's Services layer is simply GONE. Bye bye, no need >>>>> to do that ever again. >>>>> >>>>> Off the top of my head, if you're extending one of the standard record >>>>> types - objects (Cataloging/CollectionObjects), procedures, or authority >>>>> terms - you need only do this to add your extensions to both the App and >>>>> Services layers: >>>>> >>>>> * Make a few fairly simple changes in App layer config files to >>>>> declare the schema extension and its fields. (In its simplest form, adding >>>>> a single text field to a single record type, this can take just 4-5 lines >>>>> of markup: >>>>> https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/tenants/lifesci/lifesci-authority-person.xml#L18 >>>>> ) >>>>> * Build the App layer ('mvn clean install' from the top of the App >>>>> layer source code tree). This takes roughly 1 minute on a typical system. >>>>> * Run a Services Ant script to build the corresponding Services >>>>> artifacts, which include schemas (XSD files), Nuxeo document type >>>>> declarations, and service bindings (via 'run deploy_services_artifacts' >>>>> from within services/JaxRsServiceProvider). This takes roughly 20 seconds. >>>>> * Restart the CollectionSpace servers. >>>>> >>>>> And you're then nearly done. The remaining work is solely in the UI >>>>> layer, and for simple extensions, consists of: >>>>> >>>>> * Editing HTML templates in the UI layer to add your new fields where >>>>> you want them to go, on record editor pages, advanced search pages, and the >>>>> like. >>>>> * Editing the message bundle overlay file for your tenant, to add text >>>>> labels for those fields. >>>>> >>>>> Aron >>>>> >>>>> >>>>> On Tue, Oct 29, 2013 at 1:16 PM, Jesse Martinez <mjesse@gmail.com>wrote: >>>>> >>>>>> Thanks to all for these sources of info. Not having to update the >>>>>> tenant bindings file sure makes things more streamlined. >>>>>> >>>>>> I do have a few preliminary questions to ask, though. >>>>>> Is it now not necessary to create a submodule for a schema extension >>>>>> within the service layer? I see that the xsd and supporting OSGI files are >>>>>> now deprecated. >>>>>> At what times is it now necessary to update the service layer code >>>>>> base when editing/updating the app layer config files? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> - Jesse >>>>>> >>>>>> >>>>>> On Mon, Oct 28, 2013 at 4:48 PM, Aron Roberts <aronroberts@gmail.com>wrote: >>>>>> >>>>>>> One more note: per-service, per-tenant bindings are now largely >>>>>>> generated from App layer configuration in version 4.0. This occurs when >>>>>>> you run 'ant deploy' (at the top of the services source code tree) or - >>>>>>> considerably quicker - 'deploy_services_artifacts' from within >>>>>>> services/JaxRsServiceProvider. >>>>>>> >>>>>>> Because these are now generated, service bindings have been removed >>>>>>> for many record types - objects, procedures, and authorities - from the >>>>>>> 'prototype' bindings file >>>>>>> (services/common/src/main/cspace/config/services/tenants/tenant-bindings-proto-unified.xml) >>>>>>> in the services source code tree in version 4.0. Remaining in that file >>>>>>> are a number of AuthN/AuthZ and utility record types. >>>>>>> >>>>>>> >>>>>>> On Mon, Oct 28, 2013 at 1:26 PM, Ray Lee <rhlee@berkeley.edu> wrote: >>>>>>> >>>>>>>> Hi Jesse, >>>>>>>> The 4.0 pahma app layer is here: >>>>>>>> https://github.com/cspace-deployment/application/commits/pahma_4.0 >>>>>>>> >>>>>>>> If you diff it against the pahma_3.3 branch, you'll see all the >>>>>>>> changes I made to do the upgrade. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Ray >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Oct 28, 2013 at 12:26 PM, Aron Roberts < >>>>>>>> aronroberts@gmail.com> wrote: >>>>>>>> >>>>>>>>> Ray's notes on upgrading from a version 3.3 system to a version >>>>>>>>> 4.0 system can be found in his detailed comments on this issue: >>>>>>>>> >>>>>>>>> http://issues.collectionspace.org/browse/PAHMA-933 >>>>>>>>> >>>>>>>>> In addition, the Lifesci tenant in version 4.0 demonstrates some >>>>>>>>> simple configuration changes and the use of schema extensions for the >>>>>>>>> Cataloging and Person records: >>>>>>>>> >>>>>>>>> >>>>>>>>> https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/tenants/lifesci/naturalhistory-collectionobject.xml >>>>>>>>> >>>>>>>>> >>>>>>>>> https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/tenants/lifesci/lifesci-authority-person.xml >>>>>>>>> >>>>>>>>> Aron >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Oct 28, 2013 at 11:05 AM, Richard Millet < >>>>>>>>> richard.millet@berkeley.edu> wrote: >>>>>>>>> >>>>>>>>>> Jesse, >>>>>>>>>> >>>>>>>>>> We're still working on updating the documentation to reflect the >>>>>>>>>> new configuration features in the v4.0 release. We're first updating the >>>>>>>>>> documentation for creating new v4.0 installations/deployments. Once that's >>>>>>>>>> finished, our next documentation task will be to create notes on porting >>>>>>>>>> pre-v4.0 deployments to v4.0. In the mean, let us know how we can best >>>>>>>>>> help. >>>>>>>>>> >>>>>>>>>> Ray has successfully upgraded at least one of the UC Berkeley >>>>>>>>>> instances to v4.0 -making him now the "world" expert on doing this. He may >>>>>>>>>> be able to send you some of his "raw" notes on how he did the upgrade. >>>>>>>>>> Between Aron, Ray, and myself, we should be able to answer most of your >>>>>>>>>> questions. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Richard >>>>>>>>>> >>>>>>>>>> Jesse Martinez <mjesse@gmail.com> >>>>>>>>>> Monday, October 28, 2013 10:11 AM >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I'm coming across some difficulties porting over development from >>>>>>>>>> pre-v4.0 to v4.0. Specifically, how to manage the great number of changes >>>>>>>>>> that occur in the tenant bindings files. Is there a guide that shows all >>>>>>>>>> the new mappings between the app and the service's tenant bindings? I can't >>>>>>>>>> get schema extensions to save in the gui and I'm not sure how to >>>>>>>>>> troubleshoot this issue. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> - Jesse >>>>>>>>>> _______________________________________________ >>>>>>>>>> Talk mailing list >>>>>>>>>> Talk@lists.collectionspace.org >>>>>>>>>> >>>>>>>>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Talk mailing list >>>>>>>>>> Talk@lists.collectionspace.org >>>>>>>>>> >>>>>>>>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Talk mailing list >>>>>>>>> Talk@lists.collectionspace.org >>>>>>>>> >>>>>>>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk mailing list >>>>>>> Talk@lists.collectionspace.org >>>>>>> >>>>>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >