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]

Reply via email to