Fwd: Re: [oscar-devel] Packaging Bundles

[Eric S. <eri...@at...>]

On Thursday 06 May 2004 08:38, Richard S. Hall wrote:
> But how would this work for embedded libraries that are not part of
> bundlized. For example, the new version of OBR will embed kXML for
> private use. Thus, people will not be able to compile OBR unless they g=
o
> out and find a version (the right version) of kXML.

The key word here is 'version'.  Bundle object code and source code might
merit different approaches here.  Finding the right version of a dependen=
t
library source which was used to originally compile the bundle can someti=
mes
be problematic.  I would think that option 1 would be appropriate for sou=
rces
since it would reduce/eliminate bundle compilation issues.  Simply run th=
e
build.xml and you're done.  Otherwise, seek and hopefully ye shall find a=
ll
the correct source versions originally used to compile the bundle.  I gue=
ss
you have to weigh the risk versus the cost benefit.  I see a strong benef=
it
at minimal cost, but also a definite risk which can be mitigated.

One other method which I think someone already mentioned is if the reposi=
tory
could contain bundlized dependent libraries, which would be downloaded
automagically as well, in the same manner that the binary installs are do=
ne.
The versioning issue doesn't completely go away however, as OSGi's concep=
t of
versioning assumes backward compatibility.  So unless we can also have th=
e
repository download the specific dependent library versions ( not OSGi
considered 'compatible' versions ), then I'd prefer option 1.

Eric