<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. ------------------------------------------------------------------------------ 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
