I'd like to add a bit more to this:
(1) Instead of axis2.jar for the base jar, how about axis2-core.jar?
(2) Can we also plan on importing the various axis2-{foo}-{version}.jar
files into ibiblio? Then anyone (e.g., Synapse) who wants a specific
version of the axis2 core, simply puts a dependency on the right jars
and they have it.
Sanjiva.
On Mon, 2006-01-02 at 20:26 +0600, Eran Chinthaka wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Srinath,
>
> Srinath Perera wrote:
>
> > +1 for the proposal
> >
> > 1) in the binary distribution shall we have the security and RM
> > modules included. that way we have the complete WS-Stack re lase.
> > (Or may be we can have a separate dist for that).
>
> How many such modules we gonna include with Axis2 and how can we draw
> a line to decide which modules to include and what not to include.
> Remember we have other WS-* impls like Kandula2. And, I believe that
> RM, Security must be maintained on its own and not within Axis2 (even
> though security is now with Axis2, later that should be moved in to
> WSS4J project).
>
> Lets keep the standard distribution to the minimum from Axis2. If user
> needs those, they can always go to the modules releases page and
> download them.
> But, I accept that Addressing is tightly integrated to Axis2 so its
> worth shipping it with Axis2. At the same time, this will not hinder
> addressing by releasing on its own, without waiting Axis2 to release.
>
> >
> > 2) I believe we should consider XML Beans or JAXB as our principal
> > data binding option. It is usual belief JAXB is faster.May be we
> > should try it too. At least to me data binding is already solved
> > problems and do not worth additional effort.
>
> Agreed. But I don't like to have XMLBeans or JAXB the default. Lets
> have ADB the default, which is the bear minimum and lets keep the
> flexibility to integrate any db framework.
>
> > I think best way to go is provide simple schema support with ADB
> > and ask users to go for JAXB/XMLBeans if they want to handle schema
> > that do not fell in the ADB capablity. If we keep trying add better
> > and better schema support to ADB we might end up creating a mess
> > out of ADB. AFAIK experience with Axis 1.x show maintaining a ADB
> > is a major hassle.
>
> Srinath, I think all the devs are now merging in to your idea. Thats
> why we always say "we have complete simple type support and limited
> complex type support with ADB". Can you remember we agreed to have ADB
> built-in so that user will have out of the box simple data binding
> support. If he is not satisfied with that let him go and plugin
> whatever he wants in to Axis2.
>
> >
> > +1 not include ADB in minimal ..or add it as separate jar.
>
> I agree with Dennis' proposal with the Sanjiva's comments. So let
> leave adb out of the minimal jar and have axis2-adb-version.jar.
>
> - -- Chinthaka
>
> >
> > Thanks Srinath
> >
> > On 1/2/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
> >
> >> On Mon, 2006-01-02 at 21:49 +1300, Dennis Sosnoski wrote:
> >>
> >>> Hi Eran,
> >>>
> >>> I'd really prefer to see ADB kept out of the axis2-xxx.jar.
> >>> This is partially to keep the size to a minimum, but also to
> >>> make sure there aren't any improper ties to the ADB code. Is
> >>> there any reason it can't be kept a separate jar, like the
> >>> other data binding alternatives?
> >>
> >> Good point- how about we keep it as a separate jar, but include
> >> it in the minimal distribution as well? We did ADB as a way to
> >> have some default data binding and so having it around would
> >> support that pattern. However, keeping it as a separate maven
> >> module and jar enforces that we don't take any shortcuts.
> >>
> >> In any case, I proposed that we continue to fully support
> >> XMLBeans data binding as well because ADB does not handle all of
> >> XSD in any case. Once other data binders are available (JibX?) we
> >> should treat them the same way.
> >>
> >> Sanjiva.
> >>
> >>
> >>
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (MingW32)
>
> iD8DBQFDuTgPjON2uBzUhh8RAgLMAKCCs0TMjXu8U2nLoXN6rGU9gKrgJgCgoaMT
> EvNqe88fZVcqkOzpq6HzxzM=
> =iJDF
> -----END PGP SIGNATURE-----
>
