You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by jaybytez <ja...@yahoo.com> on 2010/06/24 18:51:46 UTC
Maven CXF & wsdl2java code generation
I as looking for a way that I could code generate a web service provider or
web service consumer utilizing a wsdl and binding file (jaxb or jax-ws)
because I have already code generated my data binding model in a separate
process.
The question is can I use the information from the following link to do
that, while supplying the jaxb/jax-ws file?
http://cxf.apache.org/docs/maven-cxf-codegen-plugin-wsdl-to-java.html
Also, does any of the CXF code generation generate a Spring enabled
implementation?
Thanks,
Jay
--
View this message in context: http://old.nabble.com/Maven-CXF---wsdl2java-code-generation-tp28984474p28984474.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: Maven CXF & wsdl2java code generation
Posted by David Valeri <dv...@apache.org>.
I agree with you 100% about not version controlling the generated code. You
can version control the Maven POM that creates and packages the generated
code in SVN without version controlling the generated code itself. I'm not
a big advocate of providing generated bindings to one's end-users, but I
just wanted to point out that it is possible without encountering the issues
mentioned in the referenced article. I feel like the article brings up a
non-issue when considering modern standards based Java Web services and
wanted to stop the spread of potentially misleading info.
The right approach is whatever works for your team in your situation, but
either approach is possible when talking JAX-WS/B only code.
-----Original Message-----
From: Christian Schneider [mailto:chris@die-schneider.net]
Sent: Friday, July 09, 2010 2:48 AM
To: users@cxf.apache.org
Subject: Re: Maven CXF & wsdl2java code generation
I think when adhering to the JAX-WS and JAXB standards your risk of
incompatibilities is relatively small.
So you could do this. On the other hand code generation is easy when you
do it with maven and the cxf codegen tools.
So my attempt is to store the wsdls in the maven repository and load
them as a dependency through maven.
This leaves the choice of jaxb customizations to the developer of the
client and server. They even could use other aproaches.
Genrally I like the idea of always generating the service code on the
fly and not store the generated source in subversion.
Greetings
Christian
Am 08.07.2010 14:48, schrieb David Valeri:
> If you distribute the JAX-WS annotated interfaces and JAX-B annotated data
> binding classes that were created by wsdl2java, that library has
absolutely
> zero runtime dependency on CXF. The CXF dependency only exists at build
> time for the artifact containing the generated code. CXF is used only as
a
> build dependency through plug-in configuration and will not be involved in
> the transitive dependency resolution in Maven when the artifact is
included
> as a dependency by your end-users. For the most part, your service
> implementation code is ignorant of CXF as well. Your service code can
> either use the JAX-WS APIs to publish a service endpoint or it can be
wired
> up by CXF in a Spring configuration file. Either way, your implementation
> code will usually be completely ignorant of which JAX-WS implementation is
> in use as all of the JAX-WS implementation specific stuff can be done in
> Spring with CXF or using other external configuration files when using
other
> JAX-WS implementations.
>
> So, you can distribute the generated code in one JAR and sample
> implementation classes in another JAR and neither needs to be CXF specific
> if you code to the JAX-WS API. It is only in your WAR that you bring in a
> JAX-WS implementation and provide CXF specific configuration in a Spring
> file or in CXF aware Java code.
>
> One advantage of having a central person generate the code is when you
have
> a schema that needs lots of attention to generate code from. For example,
> name collisions, and data type issues that require a XJB file or tweaks in
> the schema to make work. Rather than having all of your service's users
in
> your company waste time figuring out the needed customizations, you have
one
> person do it and get it working right.
>
> Regardless of if you distribute generated code or not, it is still a good
> idea to host your WSDLs in a well managed location for reference by
everyone
> involved and your end-users will still need to learn enough about JAX-WS
to
> know how to use your generated code in their application.
>
> Christian's referenced article argues against providing a client that is
> based on a specific stack and this was a common issue in the days before
> JAX-WS; if you program to the API and provide only JAX-WS/JAX-B annotated
> code, it is a non-issue.
>
> -----Original Message-----
> From: Christian Schneider [mailto:chris@die-schneider.net]
> Sent: Wednesday, July 07, 2010 2:23 AM
> To: users@cxf.apache.org
> Subject: Re: Maven CXF& wsdl2java code generation
>
> Hi Jay,
>
> you can create a maven project that only does the code generation. Then
> this project could be shared.
> In the war project you could then reference the project with the
> generated code as a maven dependency.
>
> While this is well possible to do I strongly advise you to not do it.
> For some time we created client jars for the users of services. That
> meant that they could start very easy
> as they simply had to reference the client jar and retrieve the service
> with a factory. The problem is that in the end you create much more
> problems doing this in the long run.
> The client jars had to reference the whole cxf stack to work. That meant
> the developer who included it made his project dependent on these libs.
> This could create some problems with his own current stack.
> The real problems start when you try to include several client jars.
> Over time you will need to build the client jars using newer version of
> cxf or spring. Then when someone includes the newer and older clients
> maven will have to choose which version to use. This can create
> incompatibilities.
>
> So my advise is to deploy the wsdl to a central repository and show the
> client and server developers how to do code generation and the spring
> config with a good sample project (like the wsdl_first example). It is
> also a good idea to have a central person that helps the teams set up
> the initial service configuration.
>
> Some articles that could be interesting for you are the following:
>
http://www.liquid-reality.de:8080/display/liquid/2009/09/03/Use+maven+reposi
> tory+as+a+service+repository
>
http://www.liquid-reality.de:8080/display/liquid/2008/08/20/Defining+Contrac
> t+first+webservices+by+generating+wsdl+from+java
>
http://www.soa-at-work.com/2010/03/why-you-should-not-deliver-client-for.htm
> l
>
> Greetings
>
> Christian
>
>
> Am 07.07.2010 01:41, schrieb jaybytez:
>> Thanks for the reference to wsdl_first example, it was very helpful.
>>
>> One last question, what would it take to do the following with the
> wsdl2java
>> and is it even possible.
>>
>> Run wsdl2java and produce the following:
>> 1) jar file the interface service class
>> 2) jar file the sample implementation classes
>> 3) war the actual web service endpoint web project
>>
>> The goal is that the interfaces could be compiled and package separately
> so
>> that both the web service endpoint (war) could use the jar and the
>> implementation jar could use the interface jar.
>>
>> And this would allow a technical lead to build these projects and just
> hand
>> off the implementation classes (jar development) to a separate team.
>>
>> Thanks for your help,
>>
>> Jay
--
----
http://www.liquid-reality.de
Re: Maven CXF & wsdl2java code generation
Posted by Christian Schneider <ch...@die-schneider.net>.
I think when adhering to the JAX-WS and JAXB standards your risk of
incompatibilities is relatively small.
So you could do this. On the other hand code generation is easy when you
do it with maven and the cxf codegen tools.
So my attempt is to store the wsdls in the maven repository and load
them as a dependency through maven.
This leaves the choice of jaxb customizations to the developer of the
client and server. They even could use other aproaches.
Genrally I like the idea of always generating the service code on the
fly and not store the generated source in subversion.
Greetings
Christian
Am 08.07.2010 14:48, schrieb David Valeri:
> If you distribute the JAX-WS annotated interfaces and JAX-B annotated data
> binding classes that were created by wsdl2java, that library has absolutely
> zero runtime dependency on CXF. The CXF dependency only exists at build
> time for the artifact containing the generated code. CXF is used only as a
> build dependency through plug-in configuration and will not be involved in
> the transitive dependency resolution in Maven when the artifact is included
> as a dependency by your end-users. For the most part, your service
> implementation code is ignorant of CXF as well. Your service code can
> either use the JAX-WS APIs to publish a service endpoint or it can be wired
> up by CXF in a Spring configuration file. Either way, your implementation
> code will usually be completely ignorant of which JAX-WS implementation is
> in use as all of the JAX-WS implementation specific stuff can be done in
> Spring with CXF or using other external configuration files when using other
> JAX-WS implementations.
>
> So, you can distribute the generated code in one JAR and sample
> implementation classes in another JAR and neither needs to be CXF specific
> if you code to the JAX-WS API. It is only in your WAR that you bring in a
> JAX-WS implementation and provide CXF specific configuration in a Spring
> file or in CXF aware Java code.
>
> One advantage of having a central person generate the code is when you have
> a schema that needs lots of attention to generate code from. For example,
> name collisions, and data type issues that require a XJB file or tweaks in
> the schema to make work. Rather than having all of your service's users in
> your company waste time figuring out the needed customizations, you have one
> person do it and get it working right.
>
> Regardless of if you distribute generated code or not, it is still a good
> idea to host your WSDLs in a well managed location for reference by everyone
> involved and your end-users will still need to learn enough about JAX-WS to
> know how to use your generated code in their application.
>
> Christian's referenced article argues against providing a client that is
> based on a specific stack and this was a common issue in the days before
> JAX-WS; if you program to the API and provide only JAX-WS/JAX-B annotated
> code, it is a non-issue.
>
> -----Original Message-----
> From: Christian Schneider [mailto:chris@die-schneider.net]
> Sent: Wednesday, July 07, 2010 2:23 AM
> To: users@cxf.apache.org
> Subject: Re: Maven CXF& wsdl2java code generation
>
> Hi Jay,
>
> you can create a maven project that only does the code generation. Then
> this project could be shared.
> In the war project you could then reference the project with the
> generated code as a maven dependency.
>
> While this is well possible to do I strongly advise you to not do it.
> For some time we created client jars for the users of services. That
> meant that they could start very easy
> as they simply had to reference the client jar and retrieve the service
> with a factory. The problem is that in the end you create much more
> problems doing this in the long run.
> The client jars had to reference the whole cxf stack to work. That meant
> the developer who included it made his project dependent on these libs.
> This could create some problems with his own current stack.
> The real problems start when you try to include several client jars.
> Over time you will need to build the client jars using newer version of
> cxf or spring. Then when someone includes the newer and older clients
> maven will have to choose which version to use. This can create
> incompatibilities.
>
> So my advise is to deploy the wsdl to a central repository and show the
> client and server developers how to do code generation and the spring
> config with a good sample project (like the wsdl_first example). It is
> also a good idea to have a central person that helps the teams set up
> the initial service configuration.
>
> Some articles that could be interesting for you are the following:
> http://www.liquid-reality.de:8080/display/liquid/2009/09/03/Use+maven+reposi
> tory+as+a+service+repository
> http://www.liquid-reality.de:8080/display/liquid/2008/08/20/Defining+Contrac
> t+first+webservices+by+generating+wsdl+from+java
> http://www.soa-at-work.com/2010/03/why-you-should-not-deliver-client-for.htm
> l
>
> Greetings
>
> Christian
>
>
> Am 07.07.2010 01:41, schrieb jaybytez:
>> Thanks for the reference to wsdl_first example, it was very helpful.
>>
>> One last question, what would it take to do the following with the
> wsdl2java
>> and is it even possible.
>>
>> Run wsdl2java and produce the following:
>> 1) jar file the interface service class
>> 2) jar file the sample implementation classes
>> 3) war the actual web service endpoint web project
>>
>> The goal is that the interfaces could be compiled and package separately
> so
>> that both the web service endpoint (war) could use the jar and the
>> implementation jar could use the interface jar.
>>
>> And this would allow a technical lead to build these projects and just
> hand
>> off the implementation classes (jar development) to a separate team.
>>
>> Thanks for your help,
>>
>> Jay
--
----
http://www.liquid-reality.de
RE: Maven CXF & wsdl2java code generation
Posted by David Valeri <dv...@apache.org>.
If you distribute the JAX-WS annotated interfaces and JAX-B annotated data
binding classes that were created by wsdl2java, that library has absolutely
zero runtime dependency on CXF. The CXF dependency only exists at build
time for the artifact containing the generated code. CXF is used only as a
build dependency through plug-in configuration and will not be involved in
the transitive dependency resolution in Maven when the artifact is included
as a dependency by your end-users. For the most part, your service
implementation code is ignorant of CXF as well. Your service code can
either use the JAX-WS APIs to publish a service endpoint or it can be wired
up by CXF in a Spring configuration file. Either way, your implementation
code will usually be completely ignorant of which JAX-WS implementation is
in use as all of the JAX-WS implementation specific stuff can be done in
Spring with CXF or using other external configuration files when using other
JAX-WS implementations.
So, you can distribute the generated code in one JAR and sample
implementation classes in another JAR and neither needs to be CXF specific
if you code to the JAX-WS API. It is only in your WAR that you bring in a
JAX-WS implementation and provide CXF specific configuration in a Spring
file or in CXF aware Java code.
One advantage of having a central person generate the code is when you have
a schema that needs lots of attention to generate code from. For example,
name collisions, and data type issues that require a XJB file or tweaks in
the schema to make work. Rather than having all of your service's users in
your company waste time figuring out the needed customizations, you have one
person do it and get it working right.
Regardless of if you distribute generated code or not, it is still a good
idea to host your WSDLs in a well managed location for reference by everyone
involved and your end-users will still need to learn enough about JAX-WS to
know how to use your generated code in their application.
Christian's referenced article argues against providing a client that is
based on a specific stack and this was a common issue in the days before
JAX-WS; if you program to the API and provide only JAX-WS/JAX-B annotated
code, it is a non-issue.
-----Original Message-----
From: Christian Schneider [mailto:chris@die-schneider.net]
Sent: Wednesday, July 07, 2010 2:23 AM
To: users@cxf.apache.org
Subject: Re: Maven CXF & wsdl2java code generation
Hi Jay,
you can create a maven project that only does the code generation. Then
this project could be shared.
In the war project you could then reference the project with the
generated code as a maven dependency.
While this is well possible to do I strongly advise you to not do it.
For some time we created client jars for the users of services. That
meant that they could start very easy
as they simply had to reference the client jar and retrieve the service
with a factory. The problem is that in the end you create much more
problems doing this in the long run.
The client jars had to reference the whole cxf stack to work. That meant
the developer who included it made his project dependent on these libs.
This could create some problems with his own current stack.
The real problems start when you try to include several client jars.
Over time you will need to build the client jars using newer version of
cxf or spring. Then when someone includes the newer and older clients
maven will have to choose which version to use. This can create
incompatibilities.
So my advise is to deploy the wsdl to a central repository and show the
client and server developers how to do code generation and the spring
config with a good sample project (like the wsdl_first example). It is
also a good idea to have a central person that helps the teams set up
the initial service configuration.
Some articles that could be interesting for you are the following:
http://www.liquid-reality.de:8080/display/liquid/2009/09/03/Use+maven+reposi
tory+as+a+service+repository
http://www.liquid-reality.de:8080/display/liquid/2008/08/20/Defining+Contrac
t+first+webservices+by+generating+wsdl+from+java
http://www.soa-at-work.com/2010/03/why-you-should-not-deliver-client-for.htm
l
Greetings
Christian
Am 07.07.2010 01:41, schrieb jaybytez:
> Thanks for the reference to wsdl_first example, it was very helpful.
>
> One last question, what would it take to do the following with the
wsdl2java
> and is it even possible.
>
> Run wsdl2java and produce the following:
> 1) jar file the interface service class
> 2) jar file the sample implementation classes
> 3) war the actual web service endpoint web project
>
> The goal is that the interfaces could be compiled and package separately
so
> that both the web service endpoint (war) could use the jar and the
> implementation jar could use the interface jar.
>
> And this would allow a technical lead to build these projects and just
hand
> off the implementation classes (jar development) to a separate team.
>
> Thanks for your help,
>
> Jay
--
----
http://www.liquid-reality.de
Re: Maven CXF & wsdl2java code generation
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Jay,
you can create a maven project that only does the code generation. Then
this project could be shared.
In the war project you could then reference the project with the
generated code as a maven dependency.
While this is well possible to do I strongly advise you to not do it.
For some time we created client jars for the users of services. That
meant that they could start very easy
as they simply had to reference the client jar and retrieve the service
with a factory. The problem is that in the end you create much more
problems doing this in the long run.
The client jars had to reference the whole cxf stack to work. That meant
the developer who included it made his project dependent on these libs.
This could create some problems with his own current stack.
The real problems start when you try to include several client jars.
Over time you will need to build the client jars using newer version of
cxf or spring. Then when someone includes the newer and older clients
maven will have to choose which version to use. This can create
incompatibilities.
So my advise is to deploy the wsdl to a central repository and show the
client and server developers how to do code generation and the spring
config with a good sample project (like the wsdl_first example). It is
also a good idea to have a central person that helps the teams set up
the initial service configuration.
Some articles that could be interesting for you are the following:
http://www.liquid-reality.de:8080/display/liquid/2009/09/03/Use+maven+repository+as+a+service+repository
http://www.liquid-reality.de:8080/display/liquid/2008/08/20/Defining+Contract+first+webservices+by+generating+wsdl+from+java
http://www.soa-at-work.com/2010/03/why-you-should-not-deliver-client-for.html
Greetings
Christian
Am 07.07.2010 01:41, schrieb jaybytez:
> Thanks for the reference to wsdl_first example, it was very helpful.
>
> One last question, what would it take to do the following with the wsdl2java
> and is it even possible.
>
> Run wsdl2java and produce the following:
> 1) jar file the interface service class
> 2) jar file the sample implementation classes
> 3) war the actual web service endpoint web project
>
> The goal is that the interfaces could be compiled and package separately so
> that both the web service endpoint (war) could use the jar and the
> implementation jar could use the interface jar.
>
> And this would allow a technical lead to build these projects and just hand
> off the implementation classes (jar development) to a separate team.
>
> Thanks for your help,
>
> Jay
--
----
http://www.liquid-reality.de
Re: Maven CXF & wsdl2java code generation
Posted by jaybytez <ja...@yahoo.com>.
Thanks for the reference to wsdl_first example, it was very helpful.
One last question, what would it take to do the following with the wsdl2java
and is it even possible.
Run wsdl2java and produce the following:
1) jar file the interface service class
2) jar file the sample implementation classes
3) war the actual web service endpoint web project
The goal is that the interfaces could be compiled and package separately so
that both the web service endpoint (war) could use the jar and the
implementation jar could use the interface jar.
And this would allow a technical lead to build these projects and just hand
off the implementation classes (jar development) to a separate team.
Thanks for your help,
Jay
--
View this message in context: http://cxf.547215.n5.nabble.com/Maven-CXF-wsdl2java-code-generation-tp557902p950506.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Maven CXF & wsdl2java code generation
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Jay,
the code generation should work nicely with the instructions you linked to.
The spring config will not be generated.
The best thing is probably to start with the wsdl_first example from the
distribution. It already contains a pom file for code generation and
also has a spring config you can use. It even shows how to use a binding
file.
Greetings
Christian
Am 24.06.2010 18:51, schrieb jaybytez:
> I as looking for a way that I could code generate a web service provider or
> web service consumer utilizing a wsdl and binding file (jaxb or jax-ws)
> because I have already code generated my data binding model in a separate
> process.
>
> The question is can I use the information from the following link to do
> that, while supplying the jaxb/jax-ws file?
>
> http://cxf.apache.org/docs/maven-cxf-codegen-plugin-wsdl-to-java.html
>
> Also, does any of the CXF code generation generate a Spring enabled
> implementation?
>
> Thanks,
>
> Jay
>
--
----
http://www.liquid-reality.de