Home » Newcomers » Newcomers » classpath not working ...
| classpath not working ... [message #254705] |
Thu, 24 April 2008 20:59  |
Eclipse User |
|
|
|
Originally posted by: jeffbis.email.arizona.edu
Hello Everyone,
I am working through the Thinking in Java book and trying to get things to
work in Eclipse.
Here is how things are set up.
1. I have a folder on drive d: called d:\work.
2. I have the Thinking in Java book source code in a folder called:
d:\tij\code
Inside of this folder are .java and .class files in a directory structure.
I have the following class defined:
import java.util.*;
import static net.mindview.util.Print;
public class Print1 {
public static void main(String[] args) {
System.out.println("hello world");
print("Hello, it's: ");
print(new Date());
}
}
I tried to compile this and of course it failed due to not finding the
print class.
I then went into the project properties, Java Build Path and added a class
path to an external folder, that being:
d:\tij\code
Same issue.
I tried retyping the import line like so:
import static net.mindview.
and pressed down arrow.
It resolved to:
net.mindview.util.
It won't resolve to print.
If I set a CLASSPATH variable to d:\tij\code and manually compile from the
command line and run the code it works fine.
Please help. It is driving me nuts.
|
|
|
| Re: classpath not working ... [message #254723 is a reply to message #254705] |
Fri, 25 April 2008 08:10  |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Jeff,
Comments below.
Jeff Bishop wrote:
> Hello Everyone,
>
> I am working through the Thinking in Java book and trying to get
> things to work in Eclipse.
>
> Here is how things are set up.
>
> 1. I have a folder on drive d: called d:\work.
>
> 2. I have the Thinking in Java book source code in a folder called:
>
> d:\tij\code
>
> Inside of this folder are .java and .class files in a directory
> structure.
>
> I have the following class defined:
>
> import java.util.*;
> import static net.mindview.util.Print;
>
> public class Print1 {
>
> public static void main(String[] args) {
>
> System.out.println("hello world");
> print("Hello, it's: ");
> print(new Date());
>
> }
> }
>
> I tried to compile this and of course it failed due to not finding the
> print class.
>
> I then went into the project properties, Java Build Path and added a
> class path to an external folder, that being:
>
> d:\tij\code
Until 3.4M6, Java didn't properly support external folder on the
classpath. You could create a Java project that has d:/tij as the
project's physical location and configure the Java project o make code a
source folder. Or you could create a jar with the .class files and
point to that.
>
> Same issue.
>
> I tried retyping the import line like so:
>
> import static net.mindview.
>
> and pressed down arrow.
>
> It resolved to:
>
> net.mindview.util.
>
> It won't resolve to print.
>
> If I set a CLASSPATH variable to d:\tij\code and manually compile from
> the command line and run the code it works fine.
>
> Please help. It is driving me nuts.
I'd recommend trying to set up the tij/code thing as a project so that
you can get at all the source to browse it and debug into it easily...
Failing that, build a jar for it or use 3.4M6 and try again. Note that
I'm assuming that the "code" folder is the root of the source tree,
i.e., that the first folder under code represents the first segment of a
qualified package name...
>
>
>
|
|
| | | |
| Re: classpath not working ... [message #254742 is a reply to message #254723] |
Fri, 25 April 2008 09:46 |
| Eclipse User |
|
|
|
Originally posted by: jeffbis.email.arizona.edu
What does everyone think about using 3.4m6? Do you think it is a pretty
stable release even though it is a beta? Can one simply unzip the eclipse
and overwrite the Eclipse already installed? What has changed in that
release?
"Ed Merks" <merks@ca.ibm.com> wrote in message
news:fushn9$8lt$1@build.eclipse.org...
> Jeff,
>
> Comments below.
>
> Jeff Bishop wrote:
>> Hello Everyone,
>>
>> I am working through the Thinking in Java book and trying to get things
>> to work in Eclipse.
>>
>> Here is how things are set up.
>>
>> 1. I have a folder on drive d: called d:\work.
>>
>> 2. I have the Thinking in Java book source code in a folder called:
>>
>> d:\tij\code
>>
>> Inside of this folder are .java and .class files in a directory
>> structure.
>>
>> I have the following class defined:
>>
>> import java.util.*;
>> import static net.mindview.util.Print;
>>
>> public class Print1 {
>>
>> public static void main(String[] args) {
>>
>> System.out.println("hello world");
>> print("Hello, it's: ");
>> print(new Date());
>>
>> }
>> }
>>
>> I tried to compile this and of course it failed due to not finding the
>> print class.
>>
>> I then went into the project properties, Java Build Path and added a
>> class path to an external folder, that being:
>>
>> d:\tij\code
> Until 3.4M6, Java didn't properly support external folder on the
> classpath. You could create a Java project that has d:/tij as the
> project's physical location and configure the Java project o make code a
> source folder. Or you could create a jar with the .class files and point
> to that.
>>
>> Same issue.
>>
>> I tried retyping the import line like so:
>>
>> import static net.mindview.
>>
>> and pressed down arrow.
>>
>> It resolved to:
>>
>> net.mindview.util.
>>
>> It won't resolve to print.
>>
>> If I set a CLASSPATH variable to d:\tij\code and manually compile from
>> the command line and run the code it works fine.
>>
>> Please help. It is driving me nuts.
> I'd recommend trying to set up the tij/code thing as a project so that you
> can get at all the source to browse it and debug into it easily...
> Failing that, build a jar for it or use 3.4M6 and try again. Note that
> I'm assuming that the "code" folder is the root of the source tree, i.e.,
> that the first folder under code represents the first segment of a
> qualified package name...
>>
>>
>>
|
|
|
| Re: classpath not working ... [message #254746 is a reply to message #254742] |
Fri, 25 April 2008 10:07 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------000908010508000209020905
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Jeff,
Comments below.
Jeff Bishop wrote:
> What does everyone think about using 3.4m6?
Because I'm developing the latest version of EMF, I always use the
platform's latest integration builds for all my development needs. It's
extremely rare for an integration build to have problems that make it
unusable.
> Do you think it is a pretty
> stable release even though it is a beta?
Definitely. Especially when you get into the later milestones and soon
the release candidate builds. It also provides a service to the
community to test these builds and iron out any issues that have been
overlooked before there is a general release. So we Eclipse developers
greatly appreciate people trying out these builds and especially
reporting problems with them! You might want to get one of the packages
if you need plugins other than just the bare Eclipse ones:
<http://www.eclipse.org/downloads/packages/>
http://www.eclipse.org/downloads/packages/
> Can one simply unzip the eclipse
> and overwrite the Eclipse already installed?
Yes, you can unzip, but no, don't overwrite existing installations. Put
it in a new place. Keep the old one around in case you have problems
and you'll be able to go back to using it.
> What has changed in that
> release?
>
The JDT added support for external folders, much to my personal
delight. Along with the corresponding changes in the PDE, this allows
me to bootstrap my development environment far more easily; I use EMF
itself to regenerate my models, so when I make changes to the generator,
I need to apply those changes to the project in the workspace I'm
already working on...
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:fushn9$8lt$1@build.eclipse.org...
>
>> Jeff,
>>
>> Comments below.
>>
>> Jeff Bishop wrote:
>>
>>> Hello Everyone,
>>>
>>> I am working through the Thinking in Java book and trying to get things
>>> to work in Eclipse.
>>>
>>> Here is how things are set up.
>>>
>>> 1. I have a folder on drive d: called d:\work.
>>>
>>> 2. I have the Thinking in Java book source code in a folder called:
>>>
>>> d:\tij\code
>>>
>>> Inside of this folder are .java and .class files in a directory
>>> structure.
>>>
>>> I have the following class defined:
>>>
>>> import java.util.*;
>>> import static net.mindview.util.Print;
>>>
>>> public class Print1 {
>>>
>>> public static void main(String[] args) {
>>>
>>> System.out.println("hello world");
>>> print("Hello, it's: ");
>>> print(new Date());
>>>
>>> }
>>> }
>>>
>>> I tried to compile this and of course it failed due to not finding the
>>> print class.
>>>
>>> I then went into the project properties, Java Build Path and added a
>>> class path to an external folder, that being:
>>>
>>> d:\tij\code
>>>
>> Until 3.4M6, Java didn't properly support external folder on the
>> classpath. You could create a Java project that has d:/tij as the
>> project's physical location and configure the Java project o make code a
>> source folder. Or you could create a jar with the .class files and point
>> to that.
>>
>>> Same issue.
>>>
>>> I tried retyping the import line like so:
>>>
>>> import static net.mindview.
>>>
>>> and pressed down arrow.
>>>
>>> It resolved to:
>>>
>>> net.mindview.util.
>>>
>>> It won't resolve to print.
>>>
>>> If I set a CLASSPATH variable to d:\tij\code and manually compile from
>>> the command line and run the code it works fine.
>>>
>>> Please help. It is driving me nuts.
>>>
>> I'd recommend trying to set up the tij/code thing as a project so that you
>> can get at all the source to browse it and debug into it easily...
>> Failing that, build a jar for it or use 3.4M6 and try again. Note that
>> I'm assuming that the "code" folder is the root of the source tree, i.e.,
>> that the first folder under code represents the first segment of a
>> qualified package name...
>>
>>>
>>>
>
>
>
--------------000908010508000209020905
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jeff,<br>
<br>
Comments below.<br>
<br>
Jeff Bishop wrote:
<blockquote cite="mid:fusnbj$qes$1@build.eclipse.org" type="cite">
<pre wrap="">What does everyone think about using 3.4m6? </pre>
</blockquote>
Because I'm developing the latest version of EMF, I always use the
platform's latest integration builds for all my development needs.
It's extremely rare for an integration build to have problems that make
it unusable.<br>
<blockquote cite="mid:fusnbj$qes$1@build.eclipse.org" type="cite">
<pre wrap="">Do you think it is a pretty
stable release even though it is a beta? </pre>
</blockquote>
Definitely. Especially when you get into the later milestones and soon
the release candidate builds. It also provides a service to the
community to test these builds and iron out any issues that have been
overlooked before there is a general release. So we Eclipse developers
greatly appreciate people trying out these builds and especially
reporting problems with them! You might want to get one of the
packages if you need plugins other than just the bare Eclipse ones:<a
href="http://www.eclipse.org/downloads/packages/"><br>
</a>
<blockquote><a href="http://www.eclipse.org/downloads/packages/">http://www.eclipse.org/downloads/packages/</a><br>
</blockquote>
<blockquote cite="mid:fusnbj$qes$1@build.eclipse.org" type="cite">
<pre wrap=""> Can one simply unzip the eclipse
and overwrite the Eclipse already installed? </pre>
</blockquote>
Yes, you can unzip, but no, don't overwrite existing installations.
Put it in a new place. Keep the old one around in case you have
problems and you'll be able to go back to using it.<br>
<blockquote cite="mid:fusnbj$qes$1@build.eclipse.org" type="cite">
<pre wrap=""> What has changed in that
release?
</pre>
</blockquote>
The JDT added support for external folders, much to my personal
delight. Along with the corresponding changes in the PDE, this allows
me to bootstrap my development environment far more easily; I use EMF
itself to regenerate my models, so when I make changes to the
generator, I need to apply those changes to the project in the
workspace I'm already working on...<br>
<blockquote cite="mid:fusnbj$qes$1@build.eclipse.org" type="cite">
<pre wrap="">
"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:merks@ca.ibm.com"><merks@ca.ibm.com></a> wrote in message
<a class="moz-txt-link-freetext" href="news:fushn9$8lt$1@build.eclipse.org">news:fushn9$8lt$1@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Jeff,
Comments below.
Jeff Bishop wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hello Everyone,
I am working through the Thinking in Java book and trying to get things
to work in Eclipse.
Here is how things are set up.
1. I have a folder on drive d: called d:\work.
2. I have the Thinking in Java book source code in a folder called:
d:\tij\code
Inside of this folder are .java and .class files in a directory
structure.
I have the following class defined:
import java.util.*;
import static net.mindview.util.Print;
public class Print1 {
public static void main(String[] args) {
System.out.println("hello world");
print("Hello, it's: ");
print(new Date());
}
}
I tried to compile this and of course it failed due to not finding the
print class.
I then went into the project properties, Java Build Path and added a
class path to an external folder, that being:
d:\tij\code
</pre>
</blockquote>
<pre wrap="">Until 3.4M6, Java didn't properly support external folder on the
classpath. You could create a Java project that has d:/tij as the
project's physical location and configure the Java project o make code a
source folder. Or you could create a jar with the .class files and point
to that.
</pre>
<blockquote type="cite">
<pre wrap="">Same issue.
I tried retyping the import line like so:
import static net.mindview.
and pressed down arrow.
It resolved to:
net.mindview.util.
It won't resolve to print.
If I set a CLASSPATH variable to d:\tij\code and manually compile from
the command line and run the code it works fine.
Please help. It is driving me nuts.
</pre>
</blockquote>
<pre wrap="">I'd recommend trying to set up the tij/code thing as a project so that you
can get at all the source to browse it and debug into it easily...
Failing that, build a jar for it or use 3.4M6 and try again. Note that
I'm assuming that the "code" folder is the root of the source tree, i.e.,
that the first folder under code represents the first segment of a
qualified package name...
</pre>
<blockquote type="cite">
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>
--------------000908010508000209020905--
|
|
| |
| Re: classpath not working ... [message #256077 is a reply to message #254754] |
Sun, 11 May 2008 12:50 |
| Eclipse User |
|
|
|
I recently set up Europa and could not get the $CLASSPATH to work in the
IDE as it does in the command line...
I figured I could set up a CLASSPATH variable, select it for a project,
and Europa would look for *.class files in $CLASSPATH + (import path).
When trying to select a CLASSPATH variable, Europa says it can't be
selected because its value is a folder... isn't that what a CLASSPATH
variable supposed to do? I realize that the tail end of the CLASSPATH
variable should contain something executable... I think, because it's
called CLASS"PATH", it's easy to confuse it with containing just a path
instead of a path with an executable at its tail.
Anyway, I moved up to Ganymede M6 after reading this thread, and
assigning a CLASSPATH variable to a project does work... as long as the
*.class files are already in the imported path... ie if there is no
class file in the imported path, Ganymede produces an error.
Normally, the Java compiler will regenerate the class file, even the
imported class files, if the source is present. Is there a way of making
Ganymede do this?
Richard
Eric Rizzo wrote:
> Jeff Bishop wrote:
>> What does everyone think about using 3.4m6? Do you think it is a
>> pretty stable release even though it is a beta? Can one simply unzip
>> the eclipse and overwrite the Eclipse already installed? What has
>> changed in that release?
>
> The Milestone builds (especially the later ones like M5, M6, and M7)
> have a long track record of stability, going back to the Eclipse 2.1
> days. I have no problem using them, personally.
> As for what has changed, that is a long answer. Start with this page
> http://download.eclipse.org/eclipse/downloads/drops/S-3.4M6- 200803301350/eclipse-news-M6.html
>
> and also follow all the links at the bottom of the page to earlier
> milestone builds.
>
> Hope this helps,
> Eric
|
|
|
| Re: classpath not working ... [message #256104 is a reply to message #256077] |
Mon, 12 May 2008 09:59 |
| Eclipse User |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
Richard Geddes wrote:
> I recently set up Europa and could not get the $CLASSPATH to work in the
> IDE as it does in the command line...
>
> I figured I could set up a CLASSPATH variable, select it for a project,
> and Europa would look for *.class files in $CLASSPATH + (import path).
> When trying to select a CLASSPATH variable, Europa says it can't be
> selected because its value is a folder... isn't that what a CLASSPATH
> variable supposed to do? I realize that the tail end of the CLASSPATH
> variable should contain something executable... I think, because it's
> called CLASS"PATH", it's easy to confuse it with containing just a path
> instead of a path with an executable at its tail.
>
> Anyway, I moved up to Ganymede M6 after reading this thread, and
> assigning a CLASSPATH variable to a project does work... as long as the
> *.class files are already in the imported path... ie if there is no
> class file in the imported path, Ganymede produces an error.
>
> Normally, the Java compiler will regenerate the class file, even the
> imported class files, if the source is present. Is there a way of making
> Ganymede do this?
It is not clear what your end goal is. It is fairly clear, however, that
you are unclear about build paths in Eclipse - it is not the same as or
similar to using javac on the command line. To begin with, Eclipse does
NOT use the system CLASSPATH variable in any way. In Eclipse, each
project has its own independent Build Path.
You seem to have discovered Classpath Variables, which are a convenient
way for projects to refer to external JARs or directories that might
differ between different machines (for example, if you and I were
working on the same projects that depended on a certain library but we
had that library installed in different locations on our machines). But
Classpath Variables are of limited use (IMO) because it is usually
better to contain all necessary libraries in the project itself or in a
special "Libs" project that other projects depend on. I always recommend
against referring to JARs that are assumed to exist somewhere on a
development file system, even though Classpath Variables make that a
little easier to manage.
If you describe your end-goal I'm sure we can provide specific advice on
how to set it up in Eclipse. Better yet, you can read the "Project
Configuration" tutorial that is in the Eclipse Help (under section Java
Development User Guide, Getting Started) - that will help you understand
the fundamentals of project set-up.
Hope this helps,
Eric
|
|
|
| Re: classpath not working ... [message #256372 is a reply to message #256104] |
Wed, 14 May 2008 15:45 |
| Eclipse User |
|
|
|
Eric Rizzo wrote:
> Richard Geddes wrote:
>> I recently set up Europa and could not get the $CLASSPATH to work in the
>> IDE as it does in the command line...
>>
>> I figured I could set up a CLASSPATH variable, select it for a project,
>> and Europa would look for *.class files in $CLASSPATH + (import path).
>> When trying to select a CLASSPATH variable, Europa says it can't be
>> selected because its value is a folder... isn't that what a CLASSPATH
>> variable supposed to do? I realize that the tail end of the CLASSPATH
>> variable should contain something executable... I think, because it's
>> called CLASS"PATH", it's easy to confuse it with containing just a path
>> instead of a path with an executable at its tail.
>>
>> Anyway, I moved up to Ganymede M6 after reading this thread, and
>> assigning a CLASSPATH variable to a project does work... as long as the
>> *.class files are already in the imported path... ie if there is no
>> class file in the imported path, Ganymede produces an error.
>>
>> Normally, the Java compiler will regenerate the class file, even the
>> imported class files, if the source is present. Is there a way of making
>> Ganymede do this?
>
> It is not clear what your end goal is. It is fairly clear, however, that
> you are unclear about build paths in Eclipse - it is not the same as or
> similar to using javac on the command line. To begin with, Eclipse does
> NOT use the system CLASSPATH variable in any way. In Eclipse, each
> project has its own independent Build Path.
> You seem to have discovered Classpath Variables, which are a convenient
> way for projects to refer to external JARs or directories that might
> differ between different machines (for example, if you and I were
> working on the same projects that depended on a certain library but we
> had that library installed in different locations on our machines). But
> Classpath Variables are of limited use (IMO) because it is usually
> better to contain all necessary libraries in the project itself or in a
> special "Libs" project that other projects depend on. I always recommend
> against referring to JARs that are assumed to exist somewhere on a
> development file system, even though Classpath Variables make that a
> little easier to manage.
>
> If you describe your end-goal I'm sure we can provide specific advice on
> how to set it up in Eclipse. Better yet, you can read the "Project
> Configuration" tutorial that is in the Eclipse Help (under section Java
> Development User Guide, Getting Started) - that will help you understand
> the fundamentals of project set-up.
>
> Hope this helps,
> Eric
You are correct, Eric. I was under the impression that the CLASSPATH
variables in Eclipse served the same purpose as the CLASSPATH variable
in javac. The names look the same.. I guess the "duck" rule does not
apply.
Thanks for the advice.. I'll go to the tutorial and learn the
distinctions between Eclipse and javac CLASSPATH vars. Just when you
think you've got it, alas there's always something new.
BTW, my goal was to make the CLASSPATH var in Eclipse give me the the
same behavior as the CLASSPATH var in javac.
Thanks,
Richard
|
|
|
Goto Forum:
Current Time: Sun Jun 08 15:09:53 EDT 2025
Powered by FUDForum. Page generated in 0.34325 seconds |
Home