setting classpath relative to source folder

H

harryos

hi,
I have a java project which I configured in eclipse (helios).it has a
src folder containing the java packages of my code.I want to share
this to others using subversion..However when I checked the
src/.classpath file ,I find that the required jars which I have put in
a lib directory are represented by their absolute paths.

<classpathentry kind="lib" path="/home/me/dev/java/mycode_ver2/lib/
required.jar"/>

This makes it difficult for another person to import my project.I wish
I could represent these jars by relative paths .Do I need to manually
edit the .classpath file to do this?Or is there another way?

thanks
harry
 
L

Lew

hi,
I have a java project which I configured in eclipse (helios).it has a
src folder containing the java packages of my code.I want to share
this to others using subversion..However when I checked the
src/.classpath file ,I find that the required jars which I have put in
a lib directory are represented by their absolute paths.

<classpathentry kind="lib" path="/home/me/dev/java/mycode_ver2/lib/
required.jar"/>

This makes it difficult for another person to import my project.I wish
I could represent these jars by relative paths .Do I need to manually
edit the .classpath file to do this?Or is there another way?

First of all, do NOT put the IDE-specific files (such as ".classpath")
in the trunk of your version control.

The problem is exactly as you describe - they're specific to your
environment.

Instead, check in an Ant build.xml that specifies the dependencies.

You should never, ever, ever, EVER use IDE-specific artifacts to drive
your build!
 
T

Tom Anderson

No, you've just done it wrong (sorry!). I assume you added the JARs using
the 'add external JAR' button in the build path dialog; that's the wrong
choice, i'm afraid. If the JARs are inside the project (as they probably
should be in most cases), the simplest thing is to add them as internal
JARs; i can't remember what the button in the dialog is called, but in the
file explorer pane, you can pop up a context menu on the JAR and simply
pick "add to build path"; the entry in the .classpath is then relative to
the project root.

If the JARs are external to the project, and have to be that way (they
belong to a framework which is installed somewhere, for example),then the
way to do it is to use classpath variables: define a variable that points
to the root directory of the installation holding the JAR (in my case, the
main example would be JBoss; we have a JBOSS_HOME classpath variable),
then use 'add variable' to add a classpath entry that is relative to that
variable. People using your project will have to define that variable
(setting its value to something appropriate for their systems), but having
done that, the JARs will be available.
First of all, do NOT put the IDE-specific files (such as ".classpath")
in the trunk of your version control.

I should clarify that this is Lew's opinion, not a universal law. Some -
me, for example - would say that it is imperative to put the IDE-specific
files (such as ".classpath") in the trunk of your version control.
Instead, check in an Ant build.xml that specifies the dependencies.

You should never, ever, ever, EVER use IDE-specific artifacts to drive
your build!

Again, this is Lew's opinion. Some - me, for example - would say that you
should maintain a single definition of your build (rather than recklessly
duplicating it between IDE and Ant files), and if you're using an IDE,
that must be your IDE-specific files. You should, therefore, standardise
on a single IDE, and arrange your build around its metadata. For eclipse,
that metadata is two fairly simple XML files per project, and it's
therefore fairly simple to run builds of Eclipse projects without using
Eclipse. If you use Ant, you may be interested in Ant4Eclipse:

http://www.ant4eclipse.org/

If you use shell scripts, you may enjoy spending an afternoon writing some
to interpret those files.

What we really need is a standard for build definition files. Ant might
do, but i don't think it would be a good choice. We could then have all
IDEs, plus stand-alone tools, be capable of interpreting these files to
carry out a build. That we do not already have such a thing demonstrates
that, as Joshua Maurice mentioned in another thread, "builds is one of the
most under-appreciated aspects of programming".

tom
 
L

Lew

Tom said:
Again, this is Lew's opinion. Some - me, for example - would say that you
should maintain a single definition of your build (rather than recklessly
duplicating it between IDE and Ant files), and if you're using an IDE, that

I agree with single-definition policy, but not that it should be IDE files.
must be your IDE-specific files. You should, therefore, standardise on a

Wrong. All popular Java IDEs, including Eclipse, use Ant (and Maven, too, for
that matter) just fine.
single IDE, and arrange your build around its metadata. For eclipse, that

Standardize on Ant, and arrange your build around that. Then Eclipse,
NetBeans and the rest will handle it just fine.
metadata is two fairly simple XML files per project, and it's therefore fairly
simple to run builds of Eclipse projects without using Eclipse. If you use
Ant, you may be interested in Ant4Eclipse:

http://www.ant4eclipse.org/

What's wrong with regular Ant?
If you use shell scripts, you may enjoy spending an afternoon writing some to
interpret those files.

What we really need is a standard for build definition files. Ant might do,

It does.
but i don't think it would be a good choice. We could then have all IDEs, plus

Why not?
stand-alone tools, be capable of interpreting these files to carry out a

We already have that capability, using either Ant or Maven. Why reinvent the
wheel?
build. That we do not already have such a thing demonstrates that, as Joshua

But we *do* already have such a thing! It's called "Ant"!
Maurice mentioned in another thread, "builds is one of the most
under-appreciated aspects of programming".

--
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/ | *\##|
|#/ * | \#|
|#----|----#|
|| | * ||
|o * | o|
|_____|_____|
|===========|
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,981
Messages
2,570,188
Members
46,732
Latest member
ArronPalin

Latest Threads

Top