On Apr 11, 2007, at 7:15 PM, Steven E. Harris wrote:
"Richard S. Hall" <[EMAIL PROTECTED]> writes:
Well, you can specify a singleton bundle, then you can only have one
version, but otherwise you are correct.
Ah, I never figured out what the singleton attribute enforced.
Yeah, I don't know who wants these crazy ideas in the spec. ;-)
It seems like you want your metadata to just be a list of URLs to
bundle JAR files, which is why you are unable to check for
overlap.
Right. As I explained in a message I just wrote to felix-dev, my
design intention thus far has been to try to keep explicit mention of
OSGi concepts out of my protocol, to see if the client and server
could just talk in terms of "resources".
Well, I think you could easily abstract these two concepts into an ID
and version, which is pretty generic and would probably map to any
system that has deployment units.
The problem with this idea boils down to lack of idempotence for
bundle installation. Apparently I can't just blindly try to install a
bundle that may already be installed, so I have to know something
about the candidate bundle to figure out what to do with it. That
means either putting that extra "something" on the wire as part of the
protocol, or digging it out of the bundle's JAR manifest myself after
downloading it.
Well, you could construct the location out of the symbolic name and
version, so that you know you will always succeed on your install,
assuming you control all installs. However, then you would have to do
garbage collection of old versions perhaps, since you never would do
an update.
If you assume your metadata includes the symbolic name and version
of the bundle, then it becomes quite easy to check for overlap.
Yes, I see. I'm wrestling with this problem today: Do all my problems
go away if I externalize the symbolic name/version pair as part of the
server's recommendation to the client? Maybe so.
See above. Nearly every deployment unit has a name and version, this
is not just an OSGi concept.
-> richard
--
Steven E. Harris
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
