axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deepal Jayasinghe <>
Subject Re: Extensions to Axis2/Java deployment engine
Date Fri, 13 Jun 2008 07:40:05 GMT

> OK, so I disagree with this position. Yes, we get lots of downloads,
> but those are of releases, 
Yes, they download the release , because they happy what Axis2 does. If 
they need any more feature they will ask about that. And I know a number 
of users have asked about various things and they have created JIRA for 
> and no-one is suggesting that big changes
> should go in just before a release. 
I agree.
> I don't believe we would release
> if something as fundamental as module deploy was broken - is there
> some approach we can come up with that allows further innovation in
> Axis2 without putting our release users at risk? What do you think?
Well , I have very good past experienced about Axis2 , if we change 
something then we can not guarantee that  all the stuff worked before 
will work as it is. So if we do not see a problem with the way Axis2 
works now , then let it be. Why we change that just because we think we 
need to change. Our first priority should be our user community , if 
they want something then we should consider doing that else , we should 
not do critical changes to place like Kernel.
> I personally think that OSGI is beyond just *cool* - It's the
> foundation for a number of Java web services hosting environments
> (including, but not limited to: Glassfish, SpringSource App Platform,
> WebSphere, JOnAS, and BEA) and so better integration with it will be a
> good thing.
Oh no. Axis2 is not place where we copy idea from here and there. BTW 
that web service stack has that cool feature how about we also doing 
that is not there in Axis2, was not something we have followed. But I 
know some of the Web service stack copied a number of things from us. 
Which is ok , in open source software development.  So if we want OSGi 
since other web services stacks has that then we should think this twice.

I never ever told that it is a bad idea to have OSGi support , I even +1 
for that. But only thing I am telling is lets do that out side the core. 
Lets have a new module and handle OSGi support there. And do a separate 
release artifact based on OSGi , what do you think about that ?

Thank you!

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message