I have just set up Hudson on my server. For some reason, my build will not call javac to compile my builds...? I have set the path to the JDK in the Manage Hudson area, and it seems to recognise it (doesn't give me a warning). Is there something else I'm supposed to do?
Here's a sample console output of one of my jobs (note how javac isn't called at all):
Started by user admin
Checking out
svn+ssh://myhost.com/Project1
A /src/Program.java
A build.xml
U
At revision 119
no change for
svn+ssh://myhost.com/Project1 since
the previous build
Finished: SUCCESS
You need to set the ant-target for your build.
Since this is a netbeans project you should have ant target like: compile, default etc?
One or more of these build target must be set in your job on hudson under the configuration menu. I think the field is called "Targets"
Some information on configuring ant in hudson: http://testinfected.blogspot.com/2009/01/hudson-default-anth.html
Related
I currently have a SoapUI project which I intend to have executed periodically (every 5 minutes) in Jenkins. I've completed the following thus far:
Created the relevant directory in the Workspace i.e workspace\SOA\SOAProject\src\test\soapui\SoapUIProject.xml
I've configured a pom.xml which sits in the SOAProject folder alongside the src folder
I've created a Jenkins job (I've chosen a Maven project, although it should not be an issue if I had chosen a freestyle job)
My question is, how do I set the endpoint?
I've done the following...
Build
**Root POM** pom.xml
Goals and options
testrunner.bat -e0.00.0.006:8040
Edit:
I've installed the EnvInject plugin. I'm not sure how to create the /properties file and what to put in their in order to set the execution environment?
I don't know the answer, but my suggestion is to get it running via command-line first. Once you figure out how to launch it without Jenkins, having Jenkins issue the same command because easy.
If you choose a Maven project, there is a useful plugin to set the endpoint and different propeties for the testSuites...
https://github.com/redfish4ktc/maven-soapui-extension-plugin
I'm setting up Jenkins for the first time and running into an issue where Jenkins does not appear to even attempt to execute the Ant task I've specified.
I've defined my JDK and Ant installations under Manage Jenkins.
I've setup my Job to Invoke Ant using the Targets 'war-all'
Whether I force a build or wait for it to naturally execute after the next commit, there is nothing in the Build Console Output about attempting to execute the ant task.
Here is a sample Console Output:
Any ideas as to why it might not be executing would be appreciated. Also tips on how I can find more logging from Jenkins which might provide clues as to why it is not executing would be helpful. I'm not sure what Logger I might specify or even then where the logging information is written on the file system.
The problem was that I was selecting "Build multi-configuration project" as the type of my job. When I select "Build a free-style software project" as my job type the Ant task will execute after the SVN update.
Looks like your svn doesn't see any changes and therefor is not re-building the module.
Try deleting the workspace and re-trigger the build, or change the check-out strategy to 'Always check out a fresh copy'.
I faced the same problem when upgraded to 1.417 from 1.413.
The combobox "Ant version" disappeared from "Invoke ant" build step. It should be here.
I just downgraded to 1.413 and continue to work.
So, the answer is - you should specify "Ant version" in project settings. But you cannot do it in 1.417.
It seems like Jenkins doesn't like when you create a job before configuring JDK. If that happens, job will never work properly. So, for me the solution was:
Delete job.
Configure JDK
Re-create job.
Probably the same problem may arise when job's JDK is deleted.
In my case,ant default target was not being picked up from build.xml so I had to explicitly mention the target in jenkins option.
I resolved this by changing the jdk to default and then again switched to what was set earlier.This is a workaround but not sure how this resolved.
I have a shell script that runs lcov (test coverage) on an iOS project that I have Hudson. Hudson's copy of this project is derived from a Git repository. The way that I have set up now is that whenever the repo is updated or if someone manually builds the project in Hudson, Hudson would automatically run the app, and then run my shell script after the build is done. lcov can only be run after the app is not only built, but automatically run with some functional test tools. So, I cannot run the shell script as part of the build process, through XCode. It must be run after the app finishes building and running.
However, I would like to use this project in multiple Hudson jobs. Unfortunately, in each Hudson job, the iOS project is named differently. I would like to refer to the build path with some sort of environmental variable, but I don't know how to. Does anyone have any tips as to how to find that?
If I understand you correctly this is really a Hudson question. You can set "global variables" in your Hudson config and then invoke shell scripts, batch files, ant builds etc. You can also set them dynamically on each invocation of your Hudson job. Not sure exactly how to help you in your specific environment without more info.
Is it possible to Trigger an exe to run on a failed build? Can you do this within Team City?
If you specifically want the failed builds, you can set up the dependent build as Eric said, and have that secondary buildscript use the REST API to pull up a list of the failed builds for the actual project.
If the latest build is in that failed builds list, then tell the build script to run the executable. If not, then you're all done!
http://confluence.jetbrains.net/display/TW/REST+API+Plugin
I don't think it's possible to trigger an executable to run only on failed TeamCity builds. TeamCity usually allows you to do things either always or only upon successful builds.
It would be possible to trigger an executable to run after this build is finished (failed or successful).
If that would work for you, you could set up a new build configuration that runs the executable. The new build configuration would have a "finish build" trigger. This would cause the executable to be run whenever the other build is completed.
You should add another build step with the exe you want to run and set the correct option to execute.execution options
My work project needs to be compiled and run under JDK1.5 and I'm on a Mac. I followed the instructions here to get 1.5 back on Snow Leopard, and it works fine when building from IntelliJ IDEA, or if I'm just in the same directory as the build.xml and try "ant CleanRebuild" When I "Run Target" in NetBeans they're all compiled with the wrong version resulting in
java.lang.UnsupportedClassVersionError:
Bad version number in .class file
(unable to load class...
when tomcat is trying to start up.
So things I've tried
Set the "Java Platform" to 1.5 under the project properties/libraries.
Set the Source/Binary Format to JDK 5 under project properties/sources.
Pointed the ant home to the ant I'm using under preferences/ant
Renaming every javac executable I could find in the hopes NetBeans would fail to compile and I could figure out which one it was using (no luck)
Setting 1.5 as the default, resulting in the need to point $netbeans_jdkhome to the 1.6 jdk in order for NetBeans to even start.
All unsuccessful....
Again, if I cd into the directory of the netbeans project with the build.xml and run the command manually all is well....so NetBeans. What's the deal?
Revised answer
Assumptions: NetBeans version 6.9.1 (although likely applicable to most or all 6.x versions), alternative build systems (e.g., Maven) are not used...the default (Ant) is used.
NetBeans, by default, uses Ant as its build system for doing things like compiling a project, building a project, cleaning built files from a project, etc. Ant has two concepts that are applicable here: targets and tasks. A target, in Ant's vocabulary, is simply a "command" or a series of jobs that need to be completed for a particular job. In NetBeans, common targets are "Compile", "Build", "Clean and Build", etc. The "jobs" that a target completes are (among other things) Ant tasks. In NetBeans one task (which is particularly relevant in answering this question) is the Javac Task. This is the task that Ant uses to compile .java files into .class files.
An Ant-based project, and therefore a NetBeans project, uses the file build.xml to control the build process and tell Ant how to go about accomplishing the targets. In a NetBeans project, the build.xml is found in the root directory of the project, by default. NetBeans, however, uses a user-extensible build.xml file. The core targets and tasks defined by NetBeans are actually located in nbprojects/build-impl.xml and imported into build.xml within the first few lines of the file. The theory is that users can add or override things in build.xml while the core NetBeans-defined configuration remains untouched in the build-impl.xml file.
If you look in the default nbproject/build-impl.xml file for a NetBeans Java project, you will find the Javac task referred to twice. (Search for "<javac".) Both are in macro definitions, and therefore deep within the complexities of NetBean's default build configuration. If we refer to the Javac Task documentation we find that the tasks uses the compiler in the location specified either by the global build.compiler property, by the compiler attribute specified with the <javac... /> task, or the default which is the Java compiler that is used when running and, and thus the one that is used when running NetBeans (because it is what fires off the Ant process). Since we don't see build.compiler or the compiler attribute anywhere (in the default build-impl.xml), then we can only conclude that the default is being used.
So here we have the (more-or-less correct) first answer. NetBeans compiles using the JDK that was used to execute NetBeans by default. It looks like it is actually a bit more complicated than that simple answer, but it is essentially correct. If you look at the documentation for the Javac Task it alludes to "a class that implements the CompilerAdapter interface", which suggests that rather than calling the javac executable directly, Ant (and therefore NetBeans) compiles using the compiler class (that, in all likelihood, the javac executable also uses). Refer to the Original answer below to determine which JDK what used to run NetBeans.
So, what if you don't want to use the default JDK that was used to run NetBeans? This is where "Java Platforms" comes in. Go to the Tools menu, and click on "Java Platforms". You likely only have one platform defined here. (As an aside, this is actually the most correct answer to what JDK is used by default... the one defined here in the Java Platform Manager.) If you would like to compile against another Java version (say your default JDK is 1.6, but you want to compile against 1.5) then you would install the alternate JDK somewhere on your system, and then configure a platform here in NetBeans' Java Platform Manager. (I'll leave it as an exercise for you to find the documentation on how to add a Java Platform. A superficial search of the wiki didn't turn up anything obvious. In any case, it's fairly self-explanatory.)
Once a new platform is created in the manager, you would right-click on your project in the Projects tab, click on "Properties", and then on "Libraries". At the top, you would select the appropriate Java platform for the project. As soon as you change this value and click on "OK", NetBeans makes several adjustments to your build-impl.xml file that point it to the new JDK against which to compile. (It is instructive for the truly geeky amongst us to make a copy of the nbproject directory before making this change and to diff that against the new contents of the nbproject directory after the change is made.) The changes instruct the Javac Ant Task to use the (equivalent of the) javac executable of the specified platform. So here we have the most correct answer: NetBeans uses the equivalent of the javac executable (as invoked by the Ant javac task) that is specified in the project's Java Platform located under the Libraries node of the project's properties.
Original answer
The path to the JDK used by NetBeans can be found in the netbeans.conf file. Look for the netbeans_jdkhome entry.
You can also specify the jdkhome at runtime (*NIX example given):
netbeans --jdkhome /usr/bin/jdk1.6.0_22
The netbeans.conf file is found in different places depending on what OS you are using. See the NetBeans.conf FAQ on the NetBeans wiki for help finding the file.
A few additional comments...
...You can specify the -target option in the project properties. In NetBeans 6.9 right-click on the project, and choose Properties. Click on the Compiling node. Add your -target to Additional Compiler Options.
...I have read in a few places that specifying a target is not a guarantee that the code will run on a JRE whose version is lower than the JDK that built it. In other words, the recommendation seems to be that if you want 1.5 binaries, then compile with the 1.5 JDK.