-
-
Notifications
You must be signed in to change notification settings - Fork 489
Decoupling
Jesse Eichar edited this page Mar 19, 2015
·
2 revisions
As a developer I'd like to explore to what extent decoupling of GeoNetwork components is possible over the short term and the long term and what that would look like. I think that there are potentially multiple levels of decoupling. At one level is a kind of "maven" artifact level of GeoNetwork libraries. At another is decoupling at the level of more or less self-contained modules that can run independently. Perhaps there are other ways to acheive the same or similar functionality as well. Some motivations are:
- reuse: a developer can use the same libraries in a customized application
- sustainability: developers on other projects that use the library or module can contribute back to parts of GeoNetwork without needing an understanding of the whole; it also broadens the GeoNetwork umbrella
- scalability: modules can be deployed across servers, etc.
- users may want or need some GeoNetwork components but be required to use proprietary/alternative components for others
Consideration:
- Migrating spring MVC will simplify because config & resources code, etc.. can be in single module
- Wro4j configuration files to be auto-discoverable within a jar or within the webapp
- convention based lookup for the configuration
If you have some comments, start a discussion, raise an issue or use one of our other communication channels to talk to us.