tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ant elder" <ant.el...@gmail.com>
Subject Re: svn commit: r632646 - in /incubator/tuscany/java/sca/tools/maven/maven-definitions:
Date Wed, 05 Mar 2008 14:35:28 GMT
On Mon, Mar 3, 2008 at 10:35 PM, Simon Laws <simonslaws@googlemail.com>
wrote:

> On Mon, Mar 3, 2008 at 10:08 PM, Jean-Sebastien Delfino <
> jsdelfino@apache.org> wrote:
>
> > >Raymond Feng <enjoyjava@gmail.com> wrote:
> > >> I wonder if it's too heavy to develop a maven plugin to merge the
> > >> definitions.xml file. BTW, I don't like the all-in-one jar too much
> as
> > it
> > >> breaks the modularity and extensibility story.
> >
> > +1 to that.
> >
> > Simon Laws wrote:
> > > If we are going to stick using the shader to produce an "all" jar then
> > we
> > > need something to aggregate definitions files together correctly.
> People
> > may
> > > put definitions.xml files in the same place in different modules by
> > accident
> > > even if we were to come up with a naming scheme.
> > >
> > > Having said that I agree with you that I don't know why we have the
> all
> > jar.
> > > The thing that confuses me is that we also build a manifest jar which
> > > references the all jar and all of the independent modules that we also
> > ship?
> > > We copy the modules when we create a war. We use the "all" jar to make
> > the
> > > build.xml script simpler for those samples that don't build a war but
> it
> > > might be more instructive to list out all the modules that samples
> use.
> > > Alternatively use the manifest jar.
> > >
> > > Simon
> > >
> >
> > +1 from me. Listing the required JARs is also what I've been trying to
> > promote with the maven-ant-generator plugin, which generates a build.xml
> > file containing the JARs you need from your pom.xml.
> >
> > I think it wouldn't be hard to go one step further and generate the list
> > of JARs from the capabilities required by a composite (implementation
> > types, bindings, policy types). That would allow application developers
> > to (1) not have to write these build files (2) see in the generated
> > build files exactly what they're using instead of an opaque
> > tuscany-all.jar.
> >
> > --
> > Jean-Sebastien
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
> Off topic a little but maybe we could add some more targets to the ant
> file
> to build our various hosting options (build-standalone, build-webapp,...).
> The pain we have at the moment is that the all jar can naturally only have
> one hosting option but then it really confuses people because we ship with
> Tomcat and hence they will get failures if they try, inadvertently, to
> build
> a webapp using it, i.e. host-webapp can't be found.
>
> Simon
>

I agree and think that type of thing may be the approach with most
potential. A significant problem with not using some form of aggregated jar
is that we expose Tuscany internals to users so each time we add/remove
modules (which we seem to do regularly) we break users builds, providing
tools to automatically generate scripts or dependencies helps but i doubt it
works or is convenient for all users so it would be better if we could find
a way where the Tuscany jars a user references doesn't change much over
releases.

As and example, if we take all the Tuscany modules used by the calculator
sample as listed here:

http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200803.mbox/%3cOFDD1B3F6A.03960D8B-ON80257403.003F5D85-80257403.003F8EDB@uk.ibm.com%3e

Could that form the basis of a single Tuscany jar named tuscany-base or
tuscany-kernal or tuscany-minimal or some such name? And then we can add
other jars to be used with that for various runtime and hosting
environments?

   ...ant

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message