You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by David Williams <da...@linux.vnet.ibm.com> on 2014/10/23 10:42:27 UTC
Question/Suggestion on your OSGi bundles
Greetings,
I work on the Orbit project at Eclipse, where we make "OSGi bundles"
from "third party" software.
And, I've noticed, you yourselves have started to provide OSGi bundles
on your download page -- so that's good! :)
But, you do them a differently than we would in Orbit, or Eclipse, so
thought I'd ask if there is a reason for it, and/or suggest a different
approach.
I first looked at your OSGi bundle for 4.3.5 and was surprised to see it
literally contain all the "prereqs" it needed, including "httpcore",
commons-logging, commons-codec, ... ).
Ordinarily we (at Eclipse) would simply have the OSGi bundle for
"httpclient" "import package" or "require bundle" for it's pre-reqs, but
leave the code separate. Then some other layer would be responsible for
"collecting" what is needed. In our (Eclipse) case, we use often use
"features", but I understand not everyone does, but seems to me, it'd be
better to provide a new bundle, maybe called "httpclient.collection" or
something, if that is the way you wanted to "distribute everything
needed". For Eclipse, we would not even *have* to use features for a
case like this since installers, such as p2, will "install" what ever
the httpclient needs, as long as it's in a reachable repository.
I was especially motivated to write this note after seeing you just come
out with a new version of httpcore (4.3.3) and make me wonder ... are
those fixes included in httpclient 4.3.5, or will there now have to be a
new client at version 4.3.6, just to include the new 4.3.3 core? (And, I
think the answer is "yes" -- though, I see from some JIRA entries, there
may be other reasons to have a 4.3.6 -- but, some of those are in part
related to this very issue I am writing about).
It seems to me to be a better "component model" to leave your OSGi
bundles seperate, and then would "match" your "Java jars" in terms of
content (only adding the OSGi required stuff) and then control the
packaging in some other way -- features, or installers that understood
OSGi required items, etc. -- and either leave that up to the consumer to
do, or if you really wanted to provide "one bundle with everything" to
create a new bundle, called "collection" or similar. I know we (Eclipse)
are only one case but we would not need that "collection" bundle. We'd
just need the pieces.
Given all that, is there a reason you do your bundles the way you do,
that I am just not aware of? Or is there any merit to my suggestion?
Thanks,
Re: Question/Suggestion on your OSGi bundles
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2014-10-24 at 08:58 -0400, Gary Gregory wrote:
> Can we give our users a choice?
>
> - Still produce the existing OSGi bundles as is
> - Make sure our other jars are OSGi-fied.
>
> This would let folks pick to their liking. But that does not sound possible
> without some jar hell?
>
I do not know OSGi well. I can't say. If someone is willing to step in
and do all the work, though, I will not stand in the way.
Oleg
> Gary
>
> On Thu, Oct 23, 2014 at 5:31 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
>
> > On Thu, 2014-10-23 at 04:42 -0400, David Williams wrote:
> > > Greetings,
> > >
> > > I work on the Orbit project at Eclipse, where we make "OSGi bundles"
> > > from "third party" software.
> > >
> > > And, I've noticed, you yourselves have started to provide OSGi bundles
> > > on your download page -- so that's good! :)
> > >
> > > But, you do them a differently than we would in Orbit, or Eclipse, so
> > > thought I'd ask if there is a reason for it, and/or suggest a different
> > > approach.
> > >
> > > I first looked at your OSGi bundle for 4.3.5 and was surprised to see it
> > > literally contain all the "prereqs" it needed, including "httpcore",
> > > commons-logging, commons-codec, ... ).
> > >
> >
> > Hi David
> >
> > 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.
> >
> > > Ordinarily we (at Eclipse) would simply have the OSGi bundle for
> > > "httpclient" "import package" or "require bundle" for it's pre-reqs, but
> > > leave the code separate. Then some other layer would be responsible for
> > > "collecting" what is needed. In our (Eclipse) case, we use often use
> > > "features", but I understand not everyone does, but seems to me, it'd be
> > > better to provide a new bundle, maybe called "httpclient.collection" or
> > > something, if that is the way you wanted to "distribute everything
> > > needed". For Eclipse, we would not even *have* to use features for a
> > > case like this since installers, such as p2, will "install" what ever
> > > the httpclient needs, as long as it's in a reachable repository.
> > >
> > > I was especially motivated to write this note after seeing you just come
> > > out with a new version of httpcore (4.3.3) and make me wonder ... are
> > > those fixes included in httpclient 4.3.5, or will there now have to be a
> > > new client at version 4.3.6, just to include the new 4.3.3 core? (And, I
> > > think the answer is "yes" -- though, I see from some JIRA entries, there
> > > may be other reasons to have a 4.3.6 -- but, some of those are in part
> > > related to this very issue I am writing about).
> > >
> > > It seems to me to be a better "component model" to leave your OSGi
> > > bundles seperate, and then would "match" your "Java jars" in terms of
> > > content (only adding the OSGi required stuff) and then control the
> > > packaging in some other way -- features, or installers that understood
> > > OSGi required items, etc. -- and either leave that up to the consumer to
> > > do, or if you really wanted to provide "one bundle with everything" to
> > > create a new bundle, called "collection" or similar. I know we (Eclipse)
> > > are only one case but we would not need that "collection" bundle. We'd
> > > just need the pieces.
> > >
> > > Given all that, is there a reason you do your bundles the way you do,
> > > that I am just not aware of? Or is there any merit to my suggestion?
> > >
> > > Thanks,
> > >
> >
> > 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.
> >
> > Oleg
> >
> > [1] https://issues.apache.org/jira/browse/HTTPCLIENT-1558
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Question/Suggestion on your OSGi bundles
Posted by Gary Gregory <ga...@gmail.com>.
Can we give our users a choice?
- Still produce the existing OSGi bundles as is
- Make sure our other jars are OSGi-fied.
This would let folks pick to their liking. But that does not sound possible
without some jar hell?
Gary
On Thu, Oct 23, 2014 at 5:31 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Thu, 2014-10-23 at 04:42 -0400, David Williams wrote:
> > Greetings,
> >
> > I work on the Orbit project at Eclipse, where we make "OSGi bundles"
> > from "third party" software.
> >
> > And, I've noticed, you yourselves have started to provide OSGi bundles
> > on your download page -- so that's good! :)
> >
> > But, you do them a differently than we would in Orbit, or Eclipse, so
> > thought I'd ask if there is a reason for it, and/or suggest a different
> > approach.
> >
> > I first looked at your OSGi bundle for 4.3.5 and was surprised to see it
> > literally contain all the "prereqs" it needed, including "httpcore",
> > commons-logging, commons-codec, ... ).
> >
>
> Hi David
>
> 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.
>
> > Ordinarily we (at Eclipse) would simply have the OSGi bundle for
> > "httpclient" "import package" or "require bundle" for it's pre-reqs, but
> > leave the code separate. Then some other layer would be responsible for
> > "collecting" what is needed. In our (Eclipse) case, we use often use
> > "features", but I understand not everyone does, but seems to me, it'd be
> > better to provide a new bundle, maybe called "httpclient.collection" or
> > something, if that is the way you wanted to "distribute everything
> > needed". For Eclipse, we would not even *have* to use features for a
> > case like this since installers, such as p2, will "install" what ever
> > the httpclient needs, as long as it's in a reachable repository.
> >
> > I was especially motivated to write this note after seeing you just come
> > out with a new version of httpcore (4.3.3) and make me wonder ... are
> > those fixes included in httpclient 4.3.5, or will there now have to be a
> > new client at version 4.3.6, just to include the new 4.3.3 core? (And, I
> > think the answer is "yes" -- though, I see from some JIRA entries, there
> > may be other reasons to have a 4.3.6 -- but, some of those are in part
> > related to this very issue I am writing about).
> >
> > It seems to me to be a better "component model" to leave your OSGi
> > bundles seperate, and then would "match" your "Java jars" in terms of
> > content (only adding the OSGi required stuff) and then control the
> > packaging in some other way -- features, or installers that understood
> > OSGi required items, etc. -- and either leave that up to the consumer to
> > do, or if you really wanted to provide "one bundle with everything" to
> > create a new bundle, called "collection" or similar. I know we (Eclipse)
> > are only one case but we would not need that "collection" bundle. We'd
> > just need the pieces.
> >
> > Given all that, is there a reason you do your bundles the way you do,
> > that I am just not aware of? Or is there any merit to my suggestion?
> >
> > Thanks,
> >
>
> 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.
>
> Oleg
>
> [1] https://issues.apache.org/jira/browse/HTTPCLIENT-1558
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Question/Suggestion on your OSGi bundles
Posted by Oleg Kalnichevski <ol...@apache.org>.
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
Re: Question/Suggestion on your OSGi bundles
Posted by David Williams <da...@linux.vnet.ibm.com>.
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
Re: Question/Suggestion on your OSGi bundles
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2014-10-23 at 04:42 -0400, David Williams wrote:
> Greetings,
>
> I work on the Orbit project at Eclipse, where we make "OSGi bundles"
> from "third party" software.
>
> And, I've noticed, you yourselves have started to provide OSGi bundles
> on your download page -- so that's good! :)
>
> But, you do them a differently than we would in Orbit, or Eclipse, so
> thought I'd ask if there is a reason for it, and/or suggest a different
> approach.
>
> I first looked at your OSGi bundle for 4.3.5 and was surprised to see it
> literally contain all the "prereqs" it needed, including "httpcore",
> commons-logging, commons-codec, ... ).
>
Hi David
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.
> Ordinarily we (at Eclipse) would simply have the OSGi bundle for
> "httpclient" "import package" or "require bundle" for it's pre-reqs, but
> leave the code separate. Then some other layer would be responsible for
> "collecting" what is needed. In our (Eclipse) case, we use often use
> "features", but I understand not everyone does, but seems to me, it'd be
> better to provide a new bundle, maybe called "httpclient.collection" or
> something, if that is the way you wanted to "distribute everything
> needed". For Eclipse, we would not even *have* to use features for a
> case like this since installers, such as p2, will "install" what ever
> the httpclient needs, as long as it's in a reachable repository.
>
> I was especially motivated to write this note after seeing you just come
> out with a new version of httpcore (4.3.3) and make me wonder ... are
> those fixes included in httpclient 4.3.5, or will there now have to be a
> new client at version 4.3.6, just to include the new 4.3.3 core? (And, I
> think the answer is "yes" -- though, I see from some JIRA entries, there
> may be other reasons to have a 4.3.6 -- but, some of those are in part
> related to this very issue I am writing about).
>
> It seems to me to be a better "component model" to leave your OSGi
> bundles seperate, and then would "match" your "Java jars" in terms of
> content (only adding the OSGi required stuff) and then control the
> packaging in some other way -- features, or installers that understood
> OSGi required items, etc. -- and either leave that up to the consumer to
> do, or if you really wanted to provide "one bundle with everything" to
> create a new bundle, called "collection" or similar. I know we (Eclipse)
> are only one case but we would not need that "collection" bundle. We'd
> just need the pieces.
>
> Given all that, is there a reason you do your bundles the way you do,
> that I am just not aware of? Or is there any merit to my suggestion?
>
> Thanks,
>
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.
Oleg
[1] https://issues.apache.org/jira/browse/HTTPCLIENT-1558
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org