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... :-)
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
I am taking over a web project from my school. I am trying to deploy the project in eclipse. The project uses a group of libraries (Namely javax.mail.* , com.sun.mail.*, org.joda.* and org.apache.*). The project can not compile because it is unable to locate these. I have them in the src folder and then added the three top level folders/packages to the build path. The import statements work. But getting the joda.time.CLASSXYZ does not work (Then I instantiate the class CLASSXYZ). (The error is "The type org.joda.time.base.BaseDateTime cannot be resolved. It is indirectly referenced from required .class files" the import was joda.time.* so the class should have been imported)
I've looked at the other threads and most of them just explain how to add folders to the build path. I have Apache tomcat set up with eclipse. It works with other projects that I have deployed.
This problem has gotten pretty frustrating as its preventing me from starting the project. Any help you be much appreciated.
Cheers
Unless you use maven you need to download additional libraries:
javax.mail: http://www.oracle.com/technetwork/java/javamail/index.html (also included in Java EE)
org.apache http://commons.apache.org/
org.joda http://joda-time.sourceforge.net/
I suggest to place them in a folder 'lib' and add the jar-files to your build class path. (context menu on your project).
The other threads you mentioned are pointing you in the right direction, and provide a good practice to get in to (especially once you start having more than one project running in your eclipse ide).
So right click project - Build Path - Configure Build Path... , then in the Libraries tab, click Add External JARs and add in the jar for org.joda from the link in the other answer here. This way you can have all your external jar libraries in one spot and reuse them across multiple projects. There's also about a dozen different ways to do the same thing in eclipse, but this is the most direct I think. I'm on version Helios (your's might be slightly different). I try not to use source files of external code libraries unless I want to play around, debugging their code - not a bad thing to do - but I never have the time to spare for that.
Also I'd double check that the other libraries you mentioned aren't being automatically linked in or included as part of the JRE system library. Especially if you are setup in a Dynamic Web Project, it would surprise me if org.apache wasn't already there... but I could easily be wrong there, have been many times before & eclipse was usually involved ;-)
A team working on a project will tend to need a common configuration of Eclipse. This includes general configuration and project specific configuration. For example, generally, everyone might wish to share indentation, installation of certain plugins (say m2eclipse, testng, egit, Spring support). Further, for a project, you might want specific plug-in configurations (e.g., for m2eclipse, setting up a custom Maven settings file, configuring extra Maven targets for eclipse build events), or a custom Eclipse target platform, or even just to set-up certain custom launchers.
Currently, my team executes a series of manual steps to try and get everything configured correctly. This is tedious, error-prone and difficult for new developers to follow. Instructions also tend to get out-dated.
To what extent can this sort of configuration be automated? How should it be done?
The simplest thing available without modifications is to have a common preferences file (Export->General->Preferences), which everybody can then load. Works the best with the same Java installations present.
It is possible to drop in plugins these days but I have not worked with it. Also it might be beneficial to create a local repository with a default package depending on all the plugins you want. Then you can just install that and it will pull in the references. A local cache might be very beneficial as some repositories are quite slow.
There are several solutions for sharing Eclipse Installation/Configuration and settings. For example, Pulse (has a free version). If you browse previous questions in StackOverflow, you will find many discussions regarding these issues.
I would suggest against copying the configuration and workspace folders. From my experience, it won't always work. Plus, this technique only works once. It doesn't sync later.
Update: I just recalled that there's another useful plugin to checkout: Google Workspace Mechanic.
configure the eclipse at one workstation and then make a zip file or rar file for the same and pass it to others.. that will help and otherwise you can also write cmd scripts to copy the plugins and other useful stuff in to the same and these will be less error prone.
Configure it once and then make copies of the configuration folder. If its not enough, copy the entire Eclipse folder.
i agree with "Thorbjørn Ravn Andersen" but the preferences export doesn't export all preferences, especially from additonal plugins. you should additionally als zip a working eclipse and provide it to all teammembers.
I think different parts have different ways to configure/share.
installation
The installation could be installed in the nfs as central deployment, and maintain by administrator. All team members share the installation(eclipse and other plug-ins).
plug-ins preference
The preferences of some feature could be exported a file, then imported in other environments. But it depends on the implementation of the plug-ins. For example, you can export/import key setting and jre setting.
project's specific settings
For example, the java compiler level and code format setting are stored .pref configuration file under the folder of project. You can manage them via source control tool. So those setting can share among team members.
I'm developing various in-house extensions for JIRA, the issue tracker we use. So far I worked with Netbeans and everything worked like a charm. However, now I need to switch to Eclipse and I'm having struggle setting up the environment for this development project.
First a clarification why I'm using the approach I'm describing here: building JIRA (in an IDE) is not easily done and I'm absolutely not interested in wasting my time to figure out how to do it. Besides, I don't need to build it, I just want to develop extensions and be able to use the IDE's auto-completion and help support (API docs). Atlassian (the company that develops JIRA) provides a "development" package, but it's just a sorry excuse rather than a real solution.
What I did with Netbeans was to create a library bundle with all relevant jar-files, the Java source files and the API documentation. This way I could use auto-completion, "jump to" the source and the API docs would pop-up when needed.
It seems Eclipse doesn't offer such a functionality, at least I couldn't figure out how to add the sources and the API docs to a "User Library" (which I'd then add as a dependency to my project just as with Netbeans).
My next approach was to create a separate project that holds all the stuff and mark that project as a dependency of my project. This works, but it leaves me with another issue: now I get 37k errors reported (all within the "dependency project"). As said, correctly setting up building for this dependency is a major struggle and not my original goal, therefore I'd happily ignore these errors. Automatic building is turned off and changing the "Errors/Warnings" settings under "Java Compiler" for the project didn't change a thing, so I'm kind of lost now.
Okay, let me try to phrase this as questions:
Maybe I just didn't find it: Is there a way to create a dependency bundle (call it whatever you want) in Eclipse that -- besides just carrying jar-files -- gives me the ability to use the API docs and "jump to" the declaration in the sources?
If not, what's the common practice to do in such a situation?
If the "dependency project" solution is the way to go, how can I completely disable compiler errors for that project?
Check this for illustration with images
Add the source code for jar
Add the Javadoc for a jar
Or just right-click on the jar file in the Package Explorer view. Select "Properties" then set the according paths in the "Java Source Attachment" and the "Javadoc Location" field.
When you create user libs via window->preferences->java-build path->user libraries you can specify which jar you need, sources (in archive or folder) && javadoc (from internet, or local, or from archive). Then you can use this lib in your project via context menu on project->Build path->add library->user library-> choose your lib.
Here you acn pick up more info Eclipse help
Background:
Here at the office my group uses a common linux environment where we do our code development. Our code is kept in CVS. The latest releases of our various libraries are kept in a specific directory (ie /data/group_projects/lib). Our Makefiles/Ant builds all specify what libraries are needed. We use autoconf to create the makefile after checkout for most C/C++ projects. We've just got Eclipse (3.4) installed and are planning to incorporate it into our workflow.
Problem:
So, when I check out a project from CVS through the Eclipse interface and then I have to set up all of the library paths (and include paths for C/C++). For some of our projects, this could be a lot of work. Is there a good way to save these paths along with the code when I check it back into CVS?
Ideally, when the next person checks out the code in Eclipse, the paths (and anything else they might need) will automatically be set up and they will be able to compile straight away.
Efforts:
I know that the include/lib path info is kept in a .cproject or a .classpath file (C/C++ or Java respectively). I thought I could export this info through Export -> Preferences. The resulting epf file doesn't have any path data in it unfortunately. I tried directly adding the .cproject file to one of my projects (so I could then put it into CVS) but Eclipse really doesn't seem to want me to do that.
I am quite new to Eclipse (esp using CDT), but maybe the necessary path info can be pulled out of build.xml/Makefile automatically by Eclipse? There seems to be a bit of a disconnect in Eclipse between the buildfile/makefile and the jar/include files that the IDE uses for checking your code as you type it. Maybe I am missing something?? I'm planning to put some serious time into researching Eclipse over the next few days so hopefully the inner workings will become much more clear to me.
I've asked the guys here at the office but no one is much of an Eclipse guru. My searches haven't turned up much . . I did see a suggestion to add all external jars to Java -> Build Path -> User Libraries under Eclipse Preferences. For us, each user would have to set this up once but afterward all of our java libraries would be available to whatever project we decided to check out. Unfortunately, it doesn't seem as though I can do the same thing for CDT.
What would you suggest? Am I missing a setting or function of Eclipse? Or am I going about this the wrong way? Please let me know what you think. I'd really appreciate it. Thanks!
You simply need to share the .project, .cproject and .classpath files through CVS. You can do this from the cvs command line, or select then 'Team/add file to version control'.
You don't need to add these files to the project explicitly: they are inherently part of it.
Obviously, if you do this, you need to make sure they are location-independent.
See:
eclipse wiki
Safari books
I've done this in Eclipse, and it's not too hard. You have to check in the .project and .classpath files. There are one or two places where Eclipse doesn't correctly automatically check out the files when you want to edit them, so when you get a read-only error you have to go manually do it, but for the most part it works.
The paths need to be all relative.
If relative paths is a problem, you can also take advantage of workspace variables in Eclipse. The developer sets their workspace variables appropriately on their machine (e.g., OPENGL_INCLUDE_PATH ), and then in the builder you can set the environment to pass that path along.