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):
https://github.com/geonetwork/core-geonetwork/pull/3204
https://github.com/geonetwork/core-geonetwork/pull/3203
https://github.com/geonetwork/core-geonetwork/pull/3202
https://github.com/geonetwork/core-geonetwork/pull/3201
https://github.com/geonetwork/core-geonetwork/pull/3200
https://github.com/geonetwork/core-geonetwork/pull/3199
https://github.com/geonetwork/core-geonetwork/pull/3198
* 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.
[0] https://www.osgeo.org/events/java-2018-code-sprint/
[1] https://www.meetup.com/es-ES/SVQJUG/events/255141249/
[2]
https://github.com/geonetwork/core-geonetwork/blob/spring5/domain/src/main/java/org/fao/geonet/repository/GeonetRepositoryFactoryBean.java