Re: Oddness with release:prepare
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 What version of SVN are you using? I'm betting it's 1.5.1+. There's a bug where the release plugin can't run with SVN 1.5.1+. 1.4.x works fine, as does 1.5.0 (but I hear that has some other bad bugs). This is a real bummer, since I would love to update to SVN 1.5, but I'm stuck on 1.4. I've been following the bug here: http://jira.codehaus.org/browse/SCM-406 Apparently it's an SVN thing, not an scm plugin one, but the scm bug has a thorough discussion and links to more relevant places. James CE Johnson wrote: (Forgive me if this is a double-post. I had to re-subscribe to the list.) This is with maven 2.0.9 on Solaris 10 with Java 1.6.0_11 I have a project laid out thusly: myproject/pom.xml myproject/myproject-pom/pom.xml myproject/myproject-api/pom.xml myproject/myproject-common/pom.xml myproject/myproject-console/pom.xml The top-level pom is a minimal parent pom whose only module is myproject/myproject-pom. myproject/myproject-pom/pom.xml exists because Eclipse doesn't like nested projects. So this pom has things that would typically need to be changed. All of the other myproject/myproject-*/pom.xml are modules of myproject/myproject-pom/pom.xml. When I execute 'mvn release:prepare' things go well until it begins invoking subversion. Here is the relevant bit of output from the process: (sorry for the long lines) [INFO] Executing: /bin/sh -c cd /export/home/ci/tmp/myproject svn --non-interactive commit --file /var/tmp/maven-scm-1461319678.commit --targets /var/tmp/maven-scm-7441525038114668907-targets [INFO] Working directory: /export/home/ci/tmp/myproject [INFO] Executing: /bin/sh -c cd /export/home/ci/tmp/myproject/myproject-pom svn --non-interactive commit --file /var/tmp/maven-scm-1292675052.commit --targets /var/tmp/maven-scm-6618196211309587095-targets [INFO] Working directory: /export/home/ci/tmp/myproject/myproject-pom [INFO] Executing: /bin/sh -c cd /export/home/ci/tmp/myproject/myproject-pom/../myproject-api svn --non-interactive commit --file /var/tmp/maven-scm-1794995489.commit --targets /var/tmp/maven-scm-2050429634740604341-targets [INFO] Working directory: /export/home/ci/tmp/myproject/myproject-pom/../myproject-api [INFO] Executing: /bin/sh -c cd /export/home/ci/tmp/myproject/myproject-pom/../myproject-common svn --non-interactive commit --file /var/tmp/maven-scm-786958246.commit --targets /var/tmp/maven-scm-636982206221127-targets [INFO] Working directory: /export/home/ci/tmp/myproject/myproject-pom/../myproject-common [INFO] Executing: /bin/sh -c cd /export/home/ci/tmp/myproject/myproject-pom/../myproject-console svn --non-interactive commit --file /var/tmp/maven-scm-637551884.commit --targets /var/tmp/maven-scm-3757207476498104603-targets [INFO] Working directory: /export/home/ci/tmp/myproject/myproject-pom/../myproject-console [INFO] Tagging release with the label myproject-1.0... [INFO] Executing: /bin/sh -c cd /export/home/ci/tmp/myproject svn --non-interactive copy --file /var/tmp/maven-scm-1862162340.commit . http://my-svn-server:/svn/myrepo/myprojects/tags/myproject-1.0 [INFO] Working directory: /export/home/ci/tmp/myproject [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Unable to tag SCM Provider message: The svn tag command failed. Command output: svn: Commit failed (details follow): svn: File '/svn/myrepo/myprojects/tags/myproject-1.0/myproject-common/pom.xml' already exists After investigating a while and trying to reproduce the process manually, I discovered that the error message is somewhat misleading. If I do an 'svn update' prior to the 'svn copy' then the process completes successfully. I put a shell script named 'svn' in my path in front of /usr/local/bin and had that script do an 'svn update' when it sees an 'svn copy' request. Invoking 'mvn release:prepare' with that in place will succeed. Has anybody else seen this kind of behavior? Is there a better solution than my hack of a workaround: $ cat ~/bin/svn #!/bin/bash echo $@ ~/svn.log if [ $1 = --non-interactive -a $2 = copy -a $3 = --file ] then /usr/local/bin/svn update fi exec /usr/local/bin/svn $@ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJg3vFrZoE3ArapxERCNnzAKDcl4+y1edO5ZQO7iFC52lDdIksVgCgjt/G yK64dtaAGC593PgOjhTdTlk= =N0fw -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Up-to-date release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm subscribed to this bug: http://jira.codehaus.org/browse/SCM-406 Lots of people are complaining, but sadly there are no answers so far. The problem seems to be that when doinf releaase:prepare, the release plugin tries to commit the current working copy as a tag, instead of copying a remote URL. SVN 1.5 allows this, SVN 1.5.x apparently does not. There's bound to be a workaround. Someone suggested locking the trunk while the release plugin runs; I have no idea how feasible that would be. sverhagen wrote: Stephen Connolly-2 wrote: Use Subversion 1.5 the release plugin is broken with svn 1.5 and will not make a release if the entire workspace is not 100% up to date Hi, Stephen. Thanks for your prompt reply, but I tend to disagree. I am having exactly the problems that I described while being on 1.5.0 (see below). There is some regression in Subversion, I suppose, I have had people downgrade back to 1.5.0 for not being to able to release. Would you have the JIRA issue for what you're referring to? Thanks, Sander. svn --version svn, version 1.5.0 (r31699) compiled Jun 23 2008, 12:59:48 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEUEARECAAYFAkk/R68ACgkQ0GFaTS4nYxsnTACXWccUsTP0D7DPnN8fxTOgJE07 PgCfQjLqI5xMbRpfhMn/Zac5ktQnJhw= =enWc -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Running maven-compiler-plugin and maven-jaxws-plugin with different configurations in different phases
-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 executions 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
| | artifactIdmaven-compiler-plugin/artifactId
| | executions
| | execution
| | idjaxws-pre-compilation-hack/id
| | !-- Hack to specify order of plugin application --
| | phaseprocess-sources/phase
| | configuration
| | source1.5/source
| | target1.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
| | goalcompile/goal
| | /goals
| | /configuration
| | /execution
| | execution
| | idnormal-compilation/id
| | !-- Hack to specify order of plugin application --
| | phasecompile/phase
| | configuration
| | source1.5/source
| | target1.5/target
Re: Running maven-compiler-plugin and maven-jaxws-plugin with different configurations in different phases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 So could I generate client code directly from a class annotated with @WebService, without generating an intermediary WSDL? I couldn't find a way to do that with wsgen/wsimport, but I'd love it if that was possible. Daniel Kulp wrote: | | 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: | | 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 executions 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 | | | artifactIdmaven-compiler-plugin/artifactId | | | executions | | | execution | | | idjaxws-pre-compilation-hack/id | | | !-- Hack to specify order of plugin | application -- | | | phaseprocess-sources/phase | | | configuration
Re: Running maven-compiler-plugin and maven-jaxws-plugin with different configurations in different phases
-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 executions 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
Running maven-compiler-plugin and maven-jaxws-plugin with different configurations in different phases
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
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
| artifactIdmaven-compiler-plugin/artifactId
| executions
| execution
| idjaxws-pre-compilation-hack/id
| !-- Hack to specify order of plugin application --
| phaseprocess-sources/phase
| configuration
| source1.5/source
| target1.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
| goalcompile/goal
| /goals
| /configuration
| /execution
| execution
| idnormal-compilation/id
| !-- Hack to specify order of plugin application --
| phasecompile/phase
| configuration
| source1.5/source
| target1.5/target
| /configuration
| goals
| goalcompile/goal
| /goals
| /execution
| /executions
| /plugin
| plugin
| groupIdorg.codehaus.mojo/groupId
| artifactIdjaxws-maven-plugin/artifactId
| executions
| execution
| idmake-wsdl/id
| !-- Hack to specify order goals are run in --
| phasegenerate-resources/phase
| goals
| goalwsgen/goal
| /goals
| configuration
| seiorg.myorg.A/sei
| ...
| /configuration
| /execution
| execution
| idmake-client-bindings/id
| !-- Hack to specify order goals are run in --
| phaseprocess-resources/phase
| goals
| goalwsimport/goal
| /goals
| configuration
| ...
| /configuration
| /execution
| /executions
| ...
| /plugin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFIM3FkrZoE3ArapxERCMccAKDlPjEgU1qgJHl/HPohB/v11qLSGACgo4PY
/TE9PQTQfVgGzt1zsee9gGo=
=5LNh
