some random musings...
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).
Hmm, I feel bit upset with this. I personally feel that when you
download something, you should be able to use it out of the box. For
example, when you download Axis2, you should be able to write a sample
without any other worries.