GeoNetwork Codesprint Summary

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

GeoNetwork Codesprint Summary

delawen
Good morning everyone,

As you may already know, last week was the codesprint for Java OSGeo{0]. There was a group of developers working from Sevilla half-time to improve GeoNetwork. It is true that most of them had no spatial background because they came from the Java JUG[1]. On the bright side: we made some progress.

Work is not yet merged into master, as we have to review and test. But in summary:

 * Some libraries were upgraded (code compiled, passed the tests, at least locally, and GeoNetwork appeared to function properly, but need more proper testing):
 * Migration to Spring 5

The migration to Spring 5 was the final boss monster in the codesprint and we defeated it :) I still have to review some tests that fail and test more properly, but the work is almost done: https://github.com/geonetwork/core-geonetwork/tree/spring5

Big changes here: we are trying to go back to plain Spring/Spring-JPA/Hibernate. GeoNetwork had some customizations that were big workarounds causing weird effects (like with transactional). On this branch we go back to plain Spring behavior, not only because the previous approach doesn't work anymore on Spring 5 but because relying on the experts (spring on this case) sounds always like a good plan. That required some reorganization on imports and the hierarchy of repository DAOs, but the experienced behavior when using the DAOs should be the same (with minor renaming of functions due to Spring).

As a summary of big changes:
 * We no longer use the special repository factory bean[2]. We found a cleaner way to do it (and it was incompatible with Spring 5).
 * Some Spring-JPA functions have changed (like find(ID) is now findByID(ID)) which makes small renames all across the source code.
 * Spring-JPA now returns Optional<Entity> instead of Entity or null. More small changes all across the source code (mostly on repository classes).
 * Do not use primitives on the entities properties, use objects. Specially for the identiiers. Spring-JPA-Hibernate is not very primitives friendly and I was having some strange behaviors, specially when entities were not yet persisted and null ID (which can't be null with primitive int instead of Integer). This requires proper equals on all entities.

I have been hinted by Java experts (kudos Eduardo Ramírez and Jorge Barra @jorgejbarra) on many other things we can improve. They were, for example, surprised that we used Integers instead of Longs as identifiers. Specially if the metadata table is going to store millions of records (in some cases). Also on some of the tests we detected issues, like the creation of temporary files with hardcoded paths which made thesauri tests useless once they fail one time. We didn't have time to address any of this yet.

It was a great experience and we hope to repeat it sometime.



_______________________________________________
GeoNetwork-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork