Jim,
See my comments inline.
Simon
Jim Marino wrote:
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.
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. 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.
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.
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.
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.
See my reply above. With runtime downloading of dependencies, it
could use the capabilities of any of the extensions that we provide
in the downlowdable distro.
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?
The simplification is for the scenario I described above that does
not need remote downloading at build time.
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.
They are commonly used. Agreed that that not every deployment of
Tuscany uses them, but this applies to some of the extensions that
we are bundling into the distro for user convenience.
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.
This is definitely required and I will work on this as part of the
overall solution. We need this to deal with some of the cases,
but there are common and useful cases (see above) that can be
handled without the need to invoke this mechanism.
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.
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]
