Jenkins, Netbeans and Ant follow up: "Missing libraries in manifest file"

by


Posted on


Jenkins, Netbeans and Ant follow up:

A couple of days ago a bug report was made with the title: “Nightly builds have incorrect manifest“. Today i started to check and search why libraries where not added to the class path.
First of all, i really was not that surprised, it was more like, here we go again. It wasn’t already an “It speaks for itself” task to get a project compiling as we want as you can read at How to build in Jenkins using Netbeans and Mercurial DCVS on bitbucket. Again i will speak abount netbeans version 7.3.1.

So i first checked the manifest file created, and it even missed the Class-path declaration. As the Netbeans build xml files are quite comprehensive, i first hit google. Maybe my searches where not as good defined, because the only solutions i found where aimed at overwriting a specific ant task auto generated by netbeans. Allthough this ain’t bad, i was searching for something else because i do not want to create dependencies on local development pc’s.  We already have these like using the same jdk, jre and netbeans versions. So i began my own research.

First i wanted some verbose output to look for differences when the jar package is created. I added an init rule to my build.xml file so i could see some verbose output on the build server:

<target name="-pre-init"> 
<record name="build.log" loglevel="verbose" append="false"/>
</target>

With this a build.log is created, and i began to look for the differences. I found out that within jenkins the task “-do-jar-with-mainclass” is being ran to create the jar. In Netbeans the task “-do-jar-with-libraries-pack” is used. Ok, how can i get jenkins to run the same rule. The first hing i was thinking is, injected parameters. after tracing back from the task “-do-jar-with-libraries-pack” i found this little condition:

  <condition property="do.mkdist">
<and>
<isset property="do.archive"/>
<isset property="libs.CopyLibs.classpath"/>
<not>
<istrue value="${mkdist.disabled}"/>
</not>
</and>
</condition>

Because the jar is created i assumed the do.archive is correct, i also assumed (later on proved wrong) the libs.CopyLibs.classpath would also be set. So only the mkdist.disabled would not be set. So, i added the next to the build configuration in jenkins (screenhost later on will explain better): ‘-Dmkdist.disabled=”false”‘. After running a test build. it didn’t seemed enough, i saw in the build.log still the wrong ant task executed. The only thing i was thinking of that could be wrong, is the “libs.CopyLibs.classpath” property. The properties used in the build xml files are defined in .properties files in netbeans.

So, i began to open the project.properties, private.properties, etc.. and could not find this “libs.CopyLibs.classpath” property. After taking a look again in the in netbeans verbose output of the build command, i did see another property file is included. This was the Netbeans “C:\Users\John\AppData\Roaming\NetBeans\7.3.1\build.properties” file. After opening this file, the magic classpath property was found, and it was pointing to a jar file used for setting the the conditional property do.mkdist. Thus i added another extra command line parameter to set this property:

-Dlibs.CopyLibs.classpath="C:\\Program Files\\NetBeans 7.3.1\\java\\ant\\extra\\org-netbeans-modules-java-j2seproject-copylibstask.jar"

Now, after doing a new build test, i checked the manifest. And there they are! The Class-path in the manifest is now composed correctly and pointing to the correct directory and used jar libraries. The screenshot below explains how to set the above variables at the jenkins ant task where the jar is build. First go to your project, go to configure, and go to the ant task that builds your jar file, click the advanced button so you will see the same as below:

create-libs-in-manifest-in-jenkins

You of course have to change the paths which correspondents to you’re own installation.

If you have the same problems as i had i hope the above could help you to solve it.

John.

Latest news/blog

Friends of PiDome

Atlassian
Products for teams, from startup to enterprise
RFXCOM
Affordable 433Mhz RF transceivers
UniPi.technology
Home-automation hardware manufacturer

Latest added technology

  • SMS
  • Z-Wave
  • PushBullet
  • PlugWise
  • MQTT

Some project stats

Open Hub project report for PiDome Platform

Other

Official NLJUG Member