Bolsena2014

Bolsena 2014 - draft agenda

For the 7th time, the Bolsena OSGeo Hacking Event is taking place. This page lists some ideas that can be discussed within the GeoNetwork faction.

Please add any idea you have here !

Code Sprint Proposals

• Discussions/Presentations on new and planned developments - plenary or GN only sessions (All)
• Schema configuration (easier configuration, metadata101, define structure ...) (Maria, Simon, Francois)
• Schema / reduce number of duplicated file (eg. all translations files which are copy of the english version)
• Cleaning / Deprecate old (admin, ...) interface & Spring MVC ? (Maria, Jesse, Pierre, Paul, Francois)
• Documentation (Jean, Patrizia, Francois)
• Release 2.10.4 (Simon, ?)
• Solve Lucene concurrent use (Jose, Jesse)
• User interface (Florent, ?)
• Testing / Travis (Juan Luis)

GeoNetwork 3.0 stabilization

The roadmap says so... (see https://docs.google.com/spreadsheet/ccc?key=0AuAoDzvFLYB8dGJkREo1YURfdnhpeG1CazZqb3ZsMGc&usp=sharing)

Optimisation of build process

The actual complete build with mvn clean install takes about 13 minutes in a quite new computer (2013) with an SSD drive. For sure can be deferred the complete build to do it only before pushing the changes to git, but anyway such amount of time to build looks no much agile.

Should be good to work in possible optimisations of the build process.

Continuous integration system

Discuss to use Travis (https://travis-ci.org/) or similar continuous integration system for GeoNetwork.

Presentations

Tuesday (9h):

• Tufts Harvester
• Tufts Search Interface

Thursday (14h):

GN users - Thursday (9h):

• Spring MVC
• Metadata Editor module
• Workflow EC
• ISO19115-3 (Francois)
• Angular editor how-to

Progress reports

Where we Are

TODO This week

Future Direction

Define a plugable architecture for new features

For now the development of a new features usually involves adding/changing code to several modules, create service definitions in web module, etc.

I hope we can work part of the time in Bolsena on defining the requirements for a plugable architecture, where developers can create a new module with services/domain/security rules/web resources/etc. that can be package and deployed in a GeoNetwork instance.

This will require some changes to analyse:

1. Change services to Spring MVC: this should facilitate the definition of new services, without explicit declaration in config-XXXX.xml files. (María merge)
2. Adding new concepts like Metadata listeners for metadata operations like update, create, delete, indexing, etc. so new code can add a new listener instead of requiring to update the DataManager class.
3. Deployment of web resources.

Also an advantage of this can be not really requiring to commit all the code in the core branch, but having them as optional modules, making the distribution and maintenance lighter (module creator should be responsible to maintain it).