Re[2]: services, bundles and versioning

[Peter Kriens <Pe...@aQute.se>]

JP> plus I think versioning should not be done on a per class basis (just as
JP> you release components (like xalan, xerces) in jar bundles of classes),
JP> the version should state the version of the bundle as a whole.
In my experience package versioning works better, it seems to have the
best granularity, especially when the framework can share packages.

Kind regards,

     Peter Kriens






>> 
>> What problem is versioning supposed to solve? I see only one answer:
>> 
>> * name space extension, in other words, not only do you specify that you
>>   need X you also specify that you want X-V.
>> 
>> Then we add some arbitrary rules saying that V is compatible with a
>> range of values that client specifies in during lookup (i.e. lookup for
>> 3.0 can be satisfied by 3.anything)

JP> ok.
JP> if you mean on a bundle basis - it's ok. on a class basis it can be
JP> cumbersome to implement.

JP> note: by bundle I mean module or plugin, or assembly ...


JP> but a more cop way would be interesting too:

JP> a simple interface:

JP> interface Version {
JP>         /* or getRole( ) */
JP>         String  getSpecificationID( ) ;
JP>         boolean isCompatibleWith( BundleId, Version x ) ; 

JP> }

JP> and an implementation in the module, which by default has
JP> metainformation, e.g. a manifest or something like that.


JP>  Bundle-Specification:  aa-abbb--cc--cas        #a unique bundle id

JP>  #which takes care of answering version question, 
JP>  #implements the Version interface 
JP>  Version:               org.my.impl.VersionImpl 

JP> the question here is if a mechanism like this can be implemented
JP> efficiently in the current jar loading policy.
JP> you probably have to override the classloader to only load that
JP> VersionImpl out of the jar file and forget the rest for the checking of
JP> the versioning.

JP> if it maches than you can load the jar.
JP> I would also suggest that every bundle has a unique id, a bundle
JP> specification id which is the same for minor version but differs for
JP> major version.

JP> or in avalon terms: a bundle role id....

JP> the bundle id is used to sort out the bundles which are totally
JP> differnent and not compatible to the bundle needed. (this should speed
JP> up things a bit ).

JP> just my $0.02

>> 
>> Versioning in Avalon.
>> 
>> The only place in Avalon where versioning I see applies is component
>> versioning. But we have better ways of determining component
>> compatibility: component roles. So, instead of creating versioned
>> interfaces we simply create *different* interfaces (java
>> interfaces).
>> 
>> The Role interface becomes fixed once and for eternity along with all
>> contracts surrounding it. Event that normally triggers incompatible
>> version bump up is an incompatible interfaced change, but in this case
>> you simply produce a *different* Role interface. The old client wouldn't
>> be able to use the new implementation anyway (it's incompatible).
>> 
>> What's wrong with this model? 

JP> okay I get your point.

JP> but then you also have a configuration of, say the excalibur container,
JP> or the new fortress (which I really like) and have:

JP> <component role="x.y.z" class="a.b.c" />

JP> now the problem is again that you have only the FQCN to denote the
JP> identity of the implementation, and the Excalibur Container loads it by 

JP> Class.forName( "a.b.c" );

JP> so there is no way the VM can tell you whether to prefer bundle A or
JP> bundle B, which both provide the class "a.b.c"


>> 
>>     Jakob> And, the Package class (in the reflectioning api) is only
>>     Jakob> available, when a class of that package already got loaded so
>>     Jakob> you could only do versioning by using a separate "throw away"
>>     Jakob> class loader, in order to get rid of a class that does not
>>     Jakob> have the right version.
>> 
>> And class level is not the right place to put versioning at all in my
>> view. Moreover, having explicit versions specification in the code is a
>> plain violation of IoC (or so my understanding of IoC tells me).
>> 
JP> yes that's true. I totally agree with you.

>>     Jakob> this (.NET) I think ressembles more the shared object (or
>>     Jakob> dll) view, where you first load the shared object and then
>>     Jakob> look into the shared object to find the function pointer (or
>>     Jakob> in our case the type).
>> 
>> Anybody else feeling that those are hacks from pre-historic era of
>> weakly typed dynamic libraries don't apply anymore?
>> 
>>     Jakob> and the problem is you have to wrap everything to be used in
>>     Jakob> netbeans, to be used in osgi and to be used in eclipse in a
>>     Jakob> different way.
>> 
>> Most likely because they have totally different component models, no?
>> 
JP> granted, but there is something that applies to all:

JP> * bundling of classes and interfaces
JP> * versioning and compatibilty checking

JP> for instance:

JP> org.netbeans.modules.ModuleInfo
JP>         has 
JP>                 getCodeNameBase( ) /* the module name */
JP>                 getImplementationVersion( )  /*the version of the impl*/
JP>                 getSpecificationVersion( ) /* the version of the spec */
        
JP> org.eclipse.core.runtime.IPluginDescriptor 
JP>         has
JP>                 getPluginVersionIdentifier( )   /* the versioning of the plugin */
JP>                 getUniqueIdentifier( ) /* the unique id of the plugin */
                

JP> org.eclipse.core.runtime.PluginVersionIdentifier
JP>         has
JP>                 getMajorComponent, getMinorComponent, ...
JP>                 isEquivalentTo( PluginVersionIdentifier rhs )
JP>                 isCompatibleWith( PluginVersionIdentifer rhs )


JP> and this could be abstracted in a core. ( I like the eclipse framework)

JP> plus it is only useful when everybody agrees on it. 
JP> that is my criticism on the current java way - it can be done and is
JP> implemented but differently in different environments.

>> Thanks
>> Greg
>> 
>> --
>> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>> For additional commands, e-mail: <ma...@jakarta.apache.org>




JP> --
JP> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
JP> For additional commands, e-mail: <ma...@jakarta.apache.org>


-- 
Peter Kriens                              Tel. +46 30039800
Finnasandsvägen 22                        Fax. +46 30039805
SE-43933 Onsala                           Mob. +46705950899


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>