Maven module build order has resorted in need to fall back to freestyle BUT...

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Maven module build order has resorted in need to fall back to freestyle BUT...

Ned Collyer
Because of the strange way Hudson determines module order, I have had to resort to building with a freestyle project.

This is a bit of a shame because the Hudson integration is close to super awesome!

At any rate, this would be great solution for me... if I could execute freestyle maven builds on a windows slave.  I cannot.

I can execute a standard maven2 project on the windows slave.

Hudson: 1.130
container: tomcat 5.5
master: centos
slaves: centos

slave thats bung: windows

I get the following error
[MAIN] $ /home/fast/tools/maven/current/bin/mvn install
FATAL: command execution failed
java.io.IOException: CreateProcess: \home\fast\tools\maven\current\bin\mvn install error=193
        at java.lang.ProcessImpl.create(Native Method)
        at java.lang.ProcessImpl.<init>(Unknown Source)
        at java.lang.ProcessImpl.start(Unknown Source)
        at java.lang.ProcessBuilder.start(Unknown Source)
        at java.lang.Runtime.exec(Unknown Source)
        at hudson.Proc$LocalProc.<init>(Proc.java:79)
        at hudson.Launcher$LocalLauncher.launch(Launcher.java:168)
        at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:252)
        at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:236)
        at hudson.remoting.UserRequest.perform(UserRequest.java:69)
        at hudson.remoting.UserRequest.perform(UserRequest.java:23)
        at hudson.remoting.Request$2.run(Request.java:178)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)


Why would I get this issue?  Surely the actual maven executor must be standard between maven freestyle, and maven 2 projects.  (its the same application after all)

error 193 is "not a valid win32 process"
Reply | Threaded
Open this post in threaded view
|

Re: Maven module build order has resorted in need to fall back to freestyle BUT...

Kohsuke Kawaguchi
Administrator
Ned Collyer wrote:
> Because of the strange way Hudson determines module order, I have had to
> resort to building with a freestyle project.
>
> This is a bit of a shame because the Hudson integration is close to super
> awesome!

This was also recorded as issue #423, so I just committed a fix for this
in 1.133.


> At anyrate, this would be great solution for me... if I could execute
> freestyle maven builds on a windows slave.  I can execute a standard maven2
> project on the windows slave.
>
> Hudson: 1.130
> container: tomcat 5.5
> master: centos
> slaves: centos
>
> slave thats bung: windows
>
> I get the following error
> [MAIN] $ /home/fast/tools/maven/current/bin/mvn install
> FATAL: command execution failed
> java.io.IOException: CreateProcess: \home\fast\tools\maven\current\bin\mvn
> install error=193
> at java.lang.ProcessImpl.create(Native Method)
> at java.lang.ProcessImpl.<init>(Unknown Source)
> at java.lang.ProcessImpl.start(Unknown Source)
> at java.lang.ProcessBuilder.start(Unknown Source)
> at java.lang.Runtime.exec(Unknown Source)
> at hudson.Proc$LocalProc.<init>(Proc.java:79)
> at hudson.Launcher$LocalLauncher.launch(Launcher.java:168)
> at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:252)
> at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:236)
> at hudson.remoting.UserRequest.perform(UserRequest.java:69)
> at hudson.remoting.UserRequest.perform(UserRequest.java:23)
> at hudson.remoting.Request$2.run(Request.java:178)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
>
>
> Why would I get this issue?  Surely the actual maven executor must be
> standard between maven freestyle, and maven 2 projects.  (its the same
> application after all)
I also fixed this in 1.133. This was because incorrect OS type detection
in Maven. Notice that on Windows you'd still have to have
c:\home\fast\tools\maven\current\bin\mvn.bat


--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment