I have a project that uses a lot of external libraries (mostly .jar files). I am using Eclipse Helios Service Release 2.
When something doesn't work, the problem is usually caused by missing jars or some problem with classpath. What I have to do, is to check that all necessary jars are correctly included in my classpath.
The problem is that I have several libraries imported + external jars (in case of libraries, the classpath only points to the directory with the jars) and Eclipse provides no easy way to search for included jars. If there was any kind of function that would work like this: "search for xyz.jar" and find if the jar with given name is already included somewhere, instead of manually controlling this, it would be a great help.
It would also help if Eclipse provided a function to sort all the jars and libraries by name instead of displaying them in the same order they are specified in path (I mean only in the project manager, of course).
So my question: is there an easy way to check these things or do I have to do that manually? I have cca 30 jars to include and cca 300 already there and this is a real pain...
You could use a build environment, such as Maven, to manage your dependencies for you. Then Eclipse does zero thinking on its own and your life becomes far more pleasant (particularly when the time comes to package your code for release).
I couldn't imagine managing 300+ dependencies any other way.
Related
After using eclipse i decided to ask this what bugs me the most. When exporting a project to working .jar you have 3 options. Because using extract or package required libraries into jars gives my program a lot of space to have than 3 options, copy required libraries to directory. Now my project has only about 70 kb than 15 mb before. Actually i didn't recognize that not possessing folder with my library classes cause some issues. Why?
I heard from a friend of mine that some thing were not working for him and i send him only jar, than lib.
Is there a difference between exporting types and machines( i poses jdk my friend not only jre)?
Is there a way to check for required essentials libraries or class that are required, check on system and order to download them? Or just download the external lib folder. The most i am interested in detecting missing classes or libraries.
You would have to learn some things but you may want to try using Maven projects. Maven is a Java building tool. One of Maven's most important features is transitive dependencies.
I'm a new configuration manager at my company and I am starting a project to clean up much of our build process.
We have oodles of jars we have put away in one Subversion project. Some people copy these jars to their projects. Others put an SVN:External on their project to this directory. Others have a convoluted way of copying in these jars. These are the only jars that we're suppose to use.
I'm moving over to Ivy and maybe to Maven. I've setup a Maven repository, and have identified these jar's GroupId, ArtifactId, and Version and have documented how to access the ones you need via Ivy and Maven configurations.
I want to go through all the projects' source files, find all the import statements, and compare those imports against all the classes these jars contain.
I want to find all the jars that a given set of sources call directly. For example, if a jar contains:
import org.apache.commons.beanutils.*
I know it needs commons-beanutils.jar (version 1.6). I also know that it needs commons-logging.jar, but I'll let Maven and Ivy handle that issue. I just want to tell the developer when they create their pom.xml or ivy.xml, they'll need to include common-beanutils#common-beansutil#1.6 in their pom.xml or ivy.xml file.
I know this won't be a complete list. I know there will be jars needed for runtime, but not compile. I also know there are classes that can work with multiple jars. I also now developers could do this:
import org.apache.commons.*;
which would match with dozens of jars and tell me nothing. (Maybe there's a way to figure out what classes are actually used in the Java source files).
I could write a Python or Perl script that could probably do this, but I was hoping there was something already around that could save me several hours of work. I know about TattleTale by JBoss, but the documentation seem to say it only works with jars and shows dependencies between jars, etc. I'm not really interested in that. I just want to know what jars our sources are calling and let Ivy and Maven handle deeper dependencies.
Any such tools?
Addendum
Just to be more specific. This is an old project. In fact, there are 50 or so projects. We know that a particular project needs 20 jars to run, and tools like TattleTail can go through and show you the whole data analysis.
However, let's look at it from a developer's view point. I have a problem, and I find an open source project that will solve my problem. I read the docs, write my code and import the classes I need. I know the jar for that open source project that contains the classes, and that's pretty much all I know.
What I want to do is get back to the original developer's mindset: I used these classes in this project, and I need these 5 jars. That those 5 jars may need another 15 to run is something that Ivy/Maven will now handle. We know the 20 jars that program needs. I just want the 5 that the developers originally referred to in their code.
This is to help the developers write their pom.xml or ivy.xml. I don't want them putting all 20 jars in that pom.xml or that ivy.xml file -- just the five they need.
This is just a starting point. They might have imported com.foo.bar.bar.foo and that class is in foo-all.jar, foo-client.jar, and bar-talk.com. The developers will have to decide which one of these their project needs.
This is a massive paradigm shift in our programming, but we are losing track of jars and versions, and making sure all of these projects can talk to each other. Using Ivy/Maven will greatly simplify this mess.
Tattletale ended up giving me the first level of dependencies which is what I need to build my ivy.xml or pom.xml file. It misses one or two occasionally, but otherwise it works pretty good.
Alright, so I have a web service that was created using an eclipse dynamic web project. It is currently shared on a CVS repository, but the versioning system used is irrelevant. At the moment, I have literally NEVER been able to pull this project out as is and get it working. It leads to countless errors that cannot be fixed. Every time I need to work on this webservice in a new machine I have to create an entirely new dynamic project, copy over the source files, add all the necessary libraries and make the deployment assembly work correctly again. After finally making it run I share the project as the same one, stop after a second, and then synchronize again (in a way tricking eclipse into thinking this was the shared project all along).
I feel like others must have run into this problem and found a way around it. So if you have a web service or any dynamic web project, what files do you share, and how do you successfully pull it from the repository and get it to run on another machine besides what I currently do now?
Your help is much appreciated,
-Asaf
Edit: After reading some of the responses I feel that this question is actually more specific to those who use WTP to create/test their web services. Just wanted to add the clarification.
Edit2: Let me also clarify that the other 20 or so projects not using WTP are shared just fine. I am able to pull and run them with no problem. Only web service projects are an issue.
In general, you want to check in everything that's not "derived" (generated or compiled - that's usually the contents of the bin directory or other place where your code is compiled/built into). For Eclipse Java projects, you want to include the .project, .classpath, .settings, and any other similar files that Web Tools might create for Dynamic Web projects. The Eclipse CVS client will ignore files marked as Derived so you shouldn't have to worry to much about it.
Without more detail about what kind of problems you've run into, it's not possible to guess what was causing them. My only guess is that perhaps you had different versions of Eclipse and/or the WTP (Web Tools Platform) plugins installed on the different machine. That's just a wild guess, but could explain some incompatibility when you check out the project from CVS.
Bottom line, checking in those .* files is the long recommended approach from Eclipse gurus. Maven can kind of change things, but you didn't mention it so I'm assuming you aren't using it.
I am primarily sharing my experience, may be you can find some help.
Conceptually speaking, the files which the IDE can generate itself while creating new project should not be pushed. I.e the IDE specific files should not be pushed. And everything which the IDE cannot generate on its own must be pushed.
Forexample in case of eclipse, following files should not be pushed:
.settings
build
.classpath
.project
For setting the project on new machine, first pull the files from server, and then create a project from IDE using pulled files.
EDIT: If your project has external jars/libraries, then you will have to add to the classpath manually. You could also push .classpath but that might give errors while creating a new project.
I think it's easiest to use a build system and let the IDE generate the project from your build system.
Eclipse, Netbeans, and Intellij are all pretty good at building projects from maven or ant build files. With this solution you have a simple build that is easy to setup in CI (Hudson, Bamboo, whatever) and you don't have any IDE specific files checked in. If my workspace is totally different than yours, with different versions, plugins, whatever, I'm not stuck with your project file and you're not stuck with mine. My IDE creates the project appropriate for my environment and your IDE does the same for yours.
Since you mentioned having to manually add libraries, I assume you are not using any build manager (like, maven or ant) besides ecplise.
For ecplise to handle the project properly you need the source files (*.java) in their respective directories, any resources bundled with the web service (e.g. services.xml), the ".project", ".classpath", ".settings", etc. files for eclipse. This should be enough for eclipse to generate anything else necessary to build the project.
Any files/directories that are generated by eclipse during the build process (e.g. target & bin directory, *.class, *.war) should not be checked in -- they will be generated when needed during the build.
I am thinking that, since you are adding the necessary 3rd-party jars manually, these libraries might reside in a different path between computers (e.g. if the path contains the username, it will not be transferable to another computer for a different user). To fix that you can set up the classpath using an eclipse classpath variable. In Preferences->Java->Build Path->Classpath Variables set up a varable linked to the "root" folder where the 3rd party jars a stored. Then add the libraries to the project using this new variable, not their full path. To make it work on someone else's computer, you would only need to set this classpath variable to have the build path point to the correct libraries.
It might be beneficial if you migrated your project from eclipse only to a build manager (e.g. maven) that takes care of many of these issues for you. Eclipse can build a project from the configuration of the build manager, making it easier to manage the project.
I was recently given some code that was worked on by someone other than myself, and after lots of work involving hunting down external dependencies, and editing the build.xml file to get ANT to build things in a sane way, I'd like to now get the code into a subversion repository.
The team I'm working on is rather small, but the members on the team change often. So I want people to be able to start working on this code as quickly as possible. A simple checkout from the repository, and opening the project in Netbeans to have everything building and executing properly would be ideal.
How do I achieve this when there are external dependencies that are not going to be on other team members machines?
Should I place the libraries my project uses in the VCS?
How do I instruct subversion to not track generated files such as class files and jar files?
Should binary resources that are unlikely to change such as images and sounds be placed in the VCS? If not what would be the best way to distribute them?
Thank you.
1) yes. Anything needed to build and deploy the application and isn't generated by the build process goes into version control (yah, I know the maven fanz don't like that).
2) make sure everything that's generated goes into distinct directories that you exclude from version control.
3) see 1). Same thing. Same with project documentation, release notes, etc. etc.
The biggest problem of course are directory names which will be set in your IDEs configuration files and differ between development machines.
Not just the location of the project directories, but the IDE itself, JDKs and other tools, appservers, can all be different between machines. It's a constant problem.
I usually use maven cause you can have a repository for jars and dependencies this makes life easier, but since you have already refactor your code to use ANT maybe this is not what you want, to use subversion with netbeans then you might want to add another folder for jars like libs or something and then another for the binaries like audio etc. Also check for the svn plugin for netbeans it will add the ignore to the dir and just update java files.
To add files to ignore you can use
svn propset svn:ignore -F .
or you can look for the config file in your subversion home and add something like this
global-ignores=*.classs
Hope this helps
I'm beginning to play with Clojure a bit and my Java experience is pretty limited. I'm coming from the dynamic world of Ruby and OO, so the functional side of things is very interesting!
Anyway, as I discover libraries and various tools for use (and the tutorial files for the Pragmatic Clojure Book), everything typically calls for placing files in the CLASSPATH in order for Clojure to see the library for use.
Is there such thing as good CLASSPATH practice? Would I ever want to only have a CLASSPATH with just the external libraries of files I need or can I go ahead toss any library or file I would ever need in a directory and simply define it as my CLASSPATH and only require what's needed?
If it helps, I'm an OSX and Emacs user (Using slime and swank-clojure).
I recommend using leiningen and lein-swank to manage this. You can start a REPL in the directory and connect to it from Emacs.
Personally, I'm using a variant of a clojure-project elisp function by Phil Hagelberg, see source in this post to the Clojure group. It sets up the classpath appropriately for the project you'll be working on, then launches SLIME. (EDIT: You'll need to change the value which gets assigned to swank-clojure-jar-path to point to clojure.jar. I'm using (expand-file-name "~/.clojure/clojure.jar") as the default.)
To answer the question about having everything on the classpath all the time vs only throwing in what's needed: to the best of my knowledge, nothing will actually break if you take the first approach (I know I do that for experimental purposes), but apparently things might break with the first approach (see cjstehno's comment below) and in a proper project I find the second to be cleaner. At some point it'll be necessary to determine what libs are being used (and which versions of them), if only to tell leiningen (or maven) about it -- why not keep tabs on it as you go.
We are using Clojure and use a number of infrastructure tools, especially Eclipse (IDE) (http://en.wikipedia.org/wiki/Eclipse_%28software%29) and maven (http://en.wikipedia.org/wiki/Apache_Maven). maven manages libraries and jar dependencies so if you have a number of these and they are likely to grow start using maven.
In answer to your original question you can just put your jars in one directory and you can access them by name every time you run. But you will benefit from the tools...
If you are just exploring then Eclipse will probably manage your jar files fairly painlessly. You can add these to the project as required through the Build Path -> Configure Build Path option.
As your work progresses you will possibly wish to split it into Projects which Eclipse supports so you can add your (or other projects) to your Build Path.
If you use external Clojure libraries look to see if they have been packaged as maven projects (they will have a pom.xml file). The POM will give a list of dependencies.
#
The usual CLASSPATH practice for Java is to put only the jar files needed for a project into this projects class path, which means to have potentially different class paths for diffent projects. This is usually managed by the IDE as part of it's project properties.
Since you are using Emacs and thus probably don't have or use something like projects it might be more convinient for you to set up and use a single global class path for all your clojure related stuff or maybe even simply put all the needed jar files into the java2se/jre/lib/ext directory of your java installation.
The two main problems that could arise from having unneded jar files in your class path are: 1. it has a minor negative impact on the start up time of the JVM and 2. it becomes more difficult to make sure that you are not having classes with different versions in the same class path (i.e. different classes with the same package and name in different jar files).
Since Java SE 1.6 (or JDK 1.6) you can include class path entries by wildcard. If your class files live in .\bin, and your library jar files live in .\lib, then on Windows you could define your class path like this:
set CLASSPATH=bin;lib\*;
This will let you add jar files into the .\lib directory and they will automatically be added to the class path for new instances of the JRE.
See this link for details: Setting the class path
Prior to JDK 1.6 you had to add each jar file onto the ClassPath individually.
I just discovered this bit which I need to give a shot:
(setq swank-clojure-extra-classpaths (list "/class/path/1" "/class/path/2" "/class/path/3" "etc"))
clojure-contrib/launchers/bash/clj-env-dir has an interesting property that you can point it at a directory and it will basically include anything in there. In the past I've had a ~/classpath directory which I would dump any jars into and link any commonly used directories and it worked great. Very simple way to dump and use. Now I tend to use Maven clojure-maven-plugin and that works well also though can be a bit tedious when you just want to muck around with some ideas.