handling of unsupported modules
-
Motivation: Clarity of purpose
-
Tracker: https://osgeo-org.atlassian.net/browse/GEOT-1953 Build Change, https://osgeo-org.atlassian.net/browse/GEOT-1955 Developers Guide Change
-
Tagline: got code?
-
Background: The introduction of unsupported modules has been a great success; now that we are nearing the release of GeoTools 2.5.0 we need to sort out a few build issues; and nail down exactly how to make modules supported.
We introduced the "modules/unsupported" directory in an effort to help prevent the development community working on branches; and as an effort to introduce new developers to the GeoTools community. This also allowed us to demote several modules that have been with out a maintainer (so it is obvious to the user community what is going on).
This proposal would like to refine how we are handling unsupported modules:
- The creation of a single page in the developers guide outlining all the requirements from creation through supporting a module (right now this content is split across several pages). We should clarify how a module can drop back to unsupported status and so forth.
- Modify the unsupported/pom.xml so that profiles are available grouping like functionality; using a single environmental -Dall to turn on all functions
- Deployment of all modules to maven (including those in unsupported)
- Continuous testing of all modules (including those in unsupported)
- Restrict unsupported modules from the default download
The goals here are several fold:
- Ensure that everything we (ie the PMC) make available for download has passed the Project QA checks and meets the requirements of our Developers Guide
- Continue to foster new development
- Ensure that GeoTools always builds in a reasonable amount of time
We would like to close up this issue in a timely fashion for the 2.5.0 release:
- Andrea Aime +1
- Ian Turton
- Justin Deoliveira +1
- Jody Garnett +1
- Martin Desruisseaux
- Simone Giannecchini
Discussion
- http://docs.codehaus.org/display/GEOTOOLS/2008/08/18/
- http://docs.codehaus.org/display/GEOTOOLS/2008/08/11/
This section is used to make sure your proposal is complete (did you remember documentation?) and has enough paid or volunteer time lined up to be a success
| :white_check_mark: | :no_entry: | :warning: | :negative_squared_cross_mark: |
------------|--------------------|------------|-------------------------|-------------------------------| no progress | done | impeded | lack mandate/funds/time | volunteer needed |
- ✅ API changed based on BEFORE / AFTER patch is waiting to be applied, this is required to make 2.5.0 ready for release
- (jive) Update the developers guide and ask for review
- Ask a module to step through the process in order to "debug" the procedure
Currently all children of unsupported/pom.xml are included in the build (or they are placed into a profile like "archive" if the code does not compile).
<profiles>
<profile>
<id>gdal</id>
<modules>
<module>imageio-ext-gdal</module>
</modules>
</profile>
<profile>
<id>pending</id>
<modules>
<module>coveragetools</module>
<module>sql-datastore</module>
<module>geometryless</module>
<module>notifying-collections</module>
</modules>
</profile>
<profile>
<id>archive</id>
<modules>
<module>community-schemas</module>
<module>hsql</module>
<module>geomedia</module>
<module>ogr</module>
<module>gml3</module>
<module>tile</module>
</modules>
</profile>
</profiles>
<modules>
<module>coverageio</module>
<module>coverageio-netcdf</module>
<module>coveragetools</module>
<module>directory</module>
<module>epsg-oracle</module>
<module>geometry</module>
<module>gml</module>
<module>gpx</module>
<module>h2</module>
<module>imagemosaic-jdbc</module>
<module>jts-wrapper</module>
<module>mappane</module>
<module>mif</module>
<module>mysql</module>
<module>ogc</module>
<module>oracle-spatial</module>
<module>postgis-versioned</module>
<module>process</module>
<module>wps</module>
<module>repository</module>
<module>temporal</module>
<module>tiger</module>
<module>vpf</module>
<module>widgets-swing-pending</module>
<module>xml-gpx</module>
</modules>
</project>We need to place the majority of unsupported modules into individual profiles; activated with a common -Dall command line setting:
...
<profiles>
<profile>
<id>fm</id>
<activation>
<property>
<name>all</name>
</property>
</activation>
<modules>
<module>coveragetools</module>
<module>sql-datastore</module>
<module>geometryless</module>
<module>notifying-collections</module>
</modules>
</profile>
<profile>
<id>archive</id>
<modules>
<module>community-schemas</module>
<module>hsql</module>
<module>geomedia</module>
<module>ogr</module>
<module>gml3</module>
<module>tile</module>
</modules>
</profile>
<profile>
<id>geometry</id>
<activation>
<property><name>all</name></property>
</activation>
<modules>
<module>geometry</module>
<module>jts-wrapper</module>
</modules>
</profile>
<profile>
<id>database</id>
<activation>
<property><name>all</name></property>
</activation>
<modules>
<module>h2</module>
<module>mysql</module>
<module>oracle-spatial</module>
<module>postgis-versioned</module>
</modules>
</profile>
<profile>
<id>workflow</id>
<activation>
<property><name>all</name></property>
</activation>
<modules>
<module>process</module>
<module>wps</module>
</modules>
</profile>
<profile>
<id>raster</id>
<activation>
<property><name>all</name></property>
</activation>
<modules>
<module>coverageio</module>
<module>coverageio-netcdf</module>
<module>coveragetools</module>
<module>imageio-ext-gdal</module>
<module>imagemosaic-jdbc</module>
</modules>
</profile>
<profile>
<id>unsupported</id>
<activation>
<property>
<name>all</name>
</property>
</activation>
<modules>
<module>directory</module>
<module>epsg-oracle</module>
<module>gml</module>
<module>gpx</module>
<module>mappane</module>
<module>mif</module>
<module>repository</module>
<module>temporal</module>
<module>tiger</module>
<module>vpf</module>
<module>widgets-swing-pending</module>
<module>xml-gpx</module>
</modules>
</profile>
</profile>
</profiles>
<!-- the ogc module is currently required by our build system -->
<modules>
<module>ogc</module>
</modules>
</project>This proposal requires modification to the Developers Guide: