…hich results in a wide, ugly message)
… about broker independence
…ompile classpath (!?)
…able (if you run nimbus-configure after moving it). Changed path configuration to be file-backed Spring Resource configurations instead of straight paths. This change allows all of the configurations to use our new "NimbusFileSystemXmlApplicationContext" instead of the Spring default "FileSystemXmlApplicationContext." The new context allows $NIMBUS_HOME to be respected in path configurations. The old strategy was to write absolute paths into configurations during the installation. The jndi-config.xml contains settings to bootstrap Spring, these are paths that are insptected before any ApplicationContext exists so our path translation (that respects $NIMBUS_HOME) can not take its effect yet. Those settings are now relative paths. See: `git diff home/sbin/run-services.sh` The following commands are being used to test this. $ ./bin/install /tmp/nimbus-relpath $ /tmp/nimbus-relpath/bin/nimbusctl start $ /tmp/nimbus-relpath/bin/nimbusctl stop $ mv /tmp/nimbus-relpath /tmp/nimbus-newpath $ cd /tmp/nimbus-newpath $ ./bin/nimbus-configure $ export GLOBUS_LOCATION=`pwd`/services $ ant -f $GLOBUS_LOCATION/share/nimbus/lib/write-props.xml $ /tmp/nimbus-newpath/bin/nimbusctl start As you can see, the changeover required writing a new ant file 'write-props.xml' that, after moving Nimbus around, will change path configurations that allow the database scripts to run (those scripts like "servicedb-reset.sh" in $NIMBUS_HOME/services/share/nimbus). Need to discuss best place to make that ant call behind the scenes... we should only have to call nimbus-configure. Query is currently broken. Need to discuss how to make it respect this new file-based resource (or maybe just need to look more soon). Because of CXF (I imagine), it seems to think the configuration is a servlet context resource instead of a file based one (and so it is looking in the jar's WEB-INF directory).
…erate them by running scripts/stubs-build.sh
…ways installs now