ant elder wrote:
On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:
I wonder if some of this debate is due to us not all talking about they same
thing so maybe it would help to go back to this proposal:
Here's what I'd like to see as a user:
- a short list of API JARs that I can add to my dev compile/build path
- a single small launcher or bootstrap JAR that takes care of bootstrapping
the Tuscany runtime
- the launcher should detect the presence of installed extensions in a
particular Tuscany installation
- as a user / app developer I should not have to know the list of JARs from
all these extensions.
This is a fundamentally different approach from what we do today where we
have all the Tuscany jars and dependencies on the application classpath. One
of the main reasons for having jars of aggregated modules is to make it
easier for users but if we change to have a runtime launcher which handles
the all the module jars instead of the user then that reason goes away.
To make this clear, today if a user has an Ant build script for their
application that build script needs to hardcode each Tuscany module jar and
dependency jar name so the build script breaks every time we change things.
The tuscany-all and manifest jars help some but as has been pointed they
have other problems. If we change to use the launcher approach then the Ant
build script just needs to hardcode the Tuscany API and launcher bootstrap
jar names and the location of the Tuscany install, and those few names
should not change much over Tuscany releses so the user application doesn't
get broken when we change Tuscany internal things. It doesn't really matter
to the user if the actual Tuscany install folder has 10 jars or 200 jars all
the they care about is the install location and the launcher handles it all
for them. This is similar to developing webapps for Tomcat, to the user all
they care about is the servlet-api jar and where Tomcat is installed, they
don't care whats in the Tomcat server lib directory.
One place where the number of jars definitely does show through is
when retrieving these artifacts from the maven repos. Also, as
discussed in your other email on this thread, when embedding and
packaging Tuscany in other environments, it will be necessary to
deal with the physical distributed artifacts.
We did use this launcher approach back in M2 and we changed in 0.90 as a
launcher makes things harder for Tuscany developers, for example when
debugging Tuscany internals, but maybe _now_ it would be better to change
back to a launcher approach as it makes things easier for users.
I can see the advantages, and I'm OK with this as long as we can make
the launcher and registry work conveniently in all the embedded
scenarios where Tuscany might be used.
I'm not quite clear on how 3rd party libraries would be handled using
the registry approach. Would these continue to be taken from the
classpath, or would they be loaded from the registry? For ease of
integration with user/application code that uses some of the same
libraries, I think it's best to take these from the classpath, except
when running in an OSGi environment.
Simon
...ant
