Dag, Eli,I've checked the IPT code again for the extension registry URL and I was actually wrong.
The current version *does* make use of the ipt.properties settings.
The standard GBIF URL that is used in the ipt.properties should be:
The registry then returns a JSON list of all known extensions located at:
So to test your own extensions you can modify this json list to include entries for your own (pointing to your extension xml definitions hosted on some URL), upload that json file to some http server and modify the ipt.properties setting to point to your registry, e.g.:
that will finally point to the file
To get everything working this registry base URL should also deal with other things, e.g. the registry of resources, organisations, services, etc.
But in order to test the extensions this should still work.
If you give it a try, please report your findings back to this list.
cheers,
Markus
On May 12, 2009, at 6:05 PM, Markus Döring (GBIF) wrote:
PS. I agree with Jörg that a convenient way to keep the old data directory when upgrading the IPT would be cute.
This is indeed the case. We will aim wherever possible to make upgrading as simple as it can be.
For bug fix releases, such as this snapshot, with no structural change the data directory can be migrated directly. In future releases, we might require a "one time" migration task be run. I anticipate the first one being required when the DwC standard is ratified.
if you look into your ipt.properties file you can modify the following settings:
dataDir=${ipt.datadir}
registryUrl=${ipt.registry.url}
the dataDir should be an absolute path pointing to your data dir (defaults to the ipt webapp data subfolder).
the registry URL can point to a development registry - unfortunately the extensions and vocabs currently dont use this setting, only the UDDI style registration of resources and organisations. We will make sure that the IPT uses this setting also for the extension registration, so you can easily point it to an alternative extension site for testing.
markus