Justin and Andrea,
for complex feature types, wfs GML3OutputFormat uses an XSLT to avoid a potentially expensive call to FeatureCollection.size(). As gt-app-schema is the only current source of complex features, this might be misconstrued as "app-schema support", but it is not, because in general any DataAccess that is not a DataStore will produce complex features.
To put GeoServer on a diet, Andrea removed the xalan dependency from GeoServer proper and added a test dependency on xalan to keep app-schema-test running. This is fine, up to the point that we want to make a deployable app-schema plugin. Because nothing depends on xalan outside the test scope, the xalan jar is not in release/target/dependency and cannot be included in the app-schema plugin by ext-app-schema.xml.
*The geoserver-2.2-SNAPSHOT-app-schema-plugin.zip built today will not work for WFS because no xalan jar is included anywhere.*
To cut a long story short, what is the right way to get the xalan jar into the app-schema plugin zip? I can see a couple of options:
(1) Add xalan as a compile dependency of GeoTools gt-app-schema. This is nasty: the dependency is being added because of the behaviour of a consumer of gt-app-schema that GeoTools should not know about. In my view, this would put the dependency in the wrong place.
(2) Add xalan as a compile dependency of GeoServer wfs. This makes sense to me, because wfs is the thing doing the transforming. We could leave xalan out of release/bin.xml and put it in release/ext-app-schema.xml so it is shipped with the app-schema plugin. This oddity should be documented in wfs/pom.xml and release/bin.xml. But then, what about the war? Will xalan be included in geoserver.war if we do this?
(3) Add xalan as a dependency of the release module.
What do you recommend?
Kind regards,
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
(4) Add xalan as a dependency of the extensions/app-schema pom artifact. This probably makes most sense if the wfs maintainer wishes to continue to pretend that his module does not depend on xalan. 
On 07/06/11 12:01, Ben Caradoc-Davies wrote:
To cut a long story short, what is the right way to get the xalan jar
into the app-schema plugin zip? I can see a couple of options:
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
On Tue, Jun 7, 2011 at 6:01 AM, Ben Caradoc-Davies
<Ben.Caradoc-Davies@anonymised.com> wrote:
(1) Add xalan as a compile dependency of GeoTools gt-app-schema. This is
nasty: the dependency is being added because of the behaviour of a
consumer of gt-app-schema that GeoTools should not know about. In my
view, this would put the dependency in the wrong place.
(2) Add xalan as a compile dependency of GeoServer wfs. This makes sense
to me, because wfs is the thing doing the transforming. We could leave
xalan out of release/bin.xml and put it in release/ext-app-schema.xml so
it is shipped with the app-schema plugin. This oddity should be
documented in wfs/pom.xml and release/bin.xml. But then, what about the
war? Will xalan be included in geoserver.war if we do this?
(3) Add xalan as a dependency of the release module.
What do you recommend?
I'd got for (1), the reasoning is not about dependencies imho, it's about
working vs not working.
Pure wfs work fine without the Xalan baggage, so it makes no sense to
add the extra load only because there is one unused code path that
depends on it.
Put the extra load where the extra load is due, in the app-schema module
that is the reason of that dependency.
See also my other mail about using built-in JDK xpath/xslt features, maybe
you can rework your xpath expression to just work against the jdk 5
xpath/xslt abilities
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-------------------------------------------------------
On Tue, Jun 7, 2011 at 12:13 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:
On Tue, Jun 7, 2011 at 6:01 AM, Ben Caradoc-Davies
<Ben.Caradoc-Davies@anonymised.com> wrote:
(1) Add xalan as a compile dependency of GeoTools gt-app-schema. This is
nasty: the dependency is being added because of the behaviour of a
consumer of gt-app-schema that GeoTools should not know about. In my
view, this would put the dependency in the wrong place.
(2) Add xalan as a compile dependency of GeoServer wfs. This makes sense
to me, because wfs is the thing doing the transforming. We could leave
xalan out of release/bin.xml and put it in release/ext-app-schema.xml so
it is shipped with the app-schema plugin. This oddity should be
documented in wfs/pom.xml and release/bin.xml. But then, what about the
war? Will xalan be included in geoserver.war if we do this?
(3) Add xalan as a dependency of the release module.
What do you recommend?
I'd got for (1), the reasoning is not about dependencies imho, it's about
working vs not working.
Pure wfs work fine without the Xalan baggage, so it makes no sense to
add the extra load only because there is one unused code path that
depends on it.
Put the extra load where the extra load is due, in the app-schema module
that is the reason of that dependency.
Btw, I guess adding xalan to the release module and make it so that
only app-schema package it would be an equally good solution.
Anything that keeps the base GeoServer xalan free works for me.
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-------------------------------------------------------
Yeah, (1) or (3) would be my preference as well. Updating the release artifact descriptor for app-schema to include xalan should be a one liner and then just a dependency from release/pom.xml.
On Tue, Jun 7, 2011 at 6:14 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
On Tue, Jun 7, 2011 at 12:13 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:
On Tue, Jun 7, 2011 at 6:01 AM, Ben Caradoc-Davies
Ben.Caradoc-Davies@anonymised.com wrote:
(1) Add xalan as a compile dependency of GeoTools gt-app-schema. This is
nasty: the dependency is being added because of the behaviour of a
consumer of gt-app-schema that GeoTools should not know about. In my
view, this would put the dependency in the wrong place.
(2) Add xalan as a compile dependency of GeoServer wfs. This makes sense
to me, because wfs is the thing doing the transforming. We could leave
xalan out of release/bin.xml and put it in release/ext-app-schema.xml so
it is shipped with the app-schema plugin. This oddity should be
documented in wfs/pom.xml and release/bin.xml. But then, what about the
war? Will xalan be included in geoserver.war if we do this?
(3) Add xalan as a dependency of the release module.
What do you recommend?
I’d got for (1), the reasoning is not about dependencies imho, it’s about
working vs not working.
Pure wfs work fine without the Xalan baggage, so it makes no sense to
add the extra load only because there is one unused code path that
depends on it.
Put the extra load where the extra load is due, in the app-schema module
that is the reason of that dependency.
Btw, I guess adding xalan to the release module and make it so that
only app-schema package it would be an equally good solution.
Anything that keeps the base GeoServer xalan free works for me.
Cheers
Andrea
–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
OK, I added xalan to the release module and ext-app-schema.xml and updated the app-schema plugin README to match. I have confirmed that xalan is *not* included in the core -war.zip or -bin.zip . I'll check again when our buildbot has run.
Kind regards,
Ben.
On 07/06/11 20:32, Justin Deoliveira wrote:
Yeah, (1) or (3) would be my preference as well. Updating the release artifact descriptor for app-schema to include xalan should be a one liner and then just a dependency from release/pom.xml.
On Tue, Jun 7, 2011 at 12:13 PM, Andrea Aime
<andrea.aime@anonymised.com<mailto:andrea.aime@anonymised.com>> wrote:
Btw, I guess adding xalan to the release module and make it so that
only app-schema package it would be an equally good solution.
Anything that keeps the base GeoServer xalan free works for me.
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre