Jim,
See comments inline.
Simon
Jim Marino wrote:
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.
.
As far as I know these are the only things (apart from the core Tuscany
runtime and application artifacts) that always need to be physically
packaged within the war. Other things would either not always be
required, or could be downloaded as an alternative to being physically
packaged.
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.
As I said, we should support both build-time and runtime resolution
of extension dependencies for both maven and ant builds. We should
not require ant users to use runtime resolution, but we should support
this as an option. The choice of build tool should not dictate whether
build-time or runtime resolution is used.
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.
I am not suggesting that we should require everything locally. The
discussion is around the bootstrapping code, specifically bootstrapping
for webapps. I am not saying that this code is part of core, but that
it should be made available locally as part of our binary distro for use
in common cases embodied in our samples, just as we make other non-core
code available locally via the contrib directory.
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.
All the examples of downloadable binary distros that I looked at were
from open source projects, not commercial software. There is value
in making something available that is in line with common open source
practice and is familiar to a large category of users, as this will
help to get a broader community engaged with Tuscany. Some of our
users will be familiar with maven and will want to do their builds in
the manner that you describe with remote downloading of everything from
the maven repos, while others will prefer a package that contains at
least the artifacts needed in order to build simple samples. We should
be willing to accommodate the preferences of both kinds of users.
Jim
---------------------------------------------------------------------
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]
