Changes between Version 67 and Version 68 of Bolsena2010


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

--

Legend:

Unmodified
Added
Removed
Modified

  • Bolsena2010

    v67 v68  
    2121
    2222 ||Id || Priority || Topics || Comments || People interested In||
    23  ||1 || ||Javadoc ||let's clean up the existing Javadoc and add new where it is missing. It'd be good to [http://java.sun.com/j2se/javadoc/ familiarize yourself] with how Javadoc works, before doing this; e.g. there should be no blank line between the Javadoc and the method it is about; the first sentence should end in a period; and things like that. || ||
     23 ||1 || ||Javadoc ||let's clean up the existing Javadoc and add new where it is missing. It'd be good to [http://java.sun.com/j2se/javadoc/ familiarize yourself] with how Javadoc works, before doing this; e.g. there should be no blank line between the Javadoc and the method it is about; the first sentence should end in a period; and things like that. || heikki: 4 ||
    2424 || 2 || ||harvesters || Let's remove the harvesters' configuration from the "settings" table to its own, first-class-citizen table. Now, if you have many harvesters, it is nigh impossible to find anything in "settings". || heikki: 1 ||
    2525 ||3 || || harvesters  || Related to before topic: rewrite harvesters client side code to remove unrequired ajax stuff. Just make "normal" forms for harvesters maintainment avoiding using ajax, except if really required for any functionality. || heikki: 1 ||
    26  || 4 || || Javadoc|| Automatically add the Javadoc pages to this wiki, updated from a Hudson build process? For all of the branches? || ||
    27  || 5 || || Coding rules || Some people really like working with ''patches''; other people prefer using short-lived SVN branches for a similar purpose. Can we all agree on doing it one way or the other? || ||
    28  || 6 || ||Community || This wiki is a bit of a mess, in my opinion. I think it would be good if we could put maybe 3 people in charge to firstly, clean it up and better structure it; and secondly, to try to keep it that way. || ||
     26 || 4 || || Javadoc|| Automatically add the Javadoc pages to this wiki, updated from a Hudson build process? For all of the branches? || heikki: 4 ||
     27 || 5 || || Coding rules || Some people really like working with ''patches''; other people prefer using short-lived SVN branches for a similar purpose. Can we all agree on doing it one way or the other? || heikki: 4 ||
     28 || 6 || ||Community || This wiki is a bit of a mess, in my opinion. I think it would be good if we could put maybe 3 people in charge to firstly, clean it up and better structure it; and secondly, to try to keep it that way. || heikki: 2 ||
    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? ||
    30  || 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] !) ? || ||
     30 || 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] !) ? || heikki: 3 ||
    3131 || 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 ||
    3232 ||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 ||
    33  ||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. || ||
     33 ||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. || heikki: 3 ||
    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. ? || heikki: 1 ||
    3535 ||13|| || RIA, Framework || Any relevant software going on that might be useful for GeoNetwork? Think of [http://mapproxy.org/ MapProxy], [http://chiba.sourceforge.net Chiba] and [http://geojquery.org/wiki/doku.php GeoJQuery]. Other ones? || heikki: 4 ||
    … …  
    7474 || 52 || ||Indexation enhancement|| Using Apache Tika to index content from files attached to metadata records in !GeoNetwork?|| ||
    7575 || 53 || ||Indexation enhancement || Replace Lucene interface in GN with Apache Solr?|| heikki: 1 ||
    76  || 54 || ||Schema management || !SchemaManager - redesign proposed by Mathieu: * use org.geonetwork.utils.xsd.XSD in the project "geonetwork-services-ebrim" to read schemas and query contents for driving the editor * GN uses a number of schemas for validation purposes eg. in OAI, could these be managed by schemamanager so that they do not need to be retrieved from net? * sometimes a document may introduce a new schema eg. !ListSets response in OAI harvester can introduce the oai_dc schema eg. when harvesting jOAI - if we need to validate these responses then creating a validator with a file based schema will cause the validation to fail as the schema is not present on disk, alternative to is create a validator with no file based schema which means that all schemas will be obtained from the net but use an entityResolver object to intercept those which are local so as to avoid unnecessary retrieval or perhaps use a Java Cache System (JCS) instance to cache all schemas locally like XLinks?|| ||
    77  || 55 || || Multi-editing || Attempting to introduce the ability to edit more than one document makes existing trunk interface confusing eg. editing documents in tabs both of which have login details. Things get out of sync - what to do? Maybe something like BlueNetMEST which is based on one window - the main search window (tabs for remote, advanced and mapviewer) with search results - editing/viewing by clicking on title opens editor/viewer in new window (multiediting is supported), clicking any of the menu options on main screen uses modalbox dialog and separate windows to keep search interface and results window untouched, log out/log in closes all editor/viewer windows to close, if editing in progress log out not allowed - this is not perfect but might be a way of thinking about how to introduce things like multiediting to trunk.  || ||
     76 || 54 || ||Schema management || !SchemaManager - redesign proposed by Mathieu: * use org.geonetwork.utils.xsd.XSD in the project "geonetwork-services-ebrim" to read schemas and query contents for driving the editor * GN uses a number of schemas for validation purposes eg. in OAI, could these be managed by schemamanager so that they do not need to be retrieved from net? * sometimes a document may introduce a new schema eg. !ListSets response in OAI harvester can introduce the oai_dc schema eg. when harvesting jOAI - if we need to validate these responses then creating a validator with a file based schema will cause the validation to fail as the schema is not present on disk, alternative to is create a validator with no file based schema which means that all schemas will be obtained from the net but use an entityResolver object to intercept those which are local so as to avoid unnecessary retrieval or perhaps use a Java Cache System (JCS) instance to cache all schemas locally like XLinks?|| heikki: 3 ||
     77 || 55 || || Multi-editing || Attempting to introduce the ability to edit more than one document makes existing trunk interface confusing eg. editing documents in tabs both of which have login details. Things get out of sync - what to do? Maybe something like BlueNetMEST which is based on one window - the main search window (tabs for remote, advanced and mapviewer) with search results - editing/viewing by clicking on title opens editor/viewer in new window (multiediting is supported), clicking any of the menu options on main screen uses modalbox dialog and separate windows to keep search interface and results window untouched, log out/log in closes all editor/viewer windows to close, if editing in progress log out not allowed - this is not perfect but might be a way of thinking about how to introduce things like multiediting to trunk.  || heikki: 5 ||
    7878 || 56 || ||Customization || Improve CSS management, clean CSS file and references to unused styles, replacing tables by divs, discuss on [wiki:ThemeCustomization]|| heikki: 1 ||
    7979 || 57 || ||Maven migration ||Move to Maven as described here : [wiki:Maven] ||Mathieu (major) | heikki: 1 |