On Nov 7, 2006, at 8:03 AM, ant elder wrote:
I understand why the jars are there Jim, actually the servlet one
is due to
the current design of the axis binding not the kernel ServletHost,
ServletHost is also referenced by other extensions as it is assumed
to be part of the host spi so it's not just Axis.
and I
think we all understand that ultimately a kitchen sink distro isn't
going to
work, but thats _ultimately_, right now today in M2 we don't have
JAXB and
JPA and JMS and all the other things you mention, and we also don't
have the
things to help that you mention completed yet such as the maven
artifact
repository stuff or multi-parent classloader support.
That's not the point. One of the primary goals of this release was
modularity. This breaks that.
Given that, for this
M2 release it may be easiest to just include the webapp jars as we
have
already done with the other ones. What is an alternative solution that
you're suggesting?
Use Maven or the artifact repository Meraaj and Jeremy worked on.
Jim
...ant
On 11/7/06, Jim Marino <[EMAIL PROTECTED]> wrote:
On Nov 7, 2006, at 6:13 AM, ant elder wrote:
> On 11/7/06, Simon Nash <[EMAIL PROTECTED]> wrote:
>
> webapp-1.0-incubator-M2-SNAPSHOT.jar
>> webapp-host-1.0-incubator-M2-SNAPSHOT.jar
>> are not present in the standalone launcher (the rest are). In
order
>> to avoid the need for ant users to download these jars from a
maven
>> repo, I'd like to propose adding them to the binary distro. For
>> example, they could go in a new webapp directory. They are not
large
>> and they would not impact use of the binary distro as a standalone
>> Tuscany launcher.
>
>
> I think the issue here is what is our binary distro in M2, is it
> just the
> standalone distro or something more? Some previous discussion have
> been
> sounding like the binary distro is just the standalone distro,
i'm not
> convinced thats true or a good idea. The current name is ...-
bin not
> ...-standalone and it already includes the servlet jar and things
> like SDO.
>
They contain SDO because of a hack and should not, specifically the
jars need to be crammed on the system classpath because we have not
yet implemented multi-parent classloading. Once this is in place,
they can be removed.
As for servlet jar, that is required by the Kernel for ServletHost.
We could factor that out as well moving forward.
> If we don't include the two tuscany webapp jars in the bin distro
> we release
> then how do we get them released officially with an ipmc vote?
>
> Being pragmatic the easiest way to fix this particular problem
> probably is
> to just also include the two tuscany webapp jars as well. And if
> we're going
> down that route why not also add the javadoc and prebuilt samples
> as well so
> we have a really easy to use binary M2 release :)
>
And then the problem we have is we wind up with the monolith we tried
to avoid based on all of the modularity discussions. As you mentioned
below, when we include BigBank, we drag in DAS. In the future, when
we have additional samples such as a BigBank that uses JPA, we will
need to included those as well. Multiply that with JAXB, other web
services stacks, JMS, etc. The "kitchen sink" approach ultimately is
not going to work with the type of extensible runtime that we have.
Instead of creating a monolith, this can be solved (better IMO) by
having the runtime dynamically provision extensions based on the
Maven Artifact repository service that Meeraj and Jeremy worked on.
Jeremy had very strong opinions on how this should be done; as our
release manager for M2, before making any significant changes to the
branch we should clear it with him. He mentioned he will be back
online Thursday.
Jim
> ...ant
>
> PS. Whats going to happen when trying to build bigbank with ant and
> the DAS
> jars are required?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
