| Re: [udig-dev] sprint update |
Hendrik, that's exactly what I have in mind. Separate features to have a much smaller foodprint of udig for integration. It would make it possible to choose only features the customer needs.
I totally agree to start with this vision so we have a goal to achieve. IMHO we can address these requirements after he first release from LocationTech
Your' re invited to help/ support or even review and test. Hope we can join forces
with other words, its worth to put it on the roadmap
--
Frank
If working with the libs already, another idea you once wrote to the list was using serviceloading in osgi in order to get the huge libs folder split and gain performance in cases where only a small number of geotools features is needed. Your mail was:
--
It looks like there may be a solution to using GeoTools in OSGi.
* http://coderthoughts.blogspot.com/2011/08/javautilserviceloader-in-osgi.html
* http://aries.apache.org/modules/spi-fly.html
Thanks to Rich Fecher at the code-sprint for pointing this out.
--
I also would love to see udig being split into more features: e.g. a wfs feature, a wms feature, a shapefile feature, … with those features bundling all the plugins (data access, rendering) needed for that functionality. But that is probably far off topic from your question… Splitting the core jars apart would be a nice first step, but in my opinion a future vision how udig should be packaged should drive the decision on how to implement the split in practice.
Hendrik Peilke
What do you think about creating fragments and register theses for host "org.locationtech.udig.libs" *.addon.<aspect>
So they having the same classloader and acting together like one bundle. Not sure if it is possible to merge Manifest content.
Going to prototype it that we have an examplte to discuss with
--
Frank
2016-01-27 8:37 GMT+01:00 Jody Garnett <jody.garnett@xxxxxxxxx>:
I am experimenting (https://github.com/locationtech/udig-platform/tree/libs.geotools) with breaking "libs" into two modules:
- libs.geotools - the geotools 14.1 jars and their friends
- libs - assorted jars needed by plugins scattered throughout the udig codebase
Oh just so everyone does not get confused, based on my experience so far I think I should rename these the other way around - make org.locationtech.udig.libs - contain geotools and the "core" libs, and make a new plugin for scattered jars ... I just do not have a good name in mind yet. Suggestions? org.locationtech.udig.libs2, org.locationtech.udig.libs.common, etc...
_______________________________________________
udig-dev mailing list
udig-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://locationtech.org/mailman/listinfo/udig-dev
IBYKUS AG für Informationstechnologie, Erfurt / HRB 108616 - D-Jena / Vorstand: Helmut C. Henkel, Dr. Lutz Richter
Vorsitzender des Aufsichtsrates: Dr. Wolfgang Habel