This week's book giveaway is in the Mac OS forum.
We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line!
See this thread for details.
The moose likes IDEs, Version Control and other tools and the fly likes Sharing the Eclipse .classpath File Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Engineering » IDEs, Version Control and other tools
Bookmark "Sharing the Eclipse .classpath File" Watch "Sharing the Eclipse .classpath File" New topic
Author

Sharing the Eclipse .classpath File

Wally Hartshorn
Ranch Hand

Joined: Jan 30, 2003
Posts: 77
I poked around through the forums, but couldn't find the answer to my problem.

We are using Eclipse to develop our first real Java webapp. We're using Subversion for version control (with the Subclipse plugin). We have 4 developers working on the project.

Suppose Adam decides to add the Jakarta Commons Net JAR file to the build path. When Becky, Carl, and Doris next update their Eclipse project from Subversion, they get an updated copy of the .classpath file. Unfortunately, Becky, Carl, and Doris each have the Jakara Commons Net JAR file in a different location. Adam has it at "C:\Jars\jakarta-commons-net.jar", while Becky has it at "C:\Java\Jars\jakarta-commons-net.jar", etc.

Is there any solution to this problem? The only one I know of (short of requiring everyone to have their JAR files in the same place) is to exclude the .classpath file from the Subversion repository and instead email everyone to say "add the Jakarta Commons Net JAR file to your build path". Seems a bit icky.

Is there a better way?


Wally Hartshorn
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18570
    
    8

I have an Eclipse project called "Jars" where I put all the jars that are part of the applications. It gets saved in the repository just like all the other projects. Then the Eclipse classpath refers to the jars in the "Jars" project and that's the same for everybody. And as a bonus, you have version control on the external jars you are using.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
As Paul says. Or you could just have a lib folder in your project for the required jar files.

I would also put the jar files into SVN. That way, if someone updates a jar file, all other developers automatically get the update, too. Also a new developer just needs to check out the project(s) and already has a compilable workspace, without having to install additional jar files manually.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Rajagopal Manohar
Ranch Hand

Joined: Nov 26, 2004
Posts: 183
Originally posted by Wally Hartshorn:
I poked around through the forums, but couldn't find the answer to my problem.
Suppose Adam decides to add the Jakarta Commons Net JAR file to the build path. When Becky, Carl, and Doris next update their Eclipse project from Subversion, they get an updated copy of the .classpath file. Unfortunately, Becky, Carl, and Doris each have the Jakara Commons Net JAR file in a different location. Adam has it at "C:\Jars\jakarta-commons-net.jar", while Becky has it at "C:\Java\Jars\jakarta-commons-net.jar", etc.


In WSAD there is an option of setting global classpath variables. i.e. Adam will have variable "CommonJARs" and value "C:\Jars\" while Beckys value for the same variable would be "C:\Java\Jars\".

Am not sure if it is a part of Eclipse or WSAD extension but check Windows->Preferences->Java->Classpath variables. Hopefully its there

-Raj
Wally Hartshorn
Ranch Hand

Joined: Jan 30, 2003
Posts: 77
Ah! Okay, thanks for the info. I checked, and Eclipse does have the "Classpath Variables" preferences setting, so that's one option. I also like the idea of creating a project that contains all of the JAR files and checking that into Subversion, since that would avoid the need to tell everyone to download and install things. I'll experiment with both methods a bit.

Thanks!
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16093
    
  21

Classpath variables are my friend. Aside from project sharing, they are good for flipping between versions of jars, too. I've used this to very good effect with TOMCAT_HOME as I tried out builds for new Tomcat releases. Also for JDO and XDoclet library bases.

I'd go so far as to say that ANY libraries outside the project should be symbolically located. It makes life a lot safer.


Customer surveys are for companies who didn't pay proper attention to begin with.
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30580
    
154

Wally,
Classpath variables are my friend too. They are useful for true environment things or workspace dependent things.

That said, the commons jar really should be under version control. What if there is a later version released that the code depends on? You would still have to inform all the developers to pull it in. Also, when you version the code, you wouldn't have a record of what jar went with it.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Wally Hartshorn
Ranch Hand

Joined: Jan 30, 2003
Posts: 77
Originally posted by Jeanne Boyarsky:
Wally,
That said, the commons jar really should be under version control. What if there is a later version released that the code depends on? You would still have to inform all the developers to pull it in. Also, when you version the code, you wouldn't have a record of what jar went with it.


Are you saying that each Eclipse project should have its own copy of the 3rd-party JAR files that it is using? I suppose that would be the safe way to do it, particularly given the fact that we're copying these JAR files into the WAR file anyway, rather than using a server-wide copy.
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30580
    
154

Originally posted by Wally Hartshorn:


Are you saying that each Eclipse project should have its own copy of the 3rd-party JAR files that it is using? I suppose that would be the safe way to do it, particularly given the fact that we're copying these JAR files into the WAR file anyway, rather than using a server-wide copy.

It depends on your set up. If your projects turn into individual jar files, each should have a separate copy of the 3rd party jar. In this case, they are independent and you shouldn't have to upgrade at the same time.

If the projects combine to form another artiface (like an ear file), you can store them in one place for the entire set of projects. For example, you could put them in the EAR file, in one of the projects or in a separate project that gets versioned together with the other projects.
 
GeeCON Prague 2014
 
subject: Sharing the Eclipse .classpath File