Jim,
See comments inline.
Simon
Jim Marino wrote:
On Nov 10, 2006, at 10:44 AM, Simon Nash wrote:
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.
There will be others, such as resource host implementations, data
source providers, etc. We would do well to create a solution that will
work now and in the future. I believe the approach of having an Ant
task will do this.
This discussion is not about whether there should be an Ant task.
We have both said that there should be. We are debating whether having
a convenience download packaging would be helpful for some users and
some use cases.
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.
Good so we are on the same page. An Ant task will need to be provided
that can download transitive extension dependencies.
Yes, we are agreed about this.
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.
And we will have bootstrapping code for OSGi containers, potentially a
Geronimo GBean, IntelliJ plugin, Eclipse plugin, etc. This will mean we
have to bundle all of this into the core distro which really breaks
modularity. I wouldn't mind having separate distros for each of these.
Otherwise, the same Ant Task that is required above could be repurposed
for this.
I have not proposed bundling all of these things into a single binary
distro. What is bundled should depend on use cases and how commonly
the various artifacts will be used. We are currently doing a modest
amount of bundling by putting certain extensions into the contrib
directory. So I am not suggesting a new approach here, but extending
the existing approach to include one more very common use case.
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.
I agree that's why I was proposing an Ant task. That would be dead-
simple, avoid a bloated distro with a lot of irrelevant modules, and
would fit into how people do Ant builds without introducing anti-
patterns such as manually copying files from place to place.
As I said, we agree on having an ant task that supports remote
downloading. The debate is about whether very simple cases whould
require remote downloading, which introduces complexities such as the
need for network connectivity and availability of the repositories.
Some users prefer this approach, and others prefer the simplicity of
having things available locally in locations that they can control.
In order to appeal to all types of users, we should accommodate both
styles rather than insist on one particular approach.
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]
