> -----Ursprüngliche Nachricht----- > Von: Jody Garnett [mailto:[EMAIL PROTECTED] > Gesendet: Sonntag, 7. September 2008 18:50 > An: Wellmann, Harald > Cc: User-friendly Desktop Internet GIS > Betreff: Re: External dependencies in net.refractions.udig.libs > > Wellmann, Harald wrote: > > Here are some intermediate results on using the FactorySPI > pattern in an OSGi environment: > > > > - I've verified that it works as expected as long as you do > not use wrapped JARs in your bundles and configure buddy > classloading appropriately. > > > Sweet! > > - OSGifying all of Geotools will be harder than expected > due to a considerable number of split packages in Geotools. > > > What do you mean by a split package - or should I just wait > for the article... > > Step 3) could be equally straightforward if Geotools would > take care to avoid split packages. (A split package is a Java > package occurring in more than one OSGi bundle, e.g. > org.geotools.factory in gt-main AND in gt-metadata). There > are ways of dealing with split packages both in OSGI and in > the maven-bundle-plugin and I'm about 95 % convinced that you > could make it work after careful analysis of the package > structure and some manual work in the POMs, but it would > probably be a lot easier to simply make package names > globally unique within Geotools. > > > Unfortantly we have a few places where developers have used > "package visibility" to make abstract base classes usable to > implementors (ie other modules that are implementing a > subclass in the same package) - but not to users who do not > really want to be troubled with the implementation details. > We can make a good argument that this is an Idea that has not > become fashionable in Java development (although at one time > it was recommended practise). >
There is nothing wrong with that, only there is a conflict with the OSGi recommendation "no split packages". So if you want your derived classes to reside in a separate bundle (which enables you to leave out the bundle from your deployment if you don't need it) then your package interface becomes a bundle interface, and so it should be public. The real question is: Geotools is now partitioned into plain old libraries or JARs, some of which are optional. uDig packs all Geotools libs into one bundle (together with other third party stuff). I've tried so far to build one bundle per lib. But is this really the optimum partitioning for OSGi? Even if we stick with one bundle per lib, it would be a good thing to restrict exports. For simplicity, I've simply exported all existing packages from each bundle. Without the Geotools expertise to tell at glance whether or not a given package is only used within the same package, I wouldn't have any other choice, except using a static analysis tool like Classycle. > I do not understand the difference between bundle and package > ... it sounds like you are talking about something very specific. Well, a package is just a plain old Java package, and a bundle is an OSGi bundle, i.e. a JAR with some special manifest headers which can be deployed into any OSGi framework. Usually, a bundle contains one or more Java packages, and a bundle also is an architectural unit with its own visibility rules. (Unfortunately, Eclipse has blurred the terminology by calling bundles plug-ins.) Actually, this is the whole point why I use OSGi in my projects. Java packages are too fine-grained to act as architecture building blocks, and once a package has public classes, you cannot prevent anyone from using them anywhere they like, so you are bound to end up with a mess of building blocks with cyclic dependencies. OSGi gives you a component model with just adequate granularity and it prevents cyclic dependencies from the start. (At runtime, you cannot resolve a bundle with cyclic dependencies. If you work with Eclipse PDE, this check already happens at compile time.) The component model is about 5 % of OSGi functionality, and even if you don't use all the rest, this alone is very valuable I think. Classloader issues are the only downside to it, but there is always a price to pay... > > That is an amazing amount of work - thanks for the > dedication. You may want to start your wiki page with just > the contents of your email; it is very clear and the GeoTools > community already has some background knowledge of the problem. > Oh well, as I said, I started using Geotools and uDig in my own project, and I'm trying to keep my house clean, if I can ;-) Geotools is not the only external dependency I had to osgify manually, and of course it always better when things get cleaned up at the source. I'm going to write that wiki page and post the link on this list. Regards, Harald ******************************************* innovative systems GmbH Navigation-Multimedia Geschaeftsfuehrung: Edwin Summers - Kevin Brown - Regis Baudot Sitz der Gesellschaft: Hamburg - Registergericht: Hamburg HRB 59980 ******************************************* Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. ******************************************* _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
