Execution failed for task ‘:common:gwt-utils:gwtCompile’.
at org.gradle.api.internal.tasks.DefaultTaskExecuter.executeActions

(DefaultTaskExecuter.java:66)
at org.gradle.api.internal.tasks.DefaultTaskExecuter.execute(DefaultTaskExecuter.java:43)
at org.gradle.api.internal.project.taskfactory.PostExecutionAnalysisTaskExecuter.execute

(PostExecutionAnalysisTaskExecuter.java:32)
at org.gradle.api.internal.project.taskfactory.ExecutionShortCircuitTaskExecuter.execute

(ExecutionShortCircuitTaskExecuter.java:50)
at org.gradle.api.internal.tasks.SkipTaskExecuter.doExecute(SkipTaskExecuter.java:57)
at org.gradle.api.internal.tasks.SkipTaskExecuter.execute(SkipTaskExecuter.java:35)
at org.gradle.api.internal.tasks.ExecuteAtMostOnceTaskExecuter.execute

(ExecuteAtMostOnceTaskExecuter.java:32)
at org.gradle.api.internal.AbstractTask.execute(AbstractTask.java:231)
at org.gradle.execution.DefaultTaskGraphExecuter.executeTask

(DefaultTaskGraphExecuter.java:167)
at org.gradle.execution.DefaultTaskGraphExecuter.doExecute

(DefaultTaskGraphExecuter.java:160)
at org.gradle.execution.DefaultTaskGraphExecuter.execute

(DefaultTaskGraphExecuter.java:78)
at org.gradle.execution.TaskNameResolvingBuildExecuter.execute

(TaskNameResolvingBuildExecuter.java:113)
at org.gradle.execution.DelegatingBuildExecuter.execute

(DelegatingBuildExecuter.java:54)
at org.gradle.execution.DelegatingBuildExecuter.execute

(DelegatingBuildExecuter.java:54)
at org.gradle.initialization.DefaultGradleLauncher.doBuildStages

(DefaultGradleLauncher.java:153)
at org.gradle.initialization.DefaultGradleLauncher.doBuild

(DefaultGradleLauncher.java:107)
at org.gradle.initialization.DefaultGradleLauncher.run

(DefaultGradleLauncher.java:75)
at org.gradle.launcher.RunBuildAction.execute(RunBuildAction.java:41)
at org.gradle.launcher.RunBuildAction.execute(RunBuildAction.java:27)
at org.gradle.launcher.CommandLineActionFactory$WithLoggingAction.execute

(CommandLineActionFactory.java:209)
at org.gradle.launcher.CommandLineActionFactory$WithLoggingAction.execute

(CommandLineActionFactory.java:193)
at org.gradle.launcher.Main.execute(Main.java:55)
at org.gradle.launcher.Main.main(Main.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke

(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke

(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.gradle.launcher.ProcessBootstrap.runNoExit(ProcessBootstrap.java:46)
at org.gradle.launcher.ProcessBootstrap.run(ProcessBootstrap.java:28)
at org.gradle.launcher.GradleMain.main(GradleMain.java:24)
Caused by: : Java returned: 1

-or-

Could not find com.google.gwt.dev.Compiler. Make sure you have it in your classpath

..and you’ve explored all options/fixes with no luck, perhaps you may be overlooking one elementary item. Is the project you’re trying to compile sitting in a directory path with spaces? If so, that’s your problem. It’s the age old Unix dislike for spaces in directory.

No ‘Plugin-Class’ entry in the manifest of …/path/to/plugin.hpi

Then you’re experiencing a problem I just experienced. The problem lies in the particular version of the hudson.war file. Like me, you probably retrieve an unofficial or out-dated version of the hudson.war.

Here’s how to do it — use XML Character entity references:

For > use >

For < use  &lt;

For “ use &quot;

For & use &amp;

For ‘ use &apos;
Any other characters you need?  Drop me a line..

atusReportTask- Failed to reach dashboard instance : http://mydomain.com:8080/dashboard/buildloop/listener, either the dashboard has not started up or there is a network problem

Recently I’ve been experiencing some build wlappc jspc freezing issue which I’ve fixed and works fine when I run it via command line, but the build continue to freeze when it invokes via CruiseControl.  Turns out, there were quite a few people who have experienced the same problem.

To fix it, I just ugpraded my CruiseControl suite from 2.7 to 2.8.2.  Quick and clean fix, forget spending time troubleshooting this problem at the low levels.  No time for that, software release must go out on schedule…

That is, until recently when the freezing/hanging started to happen on a consistent basis.  Here’s the snippet of the ANT Task:

<wlappc source=”${some.base.dir}” classpath=”${some.dir}/some_class.jar” verbose=”true”/>

The ANT output during build time is this and is where it freezes:

[wlappc] [jspc] Compiling /path/to/jsp/foo.jsp

Then after searching high and low on BEA’s site, I came upon this page (Here) which describes the task in detail.  I then realized I should add in idlVerbose=”true”.  Once I’ve added that, this is the output I got from the build:

[wlappc] [jspc] Compiling /path/to/jsp/foo.jsp
[wlappc] WARNING: unable to get an input stream for jar:file:/path/to/some/jar/WEB-INF/lib/struts.jar!/
[wlappc] java.lang.NoClassDefFoundError: org/apache/bcelx/classfile/ClassParser
[wlappc] [...]

Muuuuch better.  To fix it, now I know I need to explicitly define bcel*.jar in the classpath.  Here’s the modified ANT task:

<wlappc source=”${some.base.dir}”
classpath=”${some.dir}/some_class.jar;
${env.ANT_HOME}/lib/bcel-5.1.jar”
verbose=”true” idlVerbose=”true”/>

Notice the difference?  Yeah, that fixed it…

1. jwsc
2. wlappc (LARGE JSP Pre-Compilations)

There may be other related compilation tasks, but bottom line is the Java Heap Size is too small. To increase it, you need to add $ANT_OPTS to your environment. An overkill, but also a sure way to fix the problem can be these values:

ANT_OPTS=”-Xmx1024m -Xms512m”

This variable must be set within your build machine’s environment. When ANT executes, it automatically includes $ANT_OPTS in its execution string. I hope this little hint will solve a lot of your future headaches. I’ve been troubleshooting a similar problem on a project I’m currently working on for the past 24 hours.  We went from plan a, to b, to c, to d, and started to run into a dead end and wanted to go for a temp fix by disabling pre-compilation.. until I found this root cause.

If you’re not currently using $ANT_OPTS, perhaps you should look into implementing that on your infrastructure. May end up saving you a heap of debugging time down the road.

Access Control,

Where there is a lack of established structure and process, there exists disorder and chaos relating to software Builds and Releases.  Access control must be implemented early on and strictly enforced to clearly define what can certain groups consume.

Builds, whether it be continuous, hourly, daily, or nightly in frequencies should only be made available to Dev and QA.  No exceptions.  In your org, if Program Management happens to fall under the umbrella of Engineering, then it wouldn’t hurt to grant Program Managers the same access privileges as that of the Dev and QA teams.

In no circumstances should groups such as Tech Pubs or Operations be given access to the builds.  That is the quickest way to creating confusion and risk having the software leaked prematurely or worst, given to the customer  without proper and formal approval.

Operations should only be given access to the released software (FCS – First Customer Shipment or GA – General Availability).  Tech Pubs and to a certain limited scope extent, Operations, can be given early access preview to the Alpha or Beta phase of the software in a separate distribution location made especially for these groups.  Since there may be needs for Tech Pubs to begin the documentation work and for Operations to go through the initial deployment exercises.

Aside from that, I believe you must keep the distribution points between the various groups well defined, structured, controlled, and most importantly, enforced.  Part of being a good Build and Release Engineer is being a good enforcer of processes.   Be unwavering in your stance when approached with a sob story or forceful demand for access to the builds distribution by a group outside of the QA or Dev teams.  Speak softly, but carry a big night stick. 

I’ll be interested to learn how you manage your released software’s distribution in your org.  Please share your thoughts.

My first attempt was this:

<schedule interval="900">
    <ant time="1200"
	 anthome="${ANTHOME}"
	 antworkingdir="${my_build.dir}"
	 buildfile="${my_build.file}" 
	 target="build.all.then.test" 
	 uselogger="true"
	 usedebug="false"/>		
    <ant time="1800" 
	 anthome="${ANTHOME}"
	 antworkingdir="${my_build.dir}"
	 buildfile="${my_build.file}" 
	 target="build.all" 
	 uselogger="true"
	 usedebug="false"/>	
    <ant time="2400" 
	 anthome="${ANTHOME}"
	 antworkingdir="${my_build.dir}"
	 buildfile="${my_build.file}" 
	 target="build.all" 
	 uselogger="true"
	 usedebug="false"/>			 
</schedule>

Which translates to the following build frequency: 6pm and midnight just build using build.all target. Noon build using build.all.then.test target.

It would make sense right? That didn’t work. For some strange reasons, all three time frame, it built using build.all.

So then I modified it, according to CruiseControl’s documentation recommendation, to the following:

<schedule interval="900">
    <ant time="1200"
	 anthome="${ANTHOME}"
	 antworkingdir="${my_build.dir}"
	 buildfile="${my_build.file}" 
	 target="build.all.then.test" 
	 uselogger="true"
	 usedebug="false"/>		
    <ant multiple="1" 
	 anthome="${ANTHOME}"
	 antworkingdir="${my_build.dir}"
	 buildfile="${my_build.file}" 
	 target="build.all" 
	 uselogger="true"
	 usedebug="false"/>			 
</schedule>

Which translates to check for changes and build every 15mins, but for the 12pm build, run the build.all.then.test instead. That did NOT work.. Did you run into a similar problem? What was your solution?

So why build machine image archiving you may ask?   Because sometimes when certain software gets released (1.0), the new (2.0) continues on the trunk with added features and *changes* compiler(s).  Now as 2.0 goes forward, the legacy 1.0 may still have bug fixes and the build loop may need to be brought back to reproduce a certain build; with that in mind, having a VMWare image works wonders in such situation.  There is a long list of benefits for such practice as well, but I’m not going through them now; I may add to this post in the future…

The problem for the latter argument is that A fails whenever B fails because there is no safety net for A.  As I was being overwhelmingly outnumbered, I caved in to the second suggestion which is to have A directly point to B‘s latest and greatest build.  Well, suffice it to say the decision came back to bite us.

We got bitten and yours truly had to spend additional time in fixing and changing the build scripts to adopt my original suggestion.  Now whenever B has a successful build, the script slaps on a label for A to point and consume.  This way we successfully ensure A will have the freshest dependency on B while avoiding unnecessary broken builds due to “tip” dependency.