I have an ANT task that uses the jar task to update a few files inside of a previously built war. [The files are processed between compilation of a WAR and deliverable.] How can I get ANT to update all of the files I've specified to be updated? There is an attribute for jar called update = "[...]" that will allow you to either force a new creation of the Jar file or (add new files/"update existing ones if deemed necessary").
An example:
Java class(es) are compiled
Jars are created
A .war is created
A script runs to modify the Jars
The .war needs to update the Jars that were modified [the Jars are a subset of all of the files in the war]
The problem I'm running into is that the Jars that are being instructed to be updated aren't getting updated in the final step. The log claims that the just processed Jars are "out of date." Is there a way I can force the update to happen? If I switch "jar [...] update" back to false (which its by default) the correct Jar files get placed there, but the rest of the files in the war don't.
Note I realize that this could be moved to produce the WAR after everything is done. But this is not an option for me.
The ant task in question:
<target name="(the 'Rewaring task')" depends="step-3">
<echo>Adding modifed jars to war</echo>
<jar destfile="${output.war.dir}/existing.war" update="true">
<zipfileset dir="${output.jar.dir}/modded-jars" prefix="folder" />
</jar>
</target>
More specifically, the problem I'm having is with the "update" behavior.
It looks like the Jar task is correct.
Are you sure the files being updated have the correct Date modified time - that is what is actually compared in the zipfileset/update option?
I've seen this issue when signing Jars [and had the preservelastmodified option set to "true" (default : false)].
To fix it, you should only need to change the signing option.
Related
I'm doing a build using Ant and generates a jar file at the end that I copy to a folder using the command below.
<jar destfile="../../folder/job.jar"....>
however it looks like that it does not replace the old jar file when it generates a new one. How can I force it to replace the old jar file with the new one?
By default, the <jar> task overwrites existing JAR files...
The update parameter controls what happens if the JAR file already exists. When set to yes, the JAR file is updated with the files specified. When set to no (the default) the JAR file is overwritten.
If the <jar> task in your Ant script isn't setting update, then we'll need to see more of your Ant script to understand what is happening.
To replace an existing jar, use the 'update' attribute and set it to 'yes'. By default, update is set to "no".
So, for example:
<jar basedir="sourceDir" destfile="target/existing.jar" update="yes" />
I have a Java project composed by many jar files, let's say the application directory is composed by the following jar files:
File_1.jar
File_2.jar
...
File_N.jar
In addition there is a file executable file which makes use of the jar files
For some reason I am responsible of modifying two jar files, les's say File_1.jar and File_2.jar with the particularity that File_2.jar requieres the project associated to File_1.jar in the build path.
I generated the jar files without problems, so rigth now the application has the following jar files:
File_1_modif.jar
File_2_modif.jar
File_1.jar
File_2.jar
...
File_N.jar
Everything went fine, I mean I could execute the application with my modifications but my problem came up when I removed the old jar files(File_1.jar, File_2.jar) from the application directory. Actually I do not get an error message but the application does not behave as it did before removing the old jar files, I was wondering if I should generate the file File_1_modif.jar in an special way due to the fact that this file is requiered to build the file File_2_modif.jar. Could anybody advice my some tries to do in order to fix my problem?
It appears your project is still referencing the File_1.jar and File_2.jar. You may need to locate how the jar files are being loaded into your project, if in eclipse or netbeans, you'll need to add the File_1_modif and file_2_modif files to your build path and remove the file_1.jar and file_2.jar. If you are using ant build, you will have to include the .jar files using directives like this:
<fileset dir="${lib}">
<include name="file_1_modif.jar"/>
<include name="file_1_modif.jar"/>
<exclude name="**/${ant.project.name}.jar"/>
</fileset>
After some discussion with a colleague from another company that also uses App Engine, he told me that he managed to cut down his app warm up time from ~15 seconds to ~5 seconds using the following steps:
Configure Eclipse to bundle classes produced during compilation into a single JAR file.
Configure Eclipse to upload this single JAR file instead of hundreds (or thousands) of separate Java classes during App Engine deployment.
He argues that during instance warm up, since the instance need to load only a single bundled JAR file instead of thousands of separate classes, the warm up would be significantly faster. Any thoughts or opinions about this?
I would definitely like to try it by myself, but I don't have enough Eclipse-mojo to know how to configure such steps. Does anyone know how to configure Eclipse or the Google Plugin for Eclipse to do the steps outlined above? (And have the deployed apps successfully runs in App Engine, of course)
Thank You,
What we did in Eclipse was:
In Project Properties > Java Build Path (Source tab) change output folder from war/WEB-INF/classes to something else, e.g. bin (I believe Eclipse complained about this once)
In Project Properties > Builders add a new builder (I used type "program builder" and pointed it to the jar executable in my JDK, but as others mentioned an Ant builder would work too). Obviously you should configure this builder to take its input from wherever you decided to write your class files to, and output to something like war/WEB-INF/lib/myclasses.jar
You can configure the jar builder to execute automatically as class files change (which in turn are usually automatically recompiled as your source files change).
There are some downsides, though. For some reason the google eclipse plugin gets confused by your changing the output directory of the java compiler. This means you will have to manually point to the war directory when deploying, and I believe you'll have to manually copy some GAE jars into the war/WEB-INF/lib folder.
I don't know how (or if) you can integrate it into eclipse, but it's fairly trivial to do with ant:
<import file="${appengine.sdk.dir}/config/user/ant-macros.xml" />
<target name="deploy">
<delete dir="${staging.dir}" />
<mkdir dir="${staging.dir}" />
<copy todir="${staging.dir}">
<fileset dir="war">
<exclude name="WEB-INF/classes/**" />
<exclude name="WEB-INF/appengine-generated/**" />
</fileset>
</copy>
<jar destfile="${staging.dir}/WEB-INF/lib/classes.jar" basedir="${classes.dir}" />
<appcfg action="update" war="${staging.dir}" />
</target>
I will add that I did not experience a 3X reduction in app startup time. I posted some experimental numbers in this thread:
https://groups.google.com/d/msg/google-appengine/dStBW4wIemY/K69f9ufDiN0J
What I found is that instead of varying wildly from 20-45s, it made my app consistently load in 20s. It has not subsequently remained this consistent, but I still jar my classes as a standard part of deployment now.
One way this can be achieved if by doing the deployment through Ant, as described in: https://developers.google.com/appengine/docs/java/tools/ant
Next you can modify the ant build.xml file to call the ant command for building the jar file. Just before the actual deployment you can either delete or move the compiled artifacts away. The build jar-file should be placed in the WAR/WEB-INF/lib folder.
Drawback of this solution is that you have to deploy through the build.xml, i.s.o. through the appengine eclipse plugin.
As stated in an earlier answer, the App Engine SDK supports packaging WEB-INF/classes into a jar file, which will end up in WEB-INF/lib/_ah_webinf_classes-0000.jar. You can activate this
using the appcfg tool with the option --enable_jar_classes.
using the Google Plugin for Eclipse by configuring the properties of either your WAR or EAR project: Project properties > Google App Engine > Deployment > "Package WEB-INF/classes as a jar"
For me, on App Engine 1.9.4, this resulted in only a minor improvement in instance spin-up (about 5-10 %, if any).
Note that this will package all files in WEB-INF/classes (not only .class ones). Following the change, I got an error message during instantiation about not being able to read the logging.properties file anymore; probably because the new jar file hasn't been read at that time:
Unable to read the java.util.logging configuration file, WEB-INF/classes/logging.properties
As a workaround, I changed the path in appengine-web.xml to WEB-INF/logging.properties and configured the maven-war-plugin to copy the file to that location:
<webResources>
<resource>
<directory>lib</directory>
<targetPath>WEB-INF/lib</targetPath>
</resource>
<resource>
<!-- Workaround: During GAE deployment, all files in WEB-INF/classes will be packaged into WEB-INF/lib/_ah_webinf_classes-0000.jar,
which prevents the logging.properties referenced in appengine-web.xml from being read. -->
<directory>src/main/resources</directory>
<includes>
<include>logging.properties</include>
</includes>
<targetPath>WEB-INF</targetPath>
</resource>
</webResources>
Note that as of version 1.7.4:
You can now package all the WEB-INF/classes/* classes into jar files. This can be done via the new
--enable_jar_classes option in the appcfg tools. By default, this option is not set.
http://code.google.com/p/googleappengine/wiki/SdkForJavaReleaseNotes
I think the easiest way to do this would be to have a separate project that you write all the code in as well as store any other dependencies. When you're ready to deploy, Eclipse's export to runnable JAR file can repack all the dependencies and your classes into a single JAR file, which you would then use as your one dependency in your deployable Google App Engine project which would basically consist of any config files in the WEB-INF folder as well as other static resources + the one big JAR file.
Alternatively to the eclipse export, you can set that up as a Maven or Ant build which can also do the repacking.
He argues that during instance warm up, since the instance need to load only a
single bundled WAR file instead of thousands of separate classes, the warm up
would be significantly faster. Any thoughts or opinions about this?
I doubt it. WAR is just a ZIP file, which gets unpacked when it's deployed on the server. So there is an additional step, meaning the process can be equally fast (if unpacked when uploaded) or slower (if unpacked when instance is spun up).
I want to build my ear file once and then use ant to change some settings in application.xml, property files etc.
Is there way to do this with ant?
[edit] Just found this
How do I modify a file in a jar file using ANT?
The only way you can modify a file inside your jar or ear is to use the <unzip> task, use the <replace> task to modify the fields in the file, and then rezip the file back up with either the <zip> or <jar>/<ear> task.
There are several ways you can handle this without having to unzip and rezip your ear/jar/war files:
The preferred method is to setup your application server, so it can find your properties outside of the ear itself. It is also possible to configure the application.xml file not to use relative directories when specifying locations instead of specifying locations from the root of the machine. By removing embedded environment information from your ear, you can use the same earfile on all of your environments.
We, unfortunately, are unable to do the above and must provide separate ear files for each environment. We use Jenkins as our continuous build server. When Jenkins does our builds, we build multiple ears, one for each environment, at the same time. This way, as we move from Dev to QA to STAGE to Production, we can at least refer to the same build number. We compile once, then use the AntContrib <foreach> task to ear up the earfile with the correct properties file settings and the correct application.xml file. We use <filterset> in our <copy> task to modify the properties and application.xml as we build the ear.
You can do something like this
<zip destfile="tmp.jar" >
<zipfileset src="lib/myjar.jar" excludes="org/example/My*.class" />
<zipfileset dir="bin" includes="org/example/My*.class" />
</zip>
<move file="tmp.jar" tofile="lib/myjar.jar"/>
In this example we create a tmp.jar using myjar.jar as the source but excluding all classees beginning My in the org/example directory. We then add our new version in from the bin directory. We then replace the jar file with our new version.
When receiving a bug report or an it-doesnt-work message one of my initials questions is always what version? With a different builds being at many stages of testing, planning and deploying this is often a non-trivial question.
I the case of releasing Java JAR (ear, jar, rar, war) files I would like to be able to look in/at the JAR and switch to the same branch, version or tag that was the source of the released JAR.
How can I best adjust the ant build process so that the version information in the svn checkout remains in the created build?
I was thinking along the lines of:
adding a VERSION file, but with what content?
storing information in the META-INF file, but under what property with which content?
copying sources into the result archive
added svn:properties to all sources with keywords in places the compiler leaves them be
I ended up using the svnversion approach (the accepted anwser), because it scans the entire subtree as opposed to svn info which just looks at the current file / directory. For this I defined the SVN task in the ant file to make it more portable.
<taskdef name="svn" classname="org.tigris.subversion.svnant.SvnTask">
<classpath>
<pathelement location="${dir.lib}/ant/svnant.jar"/>
<pathelement location="${dir.lib}/ant/svnClientAdapter.jar"/>
<pathelement location="${dir.lib}/ant/svnkit.jar"/>
<pathelement location="${dir.lib}/ant/svnjavahl.jar"/>
</classpath>
</taskdef>
Not all builds result in webservices. The ear file before deployment must remain the same name because of updating in the application server. Making the file executable is still an option, but until then I just include a version information file.
<target name="version">
<svn><wcVersion path="${dir.source}"/></svn>
<echo file="${dir.build}/VERSION">${revision.range}</echo>
</target>
Refs:
svnrevision: http://svnbook.red-bean.com/en/1.1/re57.html
svn info http://svnbook.red-bean.com/en/1.1/re13.html
subclipse svn task: http://subclipse.tigris.org/svnant/svn.html
svn client: http://svnkit.com/
Use the svnversion command in your Ant script to get the revision number:
<exec executable="svnversion" outputproperty="svnversion" failonerror="true">
<env key="path" value="/usr/bin"/>
<arg value="--no-newline" />
</exec>
Then use the ${svnversion} property somewhere in your EAR. We put it in the EAR file name, but you could also put it in a readme or version file inside the EAR, or specify the version in the EAR's META-INF/manifest.mf:
<!-- myapp-r1234.ear -->
<property name="ear" value="myapp-r${svnrevision}.ear" />
You'd want to provide the Subversion branch and repository number. As discussed in How to access the current Subversion build number?, the svn info command will give you this information, which you can then use to build a VERSION file or place in any of the other files that you're building into your *AR files. If you've nothing else in mind, you could consider using the XmlProperty Ant task to extract the relevant information from the output of your
svn info --xml command
Check out the jreleaseinfo project. Contains a ANT task that can generate a java class that can be called at runtime to display the release info for your project.
I like its simplicity.
See also this question: Build and Version Numbering for Java Projects (ant, cvs, hudson)
It includes several helpful code snippets.
From the top of my mind. A tag for each jar build?
We have the first part of our build create a version.txt file in the root of the package and dump the tag used to check the code out from (in our case) CVS... Additionally, the final part of our build process checks the fully built EAR back into CVS for future reference.
That way, if we have an issue with a webapp - it's just a case of asking the reporter to hit /app/version.txt - from there we can drill down the particular build history in CVS to locate the relevant components (handles different versions of libraries in apps) to locate the error.
Not sure how much help this is to our support folk - but it's definitely something they complain about not being there!
Do automatic builds, and place a tag (with a date stamp) on the codebase when the build is succesful (with unittest ofcourse).
In your delivery process, only deliver tagged builds to the customer. This way you are in control, and can place the tag name in a readme.txt somewhere, or have the filename of the ear file reflect the tagname.
I personally switched back to CVS, and this is one of the reasons. In CVS, I can have a class report it's tag. All my jar files contain a "main" which makes them runnable. With support questions, I ask the customer to do a "java -jar somejar.jar" and send the output to me alongside the question.
This way I'm sure of the build they-re using, and I can even have information like java version, OS type and version. Without the customer having to answer strange questions.
It's simple but very effective.
Why not put the build number into a properties file... this can then be easily read by the java and output to a Help | About dialog (applet/application), web-page footer or whatever other GUI you might have.
(See the footer on every SOF page.... has the SVN version number there.)
Seems a load easier than looking in the WAR/EAR/JAR etc easy time?
I store the absolute repository revision as a part of my full version number. This gives people a quick glance to see if a given change is in a given version or not.
We also store the version number / build date / etc in the manifest file of the ear as custom properties, these are mostly informational only. We also store it in a properties file that is built into our jar, so the application can read it.