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: [email protected]
For additional commands, e-mail: [email protected]
