I agree, and the archetype has already been changed to reflect that. It is fixed in both the 3.1 branche and trunk :-)
On 4/13/07, Rossmanith, Philipp <[EMAIL PROTECTED]> wrote:
Nevermind. What I found to be a bit startling was that the WSDL-first example is utilizing a POM that is different from the one created by the wsdl-first archetype - instead of declaring the wsgen Ant task, it is executing the xfire-maven-plugin. The whole thing might be easier to grasp if the example would be based on the archetype, as well. Ciao, Philipp > -----Mensaje original----- > De: Guillaume Nodet [mailto:[EMAIL PROTECTED] > Enviado el: jueves, 12 de abril de 2007 15:50 > Para: [EMAIL PROTECTED] > Asunto: Re: Best practices for developing a servicemix-jsr181 service unit > Importancia: Baja > > Sorry, I missed your first mail. > There is a flag to set so that the stubs are not generated again. > I just can't recall its name :-( > > On 4/12/07, Rossmanith, Philipp <[EMAIL PROTECTED]> wrote: > > > > > > Hi, > > > > I've been digging further into the issue, and *one* solution to the > > problem is to configure the wsgen task inside the pom.xml to generate > > the output into Maven's default source directory. (It may not be the > > best/cleanest, but it works, as wsgen doesn't overwrite stubs.) > > > > These are the steps I followed: > > 1. created Maven project as multi-module project > > 2. Created wsdl-first SU project with ServiceMix tooling: > > mvn archetype:create -DarchetypeGroupId=org.apache.servicemix.tooling > > -DarchetypeArtifactId=servicemix-jsr181-wsdl-first-service-unit > > -DarchetypeVersion=3.1-incubating -DgroupId=group.id > > -DartifactId=simple-sensor-wsdl-first-jsr181-su > > 3. Replaced xfire-version > > 4. Changed outputDirectory="${basedir}/target/generated-sources" to > > outputDirectory="${basedir}/src/main/java" > > 5. Created WSDL > > a. All in one WSDL file > > 6. Mvn install > > a. Creates java sources ${basedir}/src/main/java > > 7. Implementing source > > 8. Configuring XBean.xml > > a. Specify Pojo class (*Impl), wsdlResource > > b. Don't specify service, interfaceName, endpoint, will be taken > > over from WSDL > > 9. Mvn install > > 10. Optional: HTTP endpoint > > a. Same service and endpoint name as defined in wsdl > > b. Namespace, service name > > 11. Create service assembly with ServiceMix tooling > > mvn archetype:create -DarchetypeGroupId=org.apache.servicemix.tooling > > -DarchetypeArtifactId=servicemix-service-assembly > > -DarchetypeVersion=3.1-incubating -DgroupId= group.id > > -DartifactId=simple-sensor-sa > > 12. Add dependencies > > 13. Mvn install > > 14. Deploy > > > > Ciao, > > Philipp > > > > > -----Mensaje original----- > > > De: Rossmanith, Philipp > > > Enviado el: martes, 10 de abril de 2007 18:52 > > > Para: [EMAIL PROTECTED] > > > Asunto: Best practices for developing a servicemix-jsr181 service unit > > > Importancia: Baja > > > > > > > > > Hi, > > > > > > Based on a recent discussion on the user > > > > > (http://www.nabble.com/Remote-deployment-of-service-assemblies-tf3427450 > > > s12049.html) and dev > > > > > (http://www.nabble.com/RE%3A-Remote-deployment-of-service-assemblies-tf3 > > > 432611s12049.html) lists, I'm currently writing on some best practices > > > for jsr181 deployment. > > > > > > What I got so far for a WSDL-first development is: > > > >> > > > - Maven servicemix-jsr181-wsdl-first-service-unit: > > > > > > mvn archetype:create -DarchetypeGroupId =org.apache.servicemix.tooling > > > -DarchetypeArtifactId=servicemix-jsr181-wsdl-first-service-unit > > > -DarchetypeVersion=3.1-incubating -DgroupId=your.group.id > > > -DartifactId=your.artefact.id > > > > > > - replace version parameters in pom.xml > > > - ${xfire-version} > > > - ${servicemix-version} [though I saw later in the wsdl first > > example > > > that this one seems to be unset] > > > - mvn generate-sources > > > - executes XFire wsgen task > > > - allows to do the implementation > > > - move source files from target\generated-sources to src\main\java > > > - Implement service in <ServiceName>Impl > > > - do the rest for deploying the su to SM (sa, ...) > > > << > > > > > > Now my problem is that with the default configuration created by SM's > > > archetype, I get an error when installing the su with mvn install: > > > >> > > > ... > > > > > {su-root}\target\generated-sources\{path-to-package}\SensorDataServiceIm > > > pl.java:[8,7] duplicate class: {package}.SensorDataServiceImpl > > > ... > > > << > > > > > > I did a second attempt in which I copied and adapted SM's wsdl-first > > > example, but ended up with the same result. > > > > > > Any idea what this could be related to? > > > > > > Thanks in advance, > > > Ciao, > > > Philipp > > > > > > This e-mail may contain confidential or privileged information. Any > > > unauthorised > > > copying, use or distribution of this information is strictly > > prohibited. > > > > This e-mail may contain confidential or privileged information. Any > > unauthorised > > copying, use or distribution of this information is strictly prohibited. > > > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > LogicBlaze > Principal Engineer, IONA > Blog: http://gnodet.blogspot.com/ This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited.
-- Cheers, Guillaume Nodet ------------------------ Principal Engineer, IONA Blog: http://gnodet.blogspot.com/
