The artifact name does not have to be unique with OSGi bundles. Due to file
system limitations, you cannot place two artifacts with the same name in the
same directory, but with OSGi you can place your artifacts with the same
name in different directories & get them to successfully deploy, provided
that the bundle versions are different.
Anyway, I was not around when module versioning was implemented, and I
strongly feel that trying to derive a version from an artifact is a "tried &
failed" approach. Even Maven does not do that. Just take a look at the
directory structure of a Maven repo. The folder structure reflects the
artifact version, even though you see a number in the artifact that looks
like a version number to a human being.
So, if we are going to implement service versioning, I'd recommend that we
go for a scheme that does not try to derive the version from the artifact.
> > IMHO, service versioning & module versioning are two different things.
> > Module versioning is purely a deployment time concept,
> of course not, we can have two different version of the same module and
> engage the one we want based on our requirement, it is not deployment
> concept, it is also there in run time too.
> > while service versioning is both a deployment & dispatch time concept.
> > So there is no need to follow the same way of implementing it. I also
> > think that deriving the module version from the MAR name is messy, and
> > is not necessarily the best or better way of implementing it.
> There is a way that you can specify the name in the module.xml.
> It may be messy, but we discussed in the mailing list and implement that
> > It should come from the module descriptor; module.xml. Java archives
> > do not have a standard way of having the version name in the artifact.
> > That is why OSGi introduced the bundle version in the manifest file.
> > So, IMO, trying to derive the name from a service, module or any other
> > artifact is a bad practice.
> I do not mind having version number in the services.xml, but I do not
> agree the way Isuru has implemented the version support.
> File name has to be unique right? I mean just because OSGi handle the
> version number using manifest file file name has to have the version
> number of some sort of unique suffix right?
> > Unfortunately, there is no standard for Web service versioning, and
> > there are different ways of implementing it. A popular way is to make
> > the WSDL targetNamespace and/or the types namespace to contain the
> > version.
> I agree, sometime you need to reflect the version form tns and URL.
> > Azeez
> > On Fri, Aug 28, 2009 at 1:34 PM, Deepal jayasinghe <deepalk@gmai... > > <mailto:deepalk@gmai...>> wrote:
> > Hi Isuru,
> > Thank you for taking your time and looking to this issues, but I
> > do not
> > agree the way you have address it, please see my comments below. The
> > reason I am telling this is, as I can see this has so many issues,
> > you have made it complicated too :) . I believe you might know that
> > have version support for modules and we do not handle that like
> > this. So
> > this simply break the consistency, and this introduce new URL
> > patterns ,
> > though you have not encounter now, I am sure you are going to face a
> > number of issues (when it come to dispatching).
> > > Currently Axis2 can only deploy services at the repository/services
> > > level. This makes it impossible to deploy several versions of
> > the same
> > > service.
> > I do not agree, you can have the version name in the aar file, for
> > example foo-1.0.aar and foo-1.1.aar. Then at the deployment time just
> > append the version number to the service name (to make the service
> > name
> > unique)
> > >
> > > Therefore, I've improved our deployment engine to deploy services
> > > looking at the hierarchical path of the service. For example this
> > > allows us to deploy a service
> > repository/services/foo/bar/version.aar.
> > > And also this allows us to deploy any number of services as
> > > repository/services/versionService/1.0.0/version.aar
> > > repository/services/versionService/1.0.1/version.aar
> > Don't you think this is complex ? what is different between
> > "services/versionService/1.0.1/version.aar" and
> > "services/version-1.0.1.aar" ?. As far as I know second one is better
> > than the first one (and you do not need much modification to handle
> > that). Which is the commonly used approach for all sort of version
> > management. (am I missing something?)
> > >
> > > In the implementation, I've attached the hierarchical part of the
> > > service (versionService/1.0.1/) in front of the service name
> > which is
> > > read from the services.xml. And also I've fixed the URI based
> > > dispatching logics to dispatch the services correctly.
> > Then how about addressing based dispatching ?
> > I remember the mess we had when someone introduce portName into
> > the URL,
> > I think we still have issues with that (though no one uses the
> > feature).
> > >
> > > This improvement doesn't affect any of the existing
> > Of course it does? how do you make sure when you change the
> > it does not break any of the existing features ? (we do not have
> > enough
> > test cases to cover all the cases) I think I have enough experience
> > Axis2, what when someone change something hoping that does not break
> > something.
> > > The only limitation of this is we can't deploy a RESTful service in
> > > this manner.
> > This is a problem right?
> > When the system move from one version to other, client will notice
> > that
> > the service does not work any more?
> > > Those can only be supported at repository/service level. That is
> > > because, incoming URL of a RESTful service can contain '/'
> > > parameters to the service.
> > oh boy, you are making system tooooooo, complicated.
> > I am sorry I am -1 on this approach, we need to discuss this
> > before we
> > implement.
> > In fact I remember we had some discussion on this at one of the
> > apachecon, there also we did not come to a conclusion.
> > Thanks,
> > Deepal
> > --
> > Thanks
> > Afkham Azeez
> > Blog: http://afkham.org > > Developer Portal: http://www.wso2.org > > WSAS Blog: http://wso2wsas.blogspot.com > > Company: http://wso2.com > > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
> Thank you!
> http://blogs.deepal.org > http://deepal.org >