-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 True, in my case that, along with a little dynamic classloading, would get rid of the source-level circular dependency. It's similar to the way I've currently abstracted the process of Nodes talking to each other - I have an abstract base NodeConnector. However, there would still be a pom-level circular dependency, since the node module (with client bindings) depends on the nodeconnector module to talk to other nodes, and the nodeconnector module depends on the node module for the client bindings needed to actually talk to another Node. I thought about breaking the client bindings out into their own module, but that just turns a 2-vertex dependency cycle into a 3-vertex triangular-shaped one.
Ultimately, I'm sorry, as I posed my original question before I'd thought through my situation fully. I thought I could get around my circular dependency issue by jumping through some very hacky hoops in one of my poms, but the circular dependency will always be there in my case. I bootstrapped everything by running wsgen and wsimport manually and checking in the generated artifacts, and while slightly unpleasant, it seems a lot better than trying to hack something together to generate everything on the fly, as it were, from by @WebService class. Thanks to all who offered suggestions! Sean Hennessy wrote: | Perhaps one convention being the client bindings from another service could be resolved by a common IService class that each client Node would derive from and be dependent? | Thereby decoupling the maven compile time binding to a generic class? |> "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..."
| | | | -----Original Message----- | From: Jan Fredrik Wedén [mailto:[EMAIL PROTECTED] | Sent: Wednesday, May 21, 2008 11:25 AM | To: Maven Users List | Subject: Re: Running maven-compiler-plugin and maven-jaxws-plugin with different configurations in different phases | | | 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: | 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_exper | | i.html | | [2] | | | http://mail-archives.apache.org/mod_mbox/maven-users/200711.mbox/%3C47 | [EMAIL PROTECTED] | | [3] | | | http://mail-archives.apache.org/mod_mbox/maven-users/200609.mbox/%3C61 | [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] | |> | |> | |> |> - --------------------------------------------------------------------- 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] | --------------------------------------------------------------------- | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFINKhvrZoE3ArapxERCIXaAKCaio3x6IcODhDU4udYRCXvRZtk+gCeNgjR j2H7x0jriit10a4LiPHmh7w= =h1np -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
