On Nov 8, 2006, at 8:40 AM, Simon Nash wrote:
Jim,
See my comments inline.
Simon
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.
Not yet, but you will (see below) ;-)
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.
In order for this to work, you are going to need to handle transitive
dependencies in all but the simplest use case. Namely an application
that cannot receive or make remote invocations. I don't see any way
around this. For example, all of the web services binding extensions
and container extensions have dependencies. Bundling the two jar
files mentioned previously will only allow someone to create a web
application that invokes a local service from a servlet or JSP. No
services exposed over remote bindings. No references with remote
bindings. That type of application doesn't strike me as very
compelling for Tuscany. In fact, I would tell people not to use
Tuscany for this and to use something more appropriate such as
PicoContainer. If someone was doing this to understand how to write
Java services, I would tell them to use the standalone client since
deploying to a web container for this sort of thing is superfluous.
What benefit would they gain except the rigamarole of having to
create a war (or an exploded directory) and wait for a server whose
capabilities they are not using to restart for every change they
make? Running the kernel inside an IDE takes milliseconds and does
not require a deployment.
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.
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 capabilities would this distribution have (please see my
comments above)? I think not much.
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.
I just don't get this. If I have to remotely download extensions
anyway, why would we complicate things by cramming web app-related
libraries into a standalone distribution?
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.
Agreed except I don't see the web app-related libraries as "basic
elements of the Tuscany runtime". Many Tuscany deployments will be to
hosts that are not servlet containers.
Again, my recommendation would be to provide the Ant task that
downloads transitive dependencies and this will provide a solution
that will work for the majority of scenarios as well as respect
modularity.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
