Hi Mauro! Just want to add my 2 cents (even though it's off-topic), perhaps it helps you. We are using (My)Eclipse, keep the sources in CVS, and do not put generated artefacts into CVS. It's like Sietse's approach. Concerning magnitude, we have 5 Web services with ~5 operations per service.
When we set up a new development environment, a checkout is done and an ANT script is run - that's all the Webapplication is ready for development AND deployment (the ant script generates needed aretfacts directly in the WEB-INF folder). Development is done using hot code replacement on a local Tomcat Server (Eclipse compiles classes to /WEB-INF/classes, no reload/restart is necessary changes are in effect immediately). Artefacts don't have to be generated for each code change during development. For a production release, the ANT script generates a clean WAR file from scratch (this includes artefact generation and re-compilation of sources). So, artefact generation takes place only when setting up the environment, for making production releases, and of course when source WSDL and/or XSD documents change. The overhead added to the development process is neglibible, also (but not only) because WSDL s and XSDs tend to change infrequently. However, resources needed for developing the necessary ANT build script were definitly significant. Cheers, Peter. <[EMAIL PROTECTED]> schrieb am 20.11.2007 12:37:40: > 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: axis-user@ws.apache.org > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]