Hmm, I'm not very familiar with jaxws so maybe I don't understand the full picture here. It just seems that if a class in one package can be compiled and used when generating wsdl and client bidnings without reference to other packages in the module, it can also be used for the same steps in module by itself.
Unless you mean that compilation of a webservice class requires client bindings from another service which is not yet built since it requires the client bindings you are about to build - that would be a painful circular dep. But I guess such a situation cannot be solved by "conventional" means anyhow... On Wed, May 21, 2008 at 7:03 PM, Clint Gilbert <[EMAIL PROTECTED]> 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] > > -- - Jan Fredrik Wedén --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
