| 22 | | ||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. || heikki: 4 || |
| 24 | | || 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 | jose: critical | francois : major || |
| 25 | | ||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 | jose: critical | francois : major || |
| 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 || |
| 29 | | || 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? Yes, this is done. We can check how to provide upgrade slq files from previous versions and integrate in GAST this upgrade files(optional) || |
| 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 || |
| 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 || |
| 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 || |
| 34 | | ||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 | jose: critical || |
| 35 | | ||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: 2 || |
| 36 | | ||14|| ||Editor enhancement || In the [http://nationaalgeoregister.nl NGR] project, a modification to the code around the editor called ''Inflation and Vacuum'' is implemented, that makes it much easier to create valid metadata from scratch. In essence it takes the function of {{{update-fixed-info.xsl}}} (which also tries to do some automatic adjustments to help things along) a whole seven miles further. What do the developers think of this? (I'll provide documentation sometime soon). || heikki: 3 || |
| 37 | | ||15|| ||Framework / Refactoring ||Whether it's going to happen soon or not, I still think it good to repeat the subject of what to choose if we ever get to a drastic make-over of current GeoNetwork code, especially in terms of (1) GUI: use [http://wicket.apache.org/ Wicket]? [http://code.google.com/webtoolkit/ GWT]? (2) MVC: use [http://struts.apache.org/2.x/ Struts]? [http://static.springsource.org/spring/docs/2.0.x/reference/mvc.html Spring MVC]? (3) Persistence: use [http://www.hibernate.org/ Hibernate]? use [http://java.sun.com/developer/technicalArticles/J2EE/jpa/ JPA/EJB3]? (4) Web Services: use [http://ws.apache.org/axis2/ Axis2]? [http://jcp.org/en/jsr/summary?id=311 Jax-RS]? || heikki: 3 | jose: major || |
| 38 | | || 16 || ||Editor enhancement (XForms) ||GeoNetwork needs a range of metadata editors and the XForms Editor (from geonetworkui sandbox) should be available as part of this range. An XForms engine is an alternative technology that potentially hides details of HTML and JavaScript from developers. (The usefulness of the XForms editor will be determined to a large extent by how well it works across browsers and how responsive it is. What does the "potentially hides details" bit actually mean? That's just wishful thinking, and adding XForms means yet another complicated technology for developers to master. Justification/Action: Develop XForms interface as providing a user friendly interface with the flexibility to meet the needs of different users. How does it relate to [http://chiba.sourceforge.net Chiba]? || heikki: 3 || |
| | 28 | |
| | 29 | === Meetings points to be discussed === |
| | 30 | ||Id || Priority (trac #) || Topics || Comments || People interested In|| Discussion || |
| | 31 | || 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 || To be discussed|| |
| | 32 | ||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: 2, Just, Francois, Jose || Decide which JS libs to use, Add libraries to use and why in proposal template || |
| | 33 | ||14|| ||Editor enhancement || In the [http://nationaalgeoregister.nl NGR] project, a modification to the code around the editor called ''Inflation and Vacuum'' is implemented, that makes it much easier to create valid metadata from scratch. In essence it takes the function of {{{update-fixed-info.xsl}}} (which also tries to do some automatic adjustments to help things along) a whole seven miles further. What do the developers think of this? (I'll provide documentation sometime soon). || heikki: 3 || Demonstration || |
| | 34 | |
| | 35 | |
| | 36 | === GeoNetwork === |
| | 37 | ||Id || Priority (trac #) || Topics || Comments || People interested In|| Discussion || |
| | 38 | || 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 | jose: critical | francois : major || No project on-going on that || |
| | 39 | || 3 || 2 || 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 | jose: critical | francois : major || || |
| | 40 | || 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 || |
| | 41 | || 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''' || |
| | 42 | ||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|| |
| | 43 | ||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 || |
| | 44 | || || 2 || || REST services and provide a Jeeves JSON outputs || || || |
| | 45 | |
| | 46 | |
| | 47 | || 16 || ||Editor enhancement (XForms) ||GeoNetwork needs a range of metadata editors and the XForms Editor (from geonetworkui sandbox) should be available as part of this range. An XForms engine is an alternative technology that potentially hides details of HTML and JavaScript from developers. (The usefulness of the XForms editor will be determined to a large extent by how well it works across browsers and how responsive it is. What does the "potentially hides details" bit actually mean? That's just wishful thinking, and adding XForms means yet another complicated technology for developers to master. Justification/Action: Develop XForms interface as providing a user friendly interface with the flexibility to meet the needs of different users. How does it relate to [http://chiba.sourceforge.net Chiba]? || heikki: 3 || || |
| | 48 | |
