I'm running a web service that allows users to create simple android apps. I'm using ANT to automate the building of the APKs:
Create the project folder (eclipse-style)
Copy libs (ad sdks) to the libs folder
Run ant
The problem is that even if the libs are always the same for all apps, they are pre-dexed for every single app and the build process takes much longer than needed. I understand this is the normal behavior for the setup I have now.
What I'd like to do is keep all the libs in a common folder on the server and tell ant to use those, preventing the pre-dexing process to happen for each app.
I'm not sure what settings to use in ant.properties or build.xml to make this happen.
Thanks!
You can use the lib switch to specify a library
-lib specifies a path to search for jars and classes. Or put the libs in the standard directories.
Any jars or classes in the directories of the path will be added to Ant's classloader. The order in which jars are added to the classpath is as follows:
*.-lib jars in the order specified by the -lib elements on the command line
*.jars from ${user.home}/.ant/lib (unless -nouserlib is set)
*.jars from ANT_HOME/lib
First of all, a tiny improvement; put your shared libs where you want and than, for each Android project that requires one or more of these libs, just create a symlink in the project libs/ directory which point to the desidered lib. You can save space and time, specially if the webserver is used by many users.
To avoid the multiple-dexing stuff, you may try to build a standalone .dex file of your libs and use it dinamically inside your apps using a ClassLoader.
You can start from this: http://android-developers.blogspot.in/2011/07/custom-class-loading-in-dalvik.html
Related
I currently have a basic Java project, that I want to deliver as an executable JAR. The program within it is based on several resource files, which must be editable by the user, or by a third-party program, which means that those files must not be embedded into the JAR archive.
I am using Eclipse to develop my project. The question is :
How to make the exportation of those files automatic, to end up with the JAR, and right next to it, a folder containing the resources for exemple (if that is possible of course) ?
Every thing I've tried or found on the net concerns resources delivered within the JAR, which avoids any modification of those resources. The ideal solution would copy the files right next to the JAR when it is exported.
Eclipse's "export executable JAR" functionality can't do this directly, it's limited to the contents of the JAR. I recommend you investigate doing this with a build tool like Gradle, Maven, or Ant, and then invoking that from Eclipse or via command-line.
I've got a Java project hosted on github. My project needs few custom .jar files to be imported. Since I was to be able to run the project anywhere, I want to include jar files inside the git repository. Is there a recommended, conventional place where jar files should be kept, e.g. lib dir of the root project directory?
PS
At the moment I'm not using Maven and I'm not considering it.
The usual case is actually a lib folder. Or webapp/WEB-INF/lib it is a web application.
But ths usual case is bad. I would not put jars in my source management system. If you need to add references to another project, you might consider having a look a git submodules (though you are using Github).
Post ADT 17, non-Android libraries need to be included either in the "libs" folders of the project or exported via the "Order and Export" tab in the build path. What's the difference (if any) between importing a library externally:
And internally:
Is there an advantage to importing a library in a way that it is included in the "Android Dependencies" group?
How do you add external jar dependencies into your Android project's build path (internally or externally) make no difference on the actual build process (more specifically at compile and dex step), all it does is to tell build process where to looking for the required jars at compile and dex step.
The Android Dependencies element shown in Java Build Path - Libraries window is just another abstract layer that ADT plugin used for managing/grouping jar dependencies. where your external jar files (in your case android-support-v4.jar) appears (inside or outside Android Dependencies) in that window makes no difference.
Since r17, dependencies management has been much improved, and it is recommended to use libs/ directory store all jar dependencies (refer to you internal way), which is considered as a automation approach (as ADT plugin becomes more smarter now), see Revisions for ADT 17.0.0:
New build features
Added feature to automatically setup JAR dependencies. Any .jar files in the /libs folder are added to the build configuration (similar to how the Ant build system works). Also, .jar files needed by library projects are also automatically added to projects that depend on those library projects. (more info)
However, you can still use the old way (refer to you external way) if you prefer, which is considered as a manual approach (as ADT plugin was stupid before), see Recent Changes‎ for r17 Release:
Important: If you are still referencing jar libraries manually instead of putting them under libs/ be aware of the following:
If the project is a Library project, these jar libraries will not be automatically visible to application projects. You should really move these to libs/
If the project is an application, this can work but you must make sure to mark the jar files as exported.
Is there an advantage to importing a library in a way that it is included in the "Android Dependencies" group?
Automation vs. Manual from dependency management perspective, automation is always considered as more errorless than manual in the world of computer science.
The number one, show stopping, 'I can't believe they didn't test this', disadvantage of putting external jars in the libs directory is that you can't set the javadocs location for them, as the option shows as 'None (non modifiable)'.
Hence I still use Export option in build properties
It has to do with library dependency management of Android. for details see http://tools.android.com/recent/dealingwithdependenciesinandroidprojects
From the Eclipse FAQ
An internal resource resides in some project in the workbench and is therefore managed by the workbench; like other resources, these resources can be version managed by the workbench. An external resource is not part of the workbench and can be used only by reference. For example, a JRE is often external and very large, and there is no need to associate it with a VCM system.
So, quite simply, if you want to be able to manage a JAR as part as the project, exposing it to SCM and such, then treat it as a internal resource otherwise, treat it as a external resource. It will not make any difference in the APK produced in the end, its simply a eclipse thing.
If you want to avoid creating a copy each time you want to use your library, treat it as a external resource. But, can I suggest you look into maven and the android maven plugin, maven has a bit of a learning curve (especially if you are used to "make" or "ant" style build scripts), but it is very much worth the effort.
I have a Java application and created a JAR file and deployed it.
The App uses external JARs such as the Log4J JAR. When creating my JAR file, how do I include all external dependent JARs into my archive?
In order to get my App working, I'm having to copy the Log4J JAR into the same directory as my own JAR which kinda defeats the purpose of the jar. Wouldn't it be more elegant to have 1 single JAR file to deploy?
If you use Eclipse, You can extract all included files into one runnable jar like this:
Right click on your project name from Package Explorer and select Export.
In Export screen, select Java -> Runnable JAR file and Next.
Fill in the Runnable JAR File Spec screen and Finish.
You can choose whether to package dependency jars as individual jar files or extract them into the generated JAR.
You could use something like One-JAR to package your Java application together with its dependency into a single executable Jar file (One-JAR uses a custom classloader to make JARs nesting possible).
You have to expand the library jars into the same place where your compiled classes go, then make a jar from that. Depending on how your build process is set up, there may be multiple ways to achieve this. It's not rocket science - a jar is just a zip archive with a META-INF directory at the root level.
Keeping JAR separate is better as it is easy to upgrade only the specific JARs to its new versions without touching any other configuration. As of your issue of having to copy each file to same location as of your JAR, you can always use Java CLASSPATH and include any JAR to your application's class path.
A JAR is not itself capable of nesting other JARs, as you discovered.
Traditionally, one would distribute a ZIP archive or other installer that would unwind the application JAR (yours) as well as any support JARs in the appropriate location for classpath access. Frequently, then, the application was invoked through a script that invoked the primary JAR and created a classpath that listed the support JARs.
As other posters have noted, you have some options to create a super-JAR if that's what you want.
You can use Maven + assembly plugin (http://maven.apache.org/plugins/maven-assembly-plugin/)
BTW, probably that's not the easiest way, if you did not work with maven.
What are the best practices (and enabling tools) to deploy Java standalone applications along with any required jar dependencies, config files, and launch scripts?
Are there any Maven plugins that easies publishing binary releases, so that users don't need to use maven for example?
Are there any Maven plugins that easies publishing binary releases, so that users don't need to use maven for example?
Use the Maven Assembly Plugin to create a binary distribution as zip/tar.gz/tar.bz2 of your project. This plugin is extremely flexible - at the price of some complexity - and you can do almost anything you want. Then deploy (in the maven sense) the produced artifact, upload it somewhere, etc.
As for dependency, I just use maven dependency copy plugin and copy all dependencies into a ./lib folder, and supply a launch script that uses the class path wildcard (that way you can change your dependencies as much as you want and don't have to change the launch script). As for configuration files, I put it in a ./config folder and again include it in my app's classpath in the launch script (The former admittedly only works for > java 1.6).
So in the end almost all my app has the following structure:
mystuff.jar launch.sh
./lib
./config
Then I'll just zip up the whole thing and give it to my users. The whole process is probably easy to automate using maven, but I confess that I do it by hand :p
If you prefer and the licenses permit, you could also just bundle all dependencies into a single jar (with expanded dependencies inside) using the assembly plugin. This tends to make the jar bulky and giving the users an updated app. more difficult. Also I had issues with it several time because of class files getting overwritten or something so I personally stick to the ./lib folder.
There's launch4j, which, if you can get it to work, will bundle up a Java app into an executable for your platform.
If your deployment target supports RPM files, I strongly suggest you investigate the rpm-maven-plugin. It allows you to easily map your project artifacts , including dependencies, to a RPM package.
I've been using it with great success to medium-scale application deployment.
You can use Oracle's ant or maven scripts:
http://docs.oracle.com/javafx/2/deployment/jfxpub-deployment.htm
The above will not only compile your code and create jar files, but it will also create binary executable (windows exe file or Mac app file). It can also create native installers. In addition it lets you include JVM with your distribution so the end use doesn't need to install Java.
Take a look at the Appassembler Maven Plugin. You may also want to combine it with the Assembly Maven Plugin.
Use the appassembler plugin to generate a set of "programs" by specifying executable names and main classes. You can also have it prepend and create an etc directory in which you can add configuration files.
If generating the directory with the start-up scripts and directory of binary files isn't enough, you can use the assembly plugin to copy over additional files (say your configuration files) into the appropriate directory and/or package your application into an archive.