I have a project which I can build and deploy correctly using Ant
I want to build a war file to deploy the project.
I can get everything working except I cannot get the properties file to appear in the classes directory.
My properties file is located here: /h/a/A/I/S/src/Serv/log4j.properties
This is the war section of my build file:
<war destfile="Int.war" webxml="web/WEB-INF/web.xml">
<lib dir="${libDir}" />
<classes dir="${outputDir}" includes="/h/a/A/I/S/src/Serv/log4j.properties"/>
<classes dir="${outputDir}" />
</war>
I have read the previously asked similar questions here and added the second classes element here which includes the properties file but it did'nt worked for me, any suggestions
In this line, path of .properties file will be assumed by ant as "${outputDir}/h/a/A/I/S/src/Serv/log4j.properties" which is an invalid path in your project..
Try using copy task for moving .properties file to '${outputDir}' directory and then perform war packaging.
I am trying to write an ant target that will create a jar based on a bunch of java files and some properties files, but am having trouble including the properties files the way the project is set up currently.
These are the ant targets I have:
1 - Compile the java souce files from the "myjar.src" folder and put the resulting classes into a "myjar.classes" folder. Once this is done copy all non .java files from "myjar.src" to "myjar.classes".
2 - Create the jar using the "jar" command using basedir = ${myjar.classes} and tell it to include everything.
These are the ant targets I want:
1 - Compile the java souce files and put the resulting classes into a "myjar.classes" folder. Only .java files are included
2 - Create the jars using the "jar" command using basedir = ${myjar.classes.location} but also include the .properties and .xml files from "myjar.src."
The key difference is I want the properties and xml files from "myjar.src" to be included when I package up the classes in "myjar.classes" using basedir = ${myjar.classes} - How do I include these fies when they are not underneath "myjar.classes"?
This is the ant target I want to modify:
<CreateManifest title="myjar classes etc"/>
<jar
destfile="${myProject.build.jars.dir}\ta_test_driver.jar"
basedir="${myjar.classes}"
manifest="${manifest}">
<include name="**"/>
</jar>
The reason I am not just using a directory one level up for basedir is that none of the other jar creation calls in the project do that, and I am hesitant to change that for just this one. I did try to do that, but had trouble specifying the right directory. (There are other jars that use a similar directory structure, and I don't want to interfere with them either now or in the future.) I was just wondering if these is a better way to do this? Thanks very much.
I managed to figure this out from here: How to include file in Jar through Ant at specific location
This was my modified ant call in the end:
<CreateManifest title="myjar classes etc"/>
<jar
destfile="${myProject.build.jars.dir}\ta_test_driver.jar"
basedir="${myProject.classes}\ta_test_driver"
manifest="${manifest}">
<include name="**"/>
<zipfileset dir="${myjar.src}"
includes="**/*.xml, **/*.properties, **/*.gif"
/>
</jar>
Notice the zipfileset tag.
In my webapp; WEB-INF/lib is added in classpath by default which is fine.
Now, I want to add spring jar files in my tomcat's classpath. If I put all the jar files inside WEB-INF/lib; it works fine. But if I want to add a directory WEB-INF/lib/spring and put all jar files inside spring directory ; it doesnt work. How can I include WEB-INF/lib/spring in classpath.
I would prefer to make changes in web.xml as that is very localised to my webapp. Surely I will not want to make changes in catalina.properties because there all the jar files are loaded in JVM ( not just added in classpath )
You shouldn't care about how the jar files are segregated into the war file: it's only used by the container. Segregating the jar files could be useful in your source project. But then you just need to have a build process (using ant, gradle, whatever) that copies all the jar files from all the subdirectories into WEB-INF/lib. Using ant:
<copy todir="web/WEB-INF/lib" flatten="true">
<fileset dir="lib">
<include name="**/*.jar"/>
</fileset>
</copy>
Since things don't care about JAR naming, another alternative is to simply append prefixes to the the JARs (i.e. "spring-OLD JAR NAME.jar") to keep related JARs grouped without folders.
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.