My Eclipse plugin needs to be executed unfolded as a flat directory (it uses JNI, and the JNI part needs access to some files provided by the plugin). Is it possible to configure the plugin to be automatically unfolded if installed as a jar ?. Or my only option is to ask the user to unzip its contents in the Eclipse dropins folder?
In case there is no way to unfold a plugin jar automatically, is it possible to build an update site configured to install the plugin in the dropins folder and copying it unfolded ?
If you package your plugin(s) as a feature then you can specify this behavior in Feature manifest editor.
The most common way to do this is to use org.osgi.framework.Bundle.getEntry(String) and then org.eclipse.core.runtime.FileLocator.toFileURL(URL). getEntry("/jni_lib/") will return a URL that points to a folder, and FileLocator will expand the requested bundle URL to the local disk if necessary. This works if you use features or not, if the plugins on disk are exported or not, etc.
#vanaprogeja proposed the second most common option, and needs features to work (which is perfectly acceptable)
You can check the unpack option while you are creating Feature project for your plugin project.
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 have a project where I want to add an external JAR file. The desired external JAR file has a nifty Github page with source, but no pre-compiled JAR file.
These are the steps I've completed so far:
1. I have downloaded the source in a zip. (its Twinkle from SwingFx.ch in case you're interested)
2. I have extracted the zip file to my workspace.
3. I have created a new project with the same name as the extracted folder from the zip file. (project loads the source successfully)
4. I select the export option from the File menu and selected the 'JAR file' option and clicked next.
Note: I had to add an external library to the above Twinkle project for it to build successfully (in case that makes a difference to the settings).
On the JAR File Specification page there are multiple check-box options available(see below):
Export generated class file and resources
Export all output folder for checked projects
Export Java source files and resources
Export refactorings for checked projects
Compress the contents of the JAR file
Add directory entries
I am not sure which are supposed to be selected and if it makes a difference in the behaviour of the project I will add the (soon-to-be) exported JAR file to. I tested it by exporting with the default settings. This worked ok.. However, I now do not know if I should have chosen different settings in case of any reasons I am not aware of. I am not sure if there are specific settings I should choose when I intend for the JAR file to, specifically, be added as an external JAR file to another project.
Please enlighten me!
This is a traditional Java library that uses Maven. It should be fairly easy to build using Maven, which should be better and quicker to build this, if you already have Maven and git installed.
Let's consider that you did not download the source file as a zip, but take the github approach, where you'd use git to download the source code.
If you don't have git, download its latest version and install it.
If you don't have Maven, download its latest version and install it.
Once Maven and git are installed, make sure the Maven and git binaries are configured in your environment PATH variable. If not set, you would, on the Windows platform and for Maven binaries, set it this way (using the default installation path):
set PATH=%PATH%;C:\Program Files (x86)\Apache\maven-3.1.1\bin
Create and change directory in a work directory of your choice, that we'll refer to %work_directory% from now on.
Run the following:
cd %work_directory%
git clone https://github.com/spreiter301/Core.git
git clone https://github.com/spreiter301/Twinkle.git
cd Core
mvn clean install
cd ../Twinkle
mvn package
6. Retrieve the twinkle-1.0.0.jar file in the newly created '%work_directory%/Twinkle/target' folder.
In this case, it was necessary to retrieve the Core library because it is a dependency of the Twinkle project. Normally, this is not necessary because dependencies are automatically retrieved from a maven repository. But in that case, that dependency is not available on any Maven repository. Hence we manually retrieved the dependency from github, compiled it and installed it in your local cached repository. Then we could package the Twinkle project into the JAR file.
This should do it. If you want a 5 minutes tutorial on Maven, there is a tutorial for this here. I highly recommend it, you will encounter this often in the Java world. Maven is the standard build tool for Java, just like 'make' is for C, 'rake' for Ruby, 'sbt' for Scala, etc..! Good luck with the rest.
I am currently using eclipse for working with Java. Additionaly I use git to synchronize my project between my laptop and my desktop PC.
The problem is now the following: I added external JARs to the project (Slick-Util, LWJGL).
But the path to each library is another on each device. So everytime I start working on the other device, I have to change the path to the jar files and the javadocs.
The libraries are all stored in my eclipse workspace. So the libraries and the projects are all in the same folder. And this folder is also commited with git.
Is there a way to change the eclipse settings (or do something else) so I do not have to change the path to the libraries and javadocs everytime?
I already googled and searched for it, but I could not find something about it.
Just don't add the libraries' jars to git. There are multiple build tools for java, which manage dependencies for you - you just state the libraries you're going to use, and the build tool downloads it for you at build time.
I would recommend Gradle, but Maven is also a very popular choice.
In gradle, you would create a file build.gradle, and define your dependencies in it:
apply plugin: 'eclipse'
apply plugin: 'java'
repositories {
mavenCentral()
}
dependencies {
compile 'org.lwjgl.lwjgl:lwjgl:2.9.0'
compile 'org.lwjgl.lwjgl:lwjgl_util:2.9.0'
}
Then you would run gradle eclipse from the command line - that would add the libraries you use to the classpath in eclipse. And when you want to compile and package your project you would run gradle build from the command line. You should read about it if you're going to use it, what I describe may not be exactly what you need.
Also, there are instructions for using LWJGL with maven.
add jar files to a lib folder inside your project like this : D:\Workspace\myproject\lib\your-jar-file.jar
then go to your projects build path select libraries tab and click on add jars and NOT add external jars this way your jar files path will be relative to your project
EDIT :
I highly recommend to use a build tool as Kiril Raychev described.
it will look a bit confusing to start with but after a while and after a normal growth in your application that will lead to using different frameworks, controlling and managing dependencies and their conflicts without a build tool will literally kill you.
You can simply use -f flag on add command.
git add -f test.jar
And, then commit and push to your repo.
Up until now i usually use svn so i'm not entirely sure how it works out in git, but have you tried to store the JARs in the lib folder of the project they are used in? (Eclipse displays the lib folder so you can easiely add them to the buildpath with a right click on the library in the package explorer.)
That way the relative location/path of the libraries to the project should stay the same. Furthermore if you plan to pack the project into a JAR later you ship the libraries inside that JAR without having to worry whether the user of that file even has them on his computer.
PS: Looks like i'm a minute too late. Dave basically said the same thing.
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.
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.