hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Question/Suggestion on your OSGi bundles
Date Fri, 24 Oct 2014 15:08:47 GMT
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 <olegk@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


Mime
View raw message