hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Williams <david_willi...@linux.vnet.ibm.com>
Subject Re: Question/Suggestion on your OSGi bundles
Date Sun, 26 Oct 2014 21:15:35 GMT
On 10/23/2014 05:31 AM, Oleg Kalnichevski wrote:

Thanks for the comments. [I sent and earlier version of this, note, but 
didn't seem to "go through", I might have used wrong "from" address, or 
"to" address? ... or, perhaps sent in "HTML" form? But, never got any 
sort of "rejection" note either? So, sorry for the delay. I'll see if 
this one goes through.]

 > While inclusion of commons codec code was intentional that of httpcore
 > was not. The problem has been fixed in 4.3.x and trunk [1] but not yet
 > released.

OK, that's good. Is there a plan for when 4.3.6 will be released. If 
soon, I'll wait till then to do any further "Orbit work" and re-consider 
once I see that release. Just curious (i.e. don't change your plans just 
for Orbit :)

 > The model where one Jar equals OSGi bundle seems to completely defeat
 > the whole point of using bundles in my opinion. For instance, in case
 > HttpClient I see no point imposing a dependency on Commons Codec. The
 > fact that HttpClient makes use of Commons Codec internally should be
 > completely irrelevant to HttpClient consumers. OSGi enables us to bundle
 > Base64 codecs of a specific version without imposing the same dependency
 > on the end user.

There's certainly exceptions to every rule, but I think for the most 
part, OSGi experts would disagree. And, I'm not really arguing about 
this specific case ... perhaps you are doing the right thing for your 
needs and the needs of most of your consumers in terms of "commons 
Codec". But, as counter example, (again, for the general case) if there 
happened to be a fix in "commons Codec" then consumers of http client 
would have to wait to get the fix in 'client', until you decided to come 
out with a new release, instead of getting the fix immediately when 
"commons Codec" was released.

An additional, traditional reason for "low level" (small bundles) 
componitization, is that in large applications there may be a large 
number of other bundles that use "commons Codec". If everyone used your 
approach, then that large application would have multiple copies of 
"commons Codec", in theory at different levels, which could lead to 
problems -- if nothing else increasing the size of the large application.

Plus, I'll point out, any modern build or provisioning system, whether 
Eclipse p2, Maven, or OSGi BND (with OSGi repository indexes) makes the 
dependency completely transparent to the user; if it is required, it is 
retrieved, as long as it is in the repository. The user should never 
have to know about it. Occasionally release engineers might need to know 
details about it, depending on the level of detail they want for their 
build reproducibility.

"Commons Codec" isn't the best "counter example", since it is small and 
very stable, but ... the principle still applies. I think in general, if 
there is a bundle provided by others (other projects, such as "commons 
codec" and "commons logging", then those are clear cases you want to 
simply "require" them (via import package, usually).

In some (advanced) cases, there might be reason to "break up" your own 
bundles/jar more, such as "fluent" package is clearly an convenience 
API, an "add on" to the core functionality, that some consumers 
obviously want, but others might not. (Again, just using 'fluent' as an 
example -- not saying you should change that or anything). Again, I was 
most surprised that your "OSGi" version, had substantially different 
content than your "plain jar" version.

Thanks again for your comments and explaining your point of view, and 
listening to mine.

To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message