Changes between Version 63 and Version 64 of Bolsena2010


Ignore:
Timestamp:
May 18, 2010, 4:38:14 PM (14 years ago)
Author:
heikki
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Bolsena2010

    v63 v64  
    2929 || 7 || || Database || Let's create SQL files that can fill an empty GeoNetwork database with only the minimum needed to run the program? The admin user, settings, regions, things like that. Not everyone is really eager to use GAST for anything. || Done by Jose? ||
    3030 || 8 || || Database || Can we agree that we'll provide SQL scripts to create the database, and SQL scripts to fill it with sample data? And let's phase out those DDF files and the unfortunate GAST altogether? And that we provide update SQL scripts with new versions of GeoNetwork, both for changes to database schema and for content (like, [http://geonetwork.tv/settings Settings] !) ? || ||
    31  || 9 || || Release Strategy|| Can we release GeoNetwork 3.0 (with the CSW/ebRIM interface)? Maybe we can have simultaneous "current releases" in both the GN2.x and GN3.x lineages, as do for example Lucene and Tomcat? || ||
    32  ||10|| || Database  || Does anyone like the function of the installer that it overwrites your JDBC credentials with randomly generated values? I certainly don't, as my DB lives very much longer than the many GeoNetwork installations I always do, so I have to edit {{{config.xml}}} everytime. How's about removing that? || ||
     31 || 9 || || Release Strategy|| Can we release GeoNetwork 3.0 (with the CSW/ebRIM interface)? Maybe we can have simultaneous "current releases" in both the GN2.x and GN3.x lineages, as do for example Lucene and Tomcat? || heikki: 3 ||
     32 ||10|| || Database  || Does anyone like the function of the installer that it overwrites your JDBC credentials with randomly generated values? I certainly don't, as my DB lives very much longer than the many GeoNetwork installations I always do, so I have to edit {{{config.xml}}} everytime. How's about removing that? || heikki: 2 ||
    3333 ||11|| ||Community || Would it be an idea to appoint Language Managers for each of the supported translations? They would form the International Internationalization Committee (IIC, or CII in French) and they're summoned to maintain the i18n files for their language, before each new release. This might even be arranged in an [http://www.osgeo.org/ OSGEO]-wide manner. ||  ||
    3434 ||12 || ||Code Refactoring || The class {{{DataManager.java}}} and its sister {{{XMLSerializer.java}}} are in particularly bad shape, in my opinion. There are literally dozens of public methods that all do more or less the same thing. Of course it's not clearly documented why they are all there or when to use which. Would it be too drastic to propose that we keep 1 single public method for each of the functions ''createMetadata'', ''updateMetadata'', ''validateMetadata'', etc. ? ||  ||