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.
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.
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.
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.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
