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: [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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
