Finally a question I can help with :-)
JP> I have also looked at the osgi spec (btw: there is an open source osgi
JP> implementation I found reasently: oscar-osgi.sf.net ).
JP> The osgi packaging mechanism is a bundle. I didn't get all the details
JP> of the osgi paper, so at this time I can't say anything specific about
JP> versioning other, than it is embedded in the manifest like the weak
JP> versioning spec of j2se 1.3+ (i think). The manifset is used to specify
JP> the version as well as the import and export dependencies.
Versioning in OSGi is done on package level. A bundle can export a
package of a certain level and/or import a package of a certain level.
The OSGi framework assures that you never get a package that has a
lower version than you specify. E.g.
Import-Package: org.xml.sax; specification-version=2.0,
org.osgi.service.log; specification-version=1.0
Export-Package: javax.xml.parsers; specification-version=1.1,
org.osgi.service.log; specification-version=1.2
This is more than just adding an extra dimension because of
the backward compatibility rule. The package versioning is used for
both libraries and components because they are the same in the OSGi.
We are currently finalizing version 3 and the used model seems to work
very well. Many component interfaces had small extensions that fitted
the versioning model well.
.NET is kind of interesting because it allows multiple versions to be
resident at the same time. Which imho may lead to conflicts if the
assembly uses limited resources. I.e. if there is only one physical GPS,
there may be a conflict (I think).
BTW, Espial promised to place their Framework implementation in the
public domain once it passes compliance.
Kind regards.
Peter Kriens
JP> Also .Net (which I don't like much (I prefer java)) has something like
JP> that (nothing fancy):
JP> /* it is enought to just specify an assembly name here, but I would like
JP> to point out that the version exists */
JP> Assembly a = Assembly.Load( "assemblyName, Version=a.b.c.d, ...." );
JP> Object myObject = a.CreateInstance( "MyClass" );
JP> instead of the java variant:
JP> Class c = ClassLoader.loadClass( "MyClass" );
JP> Object myObject = c.newInstance( );
JP> this (.NET) I think ressembles more the shared object (or dll) view,
JP> where you first load the shared object and then look into the shared
JP> object to find the function pointer (or in our case the type).
JP> Way all this?
JP> I would like to see a mechanism, by which java distinguishes the classes
JP> of specific versions, or better by which java uses modules ( or
JP> assemblies, plugins, bundles (however you call them) ) in its core.
JP> You see things like these coming out of every larger java community:
JP> netbeans has that module thing
JP> eclipse uses plugins
JP> osgi ueses bundles
JP> ...
JP> [ don't know about this one: jjar - the "jakarta jar" I've come accross
JP> the other day - it also uses versioning to automatically download the
JP> current jakarta dists of subprojects - still in design phase I think ...
JP> ]
JP> ...
JP> and the problem is you have to wrap everything to be used in netbeans,
JP> to be used in osgi and to be used in eclipse in a different way.
JP> Perhaps I am totally wrong here, and too many mandatory specifications
JP> are wrong, as they kill the openness java has proven, but I think it is
JP> a pitty that the jcp (or sun) has not better specified a mandatory way
JP> to do versioning and module loading.
JP> what are your thoughts about the versioning dilemma?
JP> thank you
JP> -- Jakob
JP> --
JP> To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org>
JP> For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
--
Peter Kriens Tel. +46 30039800
Finnasandsv�gen 22 Fax. +46 30039805
SE-43933 Onsala Mob. +46705950899
--
To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
