[Geoserver-devel] GeoServer release doc notes

GeoServer GeoServer Developer
1

Almost forgot to send this out.

As I went through the release documentation, there were a few things that didn't line up that I took note of. There were some other things, in particular with cite tests, that didn't get written down; Justin was very patient with walking me through my issues.

-Build documentation
-- HTML

The sphinx-build command listed gives an error when run in doc/user and
doc/developer as the source directory should be 'source' in order ot
find the conf.py file needed.

Additionally the zipping of the html docs leads to the developer docs
overwriting files in the user docs. This is because the assumed
directories 'user' and 'developer' are not created as part of the doc
generation and must be done manually. The note at the end of the
section describing the expected results saved me on this one.

-CITE Test Guide
-- Checkout
The url http://svn.codehaus.org/geoserver/trunk/community/cite should be
http://svn.codehaus.org/geoserver/trunk/src/community/cite.

--WCS 1.1.1 and 1.0.0
There was an issue in the pom, where the copy command to move wcs data
was commented out. Putting this back in was required to get things
working. Other copies were also removed (wfs-1.0.0, wms-1.0.0,1.1.1)
but didn't cause me problems.

--
Mark Leslie
Geospatial Software Architect
LISAsoft

-------------------------------------------------------------
Ph: +61 2 8570 5000 Fax: +61 2 8570 5099 Mob: +61
Suite 112, Jones Bay Wharf 19-21 Pirrama Rd Pyrmont NSW 2009
-------------------------------------------------------------

LISAsoft is part of the A2end Group of Companies
http://www.ardec.com.au
http://www.lisasoft.com
http://www.terrapages.com

2

Mark Leslie ha scritto:

--WCS 1.1.1 and 1.0.0
There was an issue in the pom, where the copy command to move wcs data
was commented out. Putting this back in was required to get things
working. Other copies were also removed (wfs-1.0.0, wms-1.0.0,1.1.1)
but didn't cause me problems.

I think this is done to generate a cite engine .war that contains
only a specific test suite. It is my experience that otherwise
Tomcat will OOM trying to xslt all the test suites as once.
How did you run the cite tests?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

3

Andrea Aime wrote:

Mark Leslie ha scritto:

--WCS 1.1.1 and 1.0.0
There was an issue in the pom, where the copy command to move wcs data
was commented out. Putting this back in was required to get things
working. Other copies were also removed (wfs-1.0.0, wms-1.0.0,1.1.1)
but didn't cause me problems.

I think this is done to generate a cite engine .war that contains
only a specific test suite. It is my experience that otherwise
Tomcat will OOM trying to xslt all the test suites as once.
How did you run the cite tests?

Cheers
Andrea

I was running the stand-alone app (./run.sh wcs-1.0.0). I haven't used the web app, since I was told it OOM'd.

--
Mark

4

Mark Leslie ha scritto:

Andrea Aime wrote:

Mark Leslie ha scritto:

--WCS 1.1.1 and 1.0.0
There was an issue in the pom, where the copy command to move wcs data
was commented out. Putting this back in was required to get things
working. Other copies were also removed (wfs-1.0.0, wms-1.0.0,1.1.1)
but didn't cause me problems.

I think this is done to generate a cite engine .war that contains
only a specific test suite. It is my experience that otherwise
Tomcat will OOM trying to xslt all the test suites as once.
How did you run the cite tests?

Cheers
Andrea

I was running the stand-alone app (./run.sh wcs-1.0.0). I haven't used the web app, since I was told it OOM'd.

It does not if you prepare one web app pre test using the "comment out"
trick you found in the pom.xml.
But then you have to setup one separate tomcat per teamengine web app,
since the thing works only if you call it exactly "teamengine.war",
if you turn it into "donaldduck.war" it will stop working.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

5

On a somewhat related note, after watching the pain that Mark went through running the cite tests I took another shot at trying to make them easier to run, and I am happy to report success.

First off, it seems that the version of teamengine we are using is out dated, and the latest and greatest version actually lives on a branch.

The most exciting thing to report is the startup time is greatly improved. I am not sure if this is due to the engine itself, or how the test are newly structured. I think that the tests are now precompiled once at build time instead of every time on engine startup. Bottom line, much faster to run the tests.

With a shiny new engine I decided to take another crack at running it with jetty. And met success here as well (although i had to minorly patch the web.xml file).

So now instead of going through the pain of either a) using the command line and copying/pasting test ids around to get logs or b) building the custom war per test suite and deploying it in tomcat we can c) simply fire up jetty from the engine directory (with all the suites) and it works like a charm.

Sorry I did not do this sooner Mark, but the new version of the engine was unknown to me until recently.

I am just updating the developer docs for running cite to reflect the changes, will commit soon.

-Justin

Andrea Aime wrote:

Mark Leslie ha scritto:

Andrea Aime wrote:

Mark Leslie ha scritto:

--WCS 1.1.1 and 1.0.0
There was an issue in the pom, where the copy command to move wcs data
was commented out. Putting this back in was required to get things
working. Other copies were also removed (wfs-1.0.0, wms-1.0.0,1.1.1)
but didn't cause me problems.

I think this is done to generate a cite engine .war that contains
only a specific test suite. It is my experience that otherwise
Tomcat will OOM trying to xslt all the test suites as once.
How did you run the cite tests?

Cheers
Andrea

I was running the stand-alone app (./run.sh wcs-1.0.0). I haven't used the web app, since I was told it OOM'd.

It does not if you prepare one web app pre test using the "comment out"
trick you found in the pom.xml.
But then you have to setup one separate tomcat per teamengine web app,
since the thing works only if you call it exactly "teamengine.war",
if you turn it into "donaldduck.war" it will stop working.

Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

6

Justin Deoliveira ha scritto:

On a somewhat related note, after watching the pain that Mark went through running the cite tests I took another shot at trying to make them easier to run, and I am happy to report success.

First off, it seems that the version of teamengine we are using is out dated, and the latest and greatest version actually lives on a branch.

The most exciting thing to report is the startup time is greatly improved. I am not sure if this is due to the engine itself, or how the test are newly structured. I think that the tests are now precompiled once at build time instead of every time on engine startup. Bottom line, much faster to run the tests.

With a shiny new engine I decided to take another crack at running it with jetty. And met success here as well (although i had to minorly patch the web.xml file).

So now instead of going through the pain of either a) using the command line and copying/pasting test ids around to get logs or b) building the custom war per test suite and deploying it in tomcat we can c) simply fire up jetty from the engine directory (with all the suites) and it works like a charm.

Wow, awesome!
Can't wait to check it out

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

7

As promised updated docs:

http://docs.geoserver.org/trunk/developer/cite-test-guide/index.html

-Justin

Andrea Aime wrote:

Justin Deoliveira ha scritto:

On a somewhat related note, after watching the pain that Mark went through running the cite tests I took another shot at trying to make them easier to run, and I am happy to report success.

First off, it seems that the version of teamengine we are using is out dated, and the latest and greatest version actually lives on a branch.

The most exciting thing to report is the startup time is greatly improved. I am not sure if this is due to the engine itself, or how the test are newly structured. I think that the tests are now precompiled once at build time instead of every time on engine startup. Bottom line, much faster to run the tests.

With a shiny new engine I decided to take another crack at running it with jetty. And met success here as well (although i had to minorly patch the web.xml file).

So now instead of going through the pain of either a) using the command line and copying/pasting test ids around to get logs or b) building the custom war per test suite and deploying it in tomcat we can c) simply fire up jetty from the engine directory (with all the suites) and it works like a charm.

Wow, awesome!
Can't wait to check it out

Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

8

Justin Deoliveira ha scritto:

As promised updated docs:

http://docs.geoserver.org/trunk/developer/cite-test-guide/index.html

Tried this out, got an error while building the app:

aaime@anonymised.com:~/devel/gstrunk/src/community/cite$ mvn install
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building Compliance + Interopability Testing + Evaluation (CITE) Module
[INFO] task-segment: [install]
[INFO] ------------------------------------------------------------------------
[INFO] [antrun:run {execution: pre}]
[INFO] Executing tasks
[INFO] Executed tasks
[INFO] [dependency:copy {execution: pre}]
[INFO] Configured Artifact: tomcat:catalina:5.5.9:jar
[INFO] Configured Artifact: javax.servlet:servlet-api:2.4:jar
[INFO] Copying catalina-5.5.9.jar to /home/aaime/devel/gstrunk/src/community/cite/target/server/lib/catalina.jar
[INFO] Copying servlet-api-2.4.jar to /home/aaime/devel/gstrunk/src/community/cite/target/common/lib/servlet-api.jar
[INFO] [resources:resources]
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory /home/aaime/devel/gstrunk/src/community/cite/src/main/resources
[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [antrun:run {execution: compile}]
[INFO] Executing tasks

all:

init.version.stamp:

zip.engine.src:
    [delete] Deleting directory /home/aaime/devel/gstrunk/src/community/cite/engine/build
     [mkdir] Created dir: /home/aaime/devel/gstrunk/src/community/cite/engine/build
     [mkdir] Created dir: /home/aaime/devel/gstrunk/src/community/cite/engine/build/teamengine-2009.07.23
      [copy] Copying 55 files to /home/aaime/devel/gstrunk/src/community/cite/engine/build/teamengine-2009.07.23
       [zip] Building zip: /home/aaime/devel/gstrunk/src/community/cite/engine/zips/teamengine-2009.07.23-src.zip

jar.engine:

compile:
     [javac] Compiling 49 source files to /home/aaime/devel/gstrunk/src/community/cite/engine/apps/engine/build/classes
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] An Ant BuildException has occured: The following error occurred while executing this line:
/home/aaime/devel/gstrunk/src/community/cite/engine/build.xml:471: The following error occurred while executing this line:
/home/aaime/devel/gstrunk/src/community/cite/engine/build.xml:82: The following error occurred while executing this line:
/home/aaime/devel/gstrunk/src/community/cite/engine/apps/engine/build.xml:17: Unable to find a javac compiler;
com.sun.tools.javac.Main is not on the classpath.
Perhaps JAVA_HOME does not point to the JDK

Now, I double checked and JAVA_HOME points to a JDK.
I then looked into the pom and noticed a commented out bit about tools.jar, uncommented it, and the build passes.
I have vague recollections of this being a platform/jdk dependent
issue?

Besides that, I tried to run the WFS 1.1 test suite... amazing,
starts fast, works fast. Finally a CITE engine worth using!

Oh, running the tests on trunk I noticed that besides the usual
error about like on dates on postgres 8.3 I got another failure.
The test simply runs a query and checks the gml:id are valid:

http://localhost:8080/geoserver/wfs?&service=WFS&version=1.1.0&request=GetFeature&featureid=EntitéGénérique.f004,EntitéGénérique.f007&namespace=xmlns(sf=http://cite.opengeospatial.org/gmlsf)

but the response contains the usual results and
some oddball ones:

<sf:EntitéGénérique xlink:href="#EntitéGénérique.f004">
...
<sf:EntitéGénérique xlink:href="#EntitéGénérique.f007">

See the full response:

<wfs:FeatureCollection xmlns:gml="http://www.opengis.net/gml&quot; xmlns:ogc="http://www.opengis.net/ogc&quot;
                        xmlns:ows="http://www.opengis.net/ows&quot;
                        xmlns:sf="http://cite.opengeospatial.org/gmlsf&quot;
                        xmlns:wfs="http://www.opengis.net/wfs&quot;
                        xmlns:xlink="http://www.w3.org/1999/xlink&quot;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;
                        numberOfFeatures="4"
                        timeStamp="2009-07-23T16:24:36.360+02:00"
                        xsi:schemaLocation="http://www.opengis.net/wfs http://localhost:8080/geoserver/schemas/wfs/1.1.0/wfs.xsd http://localhost:8080/geoserver/wfs?service=WFS&amp;version=1.1.0&amp;request=DescribeFeatureType&amp;typeName=sf:EntitéGénérique&quot;&gt;
    <gml:boundedBy>
       <gml:Envelope srsName="urn:x-ogc:def:crs:EPSG:4326">
          <gml:lowerCorner>35.0 0.0</gml:lowerCorner>
          <gml:upperCorner>64.0 22.5</gml:upperCorner>
       </gml:Envelope>
    </gml:boundedBy>
    <gml:featureMembers>
       <sf:EntitéGénérique gml:id="EntitéGénérique.f004">
          <gml:description>description-f004</gml:description>
          <gml:name>name-f004</gml:name>
          <gml:boundedBy>
             <gml:Envelope srsName="urn:x-ogc:def:crs:EPSG:4326">
                <gml:lowerCorner>60.5 0.0</gml:lowerCorner>
                <gml:upperCorner>64.0 6.25</gml:upperCorner>
             </gml:Envelope>
          </gml:boundedBy>
          <sf:attribut.Géométrie>
             <gml:Polygon srsName="urn:x-ogc:def:crs:EPSG:4326">
                <gml:exterior>
                   <gml:LinearRing>
                      <gml:posList>60.5 0.0 64.0 0.0 64.0 6.25 60.5 6.25 60.5 0.0</gml:posList>
                   </gml:LinearRing>
                </gml:exterior>
                <gml:interior>
                   <gml:LinearRing>
                      <gml:posList>61.5 2.0 62.5 2.0 62.0 4.0 61.5 2.0</gml:posList>
                   </gml:LinearRing>
                </gml:interior>
             </gml:Polygon>
          </sf:attribut.Géométrie>
          <sf:boolProperty>true</sf:boolProperty>
          <sf:str4Property>abc3</sf:str4Property>
          <sf:featureRef>name-f003</sf:featureRef>
       </sf:EntitéGénérique>
       <sf:EntitéGénérique gml:id="EntitéGénérique.f007">
          <gml:description>description-f007</gml:description>
          <gml:name>name-f007</gml:name>
          <gml:boundedBy>
             <gml:Envelope srsName="urn:x-ogc:def:crs:EPSG:4326">
                <gml:lowerCorner>35.0 15.0</gml:lowerCorner>
                <gml:upperCorner>40.0 22.5</gml:upperCorner>
             </gml:Envelope>
          </gml:boundedBy>
          <sf:attribut.Géométrie>
             <gml:Polygon srsName="urn:x-ogc:def:crs:EPSG:4326">
                <gml:exterior>
                   <gml:LinearRing>
                      <gml:posList>35.0 15.0 40.0 16.0 39.0 20.0 37.0 22.5 36.0 18.0 35.0 15.0</gml:posList>
                   </gml:LinearRing>
                </gml:exterior>
                <gml:interior>
                   <gml:LinearRing>
                      <gml:posList>37.1 17.5 37.2 17.6 37.3 17.7 37.4 17.8 37.5 17.9 37.0 17.9 37.1 17.5</gml:posList>
                   </gml:LinearRing>
                </gml:interior>
             </gml:Polygon>
          </sf:attribut.Géométrie>
          <sf:boolProperty>false</sf:boolProperty>
          <sf:str4Property>def4</sf:str4Property>
       </sf:EntitéGénérique>
       <sf:EntitéGénérique xlink:href="#EntitéGénérique.f004">
          <gml:description>description-f004</gml:description>
          <gml:name>name-f004</gml:name>
          <gml:boundedBy>
             <gml:Envelope srsName="urn:x-ogc:def:crs:EPSG:4326">
                <gml:lowerCorner>60.5 0.0</gml:lowerCorner>
                <gml:upperCorner>64.0 6.25</gml:upperCorner>
             </gml:Envelope>
          </gml:boundedBy>
          <sf:attribut.Géométrie>
             <gml:Polygon srsName="urn:x-ogc:def:crs:EPSG:4326">
                <gml:exterior>
                   <gml:LinearRing>
                      <gml:posList>60.5 0.0 64.0 0.0 64.0 6.25 60.5 6.25 60.5 0.0</gml:posList>
                   </gml:LinearRing>
                </gml:exterior>
                <gml:interior>
                   <gml:LinearRing>
                      <gml:posList>61.5 2.0 62.5 2.0 62.0 4.0 61.5 2.0</gml:posList>
                   </gml:LinearRing>
                </gml:interior>
             </gml:Polygon>
          </sf:attribut.Géométrie>
          <sf:boolProperty>true</sf:boolProperty>
          <sf:str4Property>abc3</sf:str4Property>
          <sf:featureRef>name-f003</sf:featureRef>
       </sf:EntitéGénérique>
       <sf:EntitéGénérique xlink:href="#EntitéGénérique.f007">
          <gml:description>description-f007</gml:description>
          <gml:name>name-f007</gml:name>
          <gml:boundedBy>
             <gml:Envelope srsName="urn:x-ogc:def:crs:EPSG:4326">
                <gml:lowerCorner>35.0 15.0</gml:lowerCorner>
                <gml:upperCorner>40.0 22.5</gml:upperCorner>
             </gml:Envelope>
          </gml:boundedBy>
          <sf:attribut.Géométrie>
             <gml:Polygon srsName="urn:x-ogc:def:crs:EPSG:4326">
                <gml:exterior>
                   <gml:LinearRing>
                      <gml:posList>35.0 15.0 40.0 16.0 39.0 20.0 37.0 22.5 36.0 18.0 35.0 15.0</gml:posList>
                   </gml:LinearRing>
                </gml:exterior>
                <gml:interior>
                   <gml:LinearRing>
                      <gml:posList>37.1 17.5 37.2 17.6 37.3 17.7 37.4 17.8 37.5 17.9 37.0 17.9 37.1 17.5</gml:posList>
                   </gml:LinearRing>
                </gml:interior>
             </gml:Polygon>
          </sf:attribut.Géométrie>
          <sf:boolProperty>false</sf:boolProperty>
          <sf:str4Property>def4</sf:str4Property>
       </sf:EntitéGénérique>
    </gml:featureMembers>
</wfs:FeatureCollection>

Did not investigate further but... look like something changed
in the way feature collections are encoded?

Disclaimer: take this with a pinch of salt, I did not cleanup
the database before running the test, but I don't remember
seeing these results in previous runs.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

9

Andrea Aime wrote:

Justin Deoliveira ha scritto:

As promised updated docs:

http://docs.geoserver.org/trunk/developer/cite-test-guide/index.html

Tried this out, got an error while building the app:

aaime@anonymised.com:~/devel/gstrunk/src/community/cite$ mvn install
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building Compliance + Interopability Testing + Evaluation (CITE) Module
[INFO] task-segment: [install]
[INFO] ------------------------------------------------------------------------
[INFO] [antrun:run {execution: pre}]
[INFO] Executing tasks
[INFO] Executed tasks
[INFO] [dependency:copy {execution: pre}]
[INFO] Configured Artifact: tomcat:catalina:5.5.9:jar
[INFO] Configured Artifact: javax.servlet:servlet-api:2.4:jar
[INFO] Copying catalina-5.5.9.jar to /home/aaime/devel/gstrunk/src/community/cite/target/server/lib/catalina.jar
[INFO] Copying servlet-api-2.4.jar to /home/aaime/devel/gstrunk/src/community/cite/target/common/lib/servlet-api.jar

[INFO] [resources:resources]
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory /home/aaime/devel/gstrunk/src/community/cite/src/main/resources
[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [antrun:run {execution: compile}]
[INFO] Executing tasks

all:

init.version.stamp:

zip.engine.src:
   [delete] Deleting directory /home/aaime/devel/gstrunk/src/community/cite/engine/build
    [mkdir] Created dir: /home/aaime/devel/gstrunk/src/community/cite/engine/build
    [mkdir] Created dir: /home/aaime/devel/gstrunk/src/community/cite/engine/build/teamengine-2009.07.23

     [copy] Copying 55 files to /home/aaime/devel/gstrunk/src/community/cite/engine/build/teamengine-2009.07.23

      [zip] Building zip: /home/aaime/devel/gstrunk/src/community/cite/engine/zips/teamengine-2009.07.23-src.zip

jar.engine:

compile:
    [javac] Compiling 49 source files to /home/aaime/devel/gstrunk/src/community/cite/engine/apps/engine/build/classes

[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] An Ant BuildException has occured: The following error occurred while executing this line:
/home/aaime/devel/gstrunk/src/community/cite/engine/build.xml:471: The following error occurred while executing this line:
/home/aaime/devel/gstrunk/src/community/cite/engine/build.xml:82: The following error occurred while executing this line:
/home/aaime/devel/gstrunk/src/community/cite/engine/apps/engine/build.xml:17: Unable to find a javac compiler;
com.sun.tools.javac.Main is not on the classpath.
Perhaps JAVA_HOME does not point to the JDK

Now, I double checked and JAVA_HOME points to a JDK.
I then looked into the pom and noticed a commented out bit about tools.jar, uncommented it, and the build passes.
I have vague recollections of this being a platform/jdk dependent
issue?

Ahh, right, opps, my bad, did not mean to commit that. Commenting it out seems to be necessary on max os. Time for a profile...

Besides that, I tried to run the WFS 1.1 test suite... amazing,
starts fast, works fast. Finally a CITE engine worth using!

Oh, running the tests on trunk I noticed that besides the usual
error about like on dates on postgres 8.3 I got another failure.
The test simply runs a query and checks the gml:id are valid:

http://localhost:8080/geoserver/wfs?&service=WFS&version=1.1.0&request=GetFeature&featureid=EntitéGénérique.f004,EntitéGénérique.f007&namespace=xmlns(sf=http://cite.opengeospatial.org/gmlsf)

but the response contains the usual results and
some oddball ones:

<sf:EntitéGénérique xlink:href="#EntitéGénérique.f004">
...
<sf:EntitéGénérique xlink:href="#EntitéGénérique.f007">

See the full response:

<wfs:FeatureCollection xmlns:gml="http://www.opengis.net/gml&quot; xmlns:ogc="http://www.opengis.net/ogc&quot;
                       xmlns:ows="http://www.opengis.net/ows&quot;
                       xmlns:sf="http://cite.opengeospatial.org/gmlsf&quot;
                       xmlns:wfs="http://www.opengis.net/wfs&quot;
                       xmlns:xlink="http://www.w3.org/1999/xlink&quot;

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;
                       numberOfFeatures="4"
                       timeStamp="2009-07-23T16:24:36.360+02:00"
                       xsi:schemaLocation="http://www.opengis.net/wfs http://localhost:8080/geoserver/schemas/wfs/1.1.0/wfs.xsd http://localhost:8080/geoserver/wfs?service=WFS&amp;version=1.1.0&amp;request=DescribeFeatureType&amp;typeName=sf:EntitéGénérique&quot;&gt;

   <gml:boundedBy>
      <gml:Envelope srsName="urn:x-ogc:def:crs:EPSG:4326">
         <gml:lowerCorner>35.0 0.0</gml:lowerCorner>
         <gml:upperCorner>64.0 22.5</gml:upperCorner>
      </gml:Envelope>
   </gml:boundedBy>
   <gml:featureMembers>
      <sf:EntitéGénérique gml:id="EntitéGénérique.f004">
         <gml:description>description-f004</gml:description>
         <gml:name>name-f004</gml:name>
         <gml:boundedBy>
            <gml:Envelope srsName="urn:x-ogc:def:crs:EPSG:4326">
               <gml:lowerCorner>60.5 0.0</gml:lowerCorner>
               <gml:upperCorner>64.0 6.25</gml:upperCorner>
            </gml:Envelope>
         </gml:boundedBy>
         <sf:attribut.Géométrie>
            <gml:Polygon srsName="urn:x-ogc:def:crs:EPSG:4326">
               <gml:exterior>
                  <gml:LinearRing>
                     <gml:posList>60.5 0.0 64.0 0.0 64.0 6.25 60.5 6.25 60.5 0.0</gml:posList>
                  </gml:LinearRing>
               </gml:exterior>
               <gml:interior>
                  <gml:LinearRing>
                     <gml:posList>61.5 2.0 62.5 2.0 62.0 4.0 61.5 2.0</gml:posList>
                  </gml:LinearRing>
               </gml:interior>
            </gml:Polygon>
         </sf:attribut.Géométrie>
         <sf:boolProperty>true</sf:boolProperty>
         <sf:str4Property>abc3</sf:str4Property>
         <sf:featureRef>name-f003</sf:featureRef>
      </sf:EntitéGénérique>
      <sf:EntitéGénérique gml:id="EntitéGénérique.f007">
         <gml:description>description-f007</gml:description>
         <gml:name>name-f007</gml:name>
         <gml:boundedBy>
            <gml:Envelope srsName="urn:x-ogc:def:crs:EPSG:4326">
               <gml:lowerCorner>35.0 15.0</gml:lowerCorner>
               <gml:upperCorner>40.0 22.5</gml:upperCorner>
            </gml:Envelope>
         </gml:boundedBy>
         <sf:attribut.Géométrie>
            <gml:Polygon srsName="urn:x-ogc:def:crs:EPSG:4326">
               <gml:exterior>
                  <gml:LinearRing>
                     <gml:posList>35.0 15.0 40.0 16.0 39.0 20.0 37.0 22.5 36.0 18.0 35.0 15.0</gml:posList>
                  </gml:LinearRing>
               </gml:exterior>
               <gml:interior>
                  <gml:LinearRing>
                     <gml:posList>37.1 17.5 37.2 17.6 37.3 17.7 37.4 17.8 37.5 17.9 37.0 17.9 37.1 17.5</gml:posList>
                  </gml:LinearRing>
               </gml:interior>
            </gml:Polygon>
         </sf:attribut.Géométrie>
         <sf:boolProperty>false</sf:boolProperty>
         <sf:str4Property>def4</sf:str4Property>
      </sf:EntitéGénérique>
      <sf:EntitéGénérique xlink:href="#EntitéGénérique.f004">
         <gml:description>description-f004</gml:description>
         <gml:name>name-f004</gml:name>
         <gml:boundedBy>
            <gml:Envelope srsName="urn:x-ogc:def:crs:EPSG:4326">
               <gml:lowerCorner>60.5 0.0</gml:lowerCorner>
               <gml:upperCorner>64.0 6.25</gml:upperCorner>
            </gml:Envelope>
         </gml:boundedBy>
         <sf:attribut.Géométrie>
            <gml:Polygon srsName="urn:x-ogc:def:crs:EPSG:4326">
               <gml:exterior>
                  <gml:LinearRing>
                     <gml:posList>60.5 0.0 64.0 0.0 64.0 6.25 60.5 6.25 60.5 0.0</gml:posList>
                  </gml:LinearRing>
               </gml:exterior>
               <gml:interior>
                  <gml:LinearRing>
                     <gml:posList>61.5 2.0 62.5 2.0 62.0 4.0 61.5 2.0</gml:posList>
                  </gml:LinearRing>
               </gml:interior>
            </gml:Polygon>
         </sf:attribut.Géométrie>
         <sf:boolProperty>true</sf:boolProperty>
         <sf:str4Property>abc3</sf:str4Property>
         <sf:featureRef>name-f003</sf:featureRef>
      </sf:EntitéGénérique>
      <sf:EntitéGénérique xlink:href="#EntitéGénérique.f007">
         <gml:description>description-f007</gml:description>
         <gml:name>name-f007</gml:name>
         <gml:boundedBy>
            <gml:Envelope srsName="urn:x-ogc:def:crs:EPSG:4326">
               <gml:lowerCorner>35.0 15.0</gml:lowerCorner>
               <gml:upperCorner>40.0 22.5</gml:upperCorner>
            </gml:Envelope>
         </gml:boundedBy>
         <sf:attribut.Géométrie>
            <gml:Polygon srsName="urn:x-ogc:def:crs:EPSG:4326">
               <gml:exterior>
                  <gml:LinearRing>
                     <gml:posList>35.0 15.0 40.0 16.0 39.0 20.0 37.0 22.5 36.0 18.0 35.0 15.0</gml:posList>
                  </gml:LinearRing>
               </gml:exterior>
               <gml:interior>
                  <gml:LinearRing>
                     <gml:posList>37.1 17.5 37.2 17.6 37.3 17.7 37.4 17.8 37.5 17.9 37.0 17.9 37.1 17.5</gml:posList>
                  </gml:LinearRing>
               </gml:interior>
            </gml:Polygon>
         </sf:attribut.Géométrie>
         <sf:boolProperty>false</sf:boolProperty>
         <sf:str4Property>def4</sf:str4Property>
      </sf:EntitéGénérique>
   </gml:featureMembers>
</wfs:FeatureCollection>

Did not investigate further but... look like something changed
in the way feature collections are encoded?

Disclaimer: take this with a pinch of salt, I did not cleanup
the database before running the test, but I don't remember
seeing these results in previous runs.

Hmmm... not sure. Worth looking into. Fwiw I ran the wfs 1.1 tests with h2 on trunk and 1.7.x and passed. So yeah.. perhaps a dirty db issue or a postgres issue.

Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

10

Justin Deoliveira ha scritto:

------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] An Ant BuildException has occured: The following error occurred while executing this line:
/home/aaime/devel/gstrunk/src/community/cite/engine/build.xml:471: The following error occurred while executing this line:
/home/aaime/devel/gstrunk/src/community/cite/engine/build.xml:82: The following error occurred while executing this line:
/home/aaime/devel/gstrunk/src/community/cite/engine/apps/engine/build.xml:17: Unable to find a javac compiler;
com.sun.tools.javac.Main is not on the classpath.
Perhaps JAVA_HOME does not point to the JDK

Now, I double checked and JAVA_HOME points to a JDK.
I then looked into the pom and noticed a commented out bit about tools.jar, uncommented it, and the build passes.
I have vague recollections of this being a platform/jdk dependent
issue?

Ahh, right, opps, my bad, did not mean to commit that. Commenting it out seems to be necessary on max os. Time for a profile...

Mark just stumbled upon this. I wanted to fix it, but I don't know how,
since it would require a profile that is activated when the OS is not
a Mac (profiles being purely additive to the existing pom).

So I've opened a jira instead: http://jira.codehaus.org/browse/GEOS-3288

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

11

<snip>

Mark just stumbled upon this. I wanted to fix it, but I don't know how,
since it would require a profile that is activated when the OS is not
a Mac (profiles being purely additive to the existing pom).

So I've opened a jira instead: http://jira.codehaus.org/browse/GEOS-3288

Ok, for now i have uncommented the dependency so it should work out of the box for non-mac people.

But fixing with a profile for this one is a pain. We could change the pom so that the dependency by default is not there, but in the windows and linux (and any other os that is not mac) add the dependency.

The problem with this is that it would throw off all other profiles which are activated by default. The other profiles being the ones to copy over certain test configurations.

So a couple of options:

1) Create a readme for mac people with some comments in the pom instructing that they should simply comment out the dependency

2) Do away with the profiles to only include certain test configurations, and always have all copied over by default. Now that the engine has fixed the performance problems I think this is probably a feasible option now. And actually if one really wanted to deactivate a certain test suite they could just remove or rename it from under the tests directory.

So all things considered I think 2) might work best. But 1) also works for me if people like the per test suite profiles. Thoughts and opinions?

-Justin

Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

12

Justin Deoliveira ha scritto:

<snip>

Mark just stumbled upon this. I wanted to fix it, but I don't know how,
since it would require a profile that is activated when the OS is not
a Mac (profiles being purely additive to the existing pom).

So I've opened a jira instead: http://jira.codehaus.org/browse/GEOS-3288

Ok, for now i have uncommented the dependency so it should work out of the box for non-mac people.

But fixing with a profile for this one is a pain. We could change the pom so that the dependency by default is not there, but in the windows and linux (and any other os that is not mac) add the dependency.

The problem with this is that it would throw off all other profiles which are activated by default. The other profiles being the ones to copy over certain test configurations.

So a couple of options:

1) Create a readme for mac people with some comments in the pom instructing that they should simply comment out the dependency

2) Do away with the profiles to only include certain test configurations, and always have all copied over by default. Now that the engine has fixed the performance problems I think this is probably a feasible option now. And actually if one really wanted to deactivate a certain test suite they could just remove or rename it from under the tests directory.

So all things considered I think 2) might work best. But 1) also works for me if people like the per test suite profiles. Thoughts and opinions?

2) works for me, there is no more reason to have the per suite profiles

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.