Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Sharing the Eclipse .classpath File

 
Wally Hartshorn
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Paul Clapham
Sheriff
Pie
Posts: 20769
30
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Rajagopal Manohar
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 77
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 18020
47
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34095
337
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Wally Hartshorn
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 34095
337
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic