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.
