[prev in list] [next in list] [prev in thread] [next in thread] 

List:       httpclient-commons-dev
Subject:    Re: Question/Suggestion on your OSGi bundles
From:       Oleg Kalnichevski <olegk () apache ! org>
Date:       2014-10-29 8:54:59
Message-ID: 1414572899.2513.21.camel () ubuntu
[Download RAW message or body]

On Sun, 2014-10-26 at 17:15 -0400, David Williams wrote:
> 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 :)
> 

I would like to cut 4.3.6 release this weekend.

>  > 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.
> 

This is no different from any bug in HC which may or may not deserve an
immediate release.

> 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.
> 

I find the application size argument really not convincing. Who these
days care about a few extra bytes of external storage even in the
context of mobile devices? It has no impact on the memory footprint of
the application, as unused classes never get loaded into memory.

> 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.
> 

Again, in my opinion 'one maven artifact equals one OSGi bundle'
principle makes OSGi almost useless compared to just using plain Maven
based application assemblies. However, you are very welcome to fork
HttpClient on GitHub, completely redesign existing OSGi bundles and
raise a PR. 

Just one remark: httpmime and hc-fluent modules are very likely to get
folded into httpclient module in 5.0. They are being kept separate in
4.x simply due to historical reasons. A separate OSGi bundle for the
caching module may be a good idea, though.

Oleg 



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

[prev in list] [next in list] [prev in thread] [next in thread]