That is quite fun; you should make a blog post as it is an interesting tidbit.
Jody
On 31/07/2010, at 5:06 AM, Ian Turton wrote:
> Apparently a "Competent GeoSpatial technologist" must be able to:
> "Customize geospatial software using proprietary and open source
> software components, such as E
Ian Turton wrote:
> Apparently a "Competent GeoSpatial technologist" must be able to:
> "Customize geospatial software using proprietary and open source
> software components, such as ESRI's ArcObjects, Intergraph's GeoMedia
> software suite, and the GeoTools open source project" see
> http://www.c
Apparently a "Competent GeoSpatial technologist" must be able to:
"Customize geospatial software using proprietary and open source
software components, such as ESRI's ArcObjects, Intergraph's GeoMedia
software suite, and the GeoTools open source project" see
http://www.careeronestop.org/competencym
memory leak
---
Key: GEOT-3227
URL: http://jira.codehaus.org/browse/GEOT-3227
Project: GeoTools
Issue Type: Bug
Components: data arcsde
Affects Versions: 2.6.0
Environment: geoserver-2.0.2 arcsde-datastore-2.6.
Hi Jody and all,
Regarding the GPG signing of jars, for releases I think this would
usually be done en masse when you are submitting the release to
sonatype for checking and publishing - at least that's how I've done
it with little projects. So whoever is building the jars would
normally be signi
Wow - with all the quickfire questions and answers this is actually
looking possible.
So we have one outstanding issue with the geoapi jars; I can publish
them as a representative of that project; or we can bundle them into
gt-api.
So yeah, we have a proposal about this already
(http://docs.codeh
2010/7/29 Jody Garnett :
>> * Project POM has the following elements.
>> **
>> **
> check.
>
>> ** If the project packaging is jar, and the jar file contains java classes,
>> there must be a -javadoc.jar for main artifact.
>
> Not sure how we would turn this on?
>
maven will do this for you
On 30/07/10 13:35, Jody Garnett wrote:
>> Also, should the scm entries point to the GeoTools poms used to build the
>> packages, or should they in the case of packaging third-party schemas point
>> to the originating third-party scm?
>
> I think the geotools location. For third party schemas (ie og
