One option is to go completely code first and not generate anything.
Use the same SEI interface for the client and for the service impls.
You don't need to generate any wsdl's or anything then. I know
Apache CXF supports that directly without problems. No generation of
anything needed at all. With the Sun RI, you would still need wsgen
to generate the wrapper beans/fault beans, but it can also compile them.
Dan
On May 21, 2008, at 1:03 PM, Clint Gilbert wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jan, thank you very much for your suggestion.
That was almost the first thing I tried. The problem is that my web
service instances (I
call them Nodes - they're components of a distributed DB system)
need to talk to each other.
A Node needs to be compiled to generate the client bindings, and a
Node needs to invoke
the bindings to talk to other Nodes. There's always a circular
dependency. I tried to
get around this by abstracting the process of talking to a node in
order to hide the JAXWS
client bindings from the nodes that use them. That let me attempt
the two-pass
compilation hack, but can't get around the circular dependency.
I think I'm going to bootstrap my module by checking in the
generated code and artifacts.
Just for reference, does anyone know for sure if you can give
different configs for
different <execution>s of maven-compiler-plugin?
Jan Fredrik Wedén wrote:
| Hi,
|
| Could you not split this into two modules where your step 4
resides in
| a module which dependes on another module containing the results
from
| 1, 2 and 3? Seems like the most correct Maven-way if you are allowed
| to split your codebase to accomplish this.
|
| On Wed, May 21, 2008 at 2:48 AM, Clint Gilbert
| <[EMAIL PROTECTED]> wrote:
| Hello everyone,
|
| First of all, I cannot overstate the beneficial effect that Maven
has had on
| the
| development process at my organization. To the devs: thanks for
the great
| tool!
|
| I have a pom that specifies two executions of the compiler plugin,
with
| different phases
| specified and different configs, but they're not both running.
(See pom
| excerpt below.)
| Is that expected? Can I configure multiple executions of the
compiler
| plugin with
| different configurations? It seems like no - [1], [2], [3] - but
I hope
| someone has an
| definitive answer.
|
| Here's some background on my problem, which I admit is fairly
obscure.
| Basically, what I
| need to do is:
|
| 1 Compile class A in package org.myorg, which is annotated with
@WebService
|
| 2 Run JAXWS's wsgen (via maven-jaxws-plugin) to make a WSDL from the
| compiled A.class
|
| 3 Run JAXWS's wsimport (via maven-jaxws-plugin) to make client-
side bindings
| from the
| just-generated WSDL
|
| 4 Compile non-generated classes that reference the just-generated
client
| bindings. These
| live in separate sub-packages - org.myorg.x, org.myorg.y, etc -
and would
| have failed if
| compiled during step 1 because they reference code generated in
step 3.
|
| I've included (what I hope are) the relevant sections of my pom
below.
|
| PS: Do I need to do things this way? Unfortunately, I think so.
Class
| org.myorg.A is a
| web service that needs to invoke other org.myorg.A web services
arranged in
| a tree or mesh
| topology. I've tried to break out the bindings, the SEI (A), and
the
| classes that
| abstract the connection between As using the client bindings into
| submodules, but I've
| only managed to introduce circular dependencies.
|
| In the past, I've dealt with this sort of chicken-and-egg problem by
| generating WSDLs and
| code and then checking them into source control. This feels bad,
and makes
| updates if the
| interface of the SEI changes a hassle. I'd much rather define a
simple SEI
| annotated with
| @WebService and have the low-level stuff (WSDLs, client bindings)
generated
| from that.
|
| [1]
| http://weblogs.java.net/blog/ss141213/archive/2007/11/my_maven_experi.html
| [2]
|
http://mail-archives.apache.org/mod_mbox/maven-users/200711.mbox/[EMAIL
PROTECTED]
| [3]
|
http://mail-archives.apache.org/mod_mbox/maven-users/200609.mbox/[EMAIL
PROTECTED]
|
| | <plugin>
| | <artifactId>maven-compiler-plugin</artifactId>
| | <executions>
| | <execution>
| | <id>jaxws-pre-compilation-hack</id>
| | <!-- Hack to specify order of plugin
application -->
| | <phase>process-sources</phase>
| | <configuration>
| | <source>1.5</source>
| | <target>1.5</target>
| | <includes>
| |
| <include>${source.dir}/org/myorg</include>
| | </includes>
| | <excludes>
| |
| <exclude>${source.dir}/org/myorg/x</exclude>
| |
| <exclude>${source.dir}/org/myorg/y</exclude>
| | </excludes>
| | <goals>
| | <goal>compile</goal>
| | </goals>
| | </configuration>
| | </execution>
| | <execution>
| | <id>normal-compilation</id>
| | <!-- Hack to specify order of plugin
application -->
| | <phase>compile</phase>
| | <configuration>
| | <source>1.5</source>
| | <target>1.5</target>
| | </configuration>
| | <goals>
| | <goal>compile</goal>
| | </goals>
| | </execution>
| | </executions>
| | </plugin>
| | <plugin>
| | <groupId>org.codehaus.mojo</groupId>
| | <artifactId>jaxws-maven-plugin</artifactId>
| | <executions>
| | <execution>
| | <id>make-wsdl</id>
| | <!-- Hack to specify order goals are run
in -->
| | <phase>generate-resources</phase>
| | <goals>
| | <goal>wsgen</goal>
| | </goals>
| | <configuration>
| | <sei>org.myorg.A</sei>
| | ...
| | </configuration>
| | </execution>
| | <execution>
| | <id>make-client-bindings</id>
| | <!-- Hack to specify order goals are run in -->
| | <phase>process-resources</phase>
| | <goals>
| | <goal>wsimport</goal>
| | </goals>
| | <configuration>
| | ...
| | </configuration>
| | </execution>
| | </executions>
| | ...
| | </plugin>
|
|
|
|>
|>
-
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
|>
|>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFINFXqrZoE3ArapxERCOuwAKDNDxmVMSWuHkShvdFP8UKg5UPMWwCgiOWb
VgWxKkB5UMu2NwUpllcu+cg=
=K/MD
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
