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.
Related
I mean, I want a developer to be able to check out a project and not have to change anything to in order to get it to build and run. One problem I have run up against is that the proper compiler has to be added to the Build Path -- is there a way this can be done? I realize that the actual JDK will still have to be downloaded but could it be clear from looking at Eclipse which JDK is needed?
The build path is usually stored in a file called .classpath under the project directory, consisting of the classpath entries that were added in Eclipse. Among the entries in the file is one which points to the JRE library.
There is no "complete" configuration that can be saved. Every configuration is stored in a separate file. Some are stored in the project directory. Others are stored in the root directory of your workspace. You'd have to pick exactly which configuration you want to save.
One way to save a configuration for the project and its dependencies is to use a project management tool like Maven. It can configure the required JDK to compile the project (it can even enforce this rule), needed dependencies, etc.
If you set up your project to use an Execution Environment as its JRE Library (as opposed to the "Workspace default" option), then check in the .classpath and .project files, then checkout is a simple process. Execution Environment is an abstraction of the actual JRE/JDK that's installed on any machine/workspace; Eclipse uses that to map to a physical JDK in whatever workspace it's working in.
As others have mentioned, using Maven (or, even better, Gradle) to manage the dependencies will help, too - as long as every developer has the m2e (Maven integration for Eclipse) features installed into his Eclipse.
I need to do a Java web project. I'm going to be using Eclipse.
I thought of using Spring MVC. As far as I can tell - it's gonna require me to add some "extra" stuff to a "clean" Java web project. I don't mind that - the thing is - one of the project requirements is - that I'll be able to send the project to someone else - that doesn't have any extra installation and/or configuration - and he will be able to compile the project.
Is that possible with Spring MVC? Does the Spring MVC framework is just a "JAR" like addition to the project - therefore - the project can be shared without a problem?
Thanks.
Short answer: yes, you are right.
To use Spring in your Java web project, you generally need to add two things:
the appropriate Spring configuration file(s) (XML)
the appropriate Spring JAR files (traditionally placed in /WEB-INF/lib, the same as other JARs). By the way, it is NOT a single JAR file, but several JAR files.
That is all there is to it.
Spring has nothing to do with "sharing the project".
To "share" the project with someone else, you put it on the SCM of your choice and your collaborators will be able to get the code and work on it.
Building the project is a different aspect. To correctly compile the project you have to make sure that all the classes and/or jars are visible in the classpath (and runtime if you want to execute the code). Spring is made of a bunch of jars that, depending on which classes of the framework you use, must be in the classpath (eg. putting them in the /WEB-INF/lib directory). You may version them as well, or just version the configuration (I'm thinking about Maven for example, that will take care of resolving the dependencies).
Another piece of the puzzle is making all of this work in your IDE. This is a matter of taste. I prefer not to version ide-specific files (in the case of Eclipse, .settings and .project files/folders). You can do that, making sure you do not use absolute path anywhere, and technically you will be able to import the project without problems from another machine.
Yes.
If the other person has nothing extra installed and configured, namely no build tool, you need to put every needed Spring and other Jar into a folder, typically called "lib" and tell him to add them into his compile process. If he just uses the JDK he will get an enormous command line. It is much better to use a build tool like Maven or Ant+Ivy for building and dependency resolution. But that would be an "extra installation" per your question.
If he has Eclipse installed like you have and you use Eclipse internal for building:
Put the JARs in a lib folder
Configure the build path
Make a local test build
Export the project as zip (File menu > Export)
" The other person needs to import the project into his workspace
The exported project should not have any absolute paths as long as you didn't set some deliberately in the build path.
This works but is not exactly best practice. Installing a build tool like Maven is absolutely worth the time and should be preferred under any circumstances. It will save you a lot of time and nerves.
I am working on a Hadoop project in Eclipse that depends on another one of my projects; I've included the other project in my build path, but when I export the dependent project, it only contains the classes from that same project.
Ordinarily, this would not be a problem, as I could just link the other project with the -cp flag, but Hadoop requires you to pass the jar as an argument, meaning that all of my dependencies must be inside that jar.
Is there a way, in Eclipse, to automatically build and include classes from projects that you depend on?
Thanks.
You coud use Ant to automatically build, test and export. It needs some time learning it, but its worth.
There are possible tasks (fileset, zipgroupfileset, copy) to include files, jars (unzipped) or anything into the final jar. By this way you definitly know whats inside your distribution jar and you don't need an eclipe installation running.
I suggest you take a look at maven as a build tool. You define the dependencies and build steps for each of your projects in files called pom files. The maven plugins for Eclipse (the m2e plugins) can take the configuration in the pom file and setup your Eclipse build paths and project description so that you can access the classes in your other project in Eclipse. Maven can also create a jar for you that has the classes from both projects (a "jar-with-dependencies").
In maven terms, your two projects are called "artifacts" with one having a dependency on the other.
The one downside to maven (and the cause for many negative comments about maven) is an initially steep learning curve that can be frustrating. What you're trying to do, however, is very straightforward and I expect you can find a number of examples showing you exactly what you want to do.
The first step, and that's what my answer is about, is to take a look at maven. It may seem overly complex, but it can scale to handle just about any build configuration you need as your hadoop apps get more and more complex.
You can export a project as a Runnable jar, which can be useful if you want a single jar, with dependencies included.
Select the Project. File > Export. Select the Java section. Select Runnable JAR file.
See related answer:
Eclipse: How to build an executable jar with external jar?
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.
I run into this obstacle when my debugger steps into some classfile
without corresponding source. Finding it is often difficult:
You have to search for the site hosting the respective project,
and find its ``download source'' page (for instance, last time I searched
for the JPA API, and it took me hours to obtain the sources). Or, you might
be required to check it out from revision control.
You need to know the exact version you are using. Otherwise
the debugger might step into comments and empty lines :)
There is no convention for packaging source code—some
projects include it in the jar itself; some provide a separate zip file;
others put it in a src/ subfolder within the zip.
I know Maven has the capability of downloading source from its repository and
including it in the src paths when an IDE config file is generated. But
Maven's repo is so poor in terms of content—few libs actually have
their source uploaded.
Why is it so complicated when it can be made straightforward? We could have
some central repo which relates a classfile (or a hash thereof) to the source
file it was compiled from (or a link to it). Maybe a rather huge repo, but
pretty simply structured. An IDE plugin could query it to fetch what's needed automatically.
Have you, guys, experienced the same?
How do you obtain the sources to attach?
Both m2eclipse and IDEA will download the sources and javadocs for any dependencies. The m2eclipse sources can be downloaded by right-clicking on a dependency (or the whole project if you want all sources) and clicking Maven->Download Sources.
On newer versions of m2eclipse you can also automatically download sources by going to Window->Preferences...->Maven, then selecting the "Download Artifact Sources" option. When you open a type in a dependency jar that there are currently no sources available for, Maven will download the sources in the background and update the source attachment in the background.
Haven't seen a satisfactory solution myself.
I tend to roll my own repo, without Maven (Maven is fine, but it doesn't click with me). I run something similar to the BSD ports system, that is, one big structured tree that contains little Ant build files. These build files either checkout the source of a project, pull its dependencies from somewhere else in the tree and build it (these are for the projects I want to build- i.e., mine) or pull binaries from somewhere else (which might be an external source or my own binaries repository).
The system could easily be extended to pull src jars, but I do that manually now.
it may be complicated but it is worth the initial effort.
i do it the following way:
in my project directory i have three major directories,
src (my own)
lib
suppl (sources / javadocs when no sources exist)
i put in suppl one zip file per library, containing the sources. in intellij this gives me not only debugger superpowers, but also javadocs.
you are right, obtaining the sources is a pain. sometimes the sources come deliveded in the .jar file of the lib, sometimes as a seperate download (my favorite) and sometimes i have to create a seperate cvs/svn dir where i can checkout the sources. i usually need to re-package them the way i like them, even if provided in a zip.
i am sceptical about maven. i just don't like to hand over my decisions about choosing libs to a program.
we do something similar to Andreas. Our lib directory has subdirectories categorizing further. One such sub dir is source or debug which has the source JAR/ZIPs of all the jars that we want to debug. Do it once and you're good. We use an IVY repository for the jars and source jars.
This is all done automatically if you use M2eclipse (http://m2eclipse.sonatype.org).