GvSIG CE Code Sprint in Munich

From gvSIG CE Wiki

Jump to: navigation, search

gvSIG CE Code Sprint Munich 2012

The gvSIG CE Team will organize a gvSIG CE Code Sprint in Munich (Germany) from 15.10 until 19.10.2012 . Developers and Users are invited to decide on the next steps of the project together.



This first community sprint of gvSIG CE is a great opportunity to support the development of the project contributing actively to the source code, manuals or improving any aspects of gvSIG CE. The community sprint is a get-together for gvSIG CE project members and supporters and the best way to make decisions and treat larger problems. For this meeting developers, document writers, bug reporters, translators etc. are welcome!

Time and location

We are planning a five days hack fest.

Location: Innere Wiener Str. 32, D - 81667 München

Duration: 15.10 - 19.10.2012 from approximately 9am-4pm


Please write here which items we should discuss or write an email to our community list to discuss them together. Suggestion: We use this first code sprint mainly for API clean-ups and to fix the most critical bugs.

Please take a look at our page on Development_and_releases for the version 1.0 release plan.

Clean-up work

One of the main goals of this code sprint will be to get the code base into better shape:

  • Remove proprietary, unneeded or duplicate features and extensions. Candidates:
    • SEXTANTE native Java algorithms that duplicate SAGA modules
    • Wizard GUI for processing tools (can use SEXTANTE now; but keep tool GUIs)
      • Remove: /extGeoProcessing/src/com/iver/cit/gvsig/geoprocess/gui (?)
      • Remove: /extGeoProcessing/src/com/iver/cit/gvsig/geoprocess/manager
      • Remove: /extGeoProcessing/src/com/iver/cit/gvsig/geoprocess/wizard
    • gvSIG native processing tools that are also available via SEXTANTE
    • Remove extMeasureGeometry once all tools are in SEXTANTE
    • Remove custom menu system from Raster and Remote Sensing tools and move tools into SEXTANTE toolbox
    • Remove libjni-ecw and libjni-mrsid (use GDAL drivers instead) 16px-Ok.png
    • Native drivers for formats also supported by Geotools/GDAL/OGR (no more libjni-gdal)
    • Java Advanced Imaging (dead since 2003!) -> use GDAL instead (keep, but ship Java-only)
    • Remove extJCRS, libProjection and libjni-proj4 after transition to GeoTools
    • Remove extJDBC after transition to GeoTools
    • Remove copy of openjdk-printing1.7 (backport from Java 7) 16px-Ok.png
    • ExtDerivedGeometries (can all be done with field calculator) 16px-Ok.png
    • Move extGridViewLayout to unsupported (Removed. It was not even in the build list) 16px-Ok.png
    • Remove all translations we cannot maintain 16px-Ok.png
    • CSV file import ("Normalize Text File" works much better: /libFMap/drivers/csvstring/csvstring.jar) 16px-Ok.png
    • Remove DWG support: extDWG, libDWG 16px-Ok.png
    • Remove DXF support: libFMap/src/com/iver/cit/gvsig/fmap/drivers/dxf, libDXF 16px-Ok.png
    • Remove DGN support: libFMap/src/com/iver/cit/gvsig/fmap/drivers/dgn 16px-Ok.png
    • Remove extScripting (not used, not documented) 16px-Ok.png
    • Remove extSDE (outdated) 16px-Ok.png
    • Remove extHelp (Link to Wiki for help pages) 16px-Ok.png
    • Remove extDataLocator (Navtable has same functionality) 16px-Ok.png
  • Drop dead features that cannot realistically be maintained by us
  • Look for opportunities to refactor and "outsource" API parts
  • Identify low-hanging fruits for updates and improvements
  • Update API to Java 7 16px-Ok.png
  • API documentation
    • Start a new Wiki page with API-level programming hints
    • Update JavaDocs
  • Language updates
    • Find all hard-coded Spanish strings and translate them to English
    • Re-organize translation files: Merge all files from extension folders into one main file and resolve duplicates
    • Drop translations that we cannot maintain 16px-Ok.png
    • Fix missing or wrong English translations

Postponed clean-up work

  • Remove icon themes extension:
    • All config.xml must be modified in order to reference the actual icon instead of a "key".
    • There will be no need to register the icons in the initialize method of the extensions
    • all the tree under PluginServices.getIconThemeManager() and PluginServices.getIconTheme() could be removed.

Bug fixing

  • Raise patch level to that of gvSIG 1.12 (final): evaluate those functionalities that should be integrated
  • Release planning: classify all bugs that need to be fixed for the 1.0 release 16px-Ok.png
  • Bugs with highest importance for the 1.0 release ("major", "crash" and "block"):
  • Update Roadmap 16px-Ok.png

GUI improvement

  • Find inconsistencies:
    • OK and Cancels buttons always present?
    • Always the same button order?
  • Annoyances:
    • Dialogs resizable when they should be?
    • Transient/non-transient as they should be?
    • Layout errors such as unneeded frames or wasted space?
    • Text field contents readable?
  • Labelling:
    • Are ":" and "..." used properly in all cases?
    • Do dialogs and buttons have meaningful titles/labels?
  • Menu items:
    • Correct order and groups?
    • Hotkeys working/appropriate?
    • Submenu system intuitive, everything in the place where it should be?
    • Do all context menu items and icons have corresponding entries in the main menu?
    • Should the context menu be extended/reduced?
  • Where to put the Raster Tools functions?
  • Where to put the SEXANTE tools?
  • Add Shortcuts

Replace data access layer with geotools

Technically, the key part for making this feasible is to keep a small scope, to keep the refactoring "partial". Changing data access may involve changing also geometry model, which may involve changing also rendering, symbology, etc. That's the risk. We should try to reduce the refactoring to data access as much as we can. Not sure if it is possible in a sensible way.

At least, we should analyse the feasibility and specify a list of tasks or a roadmap, so that the refactoring can be done in a collaborative way.

See Geotools in gvSIG CE

New features


Project Organization

  • gvSIG CE & OSGeo (get information; prepare for incubation after gvSIG CE 1.0). gvSIG CE Team will work following The OSGeo Way preparing ourselves for the incubation process. 16px-Ok.png
  • Sponsorship program
  • Plan the gvSIG CE Project Steering Committee


Please keep in mind that all participants are volunteering several days of their time in addition to paying for their own travel and hotel expenses.

Participants should plan for the following costs:

  • Travel to Munich, variable depending on where you are.
  • Accommodation for four nights, 60 €-90 € depending on what room you choose.
  • Breakfast, lunch, and other snacks.


Please join the mailing list at: gvSIG CE community list

Remote Participation:

If you can not make it to Munich in person, and you still want to actively participate, there will be a chance to do it by joining the event on IRC. If you are interested in remote participation, feel free to add yourself below.

Equipment needed:

List of participants

You are welcome to join us and bring new ideas with you. Please add your name an email adresse to the list. The following people will attend our first code sprint:

  • Benjamin Ducke <benducke[at]fastmail.fm>
  • Fernando González <fernando.gonzalez[at]geomati.co>
  • Ruth Schönbuchner <ruth.schoenbuchner[at]csgis.de>
  • Johannes Valenta <office[at]arch-iv.de>
  • Jose Canalejo <jose.canalejo[at]csgis.de>
  • Víctor González <victor.gonzalez[at]geomati.co>
  • Francisco Puga <fpuga[at]cartolab.es>

Remote participation

  • Victor Olaya <volayaf[at]gmail.com>


The code sprint has been announced on the following lists:

  • gvsigce-community@lists.sourceforge.net 16px-Ok.png
  • gvsigce-users@lists.sourceforge.net 16px-Ok.png
  • Geotools-gt2-users@lists.sourceforge.net 16px-Ok.png
  • fossgis-talk-liste@fossgis.de 16px-Ok.png
  • Slashgeo 16px-Ok.png
  • discuss@lists.osgeo.org 16px-Ok.png
  • grass-dev@lists.osgeo.org 16px-Ok.png
  • add your list


What is a code sprint?

A code sprint is getting developers for a set amount of time and just writing code. Participants will learn from others, but the focus is not on instruction. A significant benefit of sprinting is that the project members meet in person, socialize, and start to communicate more effectively than when working together remotely.


Some photos at dropbox

Next Code Sprint

The Next Code Sprint in 2013 will be held in ... (to be discussed in Munich):

  • a) Toulouse (France)
  • b) Girona (Spain)
  • c) Berlin (Germany)
  • d) Add a location


The first gvSIG CE Code sprint took place from Monday October 15th to Friday October 19th 2012 in Munich. 100% of the cost of this code sprint have been covered by ArchIV, Benjamin Ducke, CSGIS, Cartolab and Geomati.co. It has been a very intensive and productive week with these participants:

  • Benjamin Ducke <benducke[at]fastmail.fm>
  • Fernando González <fernando.gonzalez[at]geomati.co>
  • Ruth Schönbuchner <ruth.schoenbuchner[at]csgis.de>
  • Johannes Valenta <office[at]arch-iv.de>
  • Jose Canalejo <jose.canalejo[at]csgis.de>
  • Víctor González <victor.gonzalez[at]geomati.co>
  • Francisco Puga <fpuga[at]cartolab.es>

Benjamin Ducke worked on the integration of GRASS GIS in SEXTANTE 1.0 and managed the gvSIG CE release plan. The next release will be a beta release for gvSIG CE 1.0. We plan to release the first beta version of gvSIG CE 1.0 in November 2012 and the final version 1.0 before the end of that year. It will feature many bug fixes, user interface improvements, and some new/updated extensions (most importantly, a new version of SEXTANTE, OpenCAD and NavTable).

Fernando and Victor Gonzalez were examining a possible Integration of Geotools in gvSIG CE. This is a very important task for gvSIG CE because it will improve hugely the development of gvSIG CE. At this point we would like to say a big thank you! They have invested several days on this work without any sponsor. The first results allow us to estimate a roadmap and evaluate next steps. Surely more investigation and testing will be needed.

Francisco Puga helped us accomplishing the best integration of OpenCadTools and Navtable in gvSIG CE and he also discussed the integration of geotools into the official gvSIG as this task could be also important for the gvSIG development.

Ruth Schönbuchner, Johannes Valenta and José Canalejo were working on updating the project documentation. The website has been updated, a gvSIG CE Quickstart based on OADE Quickstart has been put online. An example project with sample data will be part of the next CE 1.0.

The code sprint is a great opportunity to make decisions about the future of the project. It has been a very good experience for all of us. We are looking forward to the next code sprint! If you like to discuss next steps of the project we would like to hear from you (e.g. add a location for the next code sprint: Toulouse, Girona, Berlin, ?). Join our community list or follow us at twitter.

We're grateful to all the developers for their awesome engagement! See you soon and thank you very much to all participants!

The gvSIG CE Team