I need to add an external library named ControlFX in my project. Here is the official link to download it: https://github.com/controlsfx/controlsfx
The issue is that this file is .zip type. So, I'm really confused about how can I add it as a library to my project (it doesn't include.jar files inside).
Any idea, please?
Check out How to add external library properly in Eclipse? if you want to add it manually, but it's very much not advised if you don't know what you're doing.
If you want to learn the proper way to use external resources look into how to use Maven or Gradle to incorporate libraries into your projects.
Related
So I took a Coursera course that had me work with external libraries. Two .jar files which most of the weekly projects depended upon.
I'm not entirely sure how eclipse compiles and runs the files, and how it links to these external libraries -- what is the proper way of organizing this? Do I put a copy of each .jar file in each project directory?
Is there another, cleaner way that I should be organizing this?
Thanks --
As a beginner programmer it is OK to put it in each project. But consider that this is ongoing work and at some time in future you want to upgrade to a new version of these external libraries. Then you would have to copy it everywhere.
Instead another option is to store them in one place and add it in classpath in each project. Now you have only one copy of it, which is always better.
Now, if and when you do get a new version then the file names might change, so you will still have to change the classpath of each project.
But I advise you to worry about these and other such problems later. For now, focus on programming related problems rather than configuration.
If you want to maintain your libraries professionally in a formal manor then you're better of using a build tool like Gradle of Maven.
I'd suggest you to use Gradle to maintain the project since it has a whole lot of useful build tools available to you to use. Eclipse has a Gradle plugin available which allows you to use Gradle projects with it. See link below.
To give you a idea of how Gradle is used professionally. Android uses it by default to maintain their projects now. So Android java projects uses the Gradle build tool to maintain its library sources, compilation processes and such.
The difference between a Gradle project and a normal java project is that a Gradle project has a list of pre-defined scripts available to you which fetches the libraries, compiles them and prepares them before exporting the final bundle (jar). So really all Gradle does in before hand is fetch the libraries and prepares the specified tools before compilation so you won't need to mess with them your self. It prepares your project directory and remotely maintains your libraries so if they're available from a repository then it'll make sure to prepare them appropriately in before hand and setup your projects directories.
So really the difference you'd physically notice is that instead of using the default Eclipse export button to create your bundle (jar) you'd instead use a button from the side menu which the Gradle plugin adds and also you'd cleanly list the libraries in a structured order in a file that gets added to your project root.
If you want to get a basic understanding of how it works and really want to start to proffesionally or formally structure your project then try to create a very basic android app in Android Studio. see link below
If this isn't what you want at all and don't want to take it to this advanced level yet then adding the library bundles into some kind of lib folder that's located in your project root is properly best practice.
If you wonder why? Well basically different projects might use different versions of the library which may add or remove support to them. So to keep the versions consistent and make sure to have the right version available to you, you have the direct source near the project it self.
Here's some useful link:
http://www.vogella.com/tutorials/EclipseGradle/article.html
http://developer.android.com/sdk/index.html
Sorry if it is a stupid question, but I can't figure out how to do this...
I downloaded commons-net-3.1 from commons.apache.org and I don't know how to have it in my Java System Library or anywhere else I can use it from. I need to use org.apache.commons.io.FileUtils.
This might be overkill for what you're trying to do, but please use a dependency management system instead of managing your dependencies manually. It's a bit more setup now, but you'll reap the rewards later (and anyone else working on your project will thank you).
Take a look at maven, for example.
You need to import/add jar file to your project by browsing to downloaded/extracted binaries folder.
For example in Eclipse, right click on project -> build path -> libraries -> add external jar
I have pretty much no experience with Java so I apologies if I'm not too clear.
I'm trying to create an Android application that uses another package. I only have the source code .java files from the package, which are all part of com.X.Y
I have saved this in a folder called "Database" which I have zipped and added to the build path, so it now appears under "referenced libraries" in Eclipse. However I don't know how to include this, it's not finding import com.X.Y, and I am unsure of what to do next.
I'm a little over my depth in this project, any help would be greatly appreciated
Create a folder structure com/X/Y within your source folder and put your .java file inside of that
Step #1: Move the classes out of "Database" and into the main source tree of your project.
Step #2: There is no step #2.
I strongly recommend that you step away from Android for a while and learn Java separately. There are tons and tons of materials to help you learn Java, including lots of free stuff online. Here is a blog post where I point out a number of topics in Java that Android developers need to learn.
If you want to include those files as an external library I would look at creating a proper jar of the compiled code you want to include instead of just zipping up the source. For you the easiest way would probably be to create a second project in Eclipse, compile it and use the resulting jar.
Once you have the jar, put it in the libs subdir of your Android project. I believe that's enough to get the Android ant target to work...although for Eclipse to be happy I believe you will also need to add it to your Java Build Path.
Or if you are hell bent on just including raw source you may as well just copy/paste the entire package source into your android source directory.
I am attempting to install XOM so I can use it in my Java apps. The only problem is, I don't know where I can place it so NetBeans can find it. It would make sense to put it where the other .classes files are, but I can't seem to find them either.
The README file for XOM says to install it to the Classpath variable, but I don't know what that is.
So, how do I install XOM, and what is "Classpath"?
You can use the NetBeans Library Manager (Tools|Libraries) to create a new library, add the Xom jar file (and all dependencies) to it and use this library in a new Java project.
To do this, use the Properties dialog for the project, navigate to the libraries page, and choose your new Xom library using "Add Library..."
I'm having a difficult time figuring out how to add a .jar/library to a Netbeans project in such a way that I can get it committed to the repository.
The typical way to add a library (per the Netbeans documents I've already gone through) ends up with it just being local to me. Anyone who checks out my project ends up missing my required library.
Inserting it manually and trying to work around Netbeans results in Netbeans hanging while trying to scan the project...
So, how can I tell Netbeans to pick up a jar as a library and include it in my project in such a way that Subversion will be able to handle it?
There are a couple ways to fix this.
A. When you define your Library, use a path to a common location. A location that's identical on everyone's machine--such as the location of a JAR installed with a third-party app into Program Files or /usr/local/ works well or a network drive.
Then, when they check-out the code, the path will still be correct and they do not have to define the Library on their Netbeans workspace.
B. Edit your project.properties file to use a relative path. Open your project.properties file and look for "libs.LIBRARY_NAME.classpath=...". That will be the "default" location used if the Library is not defined.
Change this to use a path relative to your project and store the jar files in your project. For example:
libs.Log4J.classpath=lib/log4j.jar
Keep in mind that the Library definition in your Library Manager will override this value--so make sure you keep them in-sync (i.e. append a version number to the library name!).
C. Use Vincent's suggestion of using a build-system such as Maven. The Maven build-process will take care of downloading dependencies, etc. Netbeans has plugins for several popular build systems.
There is a new feature in NetBeans 6.5 (variable-based paths in projects) which should make this easier.
See http://wiki.netbeans.org/NewAndNoteWorthyNB65#section-NewAndNoteWorthyNB65-VariableBasedPathsInJ2SEJ2EEProjects for details. Note the screenshot includes variable references in the library customizer.
Not really an answer to your question but... generally you should not include these libraries in your subversion repository. There is usually no need to have them managed. What you might want is to set up a central repository similar to what happens with maven. If you use maven, you can create a local repository of libraries on a server accessible by the team. The dependencies on these libraries are entered in the pom.xml file and this is in the subversion repository. Now, as team members check out the code from subversion they all have access to the maven repository.
[I am looking for a reference to this right now. When I find it I'll edit this answer.]
I use NetBeans IDE 6.5.1 and the best solution I've found so far is to include the needed libraries from your local host and then change their paths to relative. After that you have to remove the libraries manually from the NetBeans file explorer, and then copy them from their OS location in your computer manually to the file explorer again. That way NetBeans detects the change and you can commit it to the repository.
Note: I Highly recommend to clean and build the project again after updating.
An easy way to pack up your lib/jars into your project so that subversion "just handles it" so you can grab it out with all the attached libraries ready to compile and go is to include them all under your project directory via the "shared libraries" option by managing the libraries folder.
When creating a new project you can specify "Use Dedicated Folder for Storing Libraries" and then use the suggested relative .\lib path. If you have an existing project, you can edit it's properties, Libraries Category, and Browse for a Libraries Folder. Again a first-time run will suggest .\lib and then offer to copy existing dependencies to that folder. These graphical actions should provide similar results to James Schek's 'B' answer.
Commit the project with the newly added libs in .\lib and you should be able to checkout and build from anywhere and know you'll have the same libs (at the same version) as you had when you last built and committed.
I don't know how long this feature has been in NetBeans. For more details see:
http://netbeans.org/kb/docs/java/project-setup.html#projects-shared-libraries
I ended up just downloading my own set and putting them on my local drive for this project. I setup my Netbeans to look there and warned the other guys what I did... Eventually, we'll have to do something a bit more scalable though... :-)
OK, the working solution that I've now moved to is to extract the class files out of the jars and dump them into the Source Packages area. Then it all gets committed to the repository and also avoids having to deal with handling a separate "lib" directory in the deployment phase.
This solution does everything I'm looking for, yet I feel real dirty about doing it this way. It just seems horribly broken and wrong... :-)