Hi Peter and Mauro, I agree that this is offtopic, but I think this discussion is very important! That's why I continue on it.
The usage of ant / maven doesn't matter. They wanted me to work with maven, and I start being happy with it (after a lot of struggle). Peter's point is exactly what I wanted to point out and that is: - When we set up a new development environment, a checkout is done and an ANT script is run (in my case "mvn clean generate-sources"). I think it is also important to be IDE independent. That way every developer can work with his favourite IDE and I don't see a reason why an dependency to an IDE should be a part of the product. In my opinion you should have an automated build (i.e. "ant build", "mvn package"). Every manual action needed is one too much and is error prone. Project dependencies are one of the points where maven is very strong! Although I haven't used it widely, because I don't have all those dependencies on own packages, maven can handle these for you. I think there also is an ant workaround for it but I can't answer that question. I only have the main ant knowledge. The build script is part of the build, so it should be stored in CVS yes. You should store everything which is needed to create a build in the CVS. When someone checks out from the trunk, he/she needs to be able to build the complete system automatically. Mauro: But why do you say that putting Axis2 generated code under source control means duplicating code? The source is the wsdl + xsd files, not the generated source. The duplication is the generated source, which is exactly the same as the wsdl + xsd files. This is important to notice, and that is exactly the reason that it is not needed. If the wsdl / xsd files are changing, you change the contract of the service. It is fair in my opinion that you've to adjust the code which makes use of the generated sources for that. You are right that the code under version control isn't compilable directly, it needs the code generation first! Regards, Sietse -----Original Message----- From: Peter Hrastnik [mailto:[EMAIL PROTECTED] Sent: 20 November 2007 12:56 To: [email protected] Subject: RE: Shared schemas: where to put them? 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
