On 10/24/05, Eran Chinthaka <[EMAIL PROTECTED]> wrote:
Hi all,
We all know that we have a small problem with our packaging of distros.
We were telling lot of things about this here and there, but no solid
solution so far.
IMHO this is part is of a bigger problem concerning java and the wider FOSS infrastructure and AFAIK there are no really good solutions.
the bigger question is: what's the right way for axis2 to fit into the wider downstream infrastructure?
So I'd like to propose two things, for you to start with. Do not take
these hard and these are just ideas came to my mind which are open to
discussion ( Opening up a defensive port ;-) )
1. Shall we not ship modules other than WS-A with Axis2 distros. What I
would like to see is, we host our module download page with version
numbers as Sanjiva proposing in the other thread. And module authors are
responsible for maintaining compatible versions. For example, Security
or Sandesha people can announce their own versions or releases with the
compatible Axis2 versions.
So the proposal is not to ship modules other than WS-A with Axis2 and
make the compatible versions downloadable.
i think that it's clear that once the axis2 core is stable then the modules are going to require more frequent releases than the core. it's likely to become difficult to coordinate release cycles between different modules. therefore i think that each module will need to be able to be released independently.
it may be worth considering that in the short term, the core module may actually need a faster release cycle than more of the other modules: as the product take-up increases and is tested in production, it's inevitable that bugs are going to need to be fixed.
perhaps there is merit in decoupling the releases and versions numbers of the different modules from releases of Axis2 (as a headline product).
one possibility would be to tie everything together with less frequent headline Axis2 releases (comprising releases of modules which are known to interoperate) and then let modules release more frequently in their own right. this approach would allow (for example) the core to go 1.0 before the porting work has been completed for an Axis2 1.0 release containing functionality similar. experts would then roll their own versions including the latest and greatest module releases whereas other could wait for the slower Axis2 release cycle.
systematic version numbers could be used to tie everything together.
2. Shall we make our Axis2.war file a separate download, and not putting
it in dist-bin ? Some people may need only the war file and they can
download it without downloading the whole dist-bin.
people have been talking about CPAN for Java for years and years but it's never really gained any momentum. the maven repository exists somewhere in that solution space but IMHO doesn't really covered it.
i've been wondering whether one possible approach might be to ask people to build (using ant or maven) some of the artifacts themselves. we could ship maven project.xml's (or ant build scripts) which would then download and build the required artifacts. this would allow various standard, tested recipies to be included as part of a release without having to include lots of jars. perhaps this is a way to satisfy the competing demands of newbies and evaluators (who want everything and just to work) and minimalists (who want just the bare bones so that they can add only what they need).
as always, opinions are encouraged :)
- robert
