[ http://issues.apache.org/jira/browse/AXIS2-663?page=comments#action_12434584 ] Derek Foster commented on AXIS2-663: ------------------------------------
I have run into this problem too. It is really frustrating. Suppose I have services Service1 and Service2. They both include the same XML schema file, Schema1, as well as some other schemas that are individual to each service. Now I run WSDL2Java on each, and put the output in Output1 and Output2 respectively. Now I have two copies of Schema1's files, including generated .java files: one in Output1 and one in Output2. This causes my IDE and compiler to complain that there are two duplicate copies of each of the Java classes in Schema1 if I try to include these both into the same project or compilation unit. On the other hand, if I try to have the output generated into the same directory for both services, the Java classes work OK. (Identical source files overwrite each other when WSDL2Java runs, but that is fine). However, the .wsdl and .xsb and build.xml and so forth files overwrite each other in some cases, so when I try to use the Java files for one service, it may crash because it was expecting to find it's own files, but is finding the other services' instead. As a workaround, I tried using the namespace2package option to remap each schema into its own directory, so that the classes from the two services which share the same schema are placed in different directories and packages. This works... sort of... but it means that if I have a particular element type in the schema named, say, MyElement, that I now have two different classes named MyElement, in different packages, and therefore if I wish to write a utility routine that is shared by both services and which takes a parameter of type MyElement, I can't do it: What was supposed to be one type is now two. The -o option really isn't enough. There really needs to be a way to cause source code for identical schemas in multiple services to be shared (when the same schema is used in multiple services), while allowing the data files to be distinct. > WSDL2Java: allow user to specify separate destination folders for src and > resources > ----------------------------------------------------------------------------------- > > Key: AXIS2-663 > URL: http://issues.apache.org/jira/browse/AXIS2-663 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Improvement > Components: Tools > Affects Versions: 1.0 > Environment: Axis2 1.0 RC5 > Reporter: Thilo Frotscher > Assigned To: Ajith Harshana Ranabahu > Priority: Blocker > > WSDL2Java generates source code, resources (service.xml, wsdl, xsd) and a > build.xml file. > The user can specify a destination folder for all of these files, but they > all go into the same folder. > When generating code for more than one service, you'll generally want to have > the source code for all services in the same src-folder. > That's why you would specify the same destination folder for all services. > However, in this causes the problem that the build.xml files > and the resources for all the services go into the same folder as well and > interfere with each other, or a overwritten respectively. > Therefore, it would be great if the user could specify two separate > destination folders: one for the source code and the second one for > the build file and the resources. Of course, the build files would have to > reflect the new folder structure. > Alternative suggestion: WSDL2Java could do this automatically by introducing > a service-specific folder > under resouces: > /resources/MyService1/service.xml > /resources/MyService1/MyService.wsdl > /resources/MyService1/MyService.xsd > /resources/MyService2/service.xml > /resources/MyService2/MyService.wsdl > /resources/MyService2/MyService.xsd > For the build files a similar solution could be used. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
