Hi Mauro, I am not working in a big dev environment. But that doesn't make a difference. Common schemas or parts of it isn't a problem.
I also have the webservice structure in SCM (svn in this case). Having the generated code in there is the wrong usage of it in my opinion. This causes duplication. What I do is: - Check out the sources (using eclipse or another program/IDE who can perform svn client operations); - Let the IDE generate the sources (I use maven for this, but ant can also be used); - Now you have a working environment on your local machine (which should be independent of IDE/OS etc); - Go ahead and makes changes / improvements to your code. (I like the test driven approach, but learning that atm); - Try running them locally; - If it works local, check out the newest version from the SCM (to adapt with changes from other developers); - If you got it working and the tests pass after this you check the changes in to the SCM. I hope this helps you. I think the important bit is to NOT duplicate sources in the SCM (which you do imho with storing the generated sources). Regards, Sietse -----Original Message----- From: Mauro Molinari [mailto:[EMAIL PROTECTED] Sent: 20 November 2007 11:25 To: [email protected] Subject: Re: Shared schemas: where to put them? [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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
