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
