[Geoserver-devel] JP2K on Geoserver

GeoServer GeoServer Developer
1

Hi list,
as some of you have noticed on the geotools mailing list, we are working to move the jp2k geotools plugin to supported land.
Next step we wish to do, it’s let geoserver support jp2k data via that plugin.
Taking a look on the Geoserver’s developer guide, I see that before adding a new module to geoserver, we should define a new community module and then it need to be promoted afterwards to a superior-level land (core/extension).
However, we dont need to define a new set of classes/entities to be added to geoserver. We instead need to add only a new dependency to geoserver itself by updating the poms. For that reason, could be sufficient to add an extension module to include the proper dependencies?
Please, let us know.

Best regards.
Daniele

–

Eng. Daniele Romagnoli
Software Engineer

GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267

http://www.geo-solutions.it

2

Hi guys, to simplify,
we are talking about adding a new coverage plugin to geoserver for
reading (and in the near future writing) jpeg2000 imagery. This would
rely on kakadu binaries if avalaible otherwise it will fallback onto
jai imageio standard plugins.

Me and Daniele were trying to understand which is the best path to get
this inside GeoServer. Notice that we are targeting 2.0.x and trunk
for the moment, 1.7.x is not an objective. Feedback?

Simone.
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://simboss.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini

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

On Mon, Nov 16, 2009 at 2:54 PM, Daniele Romagnoli
<daniele.romagnoli@anonymised.com> wrote:

Hi list,
as some of you have noticed on the geotools mailing list, we are working to
move the jp2k geotools plugin to supported land.
Next step we wish to do, it's let geoserver support jp2k data via that
plugin.
Taking a look on the Geoserver's developer guide, I see that before adding a
new module to geoserver, we should define a new community module and then it
need to be promoted afterwards to a superior-level land (core/extension).
However, we dont need to define a new set of classes/entities to be added to
geoserver. We instead need to add only a new dependency to geoserver itself
by updating the poms. For that reason, could be sufficient to add an
extension module to include the proper dependencies?
Please, let us know.

Best regards.
Daniele

--
-------------------------------------------------------
Eng. Daniele Romagnoli
Software Engineer

GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267

http://www.geo-solutions.it

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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

3

I guess being only a plug-in consisting of dependencies does not leave much of anything to do with regard to getting it to supported status. That said extensions also relay a sense of stability, so having it hang out in community not be a bad idea while setting up, and then once fully working move it over. There is also documentation, etc... that is also required.

Anyways, a decision for the PSC I guess but I personally would be fine with seeing it go straight to extension if all the other requirements are met.

2c.

-Justin

Simone Giannecchini wrote:

Hi guys, to simplify,
we are talking about adding a new coverage plugin to geoserver for
reading (and in the near future writing) jpeg2000 imagery. This would
rely on kakadu binaries if avalaible otherwise it will fallback onto
jai imageio standard plugins.

Me and Daniele were trying to understand which is the best path to get
this inside GeoServer. Notice that we are targeting 2.0.x and trunk
for the moment, 1.7.x is not an objective. Feedback?

Simone.
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://simboss.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini

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

On Mon, Nov 16, 2009 at 2:54 PM, Daniele Romagnoli
<daniele.romagnoli@anonymised.com> wrote:

Hi list,
as some of you have noticed on the geotools mailing list, we are working to
move the jp2k geotools plugin to supported land.
Next step we wish to do, it's let geoserver support jp2k data via that
plugin.
Taking a look on the Geoserver's developer guide, I see that before adding a
new module to geoserver, we should define a new community module and then it
need to be promoted afterwards to a superior-level land (core/extension).
However, we dont need to define a new set of classes/entities to be added to
geoserver. We instead need to add only a new dependency to geoserver itself
by updating the poms. For that reason, could be sufficient to add an
extension module to include the proper dependencies?
Please, let us know.

Best regards.
Daniele

--
-------------------------------------------------------
Eng. Daniele Romagnoli
Software Engineer

GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267

http://www.geo-solutions.it

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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
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.

4

Hi Justin,
From your email I didn’t understood what I should do to proceed.
On the basis of your last sentence, can I setup a new extension?
Please, let me know.

Best Regards,
Daniele

On Mon, Nov 16, 2009 at 7:25 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

I guess being only a plug-in consisting of dependencies does not leave much of anything to do with regard to getting it to supported status. That said extensions also relay a sense of stability, so having it hang out in community not be a bad idea while setting up, and then once fully working move it over. There is also documentation, etc… that is also required.

Anyways, a decision for the PSC I guess but I personally would be fine with seeing it go straight to extension if all the other requirements are met.

2c.

-Justin

Simone Giannecchini wrote:

Hi guys, to simplify,
we are talking about adding a new coverage plugin to geoserver for
reading (and in the near future writing) jpeg2000 imagery. This would
rely on kakadu binaries if avalaible otherwise it will fallback onto
jai imageio standard plugins.

Me and Daniele were trying to understand which is the best path to get
this inside GeoServer. Notice that we are targeting 2.0.x and trunk
for the moment, 1.7.x is not an objective. Feedback?

Simone.

Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://simboss.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini

On Mon, Nov 16, 2009 at 2:54 PM, Daniele Romagnoli
<daniele.romagnoli@anonymised.com> wrote:

Hi list,
as some of you have noticed on the geotools mailing list, we are working to
move the jp2k geotools plugin to supported land.
Next step we wish to do, it’s let geoserver support jp2k data via that
plugin.
Taking a look on the Geoserver’s developer guide, I see that before adding a
new module to geoserver, we should define a new community module and then it
need to be promoted afterwards to a superior-level land (core/extension).
However, we dont need to define a new set of classes/entities to be added to
geoserver. We instead need to add only a new dependency to geoserver itself
by updating the poms. For that reason, could be sufficient to add an
extension module to include the proper dependencies?
Please, let us know.

Best regards.
Daniele

–

Eng. Daniele Romagnoli
Software Engineer

GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267

http://www.geo-solutions.it

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what’s new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july

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

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what’s new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july

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.

–

Eng. Daniele Romagnoli
Software Engineer

GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267

http://www.geo-solutions.it

5

Daniele Romagnoli ha scritto:

Hi Justin,
From your email I didn't understood what I should do to proceed.
On the basis of your last sentence, can I setup a new extension?
Please, let me know.

If it matches all the requirements for an extension (documented,
maintained, good code coverage, in this case in GeoTools) I would
go for an extension directly. +1

Just have a look at how the extension is setup for Oracle, DB2 and
other modules that in fact just add a dependency.
Usually it boils down to:
- adding a pure pom.xml module in the extension directory
- add a packaging xml in release and reference it from the main pom
- add a profile in web-app so that the extra dependency is added to
   web-app when one wants to try it out in her dev env.

I know it's more painful, but if you look at it, you'll see that
the modules GeoServer offer in core have a long standing reputation
for being stable and used by a wide use base, and are fully functional
without the need of license encoumbered extensions (think Oracle and
SDE, they have been quite stable for over one year so far, but they're
probably never going to make it into core due to the licensing issues
the carry).

Cheers
Andrea

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

6

Ciao Andrea,
things are a little different with what happens with oracle and arsde
for 2 reasons:

1> this plugin uses Kakadu only if it is available else, it falls
back on the standard JAI ImageIO plugins
2> this plugin will be referenced by the mosaic pom since I intend to
use it for building and serving JPEG2K mosaics, therefore once we
bring it into supported status it will be silently dragged in by the
mosaic plugin as it happened for GDAL. And on the same line, if the
Kakadu SDK won't be around it will be working with just the standard
ImageIO plugins for Jpeg2k.

Feedback?

Simone.

-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://simboss.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini

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

On Tue, Nov 17, 2009 at 10:11 AM, Andrea Aime <aaime@anonymised.com> wrote:

Daniele Romagnoli ha scritto:

Hi Justin,
From your email I didn't understood what I should do to proceed.
On the basis of your last sentence, can I setup a new extension?
Please, let me know.

If it matches all the requirements for an extension (documented,
maintained, good code coverage, in this case in GeoTools) I would
go for an extension directly. +1

Just have a look at how the extension is setup for Oracle, DB2 and
other modules that in fact just add a dependency.
Usually it boils down to:
- adding a pure pom.xml module in the extension directory
- add a packaging xml in release and reference it from the main pom
- add a profile in web-app so that the extra dependency is added to
web-app when one wants to try it out in her dev env.

I know it's more painful, but if you look at it, you'll see that
the modules GeoServer offer in core have a long standing reputation
for being stable and used by a wide use base, and are fully functional
without the need of license encoumbered extensions (think Oracle and
SDE, they have been quite stable for over one year so far, but they're
probably never going to make it into core due to the licensing issues
the carry).

Cheers
Andrea

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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

7

Simone Giannecchini ha scritto:

Ciao Andrea,
things are a little different with what happens with oracle and arsde
for 2 reasons:

1> this plugin uses Kakadu only if it is available else, it falls
back on the standard JAI ImageIO plugins

But it's a new plugin. Seasoning it a bit in extensions is a good thing,
even if it's just for a few releases like with the security UI.

About the fallback on JAI, is it already there?
I understand it's a way to give J2K support for free, but at
the same time it's a liability, the JAI plugin loads everything into memory undermining the overall GS stability (trying to actually use
it will easily bring GS close to the OOM).
Good for demos, but if one plans to actually use it in production... ugh!

2> this plugin will be referenced by the mosaic pom since I intend to
use it for building and serving JPEG2K mosaics, therefore once we
bring it into supported status it will be silently dragged in by the
mosaic plugin as it happened for GDAL. And on the same line, if the
Kakadu SDK won't be around it will be working with just the standard
ImageIO plugins for Jpeg2k.

Feedback?

Right, the GDAL extensions sneaked in dodging the normal evolution
of a GS functionality (community -> extension -> core).
Which is really not good and not necessary either.
The mosaic plugin could be imported adding transitive dependency
exclusions towards GDAL and J2K and should be still working, right?

Following the process that the PSC voted
http://geoserver.org/display/GEOS/GSIP+22+-+Community+Modules
is maybe slower but it's something that cannot raise objections.

Cheers
Andrea

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

8

On Tue, Nov 17, 2009 at 10:31 AM, Andrea Aime <aaime@anonymised.com> wrote:

Simone Giannecchini ha scritto:

Ciao Andrea,
things are a little different with what happens with oracle and arsde
for 2 reasons:

1> this plugin uses Kakadu only if it is available else, it falls
back on the standard JAI ImageIO plugins

But it's a new plugin. Seasoning it a bit in extensions is a good thing,
even if it's just for a few releases like with the security UI.

Np about that.

About the fallback on JAI, is it already there?

Y, see http://docs.codehaus.org/display/GEOTDOC/JP2K+plugin and
http://docs.codehaus.org/display/GEOTOOLS/JP2K+Plugin

I understand it's a way to give J2K support for free, but at
the same time it's a liability, the JAI plugin loads everything into
memory undermining the overall GS stability (trying to actually use
it will easily bring GS close to the OOM).
Good for demos, but if one plans to actually use it in production... ugh!

Well, things are a little bit different than that, but nevertheless
the result is that the standard JAI ImageIO plugins are not really
suitable for serving large JPEG2K raster. That is why we have added
support for Kakadu.

2> this plugin will be referenced by the mosaic pom since I intend to
use it for building and serving JPEG2K mosaics, therefore once we
bring it into supported status it will be silently dragged in by the
mosaic plugin as it happened for GDAL. And on the same line, if the
Kakadu SDK won't be around it will be working with just the standard
ImageIO plugins for Jpeg2k.

Feedback?

Right, the GDAL extensions sneaked in dodging the normal evolution
of a GS functionality (community -> extension -> core).
Which is really not good and not necessary either.
The mosaic plugin could be imported adding transitive dependency
exclusions towards GDAL and J2K and should be still working, right?

It is not as easy as that, we would have to modify a bit more the
Mosaic plugin code since it needs to know what is available and what
is not to set predences for the various plugins serving the same
format. So if we exclude some dependencies it will throw
class_not_found errors when running in geoserver.
Daniele is trying to work this around for the Kakadu plugin so that,
for the moment, we won't be adding the kakadu plugin as a straight
dependency to both geoserver and kakadu.

Ciao,
Simone.

Following the process that the PSC voted
http://geoserver.org/display/GEOS/GSIP+22+-+Community+Modules
is maybe slower but it's something that cannot raise objections.

Cheers
Andrea

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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

9

Hi all,
I’have locally created a new geoserver extension for the jp2k plugin (as well as required poms and folders within the structure).
I have modified the dependencyManagement to make sure the imageMosaic won’t add the new jp2k dependencies to geoserver and I have tested it by doing a local release.
Can I commit this?

Regards,
Daniele

On Tue, Nov 17, 2009 at 10:58 AM, Simone Giannecchini <simone.giannecchini@anonymised.com> wrote:

On Tue, Nov 17, 2009 at 10:31 AM, Andrea Aime <aaime@anonymised.com> wrote:

Simone Giannecchini ha scritto:

Ciao Andrea,
things are a little different with what happens with oracle and arsde
for 2 reasons:

1> this plugin uses Kakadu only if it is available else, it falls
back on the standard JAI ImageIO plugins

But it’s a new plugin. Seasoning it a bit in extensions is a good thing,
even if it’s just for a few releases like with the security UI.

Np about that.

About the fallback on JAI, is it already there?

Y, see http://docs.codehaus.org/display/GEOTDOC/JP2K+plugin and
http://docs.codehaus.org/display/GEOTOOLS/JP2K+Plugin

I understand it’s a way to give J2K support for free, but at
the same time it’s a liability, the JAI plugin loads everything into
memory undermining the overall GS stability (trying to actually use
it will easily bring GS close to the OOM).
Good for demos, but if one plans to actually use it in production… ugh!

Well, things are a little bit different than that, but nevertheless
the result is that the standard JAI ImageIO plugins are not really
suitable for serving large JPEG2K raster. That is why we have added
support for Kakadu.

2> this plugin will be referenced by the mosaic pom since I intend to
use it for building and serving JPEG2K mosaics, therefore once we
bring it into supported status it will be silently dragged in by the
mosaic plugin as it happened for GDAL. And on the same line, if the
Kakadu SDK won’t be around it will be working with just the standard
ImageIO plugins for Jpeg2k.

Feedback?

Right, the GDAL extensions sneaked in dodging the normal evolution
of a GS functionality (community → extension → core).
Which is really not good and not necessary either.
The mosaic plugin could be imported adding transitive dependency
exclusions towards GDAL and J2K and should be still working, right?

It is not as easy as that, we would have to modify a bit more the
Mosaic plugin code since it needs to know what is available and what
is not to set predences for the various plugins serving the same
format. So if we exclude some dependencies it will throw
class_not_found errors when running in geoserver.
Daniele is trying to work this around for the Kakadu plugin so that,
for the moment, we won’t be adding the kakadu plugin as a straight
dependency to both geoserver and kakadu.

Ciao,
Simone.

Following the process that the PSC voted
http://geoserver.org/display/GEOS/GSIP+22±+Community+Modules
is maybe slower but it’s something that cannot raise objections.

Cheers
Andrea

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

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what’s new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july

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

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what’s new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july

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

–

Eng. Daniele Romagnoli
Software Engineer

GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267

http://www.geo-solutions.it

10

Hi,
I’m adding the jp2k extension to geoserver 2.0.x.
Simone will update the Geoserver user doc.

Regards,
Daniele

On Tue, Nov 17, 2009 at 6:00 PM, Daniele Romagnoli <daniele.romagnoli@anonymised.com> wrote:

Hi all,
I’have locally created a new geoserver extension for the jp2k plugin (as well as required poms and folders within the structure).
I have modified the dependencyManagement to make sure the imageMosaic won’t add the new jp2k dependencies to geoserver and I have tested it by doing a local release.
Can I commit this?

Regards,
Daniele

On Tue, Nov 17, 2009 at 10:58 AM, Simone Giannecchini <simone.giannecchini@anonymised.com> wrote:

On Tue, Nov 17, 2009 at 10:31 AM, Andrea Aime <aaime@anonymised.com> wrote:

Simone Giannecchini ha scritto:

Ciao Andrea,
things are a little different with what happens with oracle and arsde
for 2 reasons:

1> this plugin uses Kakadu only if it is available else, it falls
back on the standard JAI ImageIO plugins

But it’s a new plugin. Seasoning it a bit in extensions is a good thing,
even if it’s just for a few releases like with the security UI.

Np about that.

About the fallback on JAI, is it already there?

Y, see http://docs.codehaus.org/display/GEOTDOC/JP2K+plugin and
http://docs.codehaus.org/display/GEOTOOLS/JP2K+Plugin

I understand it’s a way to give J2K support for free, but at
the same time it’s a liability, the JAI plugin loads everything into
memory undermining the overall GS stability (trying to actually use
it will easily bring GS close to the OOM).
Good for demos, but if one plans to actually use it in production… ugh!

Well, things are a little bit different than that, but nevertheless
the result is that the standard JAI ImageIO plugins are not really
suitable for serving large JPEG2K raster. That is why we have added
support for Kakadu.

2> this plugin will be referenced by the mosaic pom since I intend to
use it for building and serving JPEG2K mosaics, therefore once we
bring it into supported status it will be silently dragged in by the
mosaic plugin as it happened for GDAL. And on the same line, if the
Kakadu SDK won’t be around it will be working with just the standard
ImageIO plugins for Jpeg2k.

Feedback?

Right, the GDAL extensions sneaked in dodging the normal evolution
of a GS functionality (community → extension → core).
Which is really not good and not necessary either.
The mosaic plugin could be imported adding transitive dependency
exclusions towards GDAL and J2K and should be still working, right?

It is not as easy as that, we would have to modify a bit more the
Mosaic plugin code since it needs to know what is available and what
is not to set predences for the various plugins serving the same
format. So if we exclude some dependencies it will throw
class_not_found errors when running in geoserver.
Daniele is trying to work this around for the Kakadu plugin so that,
for the moment, we won’t be adding the kakadu plugin as a straight
dependency to both geoserver and kakadu.

Ciao,
Simone.

Following the process that the PSC voted
http://geoserver.org/display/GEOS/GSIP+22±+Community+Modules
is maybe slower but it’s something that cannot raise objections.

Cheers
Andrea

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

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what’s new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july

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

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what’s new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july

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

–

Eng. Daniele Romagnoli
Software Engineer

GeoSolutions S.A.S.

Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027

mob: +39 328 0559267

http://www.geo-solutions.it

–

Eng. Daniele Romagnoli
Software Engineer

GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267

http://www.geo-solutions.it