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]
