There are of course limits and they come very quick to what you can do
to modify a jar file.
Mike
Sent from my iPhone
On Nov 18, 2009, at 4:53 PM, Dennis Reedy <[email protected]>
wrote:
So if this information is produced at build time, added into a jar's
manifest, what is the difference with using a convention of
something like a maven artifact to provide version and update support?
On Nov 18, 2009, at 744PM, Peter Firmstone wrote:
I've been having a private email discussion with one of the OSGi
people, he instantly understood my problem domain. They also have
pondered the problem of Binary compatibility over time and the
potential of static analysis.
I guess that makes sense as this is really the problem domain of
OSGi, not jini, it was suggested that results from static analysis
performed at build time should be included as additional metadata
in bundles. That changes my implementation, I was going to perform
the static analysis at the codebase, however this should be done at
build time. Having said that, it would be still useful to confirm
the metadata is correct using static analysis at the codebase for
security reasons.
Quote: "I think this is worthwhile for OSGi. It probably fits in
the area of management agents, i.e., you could build some
functionality on top of OSGi that uses this additional information
for deploying updates."
So I guess that jini codebase services that distribute OSGi bundles
would be very useful for code evolution over time in a distributed
environment where OSGi is used to control local JVM package
visibility and sharing of compatible bytecode between jini services.
The best part about OSGi bundles is that developers aren't forced
to use OSGi or the metadata, bundles can still be used as ordinary
jar files.
Cheers,
Peter.
