Jim,
See my comments inline.
Simon
Jim Marino wrote:
On Nov 7, 2006, at 10:43 AM, Simon Nash wrote:
Jeremy,
Thanks for the quick response.
I am trying to be pragmatic here and deal with simple use cases.
I haven't yet worked out the best way to deal with external or
transitive dependencies from an ant build environment (though
I do have some thoughts), but having a complete story for this
is not needed to build a simple webapp.
It seems that if you go down this route you will wind up re-inventing
Maven. Maven seems simple enough to me.
I had not intended to reinvent maven. I was thinking more in terms
of something that enables ant scripts to find dependencies in maven
repos and package these in the embedded repo within the war file.
I'm looking at various options for how best to do this in a way that
is most convenient from the perspective of ant users.
Adding these 2 jars
would be a simple change that would make the "first use" encounter
with Tuscany quite a bit easier for ant users.
Both Jeremy and Raymond pointed out the issue about working from a
standalone distribution.
>
Please see my comment to Raymond on this. I'd like to explore why
it wouldn't be appropriate to have a binary distro that could be used
for both purposes.
There is a further issue that statically
cramming things into the distribution is not going to solve. Namely,
moving forward, these jars are not going to be the only things required
to run in a web app in many of the common usage scenarios. For example,
there will also be pure-Tuscany things like a JNDI-based implementation
of ResourceHost to support the @Resource tag and service discovery. In
addition, people may want to use other optional extensions such as
Celtix instead of Axis or JAXB instead of SDO. The best way to solve
this other than using Maven (and potentially embedding it as part of
the distribution) is to use the artifact repository at runtime or, as
you mentioned, a custom Ant task that replicated its functionality at
deployment time (it could even embed Maven :-) ). The Ant task would
download the jars and place them in the Ant project folder as
determined by the user.
I am not debating the extensions issue. We need a robust and convenient
way for ant users (and users of other build tools) to obtain optional
Tuscany extensions that aren't included in the tuscany-sca binary
distro. I'm only focusing on the small set of binary artifacts that are
basic components of Tuscany and aren't packaged as Tuscany extensions.
I don't really see any distinction between these artifacts and the
"contrib" Tuscany extensions that we are including in the M2 distro.
In both cases, these could be downloaded separately, but bundling them
into a downloadable distribution is a valuable convenience to users.
What would be a less than ideal solution is to adopt the "kitchen sink"
approach. Even if today it is two jars, this will quickly break down as
the complexity of the runtime configuration increases. Putting this in
as a temporary stopgap also does not seem like a good move given the
issues it presents moving forward and the fact that we would have to
remove it in the next release.
Agreed that we don't want to do something now that we would reverse later.
I don't see why this would be necessary. Even if we had a very
sophisticated remote loading approach, there would still be a few basic
things that it would make sense to find locally.
Perhaps a custom Ant task which replicates the functionality in Maven
is something you could look into? If you embedded Maven, I don't think
it would be that much work.
I'm certainly going to look into this and I think it's the right way to
locate and load optional external dependencies. One of the approaches
I am investigating is embedding maven. But I would draw a distinction
between solving the general problem of artifact discovery and
downloading, and how we provide basic elements of the Tuscany runtime.
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]
