Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Subversive » Sharing .classpath in source-code control
Sharing .classpath in source-code control [message #766406] Thu, 15 December 2011 18:16 Go to next message
Russell Bateman is currently offline Russell BatemanFriend
Messages: 3798
Registered: July 2009
Location: Provo, Utah, USA
Senior Member

This question concerns the fact that .classpath gets full filesystem
paths when one is not careful, which makes committing it at least
unhelpful when not annoying for coworkers sharing source code repositories.

Specifically, for years I've noticed that associating Javadoc and/or
source code with a JAR via Build Path -> Libraries will result in a full
path in .classpath.

Needless to say, a full path on my development host isn't helpful for
any colleague who does svn update and gets his or her copy of .classpath
updated with the last colleague's commit.

I'd like to find out what folk out there are doing about this.

It's useful to commit .classpath because I might add a bunch of JARs and
take away a bunch of others and don't want colleagues to have to guess
what happened--which they do not if I'm committing the JARs themselves
to a project on relative paths in .classpath.

I've worked in both environments where the committed code doesn't
contain .classpath, .project, etc. and one creates a project from source
code AND where a team commits .classpath and the Eclipse project comes
ready to go (no need to muck with Build Path).

I'd greatly appreciate any discussion on best practice or opinion. I
just need to hear other people's ideas.

Many thanks,

Russ Bateman
Re: Sharing .classpath in source-code control [message #766453 is a reply to message #766406] Thu, 15 December 2011 20:24 Go to previous messageGo to next message
Russell Bateman is currently offline Russell BatemanFriend
Messages: 3798
Registered: July 2009
Location: Provo, Utah, USA
Senior Member

On 15-Dec-11 11:16, Russell Bateman wrote:
> This question concerns the fact that .classpath gets full filesystem
> paths when one is not careful, which makes committing it at least
> unhelpful when not annoying for coworkers sharing source code repositories.
>
> Specifically, for years I've noticed that associating Javadoc and/or
> source code with a JAR via Build Path -> Libraries will result in a full
> path in .classpath.
>
> Needless to say, a full path on my development host isn't helpful for
> any colleague who does svn update and gets his or her copy of .classpath
> updated with the last colleague's commit.
>
> I'd like to find out what folk out there are doing about this.
>
> It's useful to commit .classpath because I might add a bunch of JARs and
> take away a bunch of others and don't want colleagues to have to guess
> what happened--which they do not if I'm committing the JARs themselves
> to a project on relative paths in .classpath.
>
> I've worked in both environments where the committed code doesn't
> contain .classpath, .project, etc. and one creates a project from source
> code AND where a team commits .classpath and the Eclipse project comes
> ready to go (no need to muck with Build Path).
>
> I'd greatly appreciate any discussion on best practice or opinion. I
> just need to hear other people's ideas.
>
> Many thanks,
>
> Russ Bateman

Of course, I can use Maven, have the pom.xml bring down Javadoc and/or
source and then just wire stuff up when I encounter Not found/Attach
Source, etc. in which case I should NOT commit .classpath, etc. I'm just
trying to find out what's best.
Re: Sharing .classpath in source-code control [message #768280 is a reply to message #766453] Mon, 19 December 2011 20:52 Go to previous messageGo to next message
Thom DeCarlo is currently offline Thom DeCarloFriend
Messages: 8
Registered: December 2011
Junior Member
I have a similar problem trying to figure out whether to commit the .project files or to set my SVN preferences to ignore them. So far, we are ignoring them and all of the developers on the team is on his own when he joins the project and sets up his environment. It makes the install location flexible, but requires much more information during set-up; information that the new person won't have.
Re: Sharing .classpath in source-code control [message #768300 is a reply to message #766406] Mon, 19 December 2011 21:54 Go to previous messageGo to next message
Russell Bateman is currently offline Russell BatemanFriend
Messages: 3798
Registered: July 2009
Location: Provo, Utah, USA
Senior Member

On 15-Dec-11 11:16, Russell Bateman wrote:
> This question concerns the fact that .classpath gets full filesystem
> paths when one is not careful, which makes committing it at least
> unhelpful when not annoying for coworkers sharing source code repositories.
>
> Specifically, for years I've noticed that associating Javadoc and/or
> source code with a JAR via Build Path -> Libraries will result in a full
> path in .classpath.
>
> Needless to say, a full path on my development host isn't helpful for
> any colleague who does svn update and gets his or her copy of .classpath
> updated with the last colleague's commit.
>
> I'd like to find out what folk out there are doing about this.
>
> It's useful to commit .classpath because I might add a bunch of JARs and
> take away a bunch of others and don't want colleagues to have to guess
> what happened--which they do not if I'm committing the JARs themselves
> to a project on relative paths in .classpath.
>
> I've worked in both environments where the committed code doesn't
> contain .classpath, .project, etc. and one creates a project from source
> code AND where a team commits .classpath and the Eclipse project comes
> ready to go (no need to muck with Build Path).
>
> I'd greatly appreciate any discussion on best practice or opinion. I
> just need to hear other people's ideas.
>
> Many thanks,
>
> Russ Bateman

Been playing around with this every time I get a chance.

Another option (that is, if not using Maven) is to ask Eclipse to
generate build.xml. Do this via right-clicking on project, choosing
Export... -> General -> Ant Buildfiles, etc. (Be sure to click Cancel in
response to the question, "Overwrite existing buildfiles..." or it will
overwrite any build.xml you've already got.)

Commit the code (minus .classpath, .project, etc.) including the newly
generated build.xml. You can tweak it if you wanted a "real" build.xml
(but then plan on never generating it again--a disadvantage if you want
Eclipse to maintain for you the bits that get around the .classpath
problem).

Once that's done, others coming on board can check out the project (into
a suitable Eclipse workspace), then from Eclipse do File -> New ->
Project... -> Java Project from Existing Ant Buildfile.

That will create and open the project.

However, this isn't enough. You must use Build Path to remove the JRE
Library, which is obsolete as set up (don't know why), then click Add
Library and add the JRE System Library associated with your workspace.
Similar for JUnit if you're using it.

At that point, the project is usable.

I do not yet know how to do this for Dynamic Web Projects. When you get
Eclipse to generate build.xml for you, it does everything you need, but
the resulting project, when re-created as note just above, will not be a
DWP. I think the reason is probably because of missing .settings?

Still open to comments on this.
Re: Sharing .classpath in source-code control [message #769340 is a reply to message #766406] Wed, 21 December 2011 20:50 Go to previous messageGo to next message
David M. Karr is currently offline David M. KarrFriend
Messages: 800
Registered: July 2009
Senior Member
The key is to avoid having absolute paths in your .classpath file. Either specify jars relative to the current project, or relative to other specific projects. If there are jars that are really not relative to a workspace project, then define a user variable to point to that external location and specify that developers on the project need to define that user variable.

[Updated on: Wed, 21 December 2011 20:50]

Report message to a moderator

Re: Sharing .classpath in source-code control [message #769377 is a reply to message #769340] Wed, 21 December 2011 23:10 Go to previous messageGo to next message
Russell Bateman is currently offline Russell BatemanFriend
Messages: 3798
Registered: July 2009
Location: Provo, Utah, USA
Senior Member

On 21-Dec-11 13:50, David M. Karr wrote:
> The key is to avoid having absolute paths in your .classpath file.
> Either specify jars relative to the current project, or relative to
> other specific projects. If there are jars that are really not relative
> to a workspace project, then define a user variable to point to that
> external location and specify that developers on the project need to
> define that user variable.

It is easily possible to specify JARs on relative paths. It appears
utterly impossible to associate source code or Javadoc without Eclipse
resorting to inserting full paths in .classpath.

My final thoughts on this are spread across three sections of notes
beginning here:

http://www.javahotchocolate.com/notes/eclipse.html#build-xml

Thanks to the two of you for additional comments on this. I hope
something useful to others comes of it, at very least, I hope no
misinformation comes of it.

Best regards,
Russ
Re: Sharing .classpath in source-code control [message #770203 is a reply to message #769377] Fri, 23 December 2011 16:10 Go to previous messageGo to next message
Mauro Molinari is currently offline Mauro MolinariFriend
Messages: 285
Registered: July 2009
Senior Member
Hi Russell.
My 2 cents on this topic.
After years during which my team shared just the source code in a CVS
repository (mainly because every team member wanted to use his/her
preferred IDE), we have renewed our development tools so that we are now
using a Subversion repository in which we store our Eclipse projects as
a whole and everyone is now using Eclipse.

This said, we're storing also .project, .classpath and .settings files
in our SCM and I saw this:
- if you bound your project to a Java Execution Environment rather than
to a JRE, there's no "absolute path" problem for the Java runtime in the
..classpath file
- if you put your JARs within the workspace and you add them to your
projects' build path, references to those JARs are relative to project
names, even for Javadoc locations (and also for source locations, I
think); for instance, I just checked this: having project P1 and project
P2 containing a folder named "repo" with myjar.jar and
myjar-javadoc.jar, I want P1 to depend on P2/repo/myjar.jar and
associate that javadoc to it; here is what I find in P1/.classpath:

<classpathentry kind="lib" path="/P2/repo/myjar.jar">
<attributes>
<attribute name="javadoc_location"
value="jar:platform:/resource/P2/repo/myjar-javadoc.jar!/"/>
</attributes>
</classpathentry>

So, no absolute reference to either myjar.jar or myjar-javadoc.jar in my
file system.

I have less detailed experience with Dynamic Web Projects, mainly
because our projects setup is using SpringSource Tools Suite Gradle
integration to handle a Gradle multiproject setup in which the build
path servlet dependencies are resolved against JARs coming from Maven
repositories, rather than from a Server Runtime library. But what I
could remember is that if all the team member have a Server Runtime
defined with the same name ("Apache Tomcat 6", for instance), when a
member does the first checkout of a DWP, all he has to do is to "bind"
the Server Runtime library of the project (which is initially marked as
"unbound") to his own local Server Runtime installation. I don't know if
this binding operation changes the files under version control or not, I
never did in-depth experiments on this.

So, I think the current situation is good, especially since the support
for variables and virtual folders have been improved during the last two
years.

Also, consider that all the Eclipse Foundation projects on the official
Eclipse repositories are fully under version control (including
..project, .classpath, etc.), so some way to handle this in a clean way
must exist :-)

The real problem when using Subversion for storing Eclipse projects is
that merge operations may cause conflicts on these important metadata
files... and when this happens, it's not nice. You may have a look to my
report at:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=365867

Hope this gives you some ideas.
Mauro.
Re: Sharing .classpath in source-code control [message #774266 is a reply to message #770203] Tue, 03 January 2012 16:03 Go to previous messageGo to next message
Russell Bateman is currently offline Russell BatemanFriend
Messages: 3798
Registered: July 2009
Location: Provo, Utah, USA
Senior Member

On 23-Dec-11 09:10, Mauro Molinari wrote:
> Hi Russell.
> My 2 cents on this topic.
> [snip]
> - if you put your JARs within the workspace and you add them to your
> projects' build path, references to those JARs are relative to project
> names, even for Javadoc locations (and also for source locations, I
> think); for instance, I just checked this: having project P1 and project
> P2 containing a folder named "repo" with myjar.jar and
> myjar-javadoc.jar, I want P1 to depend on P2/repo/myjar.jar and
> associate that javadoc to it; here is what I find in P1/.classpath:
>
> <classpathentry kind="lib" path="/P2/repo/myjar.jar">
> <attributes>
> <attribute name="javadoc_location"
> value="jar:platform:/resource/P2/repo/myjar-javadoc.jar!/"/>
> </attributes>
> </classpathentry>
>
> So, no absolute reference to either myjar.jar or myjar-javadoc.jar in my
> file system.
>
> [snip]
>
> Hope this gives you some ideas.
> Mauro.

Thanks very much for adding this information, Mauro.

I don't know how to encourage Eclipse to generate such paths as every
time I've associated either source code or Javadoc with a JAR via Build
Path, even when I copied the source/Javadoc along with the JAR to a
folder inside the project, I get a full filesystem path.

I would like to try out what got you to the path above. Could you
possibly list the steps you used? Perhaps there's some way of doing this
I am ignorant of.

Thanks,

Russ
Re: Sharing .classpath in source-code control [message #776468 is a reply to message #774266] Sun, 08 January 2012 13:55 Go to previous messageGo to next message
Mauro Molinari is currently offline Mauro MolinariFriend
Messages: 285
Registered: July 2009
Senior Member
Il 03/01/2012 17:03, Russell Bateman ha scritto:
> I would like to try out what got you to the path above. Could you
> possibly list the steps you used? Perhaps there's some way of doing this
> I am ignorant of.

I think I just edited the javadoc location using the following path:
Properties of the project, Java Build Path, Libraries, expand the JAR,
select Javadoc location, "Edit...", Javadoc in archive, Workspace file,
"Browse..." to select the Javadoc archive in the workspace.

Mauro.
Re: Sharing .classpath in source-code control [message #776936 is a reply to message #776468] Mon, 09 January 2012 15:09 Go to previous messageGo to next message
Russell Bateman is currently offline Russell BatemanFriend
Messages: 3798
Registered: July 2009
Location: Provo, Utah, USA
Senior Member

On 08-Jan-12 06:55, Mauro Molinari wrote:
> Il 03/01/2012 17:03, Russell Bateman ha scritto:
>> I would like to try out what got you to the path above. Could you
>> possibly list the steps you used? Perhaps there's some way of doing this
>> I am ignorant of.
>
> I think I just edited the javadoc location using the following path:
> Properties of the project, Java Build Path, Libraries, expand the JAR,
> select Javadoc location, "Edit...", Javadoc in archive, Workspace file,
> "Browse..." to select the Javadoc archive in the workspace.
>
> Mauro.

Ah, yes, this may work with Javadoc already in the archive. Most
third-party libraries I consume, however, ship Javadoc and/or source
code separately (alongside the JAR and not in it).

Thanks.
Re: Sharing .classpath in source-code control [message #779827 is a reply to message #776936] Mon, 16 January 2012 16:23 Go to previous messageGo to next message
Mauro Molinari is currently offline Mauro MolinariFriend
Messages: 285
Registered: July 2009
Senior Member
Il 09/01/2012 16:09, Russell Bateman ha scritto:
> Ah, yes, this may work with Javadoc already in the archive. Most
> third-party libraries I consume, however, ship Javadoc and/or source
> code separately (alongside the JAR and not in it).

I'm also using Javadoc archives different from the binary JARs. So,
Javadoc is bundled separately in my case also, but I also put the
Javadoc ZIPs/JARs in the workspace.

Mauro.
Re: Sharing .classpath in source-code control [message #780338 is a reply to message #779827] Tue, 17 January 2012 16:15 Go to previous messageGo to next message
Russell Bateman is currently offline Russell BatemanFriend
Messages: 3798
Registered: July 2009
Location: Provo, Utah, USA
Senior Member

On 16-Jan-12 09:23, Mauro Molinari wrote:
> Il 09/01/2012 16:09, Russell Bateman ha scritto:
>> Ah, yes, this may work with Javadoc already in the archive. Most
>> third-party libraries I consume, however, ship Javadoc and/or source
>> code separately (alongside the JAR and not in it).
>
> I'm also using Javadoc archives different from the binary JARs. So,
> Javadoc is bundled separately in my case also, but I also put the
> Javadoc ZIPs/JARs in the workspace.
>
> Mauro.

Hmmm... I wonder what's different. I also moved Javadoc zips/JARs into
my workspace before associating them and it still resulted in full paths
being generated.
Re: Sharing .classpath in source-code control [message #780449 is a reply to message #780338] Tue, 17 January 2012 23:37 Go to previous messageGo to next message
Russell Bateman is currently offline Russell BatemanFriend
Messages: 3798
Registered: July 2009
Location: Provo, Utah, USA
Senior Member

On 17-Jan-12 09:15, Russell Bateman wrote:
> On 16-Jan-12 09:23, Mauro Molinari wrote:
>> Il 09/01/2012 16:09, Russell Bateman ha scritto:
>>> Ah, yes, this may work with Javadoc already in the archive. Most
>>> third-party libraries I consume, however, ship Javadoc and/or source
>>> code separately (alongside the JAR and not in it).
>>
>> I'm also using Javadoc archives different from the binary JARs. So,
>> Javadoc is bundled separately in my case also, but I also put the
>> Javadoc ZIPs/JARs in the workspace.
>>
>> Mauro.
>
> Hmmm... I wonder what's different. I also moved Javadoc zips/JARs into
> my workspace before associating them and it still resulted in full paths
> being generated.

Experimenting again (and much more attentively this time), I downloaded
a set of JARs from Apache Commons to my project,
TryStuff/lib/apache/commons-configuration-1.7.jar plus -javadoc.jar and
-source.jar.

I clicked Build Path -> Configure Build Path -> Libraries -> Add JARs...
and added the JAR. Then, I expanded the newly added JAR to reveal Source
attachment and Javadoc location.

For the first, I edited, clicking Workspace, navigating to the
-source.jar and established that.

For the second, I edited, clicking Javadoc in archive, then clicking
Workspace file and navigating to the -javadoc.jar.

This resulted in adding to .classpath:

<classpathentry kind="lib"
path="lib/apache/commons-configuration-1.7.jar"
sourcepath="lib/apache/commons-configuration-1.7.sources.jar">
<attributes>
<attribute name="javadoc_location"
value="jar:platform:/resources/TryStuff/lib/apache/commons-configuration-1.7-javadoc.jar!/"
/>
</attributes>
</classpathentry>

So, as you suggest, this works. What I'm pretty certain I've never done
before, because I wasn't paying attention to or thinking about it, is
click the radio button "Workspace file".

Thanks for being patient. If this were stackoverflow, I'd already have
bumped each of your answers by now. You've been most helpful.

Best regards,

Russ Bateman
Re: Sharing .classpath in source-code control [message #808022 is a reply to message #780449] Mon, 27 February 2012 09:52 Go to previous message
Mauro Molinari is currently offline Mauro MolinariFriend
Messages: 285
Registered: July 2009
Senior Member
Il 18/01/2012 00:37, Russell Bateman ha scritto:
> Thanks for being patient. If this were stackoverflow, I'd already have
> bumped each of your answers by now. You've been most helpful.

Well, I'm glad to know I've been of help :-)

Mauro.
Previous Topic:svn compare vs svn sync ... and diffj
Next Topic:ISVNStatus is missing repository lock information
Goto Forum:
  


Current Time: Tue Mar 19 10:20:24 GMT 2024

Powered by FUDForum. Page generated in 0.03037 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top