I was not suggesting a "kitchen sink" approach, only the inclusion
in the binary distro of 2 small extra runtime jar files that all
our users who create webapps will need.
I understand that our strategy for loading extension dependencies
is to use the runtime support for accessing a remote or embedded
Maven artifact repository that Meeraj and Jeremy worked on. I'm not
proposing that we change this strategy.
The challenge I'm facing in adding some support for building Tuscany
applications with ant is not a runtime issue but a build-time one.
For simple Tuscany webapps, I am very close to being able to build
these webapps from the binary distro and a simple ant script using only
built-in tasks. It is only the lack of these 2 webapp jar files in
the binary distro that is preventing this, since without them in the
binary distro, the ant script would need to download them from a remote
maven repo. This requires the use of a custom Ant task as well as the
need for live internet connectivity. This makes the ant build process
and the user's getting started experience a lot more complex. By adding
these 2 jars to the binary distro, we enable ant users to build simple
Tuscany webapps without needing to deal with custom Ant tasks,
dependency management, or remote maven repos.
For more complex webapps with external dependencies that we are not
delivering in our binary distro, we also need a way to build these
using ant. When I have completed the simple case without dependencies,
I will start work on this case. I have begun to investigate possible
options, which will necessarily be more complex than the simple case
where there are no dependencies. I'd like to give our users a simple
experience for doing simple things, and reserve the more complex
experience for doing more complex things.
I hope this explains why it would be very helpful from a user
perspective to have these 2 jars in the binary distro. This is a
separate issue from adding the other things that Ant mentioned.
Simon
Jim Marino 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]
>
>
>
--
Simon C Nash IBM Distinguished Engineer
Hursley Park, Winchester, UK [EMAIL PROTECTED]
Tel. +44-1962-815156 Fax +44-1962-818999
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]