Hey all,
I just added a standalone repackaging of my restlet module (that is, you can
build without it by just not disabling the community module) to 1.6.x. This
required updating the jsonlib dependency from 1.1 to 2.0.
The basics of setting up a restlet plugin are now as follows:
copy this snippet into your module's applicationContext.xml (replace
restConfig with your module's name):
<bean id="restConfigMapping" class="org.geoserver.rest.RESTMapping">
<property name="routes">
</property>
</bean>
and then for each route you want, just add a map entry with the key being the
route and the value being a restlet. routes will be automagically prefixed
with /rest/.
so
<bean id="myModuleMapping" class="org.geoserver.rest.RESTMapping">
<property name="routes">
<entry> <key> <value>/items/{item}</value> </key>
<bean class="org.geoserver.mymodule.TheBestRestletEver"/>
</entry>
</bean>
should route requests to http://localhost:8080/geoserver/rest/items/foo to a
TheBestRestletEver instance.
There are also a few classes to help with handling different output formats in
the rest module, feel free to bug me about them. See RESTConfig for lots of
examples.
-David
David Winslow wrote:
I just added a standalone repackaging of my restlet module (that is, you can build without it by just not disabling the community module) to 1.6.x. This required updating the jsonlib dependency from 1.1 to 2.0.
David, your change to community/pom.xml also booted all the other occupants out of the build, including community/community-schemas. Do you mind if I re-enable these?
Kind regards,
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
On Friday 28 March 2008 00:27:03 Ben Caradoc-Davies wrote:
David Winslow wrote:
> I just added a standalone repackaging of my restlet module (that is, you
> can build without it by just not disabling the community module) to
> 1.6.x. This required updating the jsonlib dependency from 1.1 to 2.0.
David, your change to community/pom.xml also booted all the other
occupants out of the build, including community/community-schemas. Do
you mind if I re-enable these?
Kind regards,
Oops, my geotools build doesn't include the community schemas stuff so I just
disabled all the modules I wasn't playing with. I didn't mean to commit
this, feel free to fix it.
-David
David Winslow wrote:
Oops, my geotools build doesn't include the community schemas stuff so I just disabled all the modules I wasn't playing with. I didn't mean to commit this, feel free to fix it.
OK, I will commit the updated community/pom.xml as soon as I have confirmed that it works.
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
Ben Caradoc-Davies ha scritto:
David Winslow wrote:
I just added a standalone repackaging of my restlet module (that is, you can build without it by just not disabling the community module) to 1.6.x. This required updating the jsonlib dependency from 1.1 to 2.0.
David, your change to community/pom.xml also booted all the other occupants out of the build, including community/community-schemas. Do you mind if I re-enable these?
Sorry for chiming in this late. Given that the gt2 modules
that the community schema are not included in the build in gt2,
we should put the gs ones in a profile so that they are not
built by default (otherwise nobody but you can do a mvn build on
the community subfolder).
Either that, of make the gt2 modules enter the build... which I would
not be very happy about, I've just tried building those and they
took 1.5 minutes (on a 1 year old computer), that's a way too long
time to add to an already slow build.
Cheers
Andrea
Andrea Aime wrote:
Sorry for chiming in this late. Given that the gt2 modules
that the community schema are not included in the build in gt2,
we should put the gs ones in a profile so that they are not
built by default (otherwise nobody but you can do a mvn build on
the community subfolder).
Yes, that would be an improvement. My only change was to put back the modules inadvertently disabled when the rest modules were committed, but the addition of the rest code shows that community schemas is hogging the community directory in a nonextensible fashion.
I will add a profile for community-schemas. Should there also be one for rest?
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
Ben Caradoc-Davies ha scritto:
Andrea Aime wrote:
Sorry for chiming in this late. Given that the gt2 modules
that the community schema are not included in the build in gt2,
we should put the gs ones in a profile so that they are not
built by default (otherwise nobody but you can do a mvn build on
the community subfolder).
Yes, that would be an improvement. My only change was to put back the modules inadvertently disabled when the rest modules were committed, but the addition of the rest code shows that community schemas is hogging the community directory in a nonextensible fashion.
"Hogging the community directory in a nonextensible fashion"?
It requires to be build with jdk5, and that's a problem I've just fixed
by putting that and other jdk5 requiring modules in a profile that activates only if jdk 5 is used, but I don't understand the "nonextensible" bit?
Cheers
Andrea
Andrea Aime wrote:
"Hogging the community directory in a nonextensible fashion"?
It requires to be build with jdk5, and that's a problem I've just fixed
by putting that and other jdk5 requiring modules in a profile that activates only if jdk 5 is used, but I don't understand the "nonextensible" bit?
I wrote the *community-schemas* was hogging the community directory (not the rest stuff). As you implied, optional modules, particularly those with optional dependencies, should be in profiles (or disabled) so they do not get in the way. Sorry to be obtuse. 
community-schemas profile under test right now ...
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
Ben Caradoc-Davies ha scritto:
Andrea Aime wrote:
"Hogging the community directory in a nonextensible fashion"?
It requires to be build with jdk5, and that's a problem I've just fixed
by putting that and other jdk5 requiring modules in a profile that activates only if jdk 5 is used, but I don't understand the "nonextensible" bit?
I wrote the *community-schemas* was hogging the community directory (not the rest stuff).
Another coffee is in order for me... and I should probably avoid
answering mails during early morning 
As you implied, optional modules, particularly those with optional dependencies, should be in profiles (or disabled) so they do not get in the way. Sorry to be obtuse.
Np, I'm on the who's still sleeping...
community-schemas profile under test right now ...
Nice
Cheers
Andrea
Andrea Aime wrote:
It requires to be build with jdk5, and that's a problem I've just fixed
by putting that and other jdk5 requiring modules in a profile that activates only if jdk 5 is used
Andrea, I removed two modules from the community jdk1.5 activation profile because at least one of them (csv) failed to build (missing optional GeoTools dependency?). The jdk1.5 profile activates all modules in that profile, even if they have not been requested in another profile.
Does Maven support a profile within a profile? If this is possible, we can annotate a module as jdk1.5 and also leave it as optional.
I will commit my changes now.
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
Ben Caradoc-Davies ha scritto:
Andrea Aime wrote:
It requires to be build with jdk5, and that's a problem I've just fixed
by putting that and other jdk5 requiring modules in a profile that activates only if jdk 5 is used
Andrea, I removed two modules from the community jdk1.5 activation profile because at least one of them (csv) failed to build (missing optional GeoTools dependency?). The jdk1.5 profile activates all modules in that profile, even if they have not been requested in another profile.
Sigh... csv is the module I'm working on now, so please don't remove
from the build, but report issues instead.
Also, why did you remove two modules if just one failed?
Does Maven support a profile within a profile? If this is possible, we can annotate a module as jdk1.5 and also leave it as optional.
Unfortunately not
Cheers
Andrea
Andrea Aime wrote:
Sigh... csv is the module I'm working on now, so please don't remove
from the build, but report issues instead.
Too late! Sorry. Did you mean to make it a standard module for those building in community? If so, then please put it back and I will report the build failure.
My intent was to revert to the behaviour before the inadvertent changes made by another developer when the rest changes were committed.
Also, why did you remove two modules if just one failed?
I was reverting to the original set of built modules (minus community-schemas).
Does Maven support a profile within a profile? If this is possible, we can annotate a module as jdk1.5 and also leave it as optional.
Unfortunately not
Can you suggest a workaround?
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
Ben Caradoc-Davies ha scritto:
Andrea Aime wrote:
Sigh... csv is the module I'm working on now, so please don't remove
from the build, but report issues instead.
Too late! Sorry. Did you mean to make it a standard module for those building in community? If so, then please put it back and I will report the build failure.
I put it back, and hopefully fixed the failures. Can you double check?
As for "standard module for those building in community", there is
not really such a concept... it's more that everything that builds
and it's maintained should be in the build, everything else, out.
Does Maven support a profile within a profile? If this is possible, we can annotate a module as jdk1.5 and also leave it as optional.
Unfortunately not
Can you suggest a workaround?
Not off the top of my head...
Cheers
Andrea
Andrea Aime wrote:
[community/pom.xml]
I put it back, and hopefully fixed the failures. Can you double check?
Yes, it works fine ("mvn install" in community).
Regards,
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia