I agree that Tuscany webapps will normally receive or make remote
invocations, and these will require Tuscany extensions and their
dependencies. These extensions and dependencies can be bundled
physically within the war file, or the dependencies can be downloaded
at runtime from an external maven repo. Currently the extensions
can't be downloaded at runtime, but this is something that we could
(and IMO should) support in the future.
The 2 webapp jars are in a different category. They always need to be
physically packaged inside the webapp and can never be downloaded at
runtime.
There are ways around this but there is a broader issue that I
mentioned previously, namely these are not the only things that need
to be provisioned for Ant users who want to have things statically
packaged in the war.
.
This is why they are in a different category than extensions
and dependencies, and should be considered for different treatment
as far as packaging is concerned.
The helloworldws sample (one of those for which I provided an ant
build
script) is an example of the use case I have in mind. It receives
remote invocations over Web services using the Axis2 binding and the
SDO data binding. These Tuscany extensions are packaged inside the
war file, but not their dependencies (either local or transitive).
The Tuscany runtime loads these dependencies from an external maven
repo.
So now for Ant users we require them to use the runtime resolution
mechanism? We've basically punted the problem to the runtime. For me,
we need to address the problem of transitive dependencies when
building the archive. As an Ant user, the latter strike me as more
inline with that build mechanism.
To build the helloworldws war file in this form, my ant script takes
the Tuscany runtime from the atandalone/binary distro, and the Axis2
binding and SDO data binding Tuscany extensions from the contrib
directory of the distro. The only things it currently cannot obtain
from the locally installed distro are the 2 webapp jars. Forcing a
remote download for these two jars, when everything else can be found
locally, makes this common use case considerably more complex for a
first-time or inexperienced user.
The problem is if we require everything locally, as you are
suggesting, we are going to wind up with a kitchen sink distro.
Again, I would suggest we provide an Ant task that can provisioning
any required dependency from a remote repo and assemble a runtime for
any host from the core distribution. Bootstrappers would be
provisioned when the war was created. Note that this does not include
placing boostrap code related to running in a web app into core,
which is inappropriate. It also makes the two use cases you mentioned
below dead-simple as well as reduces the complexity of the Ant script
that would be required to build the archive.
In summary, the ant support for building war files must cover the
following cases:
1. build war files with all required Tuscany extensions and their
dependencies packaged within the war file
2. build war files with all required Tuscany extensions packaged
within the war file, and their dependencies downloaded at runtime
Packaging the 2 webapp jars within the downloadable distro simplifies
the logistics of case 2 for webapps using extensions that we deliver
as part of the distro, which is a common scenario.
What I would recommend doing to help Ant users is to create a
utility that can be invoked from an Ant Task, programmatically,
or from the command line which downloads transitive dependencies
from a Maven repository. As an implementation strategy, the first
place I would look at is just wrapping Maven (or Wagon, the part
that actually does the downloading). I would also keep in mind
that reusing Maven will avoid the trouble of having to write code
that parses and understands Maven POMs. I would also look to see
what can be shared with the Maven War plugin we currently have to
avoid duplicated effort and code.
Yes, I was planning to do something very much along these lines.
Great
I'd like to make clear that I understand the value of modularity
and I strongly support it. We need to have modularity in terms of
both architecture and implementation. But when choosing how we
package our distros, we need to give some consideration to
convenience for our users, especially those who are accustomed
to a conventional dwonloadable binary distribution. I'm not
arguing for the kitchen sink, but for careful consideration
of user scenarios and how our distribution can support common
cases in a convenient manner.
I agree we need to carefully consider the end-user. However, we are
not shipping "conventional binary distributions" typically done in
many commercial software releases. I actually think an Ant script
that automates the assembly of the runtime modules as I mentioned is
actually easier and less complex for end users and is more inline
with the modularity we are trying to achieve.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
