[Geoserver-devel] Building jars for comumnity modules & other details

GeoServer GeoServer Developer
1

Today I committed the printing module to subversion in /community/printing. Documentation as it stands is at <http://geoserver.org/display/GEOS/Printing+HOWTO >; is that the correct place? However, it's not terribly useful right now for a couple of reasons:

1. You need to bulid your own GeoServer to take advantage of it, rather than being able to install it as an extension. How do you package things up to make them available as an extension? I can't find much of an answer poking around old or new dox on the GeoServer site. I may have missed it, but if not, if something needs to be written up explaining, I could do that afterward, too.

2. It expects a configuration in /data/printing. How do you distribute default/example configurations? Where ought they be put?

3. On a similar note, it would be nice to distribute an example of how it's used. Where ought that be put?

Thanks,
Alan

2

Hi Alan,

Alan Gerber wrote:

Today I committed the printing module to subversion in /community/ printing. Documentation as it stands is at <http://geoserver.org/display/GEOS/Printing+HOWTO >; is that the correct place? However, it's not terribly useful right now for a couple of reasons:

1. You need to bulid your own GeoServer to take advantage of it, rather than being able to install it as an extension. How do you package things up to make them available as an extension? I can't find much of an answer poking around old or new dox on the GeoServer site. I may have missed it, but if not, if something needs to be written up explaining, I could do that afterward, too.

Yeah, much has not been ported to the new guide yet. But the extension packaging guide is here:

http://geoserver.org/display/GEOS/GSIP+22+-+Community+Modules

It walks through the process of creating a release artifact descriptor. However, our project policies differentiate between community modules and extensions. To be release a community module must be upgraded to an extension, and this requires a few things like test coverage, documentation, etc... See the above for the requirements.

2. It expects a configuration in /data/printing. How do you distribute default/example configurations? Where ought they be put?

Is this inside the data directory? Or somewhere on the file system? All configuration stuff is usually shipped inside of the data directory. For extensions it is a bit tricky, since we probably don't want to add configuration for plug-ins to the data directory.

One trick that is used is to distribute any configuration files needed by a plugin with the plugin itself, usually some default values. Then the plugin on startup or sometime at runtime:

1) checks the data dir for the files
2) if they don't exist, copy them out into data dir from the classpath

Does that make sense?

3. On a similar note, it would be nice to distribute an example of how it's used. Where ought that be put?

Depends on what the example looks like. Is it a java program, is it a web app? etc...

Thanks,
Alan

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
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.

3

On Jun 16, 2009, at 4:23 PM, Justin Deoliveira wrote:

Hi Alan,

Alan Gerber wrote:

Today I committed the printing module to subversion in /community/ printing. Documentation as it stands is at <http://geoserver.org/display/GEOS/Printing+HOWTO >; is that the correct place? However, it's not terribly useful right now for a couple of reasons:
1. You need to bulid your own GeoServer to take advantage of it, rather than being able to install it as an extension. How do you package things up to make them available as an extension? I can't find much of an answer poking around old or new dox on the GeoServer site. I may have missed it, but if not, if something needs to be written up explaining, I could do that afterward, too.

Yeah, much has not been ported to the new guide yet. But the extension packaging guide is here:

http://geoserver.org/display/GEOS/GSIP+22+-+Community+Modules

It walks through the process of creating a release artifact descriptor. However, our project policies differentiate between community modules and extensions. To be release a community module must be upgraded to an extension, and this requires a few things like test coverage, documentation, etc... See the above for the requirements.

I see; I meant to say a community module, in that case. How does one package one of those up into a distributable jar, without dependencies hanging out in the Maven repository or such?

2. It expects a configuration in /data/printing. How do you distribute default/example configurations? Where ought they be put?

Is this inside the data directory? Or somewhere on the file system? All configuration stuff is usually shipped inside of the data directory. For extensions it is a bit tricky, since we probably don't want to add configuration for plug-ins to the data directory.

One trick that is used is to distribute any configuration files needed by a plugin with the plugin itself, usually some default values. Then the plugin on startup or sometime at runtime:

1) checks the data dir for the files
2) if they don't exist, copy them out into data dir from the classpath

Does that make sense?

The config will go in $GEOSERVER/data/printing. Your default-loading option is a sensible one. The implication is that the module needs to run at least once before the user can edit the config, yes?

3. On a similar note, it would be nice to distribute an example of how it's used. Where ought that be put?

Depends on what the example looks like. Is it a java program, is it a web app? etc...

It's a website with some javascript on it, so it'd go in $GEOSERVERDIR/data/www

Thanks,
Alan
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
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

<snip>

I see; I meant to say a community module, in that case. How does one package one of those up into a distributable jar, without dependencies hanging out in the Maven repository or such?

Well you can follow the steps in the guide and create an artifact descriptor, etc... etc.. but if you just want something quick and dirty:

From the printing module:

1) mvn clean install
2) mvn dependencies:copy-dependencies

After which you can zip up target/printing*.jar, and any libs that your plugin needs from target/dependencies into a single archive.

2. It expects a configuration in /data/printing. How do you distribute default/example configurations? Where ought they be put?

Is this inside the data directory? Or somewhere on the file system? All configuration stuff is usually shipped inside of the data directory. For extensions it is a bit tricky, since we probably don't want to add configuration for plug-ins to the data directory.

One trick that is used is to distribute any configuration files needed by a plugin with the plugin itself, usually some default values. Then the plugin on startup or sometime at runtime:

1) checks the data dir for the files
2) if they don't exist, copy them out into data dir from the classpath

Does that make sense?

The config will go in $GEOSERVER/data/printing. Your default-loading option is a sensible one. The implication is that the module needs to run at least once before the user can edit the config, yes?

Correct. I guess the alternative would be to include the default config file in the plugin archive itself with instructions of where to put it in the data directory. I guess if the file will need to be edited before printing is possible than the latter makes sense, but if sensible defaults can be made the former can be nice. It also depends on if your plugin reads configuration only on startup, or reads its config every time a request is made.

3. On a similar note, it would be nice to distribute an example of how it's used. Where ought that be put?

Depends on what the example looks like. Is it a java program, is it a web app? etc...

It's a website with some javascript on it, so it'd go in $GEOSERVERDIR/data/www

Yup. More or less the same options as the config file here.

Thanks,
Alan
------------------------------------------------------------------------------

Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
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.