On Mon, Mar 3, 2008 at 10:35 PM, Simon Laws <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 3, 2008 at 10:08 PM, Jean-Sebastien Delfino < > [EMAIL PROTECTED]> wrote: > > > >Raymond Feng <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > 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/[EMAIL PROTECTED] 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
