[axis2] versioning modules

[Sanjiva Weerawarana <sa...@opensource.lk>]

NOTE: I'm talking about Axis2 modules (.mar files) and not maven modules
in Axis2 :).

We currently use the name of the module "foo" to locate the .mar file
for it ("foo.mar"). That approach does not permit versioning of modules,
which I think is going to be critical for long term maintenance of
modules.

So, I'd like to suggest that we follow the Maven approach and name
modules with two components: a name and a version string. The actual
name of the .mar will then be:
	{name}-{version}.mar

In order to support this, the axis.xml and service.xml files will need
to have the version number indicated. Furthermore the engageModule API
will need to take a second string which is a version number.

I do not recommend that we enforce a specific format for the version
string as I don't think its necessary .. not sure whether Maven requires
a specific format; I'm happy to defer to the approach taken by Maven.

If the user does not indicate a version then we have a choice of
behavior: either fail or pick a version ourselves. I prefer simply
failing. Keep it simple.

Thoughts?

Sanjiva.

Re: [axis2] versioning modules

[Sanjiva Weerawarana <sa...@opensource.lk>]

On Sun, 2005-10-23 at 22:50 -0400, Glen Daniels wrote:
> Well, really "simple" would be simply integrating versions, if you want 
> them, into the names of the modules/jars themselves, instead of building 
> a versioning framework... wouldn't it? :)  I.e. take a "uri-like" 
> approach - if I want to call something "addressing-v2", no problem, just 
> as there's no problem with my calling something "addressing".
> 
> I'm not -1 to the idea of versioning, I'm just not sure we're gonna need 
> much beyond the ability to arbitrarily name modules.  It seems like 
> Sanjiva is saying you should *have* to specify a particular version when 
> you refer to a module - if that's the case, what's the difference 
> between <module ref="addressing" version="2"/> and <module 
> ref="addressing2"/>?

The big difference is that we recognize in the core the idea of
versioning of modules.

I don't think we can sweep versioning under the rug saying "name them
appropriately." Clearly Paul Downey (of WSDL WG fame) hasn't had enough
effect on you yet ;-). 

> If I'm understanding you correctly, you'd have:
> 
> $AXIS2_HOME/
>      axis2.xml:
>           <module ref="addressing"/>
>      module-default-versions:
>           addressing=1.2
>           security=1.0
>           ...etc
> 
> Then you could continue using "addressing", and updating the default 
> versions file would cause the engine to select a different jar.  Is that 
> right?
> 
> Seems OK, if a little complex.

+1 that this is a good convenience for users; all they care is that
"addressing" is enabled .. which version is up to the system
administrator.

Sanjiva.

Re: [axis2] versioning modules

[Glen Daniels <gl...@thoughtcraft.com>]

Hey guys:

>>If the user does not indicate a version then we have a choice of
>>behavior: either fail or pick a version ourselves. I prefer simply
>>failing. Keep it simple.

Well, really "simple" would be simply integrating versions, if you want 
them, into the names of the modules/jars themselves, instead of building 
a versioning framework... wouldn't it? :)  I.e. take a "uri-like" 
approach - if I want to call something "addressing-v2", no problem, just 
as there's no problem with my calling something "addressing".

I'm not -1 to the idea of versioning, I'm just not sure we're gonna need 
much beyond the ability to arbitrarily name modules.  It seems like 
Sanjiva is saying you should *have* to specify a particular version when 
you refer to a module - if that's the case, what's the difference 
between <module ref="addressing" version="2"/> and <module 
ref="addressing2"/>?

 > [...]
> BTW, we can do something like this. We can mention the default versions
> of all the modules that will be used in a config file. We do the same
> thing for maven jar versioning. So that user must first mention default
> versions for modules, system level in that file, but he has the
> flexibility to change it anytime in the run time.

If I'm understanding you correctly, you'd have:

$AXIS2_HOME/
     axis2.xml:
          <module ref="addressing"/>
     module-default-versions:
          addressing=1.2
          security=1.0
          ...etc

Then you could continue using "addressing", and updating the default 
versions file would cause the engine to select a different jar.  Is that 
right?

Seems OK, if a little complex.

--Glen

Re: [axis2] versioning modules

[Eran Chinthaka <ch...@opensource.lk>]

Sanjiva Weerawarana wrote:

>NOTE: I'm talking about Axis2 modules (.mar files) and not maven modules
>in Axis2 :).
>
>We currently use the name of the module "foo" to locate the .mar file
>for it ("foo.mar"). That approach does not permit versioning of modules,
>which I think is going to be critical for long term maintenance of
>modules.
>
>  
>
+1.

>So, I'd like to suggest that we follow the Maven approach and name
>modules with two components: a name and a version string. The actual
>name of the .mar will then be:
>	{name}-{version}.mar
>
>In order to support this, the axis.xml and service.xml files will need
>to have the version number indicated. Furthermore the engageModule API
>will need to take a second string which is a version number.
>
>I do not recommend that we enforce a specific format for the version
>string as I don't think its necessary .. not sure whether Maven requires
>a specific format; I'm happy to defer to the approach taken by Maven.
>  
>
Maven doesn't require any format. It will just pickup whatever string
under the version tag and append to the name of the jar file.

>If the user does not indicate a version then we have a choice of
>behavior: either fail or pick a version ourselves. I prefer simply
>failing. Keep it simple.
>  
>
Failing is better, so that engine need not know anything about the
module. For example, if the security module version is not given, how
can the engine know which version to pick up by default. But we can do a
small hacking where engine knows the compatible versions of some "well
known" modules. But this will be inconsistent as engine knows about some
modules and not know about some others.
BTW, we can do something like this. We can mention the default versions
of all the modules that will be used in a config file. We do the same
thing for maven jar versioning. So that user must first mention default
versions for modules, system level in that file, but he has the
flexibility to change it anytime in the run time.

-- Chinthaka

>Thoughts?
>
>Sanjiva.
>
>
>
>
>  
>