[EMAIL PROTECTED] ha scritto:
Hi all,
In my opinion Peter sketched out a nice solution. Why do you care of
having multiple copies of the xsd while they're generated? Generated
code shouldn't be in version management, only the sources. And because
of his solution makes use of only one xsd you're not duplicating
anything. The only source is the original (shared) xsd file.
Hi Sietse,
I don't know which is your development environment, however here we have
a very huge web application for which we are going to write many web
services. These web services can have some data in common (think of
exceptions/faults, for instance) and this is why we need a shared
common.xsd.
We use environments like Eclipse and Netbeans to develop. Having the
webservice structure ready after a CVS checkout enables us to let the
IDE auomatically do the deployment and hit a couple of clicks to make
the webapp start inside our development environment, in order to test
and/or debug.
Adding a custom deployment phase like the replication of this XSD into
all services META-INF folders breaks this automation. Although there are
ways of partially solve this, it simply adds overhead to a process that
isn't working because of what seems to me just a minor flaw of Axis2.
Moreover, maybe I'm missing something, but I can hardly realize how you
could implement your webservices without putting the generated code (at
least the Java code) under version control... How do you fill your
skeleton with the implementation? How do you use type classes generated
from the WSDL if they are not available at development time?
--
Mauro Molinari
Software Developer
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
