Re: setting classpath relative to source folder
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; format=flowed
On Wed, 9 Feb 2011, Lew wrote:
On Feb 9, 11:25?am, harryos <oswald.ha...@gmail.com> wrote:
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?
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
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:
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".
HI DERE WAHT IS IT MADE