[Geoserver-devel] REST Extensible and customizable versions report

[Carlo_Cancellieri1]

Hi all,
to complete the integration of GeoServer (and all of the installed plugin) into our continuous integration environment I need to provide a rest service to expose (at least):

… release (version)
… revision (svn tag or git hash)
… build date (optional)

for GeoServer and all of the installed extensions (f.e.):

… monitoring
… control flow

plus other custom plugins.

So I need to create an extensible mechanisms to provide those info. There are various possible approaches.
Here is my proposal based on java Manifest + maven and its plugins.

1. Each project or extension may register it’s Manifest bean into the spring context
2. For each GET request on the /rest/about[.format] path, a file in the ‘.format’ format will be returned listing all of the registered Manifest beans with all of the stored entries.
3. The output format can be produced using FreeMarker

Note also that this is an extensible and customisable approach:

1. Example on how to extend/customize:

I’ll setup for my custom plugin manifest entries adding hudson environment and build information using maven variables with:

org.apache.maven.plugins maven-jar-plugin true true ${project.build.finalname} ${project.version} ${iteration} ${maven.build.timestamp} ${BUILD_NUMBER} ${BUILD_ID} ${JOB_NAME} ${BUILD_TAG} ${EXECUTOR_NUMBER} ${JAVA_HOME} ${WORKSPACE} ${HUDSON_URL} ${SVN_REVISION} ${SVN_TAG}

The result will be a file with some more information (coming from my extension build) into the custom plugin section.

2. A simple example for geoserver with monitoring plugin installed into the lib dir:

doing a get on http://GEOSERVER/rest/about.xml (with username and password)

will result in something like:

..--SNAPSHOT ....--rc<</ daabbfaafbbfddbbbeffabbbb674bbbb1361ddd< --SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb145<< ..--SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb146<<

3. A simple example for geoserver with monitoring and my custom plugin installed into the lib dir:

get http://GEOSERVER/rest/about.xml

will result in something like:

..--SNAPSHOT ....--rc<</ daabbfaafbbfddbbbeffabbbb674bbbb1361ddd< --SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb145<< ..--SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb146<< 1.0.--SNAPSHOT ....--rc<</ MyCustom ..--SNAPSHOT ... 9<< < GEO_TS_GEOSERVER_MyCustom_BUILD 2<< < .. ... http://.... r093<< REL_79<<

Note also that non maven project can still use this using their custom (ant?) mechanisms to update their /META-INF/MANIFEST.MF file.

What do you think about this? May I have to produce a proposal page? is it possible to have this on the 2.2.x branch (in the future)?

Ref.:
http://maven.apache.org/shared/maven-archiver/examples/manifest.html
http://docs.oracle.com/javase/....//docs/api/java/util/jar/Manifest.html
https://github.com/kevinsawicki/github-maven-example/blob/master/example/pom.xml

Cheers,
Carlo Cancellieri - GeoSolutions SAS

[Justin_Deoliveira]

Hi Carlo,

Very interesting idea and is something that I have wanted to see in GeoServer for quite some time, the start of an extension management framework.

One question I have is how will the manifest lookup occur? Will it be a simple lookup of all manifests on the classpath? Will there be some marker attribute used to define a jar as a geoserver plugin?

The REST api looks good.

Can’t comment on whether 2.2.x is appropriate without looking at any code but in general this all sounds like mostly build work and additive code which shouldn’t be a problem.

$0.02

-Justin

···

On Thu, Nov 29, 2012 at 7:12 AM, Carlo Cancellieri <ccancellieri@anonymised.com> wrote:

Hi all,
to complete the integration of GeoServer (and all of the installed plugin) into our continuous integration environment I need to provide a rest service to expose (at least):

… release (version)
… revision (svn tag or git hash)
… build date (optional)

for GeoServer and all of the installed extensions (f.e.):

… monitoring
… control flow

plus other custom plugins.

So I need to create an extensible mechanisms to provide those info. There are various possible approaches.
Here is my proposal based on java Manifest + maven and its plugins.

1. Each project or extension may register it’s Manifest bean into the spring context
2. For each GET request on the /rest/about[.format] path, a file in the ‘.format’ format will be returned listing all of the registered Manifest beans with all of the stored entries.
3. The output format can be produced using FreeMarker

Note also that this is an extensible and customisable approach:

1. Example on how to extend/customize:

I’ll setup for my custom plugin manifest entries adding hudson environment and build information using maven variables with:

org.apache.maven.plugins maven-jar-plugin true true ${project.build.finalname} ${project.version} ${iteration} ${maven.build.timestamp} ${BUILD_NUMBER} ${BUILD_ID} ${JOB_NAME} ${BUILD_TAG} ${EXECUTOR_NUMBER} ${JAVA_HOME} ${WORKSPACE} ${HUDSON_URL} ${SVN_REVISION} ${SVN_TAG}

The result will be a file with some more information (coming from my extension build) into the custom plugin section.

2. A simple example for geoserver with monitoring plugin installed into the lib dir:

doing a get on http://GEOSERVER/rest/about.xml (with username and password)

will result in something like:

..--SNAPSHOT ....--rc<</ daabbfaafbbfddbbbeffabbbb674bbbb1361ddd< --SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb145<< ..--SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb146<<

3. A simple example for geoserver with monitoring and my custom plugin installed into the lib dir:

get http://GEOSERVER/rest/about.xml

will result in something like:

..--SNAPSHOT ....--rc<</ daabbfaafbbfddbbbeffabbbb674bbbb1361ddd< --SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb145<< ..--SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb146<< 1.0.--SNAPSHOT ....--rc<</ MyCustom ..--SNAPSHOT ... 9<< < GEO_TS_GEOSERVER_MyCustom_BUILD 2<< < .. ... http://.... r093<< REL_79<<

Note also that non maven project can still use this using their custom (ant?) mechanisms to update their /META-INF/MANIFEST.MF file.

What do you think about this? May I have to produce a proposal page? is it possible to have this on the 2.2.x branch (in the future)?

Ref.:
http://maven.apache.org/shared/maven-archiver/examples/manifest.html
http://docs.oracle.com/javase/…//docs/api/java/util/jar/Manifest.html
https://github.com/kevinsawicki/github-maven-example/blob/master/example/pom.xml

Cheers,
Carlo Cancellieri - GeoSolutions SAS

---

Keep yourself connected to Go Parallel:
VERIFY Test and improve your parallel project with help from experts
and peers. http://goparallel.sourceforge.net

---

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

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

[Andrea_Aime4]

On Thu, Nov 29, 2012 at 3:55 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi Carlo,

Very interesting idea and is something that I have wanted to see in GeoServer for quite some time, the start of an extension management framework.

One question I have is how will the manifest lookup occur? Will it be a simple lookup of all manifests on the classpath? Will there be some marker attribute used to define a jar as a geoserver plugin?

Wondering if the manifests can be generated automatically during the build, reading info from the pom files?
Maybe a custom maven build tool that is setup to run in the extension and community modules that would
generate these files?

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---

[Carlo_Cancellieri1]

Andrea,

Wondering if the manifests can be generated automatically during the build, reading info from the pom files?

Maybe a custom maven build tool that is setup to run in the extension and community modules that would
generate these files?

We only need to configure the maven jar (or war) plugin into the pom as in the shown into the examples:

I report it again:

org.apache.maven.plugins maven-jar-plugin true true

Cheers,
Carlo Cancellieri - GeoSolutions SAS

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---

[Andrea_Aime4]

On Thu, Nov 29, 2012 at 5:31 PM, Carlo Cancellieri <ccancellieri@anonymised.com…> wrote:

We only need to configure the maven jar (or war) plugin into the pom as in the shown into the examples:

I report it again:

org.apache.maven.plugins maven-jar-plugin true true

Ah ok, I missed it from the first mail.
I agree with Justin, we should add an extra element in the manifest to recognize
the GeoServer specific manifests, as other GeoServer unrelated jars will have a manifest
too.

Something like:

... GeoServerExtensions ...

Instead of adding a custom section in each and every module pom file we should try
to just put it in the extensions/community parent poms and check if they are inherited
from the child pom: this way we should avoid duplication and maintenance

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---

[Justin_Deoliveira]

Yeah, I was thinking that this for the most part could be handled by the root pom, the root extension pom, and the root community module pom. I was thinking something like:

…
[core|extension|community]

…

···

On Thu, Nov 29, 2012 at 10:37 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Thu, Nov 29, 2012 at 5:31 PM, Carlo Cancellieri <ccancellieri@anonymised.com> wrote:

We only need to configure the maven jar (or war) plugin into the pom as in the shown into the examples:

I report it again:

org.apache.maven.plugins maven-jar-plugin true true

Ah ok, I missed it from the first mail.
I agree with Justin, we should add an extra element in the manifest to recognize
the GeoServer specific manifests, as other GeoServer unrelated jars will have a manifest
too.

Something like:

... GeoServerExtensions ...

Instead of adding a custom section in each and every module pom file we should try
to just put it in the extensions/community parent poms and check if they are inherited
from the child pom: this way we should avoid duplication and maintenance

Cheers

Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---

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

[Andrea_Aime4]

On Thu, Nov 29, 2012 at 5:43 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Yeah, I was thinking that this for the most part could be handled by the root pom, the root extension pom, and the root community module pom. I was thinking something like:

…
[core|extension|community]

…

Ah, so we’d also list the core modules somewhere… could be useful, in case someone created
a GeoFrankenServer by putting togheter jars from different builds

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---

[Justin_Deoliveira]

Yeah, I was thinking it couldn’t hurt.

I think implementing this should be pretty easy. In the root pom basically we add the manifest entry that looks like this:

${module.type}

(Changing the name to match I think what are standard manifest key naming conventions).

In the root prom we declare the property:

<module.type>core</module.type>

Then it is just a matter of overriding the property name in extension/pom.xml and community/pom.xml sub poms.

···

On Thu, Nov 29, 2012 at 10:44 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Thu, Nov 29, 2012 at 5:43 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Yeah, I was thinking that this for the most part could be handled by the root pom, the root extension pom, and the root community module pom. I was thinking something like:

…
[core|extension|community]

…

Ah, so we’d also list the core modules somewhere… could be useful, in case someone created
a GeoFrankenServer by putting togheter jars from different builds

Cheers

Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---

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

[Carlo_Cancellieri1]

Justin,
my intention is to keep things as simple and modular as possible to easily backport this improvement to the 2.2.x.
so: (inline)

One question I have is how will the manifest lookup occur?
Will it be a simple lookup of all manifests on the classpath?

I don’t like to force users to add a specific package dependency only to use a marker interface. So:

• I chose the Manifest class as type to use for the lookup (but I don’t really like this, I’m still looking for a way to collect all the manifests files from the loaded jars… it should be possible from the spring context).
• loading the manifest file for the core (GeoServer, GeoTools) can be delegated to a new bean (no hands on core classes, just xml spring and one new class).

Then, to make extensions ready for this improvement we only have to update their pom.

Will there be some marker attribute used to define a jar as a geoserver plugin?

The REST api looks good.

ok

Also agree for the core|community|… type marker into the parents pom modules.

To limit the depth of the sealing I can try to see if sealing is supported by the maven jar plugin
http://docs.oracle.com/javase/1.4.2/docs/guide/extensions/spec.html#sealing

Introducing this we will also be able to check the jars sign and much more.

Cheers,
Carlo Cancellieri - GeoSolutions SAS

-Justin

On Thu, Nov 29, 2012 at 7:12 AM, Carlo Cancellieri <ccancellieri@anonymised.com> wrote:

Hi all,
to complete the integration of GeoServer (and all of the installed plugin) into our continuous integration environment I need to provide a rest service to expose (at least):

… release (version)
… revision (svn tag or git hash)
… build date (optional)

for GeoServer and all of the installed extensions (f.e.):

… monitoring
… control flow

plus other custom plugins.

So I need to create an extensible mechanisms to provide those info. There are various possible approaches.
Here is my proposal based on java Manifest + maven and its plugins.

1. Each project or extension may register it’s Manifest bean into the spring context
2. For each GET request on the /rest/about[.format] path, a file in the ‘.format’ format will be returned listing all of the registered Manifest beans with all of the stored entries.
3. The output format can be produced using FreeMarker

Note also that this is an extensible and customisable approach:

1. Example on how to extend/customize:

I’ll setup for my custom plugin manifest entries adding hudson environment and build information using maven variables with:

org.apache.maven.plugins maven-jar-plugin true true ${project.build.finalname} ${project.version} ${iteration} ${maven.build.timestamp} ${BUILD_NUMBER} ${BUILD_ID} ${JOB_NAME} ${BUILD_TAG} ${EXECUTOR_NUMBER} ${JAVA_HOME} ${WORKSPACE} ${HUDSON_URL} ${SVN_REVISION} ${SVN_TAG}

The result will be a file with some more information (coming from my extension build) into the custom plugin section.

2. A simple example for geoserver with monitoring plugin installed into the lib dir:

doing a get on http://GEOSERVER/rest/about.xml (with username and password)

will result in something like:

..--SNAPSHOT ....--rc<</ daabbfaafbbfddbbbeffabbbb674bbbb1361ddd< --SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb145<< ..--SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb146<<

3. A simple example for geoserver with monitoring and my custom plugin installed into the lib dir:

get http://GEOSERVER/rest/about.xml

will result in something like:

..--SNAPSHOT ....--rc<</ daabbfaafbbfddbbbeffabbbb674bbbb1361ddd< --SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb145<< ..--SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb146<< 1.0.--SNAPSHOT ....--rc<</ MyCustom ..--SNAPSHOT ... 9<< < GEO_TS_GEOSERVER_MyCustom_BUILD 2<< < .. ... http://.... r093<< REL_79<<

Note also that non maven project can still use this using their custom (ant?) mechanisms to update their /META-INF/MANIFEST.MF file.

What do you think about this? May I have to produce a proposal page? is it possible to have this on the 2.2.x branch (in the future)?

Ref.:
http://maven.apache.org/shared/maven-archiver/examples/manifest.html
http://docs.oracle.com/javase/…//docs/api/java/util/jar/Manifest.html
https://github.com/kevinsawicki/github-maven-example/blob/master/example/pom.xml

Cheers,
Carlo Cancellieri - GeoSolutions SAS

---

Keep yourself connected to Go Parallel:
VERIFY Test and improve your parallel project with help from experts
and peers. http://goparallel.sourceforge.net

---

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

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

[Carlo_Cancellieri1]

Hy,
I’ll start a new branch soon introducing the pom changes and the core manifest bean loader to start looking into other options.Regards,
Carlo Cancellieri - GeoSolutions SAS

---

From: ccancellieri@anonymised.com
To: jdeolive@anonymised.com
CC: geoserver-devel@anonymised.comge.net
Subject: RE: [Geoserver-devel] REST Extensible and customizable versions report
Date: Thu, 29 Nov 2012 17:23:23 +0000

Justin,
my intention is to keep things as simple and modular as possible to easily backport this improvement to the 2.2.x.
so: (inline)

One question I have is how will the manifest lookup occur?
Will it be a simple lookup of all manifests on the classpath?

I don’t like to force users to add a specific package dependency only to use a marker interface. So:

• I chose the Manifest class as type to use for the lookup (but I don’t really like this, I’m still looking for a way to collect all the manifests files from the loaded jars… it should be possible from the spring context).
• loading the manifest file for the core (GeoServer, GeoTools) can be delegated to a new bean (no hands on core classes, just xml spring and one new class).

Then, to make extensions ready for this improvement we only have to update their pom.

Will there be some marker attribute used to define a jar as a geoserver plugin?

The REST api looks good.

ok

Also agree for the core|community|… type marker into the parents pom modules.

To limit the depth of the sealing I can try to see if sealing is supported by the maven jar plugin
http://docs.oracle.com/javase/1.4.2/docs/guide/extensions/spec.html#sealing

Introducing this we will also be able to check the jars sign and much more.

Cheers,
Carlo Cancellieri - GeoSolutions SAS

-Justin

On Thu, Nov 29, 2012 at 7:12 AM, Carlo Cancellieri <ccancellieri@anonymised.com> wrote:

Hi all,
to complete the integration of GeoServer (and all of the installed plugin) into our continuous integration environment I need to provide a rest service to expose (at least):

… release (version)
… revision (svn tag or git hash)
… build date (optional)

for GeoServer and all of the installed extensions (f.e.):

… monitoring
… control flow

plus other custom plugins.

So I need to create an extensible mechanisms to provide those info. There are various possible approaches.
Here is my proposal based on java Manifest + maven and its plugins.

1. Each project or extension may register it’s Manifest bean into the spring context
2. For each GET request on the /rest/about[.format] path, a file in the ‘.format’ format will be returned listing all of the registered Manifest beans with all of the stored entries.
3. The output format can be produced using FreeMarker

Note also that this is an extensible and customisable approach:

1. Example on how to extend/customize:

I’ll setup for my custom plugin manifest entries adding hudson environment and build information using maven variables with:

org.apache.maven.plugins maven-jar-plugin true true ${project.build.finalname} ${project.version} ${iteration} ${maven.build.timestamp} ${BUILD_NUMBER} ${BUILD_ID} ${JOB_NAME} ${BUILD_TAG} ${EXECUTOR_NUMBER} ${JAVA_HOME} ${WORKSPACE} ${HUDSON_URL} ${SVN_REVISION} ${SVN_TAG}

The result will be a file with some more information (coming from my extension build) into the custom plugin section.

2. A simple example for geoserver with monitoring plugin installed into the lib dir:

doing a get on http://GEOSERVER/rest/about.xml (with username and password)

will result in something like:

..--SNAPSHOT ....--rc<</ daabbfaafbbfddbbbeffabbbb674bbbb1361ddd< --SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb145<< ..--SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb146<<

3. A simple example for geoserver with monitoring and my custom plugin installed into the lib dir:

get http://GEOSERVER/rest/about.xml

will result in something like:

..--SNAPSHOT ....--rc<</ daabbfaafbbfddbbbeffabbbb674bbbb1361ddd< --SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb145<< ..--SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb146<< 1.0.--SNAPSHOT ....--rc<</ MyCustom ..--SNAPSHOT ... 9<< < GEO_TS_GEOSERVER_MyCustom_BUILD 2<< < .. ... http://.... r093<< REL_79<<

Note also that non maven project can still use this using their custom (ant?) mechanisms to update their /META-INF/MANIFEST.MF file.

What do you think about this? May I have to produce a proposal page? is it possible to have this on the 2.2.x branch (in the future)?

Ref.:
http://maven.apache.org/shared/maven-archiver/examples/manifest.html
http://docs.oracle.com/javase/…//docs/api/java/util/jar/Manifest.html
https://github.com/kevinsawicki/github-maven-example/blob/master/example/pom.xml

Cheers,
Carlo Cancellieri - GeoSolutions SAS

---

Keep yourself connected to Go Parallel:
VERIFY Test and improve your parallel project with help from experts
and peers. http://goparallel.sourceforge.net

---

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

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

[Carlo_Cancellieri1]

Hi,
I decided to make a simple lookup of jars using the classloader.

We support also search through:

• resource name (from-to http://cio174:8080/geoserver/rest/about.xml?fromName=a&toName=b )
• resource name regex http://cio174:8080/geoserver/rest/about.xml?regex=gt.* )
• key (http://cio174:8080/geoserver/rest/about.xml?key=core )
• value (http://cio174:8080/geoserver/rest/about.xml?value=extension )
• key AND value ( http://cio174:8080/geoserver/rest/about.xml?value=core&key=GeoServerModule )

Here is a first commit to take a look:
https://github.com/ccancellieri/geoserver/compare/master-REST-manifest-version

Note:
probably you don’t like Hudson keys into the pom?

Example 1:

http://cio174:8080/geoserver/rest/about.xml?value=extension&key=GeoServerModule

04-Dec-2012 18:00

Web Processing Service parent

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.extension

Web Processing Service parent

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

extension

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

Example 2:

http://cio174:8080/geoserver/rest/about.xml?value=core&key=GeoServerModule

04-Dec-2012 18:00

GeoWebCache (GWC) Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

GeoWebCache (GWC) Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Main Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

Main Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Open Web Service Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

Open Web Service Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Core Platform Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

Core Platform Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

REST Support Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

REST Support Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

REST Configuration Service Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

REST Configuration Service Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

GeoServer JDBC Security Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.security

GeoServer JDBC Security Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

GeoServer LDAP Security Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.security

GeoServer LDAP Security Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Web Coverage Service Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

Web Coverage Service Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Web Coverage Service 1.0 Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

Web Coverage Service 1.0 Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Web Coverage Service 1.1 Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

Web Coverage Service 1.1 Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Core UI Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.web

Core UI Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Demoes Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.web

Demoes Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

GWC UI Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.web

GWC UI Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Security UI Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.web

Security UI Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

WCS UI Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.web

WCS UI Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

WFS UI Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.web

WFS UI Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

WMS UI Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.web

WMS UI Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Web Feature Service Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

Web Feature Service Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Web Map Service Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

Web Map Service Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

Cheers,
Carlo Cancellieri - GeoSolutions SAS

---

From: ccancellieri@anonymised.com
To: jdeolive@anonymised.com; andrea.aime@anonymised.com
Date: Thu, 29 Nov 2012 17:27:41 +0000
CC: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] REST Extensible and customizable versions report

Hy,
I’ll start a new branch soon introducing the pom changes and the core manifest bean loader to start looking into other options.Regards,
Carlo Cancellieri - GeoSolutions SAS

---

From: ccancellieri@anonymised.com
To: jdeolive@anonymised.com
CC: geoserver-devel@anonymised.comrceforge.net
Subject: RE: [Geoserver-devel] REST Extensible and customizable versions report
Date: Thu, 29 Nov 2012 17:23:23 +0000

Justin,
my intention is to keep things as simple and modular as possible to easily backport this improvement to the 2.2.x.
so: (inline)

One question I have is how will the manifest lookup occur?
Will it be a simple lookup of all manifests on the classpath?

I don’t like to force users to add a specific package dependency only to use a marker interface. So:

• I chose the Manifest class as type to use for the lookup (but I don’t really like this, I’m still looking for a way to collect all the manifests files from the loaded jars… it should be possible from the spring context).
• loading the manifest file for the core (GeoServer, GeoTools) can be delegated to a new bean (no hands on core classes, just xml spring and one new class).

Then, to make extensions ready for this improvement we only have to update their pom.

Will there be some marker attribute used to define a jar as a geoserver plugin?

The REST api looks good.

ok

Also agree for the core|community|… type marker into the parents pom modules.

To limit the depth of the sealing I can try to see if sealing is supported by the maven jar plugin
http://docs.oracle.com/javase/1.4.2/docs/guide/extensions/spec.html#sealing

Introducing this we will also be able to check the jars sign and much more.

Cheers,
Carlo Cancellieri - GeoSolutions SAS

-Justin

On Thu, Nov 29, 2012 at 7:12 AM, Carlo Cancellieri <ccancellieri@anonymised.com> wrote:

Hi all,
to complete the integration of GeoServer (and all of the installed plugin) into our continuous integration environment I need to provide a rest service to expose (at least):

… release (version)
… revision (svn tag or git hash)
… build date (optional)

for GeoServer and all of the installed extensions (f.e.):

… monitoring
… control flow

plus other custom plugins.

So I need to create an extensible mechanisms to provide those info. There are various possible approaches.
Here is my proposal based on java Manifest + maven and its plugins.

1. Each project or extension may register it’s Manifest bean into the spring context
2. For each GET request on the /rest/about[.format] path, a file in the ‘.format’ format will be returned listing all of the registered Manifest beans with all of the stored entries.
3. The output format can be produced using FreeMarker

Note also that this is an extensible and customisable approach:

1. Example on how to extend/customize:

I’ll setup for my custom plugin manifest entries adding hudson environment and build information using maven variables with:

org.apache.maven.plugins maven-jar-plugin true true ${project.build.finalname} ${project.version} ${iteration} ${maven.build.timestamp} ${BUILD_NUMBER} ${BUILD_ID} ${JOB_NAME} ${BUILD_TAG} ${EXECUTOR_NUMBER} ${JAVA_HOME} ${WORKSPACE} ${HUDSON_URL} ${SVN_REVISION} ${SVN_TAG}

The result will be a file with some more information (coming from my extension build) into the custom plugin section.

2. A simple example for geoserver with monitoring plugin installed into the lib dir:

doing a get on http://GEOSERVER/rest/about.xml (with username and password)

will result in something like:

..--SNAPSHOT ....--rc<</ daabbfaafbbfddbbbeffabbbb674bbbb1361ddd< --SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb145<< ..--SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb146<<

3. A simple example for geoserver with monitoring and my custom plugin installed into the lib dir:

get http://GEOSERVER/rest/about.xml

will result in something like:

..--SNAPSHOT ....--rc<</ daabbfaafbbfddbbbeffabbbb674bbbb1361ddd< --SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb145<< ..--SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb146<< 1.0.--SNAPSHOT ....--rc<</ MyCustom ..--SNAPSHOT ... 9<< < GEO_TS_GEOSERVER_MyCustom_BUILD 2<< < .. ... http://.... r093<< REL_79<<

Note also that non maven project can still use this using their custom (ant?) mechanisms to update their /META-INF/MANIFEST.MF file.

What do you think about this? May I have to produce a proposal page? is it possible to have this on the 2.2.x branch (in the future)?

Ref.:
http://maven.apache.org/shared/maven-archiver/examples/manifest.html
http://docs.oracle.com/javase/…//docs/api/java/util/jar/Manifest.html
https://github.com/kevinsawicki/github-maven-example/blob/master/example/pom.xml

Cheers,
Carlo Cancellieri - GeoSolutions SAS

---

Keep yourself connected to Go Parallel:
VERIFY Test and improve your parallel project with help from experts
and peers. http://goparallel.sourceforge.net

---

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

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

------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Justin_Deoliveira]

Hey Carlo,

Excited to see this work coming about. I am not sure how others feel but i imagine this is probably worthy of a gsip. Some questions/comments inline.

···

On Tue, Dec 4, 2012 at 10:31 AM, Carlo Cancellieri <ccancellieri@anonymised.com…> wrote:

Hi,
I decided to make a simple lookup of jars using the classloader.

We support also search through:

• resource name (from-to http://cio174:8080/geoserver/rest/about.xml?fromName=a&toName=b )

Sorry, don’t quite understand this one, what does fromName / toName significy?

• resource name regex http://cio174:8080/geoserver/rest/about.xml?regex=gt.* )
• key (http://cio174:8080/geoserver/rest/about.xml?key=core )
• value (http://cio174:8080/geoserver/rest/about.xml?value=extension )

So the semantics is that any jar with a manifest entry named “core” would be matched. And similarly for value any jar with a manfifest entry whose value is “extension” would be matched?

• key AND value ( http://cio174:8080/geoserver/rest/about.xml?value=core&key=GeoServerModule )

Makes sense.

Here is a first commit to take a look:
https://github.com/ccancellieri/geoserver/compare/master-REST-manifest-version

Anyways, looking quite nice. I think it would be good to sketch out the syntax/semantics of the rest api in a proposal so we can use that as a center for discussion around tweaking the api. A couple of things off the top of my head:

• rename “regex” to “resource”, since it is matching soley on the resource name correct?
• we may want to break out a separate collection for specifically the resources, in case we want to add other information as well, for example:

• /rest/about/resources.xml → what you include below
• /rest/about/version.xml → just the primary version info, what is currently included on the about page

That would leave it a bit more open ended in case we want to add more info under “about”.

Anyways, great stuff.

Note:
probably you don’t like Hudson keys into the pom?

Example 1:

http://cio174:8080/geoserver/rest/about.xml?value=extension&key=GeoServerModule

04-Dec-2012 18:00

Web Processing Service parent

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.extension

Web Processing Service parent

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

extension

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

Example 2:

http://cio174:8080/geoserver/rest/about.xml?value=core&key=GeoServerModule

04-Dec-2012 18:00

GeoWebCache (GWC) Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

GeoWebCache (GWC) Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Main Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

Main Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Open Web Service Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

Open Web Service Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Core Platform Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

Core Platform Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

REST Support Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

REST Support Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

REST Configuration Service Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

REST Configuration Service Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

GeoServer JDBC Security Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.security

GeoServer JDBC Security Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

GeoServer LDAP Security Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.security

GeoServer LDAP Security Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Web Coverage Service Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

Web Coverage Service Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Web Coverage Service 1.0 Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

Web Coverage Service 1.0 Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Web Coverage Service 1.1 Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

Web Coverage Service 1.1 Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Core UI Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.web

Core UI Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Demoes Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.web

Demoes Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

GWC UI Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.web

GWC UI Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Security UI Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.web

Security UI Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

WCS UI Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.web

WCS UI Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

WFS UI Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.web

WFS UI Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

WMS UI Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.web

WMS UI Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Web Feature Service Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

Web Feature Service Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Web Map Service Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

Web Map Service Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

Cheers,
Carlo Cancellieri - GeoSolutions SAS

---

From: ccancellieri@anonymised.com
To: jdeolive@anonymised.com; andrea.aime@…1268…
Date: Thu, 29 Nov 2012 17:27:41 +0000
CC: geoserver-devel@anonymised.comrge.net
Subject: Re: [Geoserver-devel] REST Extensible and customizable versions report

Hy,
I’ll start a new branch soon introducing the pom changes and the core manifest bean loader to start looking into other options.Regards,
Carlo Cancellieri - GeoSolutions SAS

---

From: ccancellieri@anonymised.com
To: jdeolive@anonymised.com
CC: geoserver-devel@anonymised.comorge.net
Subject: RE: [Geoserver-devel] REST Extensible and customizable versions report
Date: Thu, 29 Nov 2012 17:23:23 +0000

Justin,
my intention is to keep things as simple and modular as possible to easily backport this improvement to the 2.2.x.
so: (inline)

One question I have is how will the manifest lookup occur?
Will it be a simple lookup of all manifests on the classpath?

I don’t like to force users to add a specific package dependency only to use a marker interface. So:

• I chose the Manifest class as type to use for the lookup (but I don’t really like this, I’m still looking for a way to collect all the manifests files from the loaded jars… it should be possible from the spring context).
• loading the manifest file for the core (GeoServer, GeoTools) can be delegated to a new bean (no hands on core classes, just xml spring and one new class).

Then, to make extensions ready for this improvement we only have to update their pom.

Will there be some marker attribute used to define a jar as a geoserver plugin?

The REST api looks good.

ok

Also agree for the core|community|… type marker into the parents pom modules.

To limit the depth of the sealing I can try to see if sealing is supported by the maven jar plugin
http://docs.oracle.com/javase/1.4.2/docs/guide/extensions/spec.html#sealing

Introducing this we will also be able to check the jars sign and much more.

Cheers,
Carlo Cancellieri - GeoSolutions SAS

-Justin

On Thu, Nov 29, 2012 at 7:12 AM, Carlo Cancellieri <ccancellieri@anonymised.com> wrote:

Hi all,
to complete the integration of GeoServer (and all of the installed plugin) into our continuous integration environment I need to provide a rest service to expose (at least):

… release (version)
… revision (svn tag or git hash)
… build date (optional)

for GeoServer and all of the installed extensions (f.e.):

… monitoring
… control flow

plus other custom plugins.

So I need to create an extensible mechanisms to provide those info. There are various possible approaches.
Here is my proposal based on java Manifest + maven and its plugins.

1. Each project or extension may register it’s Manifest bean into the spring context
2. For each GET request on the /rest/about[.format] path, a file in the ‘.format’ format will be returned listing all of the registered Manifest beans with all of the stored entries.
3. The output format can be produced using FreeMarker

Note also that this is an extensible and customisable approach:

1. Example on how to extend/customize:

I’ll setup for my custom plugin manifest entries adding hudson environment and build information using maven variables with:

org.apache.maven.plugins maven-jar-plugin true true ${project.build.finalname} ${project.version} ${iteration} ${maven.build.timestamp} ${BUILD_NUMBER} ${BUILD_ID} ${JOB_NAME} ${BUILD_TAG} ${EXECUTOR_NUMBER} ${JAVA_HOME} ${WORKSPACE} ${HUDSON_URL} ${SVN_REVISION} ${SVN_TAG}

The result will be a file with some more information (coming from my extension build) into the custom plugin section.

2. A simple example for geoserver with monitoring plugin installed into the lib dir:

doing a get on http://GEOSERVER/rest/about.xml (with username and password)

will result in something like:

..--SNAPSHOT ....--rc<</ daabbfaafbbfddbbbeffabbbb674bbbb1361ddd< --SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb145<< ..--SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb146<<

3. A simple example for geoserver with monitoring and my custom plugin installed into the lib dir:

get http://GEOSERVER/rest/about.xml

will result in something like:

..--SNAPSHOT ....--rc<</ daabbfaafbbfddbbbeffabbbb674bbbb1361ddd< --SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb145<< ..--SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb146<< 1.0.--SNAPSHOT ....--rc<</ MyCustom ..--SNAPSHOT ... 9<< < GEO_TS_GEOSERVER_MyCustom_BUILD 2<< < .. ... http://.... r093<< REL_79<<

Note also that non maven project can still use this using their custom (ant?) mechanisms to update their /META-INF/MANIFEST.MF file.

What do you think about this? May I have to produce a proposal page? is it possible to have this on the 2.2.x branch (in the future)?

Ref.:
http://maven.apache.org/shared/maven-archiver/examples/manifest.html
http://docs.oracle.com/javase/…//docs/api/java/util/jar/Manifest.html
https://github.com/kevinsawicki/github-maven-example/blob/master/example/pom.xml

Cheers,
Carlo Cancellieri - GeoSolutions SAS

---

Keep yourself connected to Go Parallel:
VERIFY Test and improve your parallel project with help from experts
and peers. http://goparallel.sourceforge.net

---

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

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

------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel

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

[Carlo_Cancellieri1]

Justin,

We can have many resources loaded into the class loader so I decided to add minimal filtering capabilities to the request.

We support also search through:

• resource name (from-to http://cio174:8080/geoserver/rest/about.xml?fromName=a&toName=b )

Sorry, don’t quite understand this one, what does fromName / toName significy?

If you want, you can paginate the request using Alphabetical order (from resource named ‘a’ to resource named ‘b’ … and so on)

• resource name regex http://cio174:8080/geoserver/rest/about.xml?regex=gt.* )
• key (http://cio174:8080/geoserver/rest/about.xml?key=core )
• value (http://cio174:8080/geoserver/rest/about.xml?value=extension )

So the semantics is that any jar with a manifest entry named “core” would be matched. And similarly for value any jar with a manfifest entry whose value is “extension” would be matched?

Right, so when I add my set of extensions with mine specific key, I’ll be able to filter all but mine resources.

Here is a first commit to take a look:
https://github.com/ccancellieri/geoserver/compare/master-REST-manifest-version

Anyways, looking quite nice.
I think it would be good to sketch out the syntax/semantics of the rest api in a proposal so we can use that as a center for discussion around tweaking the api.

OK

A couple of things off the top of my head:

• rename “regex” to “resource”, since it is matching soley on the resource name correct?
• we may want to break out a separate collection for specifically the resources, in case we want to add other information as well, for example:

• /rest/about/resources.xml → what you include below

no prob

• /rest/about/version.xml → just the primary version info, what is currently included on the about page
  That would leave it a bit more open ended in case we want to add more info under “about”.

To do so, I’m thinking to use the same model having something like:

04-Dec-2012 18:00
The Open Planning Project
2.3-SNAPSHOT
core

04-Dec-2012 18:00
…
8.x-SNAPSHOT

Is this acceptable for you?

Cheers,
Carlo Cancellieri - GeoSolutions SAS

Example 2:

http://cio174:8080/geoserver/rest/about.xml?value=core&key=GeoServerModule

04-Dec-2012 18:00

GeoWebCache (GWC) Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

GeoWebCache (GWC) Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Main Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

Main Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Open Web Service Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

Open Web Service Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Core Platform Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

Core Platform Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

REST Support Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

REST Support Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

REST Configuration Service Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

REST Configuration Service Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

GeoServer JDBC Security Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.security

GeoServer JDBC Security Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

GeoServer LDAP Security Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.security

GeoServer LDAP Security Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Web Coverage Service Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

Web Coverage Service Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Web Coverage Service 1.0 Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

Web Coverage Service 1.0 Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Web Coverage Service 1.1 Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

Web Coverage Service 1.1 Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Core UI Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.web

Core UI Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Demoes Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.web

Demoes Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

GWC UI Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.web

GWC UI Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Security UI Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.web

Security UI Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

WCS UI Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.web

WCS UI Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

WFS UI Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.web

WFS UI Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

WMS UI Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver.web

WMS UI Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Web Feature Service Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

Web Feature Service Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

04-Dec-2012 18:00

Web Map Service Module

c:/Program Files/Java/jdk1.6.0_31

cancellieri

The Open Planning Project

org.geoserver

Web Map Service Module

2.3-SNAPSHOT

2.3-SNAPSHOT

The Open Planning Project

1.0

core

Apache Maven

1.6.0_31

2.3-SNAPSHOT

Plexus Archiver

Cheers,
Carlo Cancellieri - GeoSolutions SAS

---

From: ccancellieri@anonymised.com
To: jdeolive@anonymised.com; andrea.aime@anonymised.com
Date: Thu, 29 Nov 2012 17:27:41 +0000
CC: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] REST Extensible and customizable versions report

Hy,
I’ll start a new branch soon introducing the pom changes and the core manifest bean loader to start looking into other options.Regards,
Carlo Cancellieri - GeoSolutions SAS

---

From: ccancellieri@anonymised.com…
To: jdeolive@anonymised.com
CC: geoserver-devel@lists.sourceforge.net
Subject: RE: [Geoserver-devel] REST Extensible and customizable versions report
Date: Thu, 29 Nov 2012 17:23:23 +0000

Justin,
my intention is to keep things as simple and modular as possible to easily backport this improvement to the 2.2.x.
so: (inline)

One question I have is how will the manifest lookup occur?
Will it be a simple lookup of all manifests on the classpath?

I don’t like to force users to add a specific package dependency only to use a marker interface. So:

• I chose the Manifest class as type to use for the lookup (but I don’t really like this, I’m still looking for a way to collect all the manifests files from the loaded jars… it should be possible from the spring context).
• loading the manifest file for the core (GeoServer, GeoTools) can be delegated to a new bean (no hands on core classes, just xml spring and one new class).

Then, to make extensions ready for this improvement we only have to update their pom.

Will there be some marker attribute used to define a jar as a geoserver plugin?

The REST api looks good.

ok

Also agree for the core|community|… type marker into the parents pom modules.

To limit the depth of the sealing I can try to see if sealing is supported by the maven jar plugin
http://docs.oracle.com/javase/1.4.2/docs/guide/extensions/spec.html#sealing

Introducing this we will also be able to check the jars sign and much more.

Cheers,
Carlo Cancellieri - GeoSolutions SAS

-Justin

On Thu, Nov 29, 2012 at 7:12 AM, Carlo Cancellieri <ccancellieri@anonymised.com…> wrote:

Hi all,
to complete the integration of GeoServer (and all of the installed plugin) into our continuous integration environment I need to provide a rest service to expose (at least):

… release (version)
… revision (svn tag or git hash)
… build date (optional)

for GeoServer and all of the installed extensions (f.e.):

… monitoring
… control flow

plus other custom plugins.

So I need to create an extensible mechanisms to provide those info. There are various possible approaches.
Here is my proposal based on java Manifest + maven and its plugins.

1. Each project or extension may register it’s Manifest bean into the spring context
2. For each GET request on the /rest/about[.format] path, a file in the ‘.format’ format will be returned listing all of the registered Manifest beans with all of the stored entries.
3. The output format can be produced using FreeMarker

Note also that this is an extensible and customisable approach:

1. Example on how to extend/customize:

I’ll setup for my custom plugin manifest entries adding hudson environment and build information using maven variables with:

org.apache.maven.plugins maven-jar-plugin true true ${project.build.finalname} ${project.version} ${iteration} ${maven.build.timestamp} ${BUILD_NUMBER} ${BUILD_ID} ${JOB_NAME} ${BUILD_TAG} ${EXECUTOR_NUMBER} ${JAVA_HOME} ${WORKSPACE} ${HUDSON_URL} ${SVN_REVISION} ${SVN_TAG}

The result will be a file with some more information (coming from my extension build) into the custom plugin section.

2. A simple example for geoserver with monitoring plugin installed into the lib dir:

doing a get on http://GEOSERVER/rest/about.xml (with username and password)

will result in something like:

..--SNAPSHOT ....--rc<</ daabbfaafbbfddbbbeffabbbb674bbbb1361ddd< --SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb145<< ..--SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb146<<

3. A simple example for geoserver with monitoring and my custom plugin installed into the lib dir:

get http://GEOSERVER/rest/about.xml

will result in something like:

..--SNAPSHOT ....--rc<</ daabbfaafbbfddbbbeffabbbb674bbbb1361ddd< --SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb145<< ..--SNAPSHOT ....--rc<</ fff8aaaf435477737fff915bbbc3862cccb146<< 1.0.--SNAPSHOT ....--rc<</ MyCustom ..--SNAPSHOT ... 9<< < GEO_TS_GEOSERVER_MyCustom_BUILD 2<< < .. ... http://.... r093<< REL_79<<

Note also that non maven project can still use this using their custom (ant?) mechanisms to update their /META-INF/MANIFEST.MF file.

What do you think about this? May I have to produce a proposal page? is it possible to have this on the 2.2.x branch (in the future)?

Ref.:
http://maven.apache.org/shared/maven-archiver/examples/manifest.html
http://docs.oracle.com/javase/…//docs/api/java/util/jar/Manifest.html
https://github.com/kevinsawicki/github-maven-example/blob/master/example/pom.xml

Cheers,
Carlo Cancellieri - GeoSolutions SAS

---

Keep yourself connected to Go Parallel:
VERIFY Test and improve your parallel project with help from experts
and peers. http://goparallel.sourceforge.net

---

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

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

------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@anonymised.comsts.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel

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

[Justin_Deoliveira]

On Wed, Dec 5, 2012 at 11:11 AM, Carlo Cancellieri <ccancellieri@anonymised.com

wrote:

Justin,

We can have many resources loaded into the class loader so I decided to
add minimal filtering capabilities to the request.

We support also search through:
- resource name (from-to
http://cio174:8080/geoserver/rest/about.xml?fromName=&lt;http://cio174:8080/geoserver/rest/about.xml?value=extension&gt;a&amp;toName=b
)

>Sorry, don't quite understand this one, what does fromName / toName
significy?

If you want, you can paginate the request using Alphabetical order (from
resource named 'a' to resource named 'b' ... and so on)

Ahh ok, that makes more sense.

- resource name regex http://cio174:8080/geoserver/rest/about.xml?value=extension&gt;regex=gt\.\*
)
- key (http://cio174:8080/geoserver/rest/about.xml?key=c&lt;http://cio174:8080/geoserver/rest/about.xml?value=extension&gt;ore
)
- value (http://cio174:8080/geoserver/rest/about.xml?value=extension )

> So the semantics is that any jar with a manifest entry named "core"
would be matched. And similarly for value any jar with a manfifest entry
whose value is "extension" would be matched?

Right, so when I add my set of extensions with mine specific key, I'll be
able to filter all but mine resources.

Here is a first commit to take a look:

https://github.com/ccancellieri/geoserver/compare/master-REST-manifest-version

> Anyways, looking quite nice.
> I think it would be good to sketch out the syntax/semantics of the rest
api in a proposal so we can use that as a center for discussion around
tweaking the api.

OK

> A couple of things off the top of my head:
> * rename "regex" to "resource", since it is matching soley on the
resource name correct?
> * we may want to break out a separate collection for specifically the
resources, in case we want to add other information as well, for example:

> - /rest/about/resources.xml -> what you include below

no prob

> - /rest/about/version.xml -> just the primary version info, what is
currently included on the about page
> That would leave it a bit more open ended in case we want to add more
info under "about".

To do so, I'm thinking to use the same model having something like:

<about>
<resource name="main-2.3-SNAPSHOT">
<Build-Time>04-Dec-2012 18:00</Build-Time>
<Implementation-Vendor>The Open Planning Project</Implementation-Vendor>
<Application-Version>2.3-SNAPSHOT</Application-Version>
<GeoServerModule>core</GeoServerModule>
</resource>
<resource name="gt-8.x-SNAPSHOT">
<Build-Time>04-Dec-2012 18:00</Build-Time>
<Implementation-Vendor>...</Implementation-Vendor>
<Application-Version>8.x-SNAPSHOT</Application-Version>
</resource>
</about>

Is this acceptable for you?'

Hmmm... so the idea is that to provide the basic version info we just
provide the resource representation for the geoserver main, geotools main,
and gwc core jars or something like that? That would indeed do it but i
guess i was thinking about something more direct like:

GET /rest/about/version.xml

<version>
  <GeoServer>
     <Version></Version>
     <BuildRevision></BuildRevision>
     <BuildTime></BuildTime>
  </GeoServer>
  <GeoTools>
     ...
  </GeoTools>
  <GeoWebCache>
     ...
  </GeoWebCache>
</version>

Basically the equivalent of what the current about page does.

Cheers,
Carlo Cancellieri - GeoSolutions SAS

Example 2:

http://cio174:8080/geoserver/rest/about.xml?value=core&key=GeoServerModule
<about>
<resource name="gwc-2.3-SNAPSHOT">
<Build-Time>04-Dec-2012 18:00</Build-Time>
<Implementation-Title>GeoWebCache (GWC) Module</Implementation-Title>
<HudsonJavaHome>c:/Program Files/Java/jdk1.6.0_31</HudsonJavaHome>
<Built-By>cancellieri</Built-By>
<Implementation-Vendor>The Open Planning Project</Implementation-Vendor>
<HudsonJobName/>
<Iteration-Name/>
<Implementation-Vendor-Id>org.geoserver</Implementation-Vendor-Id>
<HudsonWorkspace/>
<Specification-Title>GeoWebCache (GWC) Module</Specification-Title>
<Application-Version>2.3-SNAPSHOT</Application-Version>
<HudsonSvnRevision/>
<HudsonSvnTag/>
<Implementation-Version>2.3-SNAPSHOT</Implementation-Version>
<Application-Name/>
<Specification-Vendor>The Open Planning Project</Specification-Vendor>
<Manifest-Version>1.0</Manifest-Version>
<GeoServerModule>core</GeoServerModule>
<Created-By>Apache Maven</Created-By>
<HudsonBuildNumber/>
<HudsonUrl/>
<Build-Jdk>1.6.0_31</Build-Jdk>
<HudsonBuildId/>
<Specification-Version>2.3-SNAPSHOT</Specification-Version>
<HudsonExecutorNumber/>
<Archiver-Version>Plexus Archiver</Archiver-Version>
<HudsonBuildTag/>
</resource>
<resource name="main-2.3-SNAPSHOT">
<Build-Time>04-Dec-2012 18:00</Build-Time>
<Implementation-Title>Main Module</Implementation-Title>
<HudsonJavaHome>c:/Program Files/Java/jdk1.6.0_31</HudsonJavaHome>
<Built-By>cancellieri</Built-By>
<Implementation-Vendor>The Open Planning Project</Implementation-Vendor>
<HudsonJobName/>
<Iteration-Name/>
<Implementation-Vendor-Id>org.geoserver</Implementation-Vendor-Id>
<HudsonWorkspace/>
<Specification-Title>Main Module</Specification-Title>
<Application-Version>2.3-SNAPSHOT</Application-Version>
<HudsonSvnRevision/>
<HudsonSvnTag/>
<Implementation-Version>2.3-SNAPSHOT</Implementation-Version>
<Application-Name/>
<Specification-Vendor>The Open Planning Project</Specification-Vendor>
<Manifest-Version>1.0</Manifest-Version>
<GeoServerModule>core</GeoServerModule>
<Created-By>Apache Maven</Created-By>
<HudsonBuildNumber/>
<HudsonUrl/>
<Build-Jdk>1.6.0_31</Build-Jdk>
<HudsonBuildId/>
<Specification-Version>2.3-SNAPSHOT</Specification-Version>
<HudsonExecutorNumber/>
<Archiver-Version>Plexus Archiver</Archiver-Version>
<HudsonBuildTag/>
</resource>
<resource name="ows-2.3-SNAPSHOT">
<Build-Time>04-Dec-2012 18:00</Build-Time>
<Implementation-Title>Open Web Service Module</Implementation-Title>
<HudsonJavaHome>c:/Program Files/Java/jdk1.6.0_31</HudsonJavaHome>
<Built-By>cancellieri</Built-By>
<Implementation-Vendor>The Open Planning Project</Implementation-Vendor>
<HudsonJobName/>
<Iteration-Name/>
<Implementation-Vendor-Id>org.geoserver</Implementation-Vendor-Id>
<HudsonWorkspace/>
<Specification-Title>Open Web Service Module</Specification-Title>
<Application-Version>2.3-SNAPSHOT</Application-Version>
<HudsonSvnRevision/>
<HudsonSvnTag/>
<Implementation-Version>2.3-SNAPSHOT</Implementation-Version>
<Application-Name/>
<Specification-Vendor>The Open Planning Project</Specification-Vendor>
<Manifest-Version>1.0</Manifest-Version>
<GeoServerModule>core</GeoServerModule>
<Created-By>Apache Maven</Created-By>
<HudsonBuildNumber/>
<HudsonUrl/>
<Build-Jdk>1.6.0_31</Build-Jdk>
<HudsonBuildId/>
<Specification-Version>2.3-SNAPSHOT</Specification-Version>
<HudsonExecutorNumber/>
<Archiver-Version>Plexus Archiver</Archiver-Version>
<HudsonBuildTag/>
</resource>
<resource name="platform-2.3-SNAPSHOT">
<Build-Time>04-Dec-2012 18:00</Build-Time>
<Implementation-Title>Core Platform Module</Implementation-Title>
<HudsonJavaHome>c:/Program Files/Java/jdk1.6.0_31</HudsonJavaHome>
<Built-By>cancellieri</Built-By>
<Implementation-Vendor>The Open Planning Project</Implementation-Vendor>
<HudsonJobName/>
<Iteration-Name/>
<Implementation-Vendor-Id>org.geoserver</Implementation-Vendor-Id>
<HudsonWorkspace/>
<Specification-Title>Core Platform Module</Specification-Title>
<Application-Version>2.3-SNAPSHOT</Application-Version>
<HudsonSvnRevision/>
<HudsonSvnTag/>
<Implementation-Version>2.3-SNAPSHOT</Implementation-Version>
<Application-Name/>
<Specification-Vendor>The Open Planning Project</Specification-Vendor>
<Manifest-Version>1.0</Manifest-Version>
<GeoServerModule>core</GeoServerModule>
<Created-By>Apache Maven</Created-By>
<HudsonBuildNumber/>
<HudsonUrl/>
<Build-Jdk>1.6.0_31</Build-Jdk>
<HudsonBuildId/>
<Specification-Version>2.3-SNAPSHOT</Specification-Version>
<HudsonExecutorNumber/>
<Archiver-Version>Plexus Archiver</Archiver-Version>
<HudsonBuildTag/>
</resource>
<resource name="rest-2.3-SNAPSHOT">
<Build-Time>04-Dec-2012 18:00</Build-Time>
<Implementation-Title>REST Support Module</Implementation-Title>
<HudsonJavaHome>c:/Program Files/Java/jdk1.6.0_31</HudsonJavaHome>
<Built-By>cancellieri</Built-By>
<Implementation-Vendor>The Open Planning Project</Implementation-Vendor>
<HudsonJobName/>
<Iteration-Name/>
<Implementation-Vendor-Id>org.geoserver</Implementation-Vendor-Id>
<HudsonWorkspace/>
<Specification-Title>REST Support Module</Specification-Title>
<Application-Version>2.3-SNAPSHOT</Application-Version>
<HudsonSvnRevision/>
<HudsonSvnTag/>
<Implementation-Version>2.3-SNAPSHOT</Implementation-Version>
<Application-Name/>
<Specification-Vendor>The Open Planning Project</Specification-Vendor>
<Manifest-Version>1.0</Manifest-Version>
<GeoServerModule>core</GeoServerModule>
<Created-By>Apache Maven</Created-By>
<HudsonBuildNumber/>
<HudsonUrl/>
<Build-Jdk>1.6.0_31</Build-Jdk>
<HudsonBuildId/>
<Specification-Version>2.3-SNAPSHOT</Specification-Version>
<HudsonExecutorNumber/>
<Archiver-Version>Plexus Archiver</Archiver-Version>
<HudsonBuildTag/>
</resource>
<resource name="restconfig-2.3-SNAPSHOT">
<Build-Time>04-Dec-2012 18:00</Build-Time>
<Implementation-Title>REST Configuration Service Module
</Implementation-Title>
<HudsonJavaHome>c:/Program Files/Java/jdk1.6.0_31</HudsonJavaHome>
<Built-By>cancellieri</Built-By>
<Implementation-Vendor>The Open Planning Project</Implementation-Vendor>
<HudsonJobName/>
<Iteration-Name/>
<Implementation-Vendor-Id>org.geoserver</Implementation-Vendor-Id>
<HudsonWorkspace/>
<Specification-Title>REST Configuration Service Module
</Specification-Title>
<Application-Version>2.3-SNAPSHOT</Application-Version>
<HudsonSvnRevision/>
<HudsonSvnTag/>
<Implementation-Version>2.3-SNAPSHOT</Implementation-Version>
<Application-Name/>
<Specification-Vendor>The Open Planning Project</Specification-Vendor>
<Manifest-Version>1.0</Manifest-Version>
<GeoServerModule>core</GeoServerModule>
<Created-By>Apache Maven</Created-By>
<HudsonBuildNumber/>
<HudsonUrl/>
<Build-Jdk>1.6.0_31</Build-Jdk>
<HudsonBuildId/>
<Specification-Version>2.3-SNAPSHOT</Specification-Version>
<HudsonExecutorNumber/>
<Archiver-Version>Plexus Archiver</Archiver-Version>
<HudsonBuildTag/>
</resource>
<resource name="sec-jdbc-2.3-SNAPSHOT">
<Build-Time>04-Dec-2012 18:00</Build-Time>
<Implementation-Title>GeoServer JDBC Security Module
</Implementation-Title>
<HudsonJavaHome>c:/Program Files/Java/jdk1.6.0_31</HudsonJavaHome>
<Built-By>cancellieri</Built-By>
<Implementation-Vendor>The Open Planning Project</Implementation-Vendor>
<HudsonJobName/>
<Iteration-Name/>
<Implementation-Vendor-Id>org.geoserver.security
</Implementation-Vendor-Id>
<HudsonWorkspace/>
<Specification-Title>GeoServer JDBC Security Module</Specification-Title>
<Application-Version>2.3-SNAPSHOT</Application-Version>
<HudsonSvnRevision/>
<HudsonSvnTag/>
<Implementation-Version>2.3-SNAPSHOT</Implementation-Version>
<Application-Name/>
<Specification-Vendor>The Open Planning Project</Specification-Vendor>
<Manifest-Version>1.0</Manifest-Version>
<GeoServerModule>core</GeoServerModule>
<Created-By>Apache Maven</Created-By>
<HudsonBuildNumber/>
<HudsonUrl/>
<Build-Jdk>1.6.0_31</Build-Jdk>
<HudsonBuildId/>
<Specification-Version>2.3-SNAPSHOT</Specification-Version>
<HudsonExecutorNumber/>
<Archiver-Version>Plexus Archiver</Archiver-Version>
<HudsonBuildTag/>
</resource>
<resource name="sec-ldap-2.3-SNAPSHOT">
<Build-Time>04-Dec-2012 18:00</Build-Time>
<Implementation-Title>GeoServer LDAP Security Module
</Implementation-Title>
<HudsonJavaHome>c:/Program Files/Java/jdk1.6.0_31</HudsonJavaHome>
<Built-By>cancellieri</Built-By>
<Implementation-Vendor>The Open Planning Project</Implementation-Vendor>
<HudsonJobName/>
<Iteration-Name/>
<Implementation-Vendor-Id>org.geoserver.security
</Implementation-Vendor-Id>
<HudsonWorkspace/>
<Specification-Title>GeoServer LDAP Security Module</Specification-Title>
<Application-Version>2.3-SNAPSHOT</Application-Version>
<HudsonSvnRevision/>
<HudsonSvnTag/>
<Implementation-Version>2.3-SNAPSHOT</Implementation-Version>
<Application-Name/>
<Specification-Vendor>The Open Planning Project</Specification-Vendor>
<Manifest-Version>1.0</Manifest-Version>
<GeoServerModule>core</GeoServerModule>
<Created-By>Apache Maven</Created-By>
<HudsonBuildNumber/>
<HudsonUrl/>
<Build-Jdk>1.6.0_31</Build-Jdk>
<HudsonBuildId/>
<Specification-Version>2.3-SNAPSHOT</Specification-Version>
<HudsonExecutorNumber/>
<Archiver-Version>Plexus Archiver</Archiver-Version>
<HudsonBuildTag/>
</resource>
<resource name="wcs-2.3-SNAPSHOT">
<Build-Time>04-Dec-2012 18:00</Build-Time>
<Implementation-Title>Web Coverage Service Module</Implementation-Title>
<HudsonJavaHome>c:/Program Files/Java/jdk1.6.0_31</HudsonJavaHome>
<Built-By>cancellieri</Built-By>
<Implementation-Vendor>The Open Planning Project</Implementation-Vendor>
<HudsonJobName/>
<Iteration-Name/>
<Implementation-Vendor-Id>org.geoserver</Implementation-Vendor-Id>
<HudsonWorkspace/>
<Specification-Title>Web Coverage Service Module</Specification-Title>
<Application-Version>2.3-SNAPSHOT</Application-Version>
<HudsonSvnRevision/>
<HudsonSvnTag/>
<Implementation-Version>2.3-SNAPSHOT</Implementation-Version>
<Application-Name/>
<Specification-Vendor>The Open Planning Project</Specification-Vendor>
<Manifest-Version>1.0</Manifest-Version>
<GeoServerModule>core</GeoServerModule>
<Created-By>Apache Maven</Created-By>
<HudsonBuildNumber/>
<HudsonUrl/>
<Build-Jdk>1.6.0_31</Build-Jdk>
<HudsonBuildId/>
<Specification-Version>2.3-SNAPSHOT</Specification-Version>
<HudsonExecutorNumber/>
<Archiver-Version>Plexus Archiver</Archiver-Version>
<HudsonBuildTag/>
</resource>
<resource name="wcs1_0-2.3-SNAPSHOT">
<Build-Time>04-Dec-2012 18:00</Build-Time>
<Implementation-Title>Web Coverage Service 1.0 Module
</Implementation-Title>
<HudsonJavaHome>c:/Program Files/Java/jdk1.6.0_31</HudsonJavaHome>
<Built-By>cancellieri</Built-By>
<Implementation-Vendor>The Open Planning Project</Implementation-Vendor>
<HudsonJobName/>
<Iteration-Name/>
<Implementation-Vendor-Id>org.geoserver</Implementation-Vendor-Id>
<HudsonWorkspace/>
<Specification-Title>Web Coverage Service 1.0 Module</Specification-Title>
<Application-Version>2.3-SNAPSHOT</Application-Version>
<HudsonSvnRevision/>
<HudsonSvnTag/>
<Implementation-Version>2.3-SNAPSHOT</Implementation-Version>
<Application-Name/>
<Specification-Vendor>The Open Planning Project</Specification-Vendor>
<Manifest-Version>1.0</Manifest-Version>
<GeoServerModule>core</GeoServerModule>
<Created-By>Apache Maven</Created-By>
<HudsonBuildNumber/>
<HudsonUrl/>
<Build-Jdk>1.6.0_31</Build-Jdk>
<HudsonBuildId/>
<Specification-Version>2.3-SNAPSHOT</Specification-Version>
<HudsonExecutorNumber/>
<Archiver-Version>Plexus Archiver</Archiver-Version>
<HudsonBuildTag/>
</resource>
<resource name="wcs1_1-2.3-SNAPSHOT">
<Build-Time>04-Dec-2012 18:00</Build-Time>
<Implementation-Title>Web Coverage Service 1.1 Module
</Implementation-Title>
<HudsonJavaHome>c:/Program Files/Java/jdk1.6.0_31</HudsonJavaHome>
<Built-By>cancellieri</Built-By>
<Implementation-Vendor>The Open Planning Project</Implementation-Vendor>
<HudsonJobName/>
<Iteration-Name/>
<Implementation-Vendor-Id>org.geoserver</Implementation-Vendor-Id>
<HudsonWorkspace/>
<Specification-Title>Web Coverage Service 1.1 Module</Specification-Title>
<Application-Version>2.3-SNAPSHOT</Application-Version>
<HudsonSvnRevision/>
<HudsonSvnTag/>
<Implementation-Version>2.3-SNAPSHOT</Implementation-Version>
<Application-Name/>
<Specification-Vendor>The Open Planning Project</Specification-Vendor>
<Manifest-Version>1.0</Manifest-Version>
<GeoServerModule>core</GeoServerModule>
<Created-By>Apache Maven</Created-By>
<HudsonBuildNumber/>
<HudsonUrl/>
<Build-Jdk>1.6.0_31</Build-Jdk>
<HudsonBuildId/>
<Specification-Version>2.3-SNAPSHOT</Specification-Version>
<HudsonExecutorNumber/>
<Archiver-Version>Plexus Archiver</Archiver-Version>
<HudsonBuildTag/>
</resource>
<resource name="web-core-2.3-SNAPSHOT">
<Build-Time>04-Dec-2012 18:00</Build-Time>
<Implementation-Title>Core UI Module</Implementation-Title>
<HudsonJavaHome>c:/Program Files/Java/jdk1.6.0_31</HudsonJavaHome>
<Built-By>cancellieri</Built-By>
<Implementation-Vendor>The Open Planning Project</Implementation-Vendor>
<HudsonJobName/>
<Iteration-Name/>
<Implementation-Vendor-Id>org.geoserver.web</Implementation-Vendor-Id>
<HudsonWorkspace/>
<Specification-Title>Core UI Module</Specification-Title>
<Application-Version>2.3-SNAPSHOT</Application-Version>
<HudsonSvnRevision/>
<HudsonSvnTag/>
<Implementation-Version>2.3-SNAPSHOT</Implementation-Version>
<Application-Name/>
<Specification-Vendor>The Open Planning Project</Specification-Vendor>
<Manifest-Version>1.0</Manifest-Version>
<GeoServerModule>core</GeoServerModule>
<Created-By>Apache Maven</Created-By>
<HudsonBuildNumber/>
<HudsonUrl/>
<Build-Jdk>1.6.0_31</Build-Jdk>
<HudsonBuildId/>
<Specification-Version>2.3-SNAPSHOT</Specification-Version>
<HudsonExecutorNumber/>
<Archiver-Version>Plexus Archiver</Archiver-Version>
<HudsonBuildTag/>
</resource>
<resource name="web-demo-2.3-SNAPSHOT">
<Build-Time>04-Dec-2012 18:00</Build-Time>
<Implementation-Title>Demoes Module</Implementation-Title>
<HudsonJavaHome>c:/Program Files/Java/jdk1.6.0_31</HudsonJavaHome>
<Built-By>cancellieri</Built-By>
<Implementation-Vendor>The Open Planning Project</Implementation-Vendor>
<HudsonJobName/>
<Iteration-Name/>
<Implementation-Vendor-Id>org.geoserver.web</Implementation-Vendor-Id>
<HudsonWorkspace/>
<Specification-Title>Demoes Module</Specification-Title>
<Application-Version>2.3-SNAPSHOT</Application-Version>
<HudsonSvnRevision/>
<HudsonSvnTag/>
<Implementation-Version>2.3-SNAPSHOT</Implementation-Version>
<Application-Name/>
<Specification-Vendor>The Open Planning Project</Specification-Vendor>
<Manifest-Version>1.0</Manifest-Version>
<GeoServerModule>core</GeoServerModule>
<Created-By>Apache Maven</Created-By>
<HudsonBuildNumber/>
<HudsonUrl/>
<Build-Jdk>1.6.0_31</Build-Jdk>
<HudsonBuildId/>
<Specification-Version>2.3-SNAPSHOT</Specification-Version>
<HudsonExecutorNumber/>
<Archiver-Version>Plexus Archiver</Archiver-Version>
<HudsonBuildTag/>
</resource>
<resource name="web-gwc-2.3-SNAPSHOT">
<Build-Time>04-Dec-2012 18:00</Build-Time>
<Implementation-Title>GWC UI Module</Implementation-Title>
<HudsonJavaHome>c:/Program Files/Java/jdk1.6.0_31</HudsonJavaHome>
<Built-By>cancellieri</Built-By>
<Implementation-Vendor>The Open Planning Project</Implementation-Vendor>
<HudsonJobName/>
<Iteration-Name/>
<Implementation-Vendor-Id>org.geoserver.web</Implementation-Vendor-Id>
<HudsonWorkspace/>
<Specification-Title>GWC UI Module</Specification-Title>
<Application-Version>2.3-SNAPSHOT</Application-Version>
<HudsonSvnRevision/>
<HudsonSvnTag/>
<Implementation-Version>2.3-SNAPSHOT</Implementation-Version>
<Application-Name/>
<Specification-Vendor>The Open Planning Project</Specification-Vendor>
<Manifest-Version>1.0</Manifest-Version>
<GeoServerModule>core</GeoServerModule>
<Created-By>Apache Maven</Created-By>
<HudsonBuildNumber/>
<HudsonUrl/>
<Build-Jdk>1.6.0_31</Build-Jdk>
<HudsonBuildId/>
<Specification-Version>2.3-SNAPSHOT</Specification-Version>
<HudsonExecutorNumber/>
<Archiver-Version>Plexus Archiver</Archiver-Version>
<HudsonBuildTag/>
</resource>
<resource name="web-security-2.3-SNAPSHOT">
<Build-Time>04-Dec-2012 18:00</Build-Time>
<Implementation-Title>Security UI Module</Implementation-Title>
<HudsonJavaHome>c:/Program Files/Java/jdk1.6.0_31</HudsonJavaHome>
<Built-By>cancellieri</Built-By>
<Implementation-Vendor>The Open Planning Project</Implementation-Vendor>
<HudsonJobName/>
<Iteration-Name/>
<Implementation-Vendor-Id>org.geoserver.web</Implementation-Vendor-Id>
<HudsonWorkspace/>
<Specification-Title>Security UI Module</Specification-Title>
<Application-Version>2.3-SNAPSHOT</Application-Version>
<HudsonSvnRevision/>
<HudsonSvnTag/>
<Implementation-Version>2.3-SNAPSHOT</Implementation-Version>
<Application-Name/>
<Specification-Vendor>The Open Planning Project</Specification-Vendor>
<Manifest-Version>1.0</Manifest-Version>
<GeoServerModule>core</GeoServerModule>
<Created-By>Apache Maven</Created-By>
<HudsonBuildNumber/>
<HudsonUrl/>
<Build-Jdk>1.6.0_31</Build-Jdk>
<HudsonBuildId/>
<Specification-Version>2.3-SNAPSHOT</Specification-Version>
<HudsonExecutorNumber/>
<Archiver-Version>Plexus Archiver</Archiver-Version>
<HudsonBuildTag/>
</resource>
<resource name="web-wcs-2.3-SNAPSHOT">
<Build-Time>04-Dec-2012 18:00</Build-Time>
<Implementation-Title>WCS UI Module</Implementation-Title>
<HudsonJavaHome>c:/Program Files/Java/jdk1.6.0_31</HudsonJavaHome>
<Built-By>cancellieri</Built-By>
<Implementation-Vendor>The Open Planning Project</Implementation-Vendor>
<HudsonJobName/>
<Iteration-Name/>
<Implementation-Vendor-Id>org.geoserver.web</Implementation-Vendor-Id>
<HudsonWorkspace/>
<Specification-Title>WCS UI Module</Specification-Title>
<Application-Version>2.3-SNAPSHOT</Application-Version>
<HudsonSvnRevision/>
<HudsonSvnTag/>
<Implementation-Version>2.3-SNAPSHOT</Implementation-Version>
<Application-Name/>
<Specification-Vendor>The Open Planning Project</Specification-Vendor>
<Manifest-Version>1.0</Manifest-Version>
<GeoServerModule>core</GeoServerModule>
<Created-By>Apache Maven</Created-By>
<HudsonBuildNumber/>
<HudsonUrl/>
<Build-Jdk>1.6.0_31</Build-Jdk>
<HudsonBuildId/>
<Specification-Version>2.3-SNAPSHOT</Specification-Version>
<HudsonExecutorNumber/>
<Archiver-Version>Plexus Archiver</Archiver-Version>
<HudsonBuildTag/>
</resource>
<resource name="web-wfs-2.3-SNAPSHOT">
<Build-Time>04-Dec-2012 18:00</Build-Time>
<Implementation-Title>WFS UI Module</Implementation-Title>
<HudsonJavaHome>c:/Program Files/Java/jdk1.6.0_31</HudsonJavaHome>
<Built-By>cancellieri</Built-By>
<Implementation-Vendor>The Open Planning Project</Implementation-Vendor>
<HudsonJobName/>
<Iteration-Name/>
<Implementation-Vendor-Id>org.geoserver.web</Implementation-Vendor-Id>
<HudsonWorkspace/>
<Specification-Title>WFS UI Module</Specification-Title>
<Application-Version>2.3-SNAPSHOT</Application-Version>
<HudsonSvnRevision/>
<HudsonSvnTag/>
<Implementation-Version>2.3-SNAPSHOT</Implementation-Version>
<Application-Name/>
<Specification-Vendor>The Open Planning Project</Specification-Vendor>
<Manifest-Version>1.0</Manifest-Version>
<GeoServerModule>core</GeoServerModule>
<Created-By>Apache Maven</Created-By>
<HudsonBuildNumber/>
<HudsonUrl/>
<Build-Jdk>1.6.0_31</Build-Jdk>
<HudsonBuildId/>
<Specification-Version>2.3-SNAPSHOT</Specification-Version>
<HudsonExecutorNumber/>
<Archiver-Version>Plexus Archiver</Archiver-Version>
<HudsonBuildTag/>
</resource>
<resource name="web-wms-2.3-SNAPSHOT">
<Build-Time>04-Dec-2012 18:00</Build-Time>
<Implementation-Title>WMS UI Module</Implementation-Title>
<HudsonJavaHome>c:/Program Files/Java/jdk1.6.0_31</HudsonJavaHome>
<Built-By>cancellieri</Built-By>
<Implementation-Vendor>The Open Planning Project</Implementation-Vendor>
<HudsonJobName/>
<Iteration-Name/>
<Implementation-Vendor-Id>org.geoserver.web</Implementation-Vendor-Id>
<HudsonWorkspace/>
<Specification-Title>WMS UI Module</Specification-Title>
<Application-Version>2.3-SNAPSHOT</Application-Version>
<HudsonSvnRevision/>
<HudsonSvnTag/>
<Implementation-Version>2.3-SNAPSHOT</Implementation-Version>
<Application-Name/>
<Specification-Vendor>The Open Planning Project</Specification-Vendor>
<Manifest-Version>1.0</Manifest-Version>
<GeoServerModule>core</GeoServerModule>
<Created-By>Apache Maven</Created-By>
<HudsonBuildNumber/>
<HudsonUrl/>
<Build-Jdk>1.6.0_31</Build-Jdk>
<HudsonBuildId/>
<Specification-Version>2.3-SNAPSHOT</Specification-Version>
<HudsonExecutorNumber/>
<Archiver-Version>Plexus Archiver</Archiver-Version>
<HudsonBuildTag/>
</resource>
<resource name="wfs-2.3-SNAPSHOT">
<Build-Time>04-Dec-2012 18:00</Build-Time>
<Implementation-Title>Web Feature Service Module</Implementation-Title>
<HudsonJavaHome>c:/Program Files/Java/jdk1.6.0_31</HudsonJavaHome>
<Built-By>cancellieri</Built-By>
<Implementation-Vendor>The Open Planning Project</Implementation-Vendor>
<HudsonJobName/>
<Iteration-Name/>
<Implementation-Vendor-Id>org.geoserver</Implementation-Vendor-Id>
<HudsonWorkspace/>
<Specification-Title>Web Feature Service Module</Specification-Title>
<Application-Version>2.3-SNAPSHOT</Application-Version>
<HudsonSvnRevision/>
<HudsonSvnTag/>
<Implementation-Version>2.3-SNAPSHOT</Implementation-Version>
<Application-Name/>
<Specification-Vendor>The Open Planning Project</Specification-Vendor>
<Manifest-Version>1.0</Manifest-Version>
<GeoServerModule>core</GeoServerModule>
<Created-By>Apache Maven</Created-By>
<HudsonBuildNumber/>
<HudsonUrl/>
<Build-Jdk>1.6.0_31</Build-Jdk>
<HudsonBuildId/>
<Specification-Version>2.3-SNAPSHOT</Specification-Version>
<HudsonExecutorNumber/>
<Archiver-Version>Plexus Archiver</Archiver-Version>
<HudsonBuildTag/>
</resource>
<resource name="wms-2.3-SNAPSHOT">
<Build-Time>04-Dec-2012 18:00</Build-Time>
<Implementation-Title>Web Map Service Module</Implementation-Title>
<HudsonJavaHome>c:/Program Files/Java/jdk1.6.0_31</HudsonJavaHome>
<Built-By>cancellieri</Built-By>
<Implementation-Vendor>The Open Planning Project</Implementation-Vendor>
<HudsonJobName/>
<Iteration-Name/>
<Implementation-Vendor-Id>org.geoserver</Implementation-Vendor-Id>
<HudsonWorkspace/>
<Specification-Title>Web Map Service Module</Specification-Title>
<Application-Version>2.3-SNAPSHOT</Application-Version>
<HudsonSvnRevision/>
<HudsonSvnTag/>
<Implementation-Version>2.3-SNAPSHOT</Implementation-Version>
<Application-Name/>
<Specification-Vendor>The Open Planning Project</Specification-Vendor>
<Manifest-Version>1.0</Manifest-Version>
<GeoServerModule>core</GeoServerModule>
<Created-By>Apache Maven</Created-By>
<HudsonBuildNumber/>
<HudsonUrl/>
<Build-Jdk>1.6.0_31</Build-Jdk>
<HudsonBuildId/>
<Specification-Version>2.3-SNAPSHOT</Specification-Version>
<HudsonExecutorNumber/>
<Archiver-Version>Plexus Archiver</Archiver-Version>
<HudsonBuildTag/>
</resource>
</about>

Cheers,
Carlo Cancellieri - GeoSolutions SAS

------------------------------
From: ccancellieri@anonymised.com
To: jdeolive@anonymised.com; andrea.aime@anonymised.com
Date: Thu, 29 Nov 2012 17:27:41 +0000
CC: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] REST Extensible and customizable versions
report

Hy,
I'll start a new branch soon introducing the pom changes and the core
manifest bean loader to start looking into other options.
Regards,
Carlo Cancellieri - GeoSolutions SAS

------------------------------
From: ccancellieri@anonymised.com
To: jdeolive@anonymised.com
CC: geoserver-devel@lists.sourceforge.net
Subject: RE: [Geoserver-devel] REST Extensible and customizable versions
report
Date: Thu, 29 Nov 2012 17:23:23 +0000

Justin,
   my intention is to keep things as simple and modular as possible to
easily backport this improvement to the 2.2.x.
so: (inline)

> One question I have is how will the manifest lookup occur?
> Will it be a simple lookup of all manifests on the classpath?

I don't like to force users to add a specific package dependency only to
use a marker interface. So:
- I chose the Manifest class as type to use for the lookup (but I don't
really like this, I'm still looking for a way to collect all the manifests
files from the loaded jars... it should be possible from the spring
context).
- loading the manifest file for the core (GeoServer, GeoTools) can be
delegated to a new bean (no hands on core classes, just xml spring and one
new class).

Then, to make extensions ready for this improvement we only have to update
their pom.

> Will there be some marker attribute used to define a jar as a geoserver
plugin?

> The REST api looks good.

ok

Also agree for the core|community|... type marker into the parents pom
modules.

To limit the depth of the sealing I can try to see if sealing is supported
by the maven jar plugin
http://docs.oracle.com/javase/1.4.2/docs/guide/extensions/spec.html#sealing

Introducing this we will also be able to check the jars sign and much more.

Cheers,
Carlo Cancellieri - GeoSolutions SAS

-Justin

On Thu, Nov 29, 2012 at 7:12 AM, Carlo Cancellieri <
ccancellieri@anonymised.com> wrote:

Hi all,
to complete the integration of GeoServer (and all of the installed
plugin) into our continuous integration environment I need to provide a
rest service to expose (at least):

.. release (version)
.. revision (svn tag or git hash)
.. build date (optional)

for GeoServer and all of the installed extensions (f.e.):

.. monitoring
.. control flow

plus other custom plugins.

So I need to create an extensible mechanisms to provide those info. There
are various possible approaches.
Here is my proposal based on java Manifest + maven and its plugins.

1. Each project or extension may register it's Manifest bean into the
spring context
2. For each GET request on the /rest/about[.format] path, a file in the
'.format' format will be returned listing all of the registered Manifest
beans with all of the stored entries.
3. The output format can be produced using FreeMarker

Note also that this is an extensible and customisable approach:

1. Example on how to extend/customize:

I'll setup for my custom plugin manifest entries adding hudson environment
and build information using maven variables with:

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifest>
  <addDefaultImplementationEntries>true</addDefaultImplementationEntries>
  <addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
</manifest>
<manifestEntries>
<Application-Name>${project.build.finalname}</Application-Name>
<Application-Version>${project.version}</Application-Version>
<Iteration-Name>${iteration}</Iteration-Name>
<Build-Time>${maven.build.timestamp}</Build-Time>
<HudsonBuildNumber>${BUILD_NUMBER}</HudsonBuildNumber>
<HudsonBuildId>${BUILD_ID}</HudsonBuildId>
<HudsonJobName>${JOB_NAME}</HudsonJobName>
<HudsonBuildTag>${BUILD_TAG}</HudsonBuildTag>
<HudsonExecutorNumber>${EXECUTOR_NUMBER}</HudsonExecutorNumber>
<HudsonJavaHome>${JAVA_HOME}</HudsonJavaHome>
<HudsonWorkspace>${WORKSPACE}</HudsonWorkspace>
<HudsonUrl>${HUDSON_URL}</HudsonUrl>
<HudsonSvnRevision>${SVN_REVISION}</HudsonSvnRevision>
<HudsonSvnTag>${SVN_TAG}</HudsonSvnTag>
</manifestEntries>
</archive>
</configuration>
</plugin>

The result will be a file with some more information (coming from my
extension build) into the custom plugin section.

2. A simple example for geoserver with monitoring plugin installed into
the lib dir:

doing a get on http://GEOSERVER/rest/about.xml (with username and
password)

will result in something like:

<about>
<GeoServer>
<Project-version>..--SNAPSHOT</Project-version>
<Build-Jdk>....--rc<</<Build-Jdk>

<Project-revision>daabbfaafbbfddbbbeffabbbb674bbbb1361ddd<</Project-revision>
</GeoServer>
<GeoTools>
<Project-version>--SNAPSHOT</Project-version>
<Build-Jdk>....--rc<</<Build-Jdk>

<Project-revision>fff8aaaf435477737fff915bbbc3862cccb145<<</Project-revision>
</GeoTools>
<Monitoring>
<Project-version>..--SNAPSHOT</Project-version>
<Build-Jdk>....--rc<</<Build-Jdk>

<Project-revision>fff8aaaf435477737fff915bbbc3862cccb146<<</Project-revision>
</Monitoring>
</about>

3. A simple example for geoserver with monitoring and my custom plugin
installed into the lib dir:

get http://GEOSERVER/rest/about.xml

will result in something like:

<about>
<GeoServer>
<Project-version>..--SNAPSHOT</Project-version>
<Build-Jdk>....--rc<</<Build-Jdk>

<Project-revision>daabbfaafbbfddbbbeffabbbb674bbbb1361ddd<</Project-revision>
</GeoServer>
<GeoTools>
<Project-version>--SNAPSHOT</Project-version>
<Build-Jdk>....--rc<</<Build-Jdk>

<Project-revision>fff8aaaf435477737fff915bbbc3862cccb145<<</Project-revision>
</GeoTools>
<Monitoring>
<Project-version>..--SNAPSHOT</Project-version>
<Build-Jdk>....--rc<</<Build-Jdk>

<Project-revision>fff8aaaf435477737fff915bbbc3862cccb146<<</Project-revision>
</Monitoring>
<MyCustom>
<Project-version>1.0.--SNAPSHOT</Project-version>
<Build-Jdk>....--rc<</<Build-Jdk>
  <Application-Name>MyCustom</Application-Name>
  <Application-Version>..--SNAPSHOT</Application-Version>
  <Build-Time>...</Build-Time>
  <HudsonBuildNumber>9<<</HudsonBuildNumber>
  <HudsonBuildId><</HudsonBuildId>
  <HudsonJobName>GEO_TS_GEOSERVER_MyCustom_BUILD</HudsonJobName>
  <HudsonBuildTag>2<<</HudsonBuildTag>
  <HudsonExecutorNumber><</HudsonExecutorNumber>
  <HudsonJavaHome>..</HudsonJavaHome>
  <HudsonWorkspace>...</HudsonWorkspace>
  <HudsonUrl>http://…</HudsonUrl>
  <HudsonSvnRevision>r093<<</HudsonSvnRevision>
  <HudsonSvnTag>REL_79<<</HudsonSvnTag>
</MyCustom>
</about>

Note also that non maven project can still use this using their custom
(ant?) mechanisms to update their /META-INF/MANIFEST.MF file.

What do you think about this? May I have to produce a proposal page? is it
possible to have this on the 2.2.x branch (in the future)?

Ref.:
http://maven.apache.org/shared/maven-archiver/examples/manifest.html
http://docs.oracle.com/javase/....//docs/api/java/util/jar/Manifest.html

https://github.com/kevinsawicki/github-maven-example/blob/master/example/pom.xml

Cheers,
Carlo Cancellieri - GeoSolutions SAS

------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
VERIFY Test and improve your parallel project with help from experts
and peers. http://goparallel.sourceforge.net
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

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

------------------------------------------------------------------------------
Keep yourself connected to Go Parallel: VERIFY Test and improve your
parallel project with help from experts and peers.
http://goparallel.sourceforge.net
_______________________________________________ Geoserver-devel mailing
list Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

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

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

[Andrea_Aime4]

On Wed, Dec 5, 2012 at 7:11 PM, Carlo Cancellieri <ccancellieri@anonymised.com…> wrote:

Justin,

We can have many resources loaded into the class loader so I decided to add minimal filtering capabilities to the request.

We support also search through:

• resource name (from-to http://cio174:8080/geoserver/rest/about.xml?fromName=a&toName=b )

Sorry, don’t quite understand this one, what does fromName / toName significy?

If you want, you can paginate the request using Alphabetical order (from resource named ‘a’ to resource named ‘b’ … and so on)

Hmm… I know we’re talking about small amounts of information here, but wouldn’t it be better
to separate filtering and paging?
Regexp and other means for filtering, paging though the usual startIndex and maxItems constructs?
(assuming there is even a need to page stuff, we’re in the ballpark of 100 items today, right?)

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---

[Justin_Deoliveira]

On Thu, Dec 6, 2012 at 1:36 AM, Andrea Aime <andrea.aime@anonymised.com>wrote:

On Wed, Dec 5, 2012 at 7:11 PM, Carlo Cancellieri <
ccancellieri@anonymised.com> wrote:

Justin,

We can have many resources loaded into the class loader so I decided to
add minimal filtering capabilities to the request.

We support also search through:
- resource name (from-to
http://cio174:8080/geoserver/rest/about.xml?fromName=&lt;http://cio174:8080/geoserver/rest/about.xml?value=extension&gt;a&amp;toName=b
)

>Sorry, don't quite understand this one, what does fromName / toName
significy?

If you want, you can paginate the request using Alphabetical order (from
resource named 'a' to resource named 'b' ... and so on)

Hmm.. I know we're talking about small amounts of information here, but
wouldn't it be better
to separate filtering and paging?
Regexp and other means for filtering, paging though the usual startIndex
and maxItems constructs?
(assuming there is even a need to page stuff, we're in the ballpark of 100
items today, right?)

Agreed. Actually paging is something i have been looking at adding to the
catalog portion of the rest api as well.

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

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

[Carlo_Cancellieri1]

Proposal:

http://geoserver.org/pages/viewpage.action?pageId=55574531

---

Date: Thu, 6 Dec 2012 08:11:36 -0700
Subject: Re: [Geoserver-devel] REST Extensible and customizable versions report
From: jdeolive@anonymised.com
To: andrea.aime@anonymised.com
CC: ccancellieri@anonymised.com; geoserver-devel@lists.sourceforge.net

On Thu, Dec 6, 2012 at 1:36 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Wed, Dec 5, 2012 at 7:11 PM, Carlo Cancellieri <ccancellieri@anonymised.com> wrote:

Justin,

We can have many resources loaded into the class loader so I decided to add minimal filtering capabilities to the request.

We support also search through:

• resource name (from-to http://cio174:8080/geoserver/rest/about.xml?fromName=a&toName=b )

Sorry, don’t quite understand this one, what does fromName / toName significy?

If you want, you can paginate the request using Alphabetical order (from resource named ‘a’ to resource named ‘b’ … and so on)

Hmm… I know we’re talking about small amounts of information here, but wouldn’t it be better
to separate filtering and paging?
Regexp and other means for filtering, paging though the usual startIndex and maxItems constructs?
(assuming there is even a need to page stuff, we’re in the ballpark of 100 items today, right?)

Agreed. Actually paging is something i have been looking at adding to the catalog portion of the rest api as well.

Cheers

Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---

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