Changes between Version 86 and Version 87 of Bolsena2010

Timestamp:

Mar 24, 2011, 9:29:11 AM (13 years ago)

Author:

simonp

Comment:

--

Bolsena2010

@@ -42 +42 @@
  || 8 || 1 #232 || 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] !) ? || heikki: 3 || Create a SQL script to do the migration from one release to another. Trigger on startup a migration task if DB version is older than the running GeoNetwork ||
  || 9 || 2 || 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 || Integrate to main trunk. '''Make a 2.4.2+ebRim release''' ||
- ||10|| 1 #234 || 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 || Some existing stuff in Australia||
+ ||10|| 1 #234 || 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 || Another option is to make the overwrite an optional installer pack. This has been done in some code in Australia - needs to be committed to trunk. ||
  ||12 || 2 #233 ||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. ? || heikki: 1 | jose: critical || Make the Java doc first ||
  ||  || 2 || || REST services and provide a Jeeves JSON outputs || || ||