Rick, My build hierarchy is something like this:
./src/disney/dis/family My Family.java and FamilyImpl.java files reside there. But these files are defined in a Java package disney.dis.family. So, running the WSDL2Java command in question from this directory creates the generated files "under" the current directory (not really in it) such that the location reflects the Java package name. That is, now I get this: ./src/disney/dis/family/disney/dis/family And the files are there. I can manually move them back to ./src/disney/dis/family Seems there should be an easier way. I can run the command with this option: -o ../../.. which will then put the generated files in ./src/disney/dis/family which is presumably what I want. But now my original Family.java interface definition is obliterated (overwritten). I want to keep this one because it's the "master" file that defines my web services, contains all of my Javadoc, blah, blah blah. The generated one is the ugly, machine-generated crap with the "in0" parameters, no formatting, no line breaks, no documentation, etc. Is there a "best practice" for this (or just some workaround or way that other folks have avoided the inconvenience of manually copying files around). If not I guess I have to invest time to write some build scripts now. Vartan --- Rick Reumann <[EMAIL PROTECTED]> wrote: > On 3/30/06, Rhimbo <[EMAIL PROTECTED]> wrote: > > > > How do I prevent WSDL2Java from overwriting my interface file? > > <snip> > > > This command overwrites my Family.java file. > > > > I know I can specify > > -o . > > > > as an option and WSDL2Java will create a disney/dis/family > > hierarchy underneath my current directory. > > Actually wouldn't that above would just make them in the same > directory? > > > But then I have to move the generated files to my current directory > > in order to compile everything. > > > > I'm sure there is a "best practice" that solves this problem. > > > > Is there a command line option that tells WSDL2Java "don't > > overwrite". > > I'm new to axis and web services, so I might be stating something > incorrectly, but I was basically confused by the same issue. None of > the simple lessons or tutorials I was doing online really mentioned > this behavior so I was cofused at first, so I'm not sure of the 'best > practice.' However, as was mentioned to me in a recent post it's ok > that they are overwritten and if you don't want them overwritten, you > have to build them to a different directory. If you look at what's > generated (in the overwritten files) you'll see that what axis changes > is obviously necessary so those generated files need to be somwhere > (you can't just say 'don't make them' since they are obviously > needed). > > I actually don't mind them being replaced and just using the replaced > ones. Is there a reason why you don't want to just work with the newly > generated classes? > > Also, I'm not sure what you mean by having to move the generated > classes back into the original directory. If you do that, and leave > out the generated ones that you think are 'duplicates' I don't see how > your web service will work when you deploy it. (It'll compile locally > but does the web service work). Also, even if you do have the > generated files go to a new pacakge, the files should still compile > ok. > > I wouldn't minding knowing either, though, if most experiecned axis > users just work with files that overwrite the initial ones, or if they > use ones generated to a new package. > > Another thing that sort of hit me also, that I could be wrong about, > is that some people I think generate their wsdl file first before even > creating any Java files - so they then use the WSDL2Java to make > their stubs and create what the other supporting classes they need. > (In other words they aren't using Java2WSDL to make a wsdl from > existing classes, they are possibly creating the wsdl manually with > their own schema inside and then using WSDL2Java). > > -- > Rick > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
