(This is a lot more dumbed-down than it needs to be, but at least the
information is all here. Involuntary obsession and compulsion leads me to find
a single, intact level at which to express something like this and stick with
it so it's all uniform. If I start too low, I tend to stay there and take a
lesson for next time.)
Eclipse keys and . ctag functionality here
See Java errors/warnings here.
Eclipse update sites of interest to me
Where to go to get useful plug-ins. The URL in italics is to be copied and
given to Eclipse
Help -> Install New Software... -> Add.
(Starting in Indigo, I use
Eclipse Marketplace... instead of
Install New Software.... See here.)
Contents of my
eclipse.ini at one point:
Eclipse memory issues...
Please read my
definitions of terms such as XX:MaxPermSize.
At one point, my
eclipse.ini entries, maximized because I had plenty of
room on my host computers, were:
(This is just a record I can return to for comparison; it's not otherwise
significant nor is it meant as a suggestion.)
Note that what is set in
eclipse.ini has nothing whatsoever to do with
running code you create in the IDE. It's only a configuration for Eclipse
itself. For setting configuration for the application under development in
Eclipse, see below.
Despite running Windows 64-bit and/or despite having lots of available, physical
memory, it's rarely if ever possible to increase the amount of memory for
Eclipse to anything like what you imagine you could.
This is actually not an Eclipse-specific issue; it's a general issue with Java
on Windows where continguous memory can't be provided because of how Windows
manages it. The JVM insists on managing a single, contiguous chunk rather than
accepting to unite discontinguous chunks.
There are utilities that attempt to get Windows to defragment its memory, but I
haven't tried them. There is a tool from Windows Internals called VMMap that
shows how the virtual process memory is fragmented and how big the largest
continuous block is.
In theory, it should be possible to reboot Windows and, before starting
anything else (tall order), launch Eclipse (Java). Maybe memory will not have
become so fragmented?
I read one place that it's never possible to get more than
and usually far less. This source claimed that it depends on the version of
Windows and what applications/drivers are installed.
While I haven't experimented too much, it should be possible to set the amount
of memory on Linux, especially 64-bit, to just about anything since that OS'
memory manager can maintain virtually contiguous blocks of memory. I haven't
greatly experimented with that yet because it's never become a problem I didn't
want to work around out of general "niceness" of my applications; and, for
running Eclipse, I haven't so far had the same problems there as on Windows.
Setting command-line arguments for application under development
Use these instructions to set memory configuration for running the project
under development. Obviously, when deployed, the application or other code will
have to enjoy the same treatmentat the hands of its user.
Right-click on the project (or other representative file in the project)
Project/ Package Explorer view.
Run As -> Run Configurations.... Add memory-configuration arguments on the command line as illustrated
Initial Eclipse launch...
Workspace vs. working set: best practice
Launch Eclipse and create a new workspace. Instead of using working sets (see
are otherwise very useful in Eclipse to create separation between projects in a
same workspace, use workspaces themselves between branched versions of the
russ@taliesin:~/dev> mkdir workspace-1.7
When Eclipse asks for a workspace, browse to the one you've created. Set it as
the definitive workspace used without prompting when you launch Eclipse: you
can change it using the
File->Switch Workspace menu option
should you need to create and use another code branch simultaneously.
Working with the Eclipse workspace...
The Eclipse workspace is a concept that allows you to collect related projects
into one space. You don't have to keep all your projects, however unrelated, in
one place. (You can also use "working sets" to solve this and similar problems,
but I despise large numbers of projects in my workspace.)
Workspaces are less of a headache than you might think. For example, if you
don't like the name of a workspace, you might simply rename it in the file
system. The next time you launch Eclipse, you can navigate to it and choose it.
You can even swap names thus:
mv workspace-2.0 poop
russ@taliesin:~/dev> mv workspace-1.8 workspace-2.0
russ@taliesin:~/dev> mv poop workspace-futures
One annoying thing about Eclipse is that it doesn't display the name of the
current workspace anywhere. You must determine this by process of elimination:
File->Switch Workspace. If the workspace you think you're
presently working in isn't listed, then that's probably the one you are working
Creating launch configuration
Seemingly, one never goes to Eclipse for help with Eclipse, but to
Google, an Eclipse forum, etc. In this case, Eclipse help is pretty
Later note: It's not always like this, but you can replace "galileo" in
the link above with "helios" or "indigo".
Correcting project parameters...
In the case where a different (for example, more modern) JDK/JRE and/or Tomcat
were used inadvertantly, it becomes difficult to change them back. The simplest
way is to delete the project, but not its source code which is sitting in the
filesystem from Subversion, or created and already existing and which we don't
want to use, and recreate it.
You should have used the 1.4 JDK.
After deleting the project, drop the Eclipse workbench. Go to the filesystem
and remove the following files and subdirectory:
Do not remove subdirectory
build if it is actually part of your source
code (which should not, but could be the case if you chose it on
purpose—it is the name Eclipse chooses to call the place it puts built
classes, but in our case here, we always change this to classes either
under web/WEB-INFO or directly under the project.
This is an optional way of sorting out differences between branches (release
versions) of the repository code. It's not a focus of this document, but is
mentioned in passing as a solution. The solution I'm adopting is not to use
working sets for this, but separate workspaces.
There is a little triangular control under the
tab/pane, at least, that gets you access to creating and using a working set.
See the red arrow in the image at the right (click to enlarge).
Building should happen automatically at each point of modification of any
aspect of the project unless you've turned this off. I find that in knitting
together a project, I must often iright-click on the project, use
Refresh and/or choose
Project->Clean... to reset
the state of the project and force a new rebuild in order to be certain that
the errors and warnings displayed aren't stale.
Libraries between projects
Carefully attend to all of these little tasks.
Java Build Paths->Libraries tab of most (or all)
subprojects, remove all the individual JAR references and replace with
Add Library->WebApp Libraries, choose
Server Runtime as Tomcat 5.5.
Error/warning levels in Eclipse
Gradually, the levels of what is reported as a compilation error or warning
must be adjusted a) to match the carelessness of authorship of the code
inherited or b) the refinement brought to that authorship when writing code or
subsequently. In addition, there are problably simply some errors that will
never go away, but must be eliminated for the project to be run and/or
Here are tables explaining error/warning messages you'll see and which
preferences settings correspond to them:
Following is a list of settings and the values I've chosen reached via
right-clicking on the project and choosing
It appears possible to set these globally for Eclipse (or, perhaps rather for
the workspace) by going to
Right-clicking each project, choosing
Compiler->Errors/Warnings and ensuring that
specific settings is not clicked. This will direct the project to behave
in this respect to the global Eclipse/workspace settings for compiler errors
Non-static access to static member
Indirect access to static member
Unqualified access to instance field
Undocumented empty block
Access to a non-accessible member of an enclosing type
Method with a contructor name
Non-externalized strings (missing/unused $NON-NLS$ tags)
Ignore Potential programming problems
Serializable class without serialVersionID
Assignment has no effect (e.g.: 'x = x')
Possible accidental boolean assignment (e.g.: 'if a = b')
'finally' does not complete normally
using a char array in string concatenation
Hidden catch block
Inexact type match for vararg arguments
Boxing and unboxing conversions
Enum type constant not covered on 'switch'
'switch' case fall-through
Null pointer access
Potential null pointer access
Error Name shadowing and conflicts
Field declaration hides another field or variable
Local variable declaration hides another field or variable
Include constructor or setter method parameters
Type parameter hides another type
Method overridden but not package visible
Interface method conflicts with proected 'Object' method
Error Deprecated and restricted API
Signal use of deprecated API inside deprecated code
Signal overriding or implementing deprecated method
Forbidden reference (access rules)
Discouraged reference (access rules)
Warning Unnecessary code
Local variable is never read
Parameter is never read
Check overriding and implementing methods
Ignore parameters documented with '@param' tag
Unused local or private member
Redundant null check
Unnecessary 'else' statement
Unnecessary cast or 'instanceof' operation
Unnecessary declaration of thrown checked exception
Check overriding and implementing methods
Unused 'break' or 'continue' label
— The following are unused because didn't exist in Java 4 —
Unchecked generic type operation
Usage of a raw type
Generic type parameter declared with a final type bound
Missing '@Override' annotation
Missing '@Deprecated' annotation
Annotation is used as super interface
Unhandled warning token in '@SuppressWarnings'
Warning Enable '@SuppressWarnings' annotations
Treat errors like fatal compiler errors (make compiled code not executable)
ctag-like actions in Eclipse
The following are keyboard short-cuts to doing things in Eclipse that
compensate (often much better) for the lack of
cscope. Also, other cool stuff reached similarly.
Action or description
Go to line number...
SHIFT CTRL R
The most magic: type in a classname or filename.
SHIFT CTRL T
Find class from (what's under the) cursor.
Report class/package hierarchy for present file.
List methods and data from here to end of class.
Intelligent search of Java code.
CTRL ALT H
Show method's call hierarchy (called from/calls)
Find class or object from what's clicked.
Show hierarchy in Package Explorer.
(difficult to explain stuff...)
See stuff (IntelliSense™-like).
Option to refactor source.
ALT right-(or left) arrow
Course back and forth again from CTRL-clicks. The equivalente
of CTRL-t on steroids in vi with ctags.
See more complete and better stuff like this in my friend
Scott's Eclipse Keys, in particular, consult the
"Navigate keys" list
To compare your code with what you got out from the repository or what has been
committed since, right-click on the source file name in the
Explorer, click on Compare With, then choose one of Base
Revision, shows what changes you have made or Latest from
Repository, shows how different from latest check-in which may have
happened after you began modifying code.
There are still other options there.
Someone else just committed changes to code since you performed your last
commit. How to see those? Right-click on the file, choose
then Show History. Go to the History window that should have
opened in a pane somewhere in the workbench. Click on the latest version (at
the top of the list) and control-click on the version you last worked on. Then,
right-click on one of the selected versions and choose Compare. This
gives you the same side-by-side comparison as the first method noted in this
Any two versions may be compared in this manner; just control-click the two
that interest you.
Eclipse: current working directory
When you run a stand-alone Java program, its current working directory is
simply where it was launched from. That's expected. However, what about running
a class in Eclipse when right-clicking and choosing
application? The current working directory is
<workspace/project>. You can prove it to yourself using this code
String cwd = System.getProperty( "user.dir" );
System.out.println( "Current working directory: " + cwd );
Upgrading Eclipse spelling dictionary
I can only endure seeing a misspelling so long before I want to tell a
spell-checker to stop bothering me with it. Red-underlined variable names don't
bother me in comments (
au contraire, in fact), but perfectly good words
like my own name, downloaded, idempotent, credentials and
programmatically, to mention but a few, are really annoying to see
comment after comment, file after file.
I'm running Europa (3.3.2). I followed the procedure here. As I had no user
dictionary to begin with, I had to create one as described here too.
To add a word to the user dictionary, I:
Opened a shell to my Eclipse installation directory,
Typed touch user-dictionary
Edited Eclipse Preferences:
- Browse to (empty) user-dictionary (created in step 2)
Choose Apply in preferences dialog
Click on the word (e.g.: idempotent) and type CTRL-1
Click on Add 'idempotent' to dictionary
To stop seeing the word underlined in the editor in other files, you must close
the file and reopen it.
To remove a term mistakenly added, use Vi[m] to edit
delete the word (and its line).
@author for Javadoc
This comes out as the name of the (Linux) user; in my case, the rather
informal "russ". To change this, create a Launcher shortcut and type the
Launcher -> Command as
user.name is a Java property.
It's also possible to change Eclipse workspace preferences to provide this.
Window -> Preferences. Click
Java -> Code Style -> Code Templates. Expand
Comments, click Files. Click the
Edit button. Recast the Java file-level template to contain "@author Russell
(Maybe add it on a new line in order to retain the general utility of the
In this sense, it's not really "fixing" the value for Javadoc
@author, but it achieves the same effect.
Invisible code from JARs
Sometimes control-clicking in the editor or single-stepping down through code,
code for which the source is unknown to Eclipse is encountered. An edit window
comes up with...
Class File Editor
Source not found
The jar file XxxxxYyyyy.jar has no source attachment.
You can attach the source by clicking Attach Source below:
[Button: Attach Source]
To remedy this, click the
Attach Source button to get the Source
Attachment Configuration dialog. There, you click on one of three buttons
to attach the source.
However, you are not really attaching source code (by
but looking for code associated with the JAR in question.
Source code and JARs
Some JARs come with source code and many do not. You have to pay attention to
get the source code to, say, the Apache HTTP client code, otherwise you end up
with only the binary JAR you need to link with. This is not usually a problem
because you can consider that the supplier has done his job perfectly and if
there's an error or bug, it's your own and usually you can determine the
defugalty by your own means without that third-party source code.
(This foregoing discussion is incomplete because I'm not elaborating on where
or how to get the source code to third-party JARs even though I've done it
before. Maybe another time when I have to do it again.)
When adding JARs to the build path via right-clicking on a project, choosing
Build Path->Configure Build Path..., and then clicking on
Libraries, you can see, if you click to open a listed xxx.jar,
Source attachment:. Clicking, you'll see you can Edit... the
path: you fall into the same sequence as described for the Editor above.
Javadoc and JARs
This is a similar discussion as the preceding one for source attachments in
Build Path. Edit the path to Javadoc location:. Instead of
navigating to the project, you'll be looking for an index.html in the
distribution. Choose its parent directory.
JARs in Eclipse
Making new jars and supplying to other projects...
In a mixed environment of one workspace with multiple, interdependent projects,
the JAR of one project must be ported to the
web/WEB-INF/lib of another.
This is usually done by an ant script, but as I'm working in Linux and
have slightly different path assumptions, the existing scripts won't do it for
How has this been working? It has worked because I have not so far modified
shared code (code outside RetainServer in fact) and when such code is modified,
it eventually finds its way into the repository and my updating gets it from
How to do this...
Click on the Add Buildfiles icon
Find the shared project needing rebuild (SharedJava for example).
Open the triangle and click on ant.xml.
Click OK to add it: something should show up in the Ant Pane.
These are all little
ant scripts to do precious things like clean
up, copy the trunk, etc. including make a jar. Double-clicking on any
script runs the script. (The clean script is a good one to run.)
Watch the console window to see what this does when you run a script.
If you make a new JAR, it will put it in a (usually) harmless place. You can
copy it from there on the needed path
What to do when Eclipse gets icky...
When suddenly everything is full of red stop signs and the whole damn
compilation state seems to come crashing down, there is a sequence of panic
instructions. Before pointing a small, handheld firearm at your temple, try
the following—maybe in this order:
Refresh each individual project (right-click on project, choose
Update (right-click on project, choose
Clean and rebuild—probably happening automatically, but if
not (click the Project menu, choose Clean..., then
Clean all projects, then click OK).
Close a project.
If you have more than one project open, try closing several (to reduce
the number of errors distracting you) and then concentrate on figuring
out where the errors come from. This should be done intelligently; if
projects interdepend rather than operate off each other via
ant-built JARs or something, then narrow it down to the most
fundamental and least dependent project, of course. To close a project,
right-click on the project and choose Close Project.
Adding a second JRE...
It's sometimes useful to work in multiple JREs (i.e.: at different levels of
Java) in complex development. For instance, a set of projects that need to
continue to use Java 1.4 in addition to using the latest.
To add a second JRE to the Eclipse environment
Pull down menu
Window, choose Preferences.... Expand
Java, then click on Installed JREs. Use the Add
button to add a new one. In that dialog, Browse to the new JRE and
select it to add it to the list. Don't click in the checkbox to its left if you
don't want it to become the default JRE.
To specify the new JRE for a project
Right-click on the project, choose
Build PathsConfigure Build
Path... and click on the Libraries tab. Then remove the existing
JRE (that you don't want anymore) and click Add Library.... Click on
JRE System Library, then on the Next button. Click on the
Alernate JRE radio button and then the pop-up menu. Choose
jdk1.6.0_12 (for example). Click on Finish.
Fixing a bad library problem...
Imagine you've just done an
svn update, but the build is broken.
Someone changed from using one third-party library version (in other words, a
library not beloning to or build as a project) to a later one, but
Eclipse says in the Problem pane that it's still looking for the older
one. Everywhere else, ( Build Path->Configure Build
Path->Libraries->Web App Libraries), it says the new version of the
library. In the project gating this third-party library in (so each project
doesn't do it separately), it says the new version. In the file system, what
came down from svn says the later version.
Eclipse may have a bug here. What may fix it is to remove the
Library and readd it from the supplying project.
I observe that every time one of the other team members changes a JAR on the
RetainServer/web/WEB-INF/lib, this is the result on Linux and not
on Eclipse running under Windows. The solution is always to remove Web App
Libraries and use the Add Library wizard to add it all over
never add any JAR files by hand when you're trying to get
them from sibling projects in Eclipse. There's no end to trouble there.
Fixing a bad library problem (2)...
Imagine you've just done an
svn update, but the build is broken.
Someone replaced a third-party library with another, but Eclipse says in the
Problem view that it's still looking for the older name.
The problem is that Eclipse will not tell you why it is requiring a library
that no longer exists anywhere. The challenge is to find its record of that
library and expunge it.
Go to the projects reported in
Problems as missing the
required library (under the old name), right-click and choose Build
Paths, then Libraries tab and search for the JAR by its old name.
If you find it, simply click Remove.
That failing, the problem lies in the "furnishing" project (often
RetainServer in my case).
Second, it's a problem that Eclipse doesn't yet know of the new library, which
must exist. The first thing to expect is failure to commit on the part of your
colleague who renamed it. Ensure this is the case by updating then checking the
svn filesystem area.
Ultimately, it may be the old
Refresh versus relaunch Eclipse thing.
After failing to clear the problem with one of the two steps, try the other.
Fixing a bad library problem (3)...
Don't forget that if you're consuming a collective library from one project in
(one or more) others, you may have built that library wrong. Invoke the
ant script for the supplying project to clean, compile and copy the
JAR to the other projects. Then, commit the JAR in those projects requiring it.
This can happen easily if you're working in the supplying project and do the
ant build with your new stuff without updating and getting what
everyone else has done new in that project since last update. You're pushing a
new, incomplete or inaccurate JAR out to the other projects, even after update,
and then trying to build.
To avoid this trap, never commit JARs until you have done a full update and
build. If you're trying things out locally, don't update any other projects
(risking getting new stuff) until you've finished experimenting.
Granted, this explanation isn't as clear as it could be.
Fixing a bad library problem (4)...
If another on your project has added a new JAR to be consumed, it must be added
by hand in Eclipse. I don't understand why there would not be some way of
communicating to Eclipse that this has happened, but developers cooperating on
a project in Eclipse must still knit their projects together on an on-going
basis with no help from the IDE.
Build Path dialog, click on Libraries, then Add
JARS.... Find the new JAR and add it.
"The project was not built..."
...since its build path is incomplete. Cannot find the class file for
This little infuriating gem is caused by not having the right run-time. Just
because you have Java 5 in your
Java Compiler setting doesn't mean
that Build Paths->Libraries will follow.
JRE System Library [j2sdk1.4.2_18] or similar Java Runtime
Environment library and add the correct one to match your Java 5 set-up:
Add Library...->JRE System Library->Next->Alternate
JRE:-> then choose, for example,
Other, specific errors about
Enums will go away when you do this.
If you experience
Build tasks in Eclipse
It's possible to tell Eclipse to perform certain tasks each time it rebuilds a
project. For example, you might want to create an
To set up an
ant script to fire when Eclipse builds...
Right-click on the project and choose Properties.
Click on Builders.
Click on New....
Choose Ant Builder (if an ant script is what you
Give the builder a name, choose the path to the build file (i.e.: the
ant script), the base directory*, and arguments.
base directory refers to the project attribute in the ant
Obviously, if the task takes a long time, you have to rethink whether this is
really what you want to do or not.
Eclipse project folder set-up
Sun preconizes a particular blueprint when it comes to setting up web
application projects, which is to say the names and hierarchical relationships
of directories and files in the application. Specifically, the use of
web instead of WebContent (the Eclipse default) is advised. See
Guidelines, Patterns, and Code for End-to-End Java Applications
Good Eclipse add-ons...
There are some indispensable add-ons for Eclipse. There are two
emulators for use with the editor and a white-space remover.
The Eclipse icon nightmare...
At first glance, Eclipse icons appear mysterious and gaudy—over-decorated,
. Decoration is a
clever idea, but it's sometimes a little annoying. Here are some comments to
explain them. You can turn decoration on and off at
you can force decoration to use text instead of icons.
Yellow box at lower right
(Actually, it's a cylinder.) Means the file is under version control.
Question mark superimposed on icon
Means version control is active in the project, but the file itself is not under
version control nor is it flagged as "ignored" (i.e.: in
has an svn ignore property).
Black box with asterisk at lower right
Means the file or, if a directory, a file it dominates, hasn't been committed
to source-code control. Unfortunately, you will see this even if everything
that's supposed to be committed is committed. This is because when you add
files and otherwise modify the directories, they themselves are noted as
needing to be committed when that may be the last thing you want to do.
Red box at lower left
Means there is a compilation or validation error in the file or, if a
directory, a file it dominates. If this is on a JAR or other file you wouldn't
think should be in an error state, it might mean that the actual file it
represents in the filesystem underneath has gone missing.
Yellow triangle at upper left
Means there is a compilation or validation warning in the file or, if a
directory, a file it dominates.
Bouncing an Eclipse project
If you want to delete a project and start over, you must clean up the file
system or trying to recreate the project by the same name will get you an
error to the effect that a project of that name already exists.
The filesystem will be cleaned up if you delete the project sources too, but
that would not normally be the case. Instead, you keep the sources (presumably
on a path separate from the workspace, maybe a filesystem created by
svn, and you must clean up a number of configuration files from the
root of the project sources.
# rm .project
# rm .classpath
# rm -rf .settings
Seeing Eclipse editor annotations on Linux
I run openSuSE 10.3 using GNOME, using two Dell 24" wide-aspect monitors.
Whatever the reason, backgrounds such as this page uses are washed out and
scarcely visible. I've tried adjusting the contrast and brightness settings,
but nothing seems to work. Otherwise, I love the environment and my monitors.
What this affects mostly for me is my ability to see editor annotations, that
is, little rectangles in the margin at the right of the Editor Panel. While the
error annoations (meaning, "error at this line—click here") are always
perfectly visible, and the warning annotations are visible enough, others
aren't and some of them are actually very useful.
To change the color associated with a particular annotation, go to
Editors->Annotations. Select the invisible annotation,
Occurrences for instance, and then click the Color: control
to change it to something visible.
The right margin is formally called the
Overview ruler. It's the left
margin that is referred to as the Vertical ruler.
Advice on Eclipse build paths
Here's some advice on build paths off a forum.
There are three different classpaths to be aware of when you are running
Eclipse. First, Eclipse itself is a Java application, so it has a classpath;
mostly you don't care about this one, except to make sure you're not confusing
it with the others. Second, there is the classpath (referred to as the Java
Build Path) that is in effect when you compile your code. This affects what
classes are visible—for instance, if your code contains a reference to a
Foo, then there must be a project or a jar file containing
Fooon your project's build path. Third, there is the classpath that is
in effect when you run your application; this may contain additional or
different jars than the build path, because (for instance) your app might
compile against an interface ( IFoo) but reflectively load an
implementation class ( Foo) at runtime.
Often the runtime classpath is the same as the build path, but ultimately it's
controlled by the launch configuration. Sometimes the app itself (or code in
jars it references) may extend the classpath by loading libraries from specific
URLs or disk locations; that's why I've been emphasizing the need to make sure
where your app is running from, in case it is internally trying to dynamically
load a library with a relative pathname.
You probably want to
Run As... Java Application. Once you've done this
once, there will be a launch configuration; if you go to the dialog, you'll
notice there are a bunch of tabs. I'd suggest paying attention to the contents
of each of those tabs; in particular, the field that lets you set the directory
that the application will be launched in.
Fixing Eclipse in Ubuntu 9.10 Karmic Koala
Galileo won't run on this platform because of some bugs.
Read how to fix that.
Adding software to Eclipse
This example is from Galileo. The process has gotten much better over the
years. Once, you could usually expect it to fail and you'd have to install new
software components by hand dropping myriad JARs into the Eclipse
subdirectory (now named dropins). I have done many of these in recent
times (read: Galileo) and not had anything thing (or repository site) go
missing. If that weren't enough, I "dropped in" AnyEdit tools by hand
(something I've grown used to) only to find it supported by the update manager
Help -> Install New Software -> Work with: ->
All Available Sites.
2. Wait for list to populate; this can take a while.
3. Select something such as the Eclipse Data Tools Platform.
Next. Eclipse calculates requirements and dependencies. There
could be a lot of these.
Finish. Wait patiently a long time. Usually, bouncing Eclipse
will be required afterward.
SQL scripts in Eclipse
(Much more research to do on this.) It's possible to create an SQL script and
dump it under
WebContent for use in database maintenance, for example,
as the content kick-off.
CREATE TABLE Customers (
INSERT INTO Customers VALUES (1, 'William Dupont', '(652)488-9931',
'801 Oak Street', 'Eugene', 'Nebraska');
INSERT INTO Customers VALUES (2, 'Anna Keeney', '(716)834-8772',
'86 East Amherst Street', 'Buffalo', 'New York');
INSERT INTO Customers VALUES (20, 'Horace Celestin', '(914)843-6553',
'99423 Spruce Street', 'Ann Arbor', 'Michigan');
Doing this will cause Eclipse to create a control window across the top by
which you can point its effect to any database.
To execute the script, right-click on it and choose
Execute SQL Files.
LD_LIBRARY_PATH and java.library.path
When the application you're running (or debugging) from Eclipse needs to load
shared-object libraries (on Linux, duh), you need
up, but how? The trick is simply to set it up before launching Eclipse, which
you must do from the command line:
If your application (or its dependents) are clever enough to say right out that
they can't find a native shared-object library (JNI or JNI-dependent, etc.)
because it's not on the
java.library.path, you do not want to modify
what Eclipse thinks this path is.
Instead, determine which JAR contains the code that wants to load the JAR and
fix it in
Build Path. Do this:
Right-click on the project in Eclipse.
Build Path, then Configure Build Path, then
click the Libraries tab.
Find the library containing the JAR and expand it (or simply the JAR if
it was added as a mere JAR).
Expand the JAR by cliking the little triangle to its left.
Native library location: and then Edit. Fill in the path by hand or by browsing to the directory containing the
native shared-object in question.
OK, then OK.
Renaming despite project name in use
Once you've deleted an old project, possibly through refactoring, it may
persist in the workspace and Eclipse will not let you reuse it. You'll find a
record of this on the path:
You may simply delete the project you'll find there, a rather deep directory
structure, and then use the name again. Be sure this is what you want.
...a Visual Studio term, is "Content Assist" in Eclipse parlance.
No grammar constraints (in XML)
Here's how to get rid of those (harmless) "No grammar constraints (DTD or XML
schema)" warnings in Eclipse:
Pull down menu
Window -> Preferences, go to XML ->
XML Files -> Validation.
Change the setting of
Indicate when no grammar is specified
from Warning to Ignore.
Revalidate your project.
Uninstall plug-ins from Eclipse
In the Eclipse
Help menu, click About Eclipse. Click on
Installations Detail. In
Installed Software tab, click the plug-in to remove. Click the
Reconfiguring panes (views) in Eclipse
It's fairly easy to reconfigure the Eclipse workbench, relocate views, etc.
just by clicking on a tab, dragging and dropping it somewhere else. Dragging a
tab to an edge of an existing pane (view) will create a new pane on the
workbench. Experimentation will soon have you fixed up.
However, there is some geometry that's not so obvious and it involves creating
new pane at edges where there was none. Considerable experimentation is
sometimes needed. For example, I wanted to know how to transform this
arrangement of views in my
| 1 | 4 |
| 2 | 5 |
| 3 |
| 1 | 4, 5 |
| 2 | |
| 3 |
(For my terminology here, I'm going to call
panes where the (numbered)
views are located. E.g.: above, views 4 and 5 occupy the same pane. The UI
control for grabbing and dragging a view is the tab on which its name sits.)
The steps were easy enough, but they must be done in just the right order:
Grab/drag view 5 all the way to the right until you get the indicator icon
of an arrow pointing left. This will place 5 in its own pane on the right
end of the full length of the workbench, creating:
| 1 | 4 | 5 |
| 2 | |
| 3 | |
Grab/drag view 3 down until the indicator icon points up. This makes view
3 a full-width pane below views 2 and 5.
| 1 | 4 | 5 |
| 2 | |
| 3 |
Grab/drag view 4 on top of (into the same pane as) view 5 and resize the
4, 5 pane. This produces the result above (the second illustration).
Debug perspective, these panes were:
1 Debug (stack trace)
2 Source code view
Debug perspective layout is as below since I like lots of
room for source code and variables. I only dragged my JUnit view up
into the same pane as Variables and Outline. My monitor
dimensions are 1920×1080.
| 1 | 4, 5, 3 |
| 2 | |
| | |
| | |
How to forget defunct workspaces in Eclipse
If you've renamed an Eclipse workspace or otherwise no longer wish to be
bothered seeing it as a suggestion when you switch workspaces, do the
Under the Eclipse home subdirectory (where it's installed in your
filesystem), find the following file:
Edit the file, and look for the line that starts with: "RECENT_WORKSPACES".
The workspaces are separated by newlines (Linux, at least); delete
whichever workspace you no longer wish to appear in the drop-down menu.
Save the file.
The new Eclipse command line
Beginning in Helios, there's a great deal added to the Eclipse command line.
Eclipse workbench on Ubuntu
In recent Ubuntu releases, the default desktop theme has been "Ambiance"
(unless I'm mistaken). I don't mind this at all, however, when you're working
in the Eclipse workbench, it makes a number of things miserable. For example,
Javadoc isn't particularly readable nor are error strings when you hover over
the error. These are all a dark back ground with black text. (What's in a
yellow background below is dark in the default theme.)
I stumbled upon the "ClearLooks" theme which works much better. I admit that
the white background is a little stark and I may experiment with modifying
that (click the
Customize button), but certainly things are better
with it than with the default. To get this, do
System -> Preferences
-> Appearance and choose "ClearLooks".
In configuring Eclipse, you should be aware of the issue of the number of lines
your console view will remember. Encountering errors while running may create
so much output in the console that the culprit's information has been discarded
even if you attempt to pin the console or stop its scrolling.
This is easily fixed at the expense of memory. You have two choices. Either
guess how much memory you'll need and specify that (the default is 80K
characters) or count on clearing the console by hand as often as you like
(before each run) and disable limiting the console (by unchecking the
preference). See the illustration at the right, here. Reach this preference via
Window -> Preferences -> Run/Debug -> Console.
If you must eliminate the limits on console length, you may find yourself
adding memory to Eclipse in order to accommodate (and/or clearing the console
by hand). Do this thus in
NNN is the new maximum size in megabytes you wish to limit
Eclipse's ordinary heap to. See also
Project Explorer view of Dynamic Web Projects
JAX-WS, etc. and wonder why all that "crap" shows up in your
Explorer view. You can rid yourself of that easily via this view's context
menu—the little triangle on its toolbar (red arrow). By unchecking
Web Resources in the dialog below (blue checks), I can eliminate the
corresponding needless clutter from the hierarchy in this view (blue
Conveniently consuming the Eclipse Java formatter from the command
Yes! It is possible!. I found that this just used Eclipse's own format and not
mine unless the project was carefully set up. The project itself (and not just
the workspace properties) must be enabled for this. Also, you cannot use your
.xml file containing your formatting properties directly as the
argument to the -config option.
While you have to use settings down under an existing Eclipse project, the Java
file you're formatting doesn't need to have anything to do with that project
(or any other).
Choose the project whose formatting properties you intend to make use of.
Right-click on the project and choose Properties.
Expand the triangle next to Java Code Style.
Click Enable project specific settings.
Import your profile (if you like) and make it the Active profile.
Exit Eclipse (to ensure the settings are saved).
Fill in $WORKSPACE and $PROJECT in this script.
Execute this script with the file you wish to format as argument, or the
subdirectory whose files you wish to format.
/home/russ/dev/eclipse/eclipse -nosplash \
-application org.eclipse.jdt.core.JavaCodeFormatter -verbose \
-config $SETTINGS/org.eclipse.jdt.core.prefs \
Internal web application deployment
Eclipse deploys the web application you're developing internally for testing on
the path below.
contains tmp0, tmp1, etc. tmp0 as the first server you
create, for example, using Apache Tomcat v6.x while tmp1 is the second,
for example Apache Tomcat v7.0.
When you remove an application from a server (right-click server and choose
Add and Remove...), then clean it (right-click server and choose
Clean), Eclipse cleans up, mostly by deleting everything under
Of course, when you're ready to deploy your application formally to Tomcat on a
server, you must export it as a WAR file.
Language of workbench
Start Eclipse in US English (or any other language) with the following option
on the command line:
EclEmma: code coverage for Eclipse
Get this via
Help -> Install New Software from
. The update site path is
EclEmma http://update.eclemma.org/. If you care, call it EclEmma Java Code
This is not to be confused with
eclim is a project that integrates Vim with
Eclipse Indigo. You could get an error trying to install it if, like me, you
are using the default Java that comes with Ubuntu. You'll see this:
34 <target name="installer">
35 <formic:installer property="install.complete"
36 resources="resources.install" steps="resources.steps">
2011-08-17 08:39:02,852 INFO [org.formic.Installer] Running Installer.
2011-08-17 08:39:02,918 ERROR [ANT]
-Dhttp.proxyPort=8080 -jar eclim_1.7.1.jar jar:file:/home/russ/dev/indigo/eclim_1.7.1.jar!/installer.xml:36: java.lang.ExceptionInInitializerError
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Caused by: java.lang.ExceptionInInitializerError
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
... 16 more
Caused by: java.awt.HeadlessException
... 26 more
2011-08-17 08:39:02,930 DEBUG [ANT]
Total time: 0 seconds
2011-08-17 08:39:02,943 WARN [ANT] [echo] Installation canceled.
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.9) (6b20-1.9.9-0ubuntu1~10.10.2)
OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode)
Instead, use a real, Sun Java.
2011-08-17 09:06:45,403 INFO [org.formic.Installer] Running Installer.
-Dhttp.proxyPort=8080 -jar eclim_1.7.1.jar
To control how your Java code is formatted, go to
Preferences -> Java -> Code Style -> Formatter. There,
you'll probably see (because you've likely not changed it) that the
code formatter you're using is the default shipped with Eclipse.
If you click the
Edit button, you'll be able to change a lot
about how things are done. For instance, by working with the braces,
you can change from using Kernel Normal Form (KNF) to, say, Allman
indentation (as used by ANSI and ISO).
And you can dramatically affect the way other things are physically
formatted not only as you type in code, but also as a result of
selecting code and doing
Source -> Format in the editor.
You can save your changes under a different name by giving your new
format a name and clicking on the
Export... button. This saves
your changes in an XML file.
Conversely, when you create a new Eclipse workspace, you can go to
Window -> Preferences -> Java -> Code Style ->
Formatter and click the
Import... button, navigate to
that file you saved and thereby substitute it for Eclipse's default
Eclipse artifacts and portability
How to share projects between work and home, colleagues on the team,
Eclipse workspaces are not designed to be portable. Eclipse projects,
on the other hand, are so designed. The following are solutions:
Publish projects from a source code-control repository
(Subversion, Git, etc.) from which you can get the code and back
into which you can commit changes. See
Git. (By far, the best is Git.)
As long as your project is in a working state in your Eclipse
workspace (even if it's closed, that's okay), you can pick it up and
carry it as-is somewhere else.
Import by dropping it somewhere in your new filesystem, launch
Eclipse on the workspace you intend to use, ...
File -> Import... -> General ->
Existing Projects into Workspace -> Next
Browse to the root of the project, select it, click
OK, then, if it's a valid Eclipse project, you should see it checked in a
list of projects in this wizard.
Finish and you're there.
It's useful to understand the
meta files and
subdirectories that make an Eclipse project as opposed to a
garden-variety Java project. The metafiles (directories) for an
Eclipse project are:
.project (the one required for the steps above to work)
.settings (a subdirectory)
Besides the list above, more details can be had in this discussion:
Git on Eclipse (whether or not you choose to use Git).
A third option is to set up your
workspace on an external
filesystem such as a flash drive or external hard drive you carry
around, leaving it there permanently. You can open it from Eclipse
on any computer into which the drive is plugged, but, on Windows
at least, it must be mounted under the same drive letter on each
Eclipse Web Tools Project: the Context Root
If the context root of your web service, application, etc. isn't what you
want, you can change it.
By default, Eclipse names it after your project. Thus, in the URI to be
typed into the browser, you're using the project name. Maybe your project
name stinks, like "MyRestBasedService" or something. So, when you type in
the URL, it's
So, instead, you right-click the project (in
choose Properties, then Web Project Settings, enter
something else (cool) for Context root:, like "zippity-doo-dah".
Then, your URI becomes:
Where does the coolness happen?
As frequently happens, Eclipse performs the magic, but leaves you clueless
as to where it happens and you also wonder if it will continue to happen
when you generate the WAR file.
In this case, the magic appears to happen in a file on the path
But, this file isn't present in the WAR file! I'm still trying to figure out
how this is supposed to happen. It appears that you simply have to export
the WAR file under the desired name (instead of the project name). Also, you
path="desired-name" ... > since this attribute would be ignored
without also being specified in
server.xml, a file you should never
modify nor count on modifying.
In summary, Eclipse's web project settings work-around isn't too useful
except in development to avoid subjecting yourself to your long and ugly
project name. Later, you must also carefully avoid the default presented
when you export the WAR file (because the default is the long and ugly
was one of the clearest
notes I found on this topic.
build.xml in Eclipse
From an existing Eclipse project, you can ask Eclipse to generate a
build.xml (or its contents and ask it to name it
something else). Then, from that ant script, Eclipse will
generate the project all over.
This is interesting because you might collaborate on a project with
others, committing your work to Subversion, CVS, Git, etc. It's pretty
straightforward. In order to make this work, here's what I had to do:
build.xml file by right-clicking on project,
Ant Buildfiles ->
select project by name ->
name build.xml ->
Copy off the whole project somewhere (into Subversion, etc.). This
should not include product subdirectories such as
bin, etc. Also, you don't need .classpath,
.project or .settings, although missing
.settings might be why a Dynamic Web Project done this way
will degenerate into a simple Java Project.
Now, pretend you're getting this new project...
Copy the project to the workspace as-is. (Note: this is not how
you would do it if you were creating a project directly from
existing sources rather than from
Launch Eclipse and open the workspace where the project was copied
(it will not show up in Eclipse yet).
Java Project from Existing Ant Buildfile.
This should create and open the project.
Right-click the project (in
Project or Package
Explorer) and choose Build Path -> Configure Build
Path... -> Libraries.
JRE_LIB (obsolete—not sure why Eclipse does
this, then tells you it's obsolete), click Add Library
and add the JRE System Library set up for your
You'll do similarly for JUnit if you're using that.
This should make the project usable. You can open
in the Ant view and/or simply allow Eclipse to build
Not covered here...
How to establish a proper
build.xml doing all the "real" things
you'd set it up to do while accomplishing what's recounted above. The
generated build.xml, which you may have named something else,
tells you not to modify it since you could end up regenerating it
Part of the answer is to maintain a separate build file with additional
stuff it in; you could call it from
<antcall target="myotherone.xml" >.
Another idea might be simply to maintain separate build files, trying
to cut down on duplication of content. The top of the generated one
contains the real contribution in the form of documenting what
third-party JARs you're using. That's really why you'd regenerate,
especially if you weren't too
ant-savvy and wanted Eclipse to
do this for you. But then, you'd likely not have addition stuff anyway,
so there wouldn't be a conflict.
A Dynamic Web Project in Eclipse
sans project files
This is about how you might share Eclipse Dynamic Web Projects in
Eclipse with teammates via a source-code control/version system such as
CVS, Subversion, Git, etc. Imagine you're working on a project and a
new guy starts on the team. He needs to get the project set up in
Project files in Eclipse include
The problem with keeping these under source-code control is that they
can have user-specific information, including full filesystem paths on
the development host, in particular,
method described in the next section up on
this page, which overcomes many of the problems, fails in that it will
never create a Dynamic Web Project—only a simple Java Project in
This is also discussed at some length in an article entitled,
. Read the rest of this note, however,
before drawing any conclusions.
Git-Eclipse Peculiarities One approach
You can keep
.project under a different name, .project.sample,
and keep .classpath and .settings. This is what's described in
the article on Git and Eclipse referred to above. It allows you to clone
(check out) a project nearly ready to go. There is very little to do to get
it running in Eclipse.
The disadvantage to this is that a colleague may associate Javadoc or
source code with one of the JARs in the project. This impacts
.classpath by recording a full filesystem path in it. Any
version control system will ask to commit this change. Other colleagues
end up with useless, foreign path references in their project.
A different approach is to establish the standard procedure of creating
the new project as
File -> New -> Other -> Web ->
Dynamic Web Project. When the wizard comes up, type in the name,
but change the
Project location to wherever the project was
checked out (updated) from version control.
The result is a partially set-up project. There will be many errors
corresponding to missing JARs.
Solve the JAR problem by keeping the JARs in a subdirectory of the
project that gets committed each time JARs are added to or replaced in
that subdirectory. Creating a new project necessitates using
Path to include all of the JARs (and establishing them in the
Deployment Assembly too).
This is tedious, but if you limit the libraries you put in the project
to only those that are needed (and required), at least it's not
guesswork when it's done.
Something else that makes this
a lot less tedious is not insisting on
placing JAR files under subdirectory names that describe their origin as my
example shows. In Build Path -> Libraries, you can click and
shift select the lot all at once if they're just dumped together under the
...of all of this is that the second method introduces some tedium into the
process, but anyone who associates source code or Javadoc with a JAR for
debugging and other purposes isn't inconvenienced (i.e.: the association
doesn't disappear) until that JAR changes (newer version, removed as no
longer necessary, etc.). Best yet, associating source code or Javadoc will
.classpath, but as this file isn't committed, it doesn't
inconvenience anyone else either.
Definitive approach for sharing Eclipse projects
Based on some of the sections on this page, in particular the last two, the
following is a how-to.
Creating a project
Create a project of any sort in Eclipse and develop it to the point at
which you're ready to share it.
clean or cleanall target in build.xml
that removes all development (compilation) projects. This means
.class files and other intermediate targets that are built as
part of the development process, i.e.: not source files, property
files, or "irreplaceable" resources such as JARs.
Ensure all (third-party) JARs consumed reside under subdirectory
lib in the project. Sometimes, web application developers put
these under WebContent/WEB-INF/lib. Doing that is a bit of an
over-kill and it may confuse your new colleague to have to go find
them in a deeper-than-necessary path.
Commit the subdirectories and source files described above in your
source code/version-control system. Do not commit, in particular,
.classpath file, .project file or the .settings
subdirectory. In fact, add these to your version-control system's
method to ignore them ( .cvsignore, .gitignore, etc.).
Consuming a project
Check out, clone or update the project from version control into its
own, suitably named subdirectory in the filesystem of your development
not locate this subdirectory in any Eclipse workspace.
Launch Eclipse on the appropriate workspace.
Create a new
Java Project, Dynamic Web Project or
other using the usual wizard, but take care to dictate to it (it's
about the second thing you do) that the sources are located in another
subdirectory. Finish answering questions in the wizard as usual.
Once the project is created, right-click its name in the
Project/ Package Explorer and choose Build
Path to add the libraries residing under the lib
subdirectory. Add them also to the Deployment Assembly (new
name beginning with Helios).
It's not possible to share workspaces, but you might get away with
sharing the same project. Even via Dropbox. Here's how.
Create the project on one computer, get it more or less how you'd
like it (i.e.: simple
Java Project, Dynamic Web
Project, etc. as created by Eclipse). You'll be able to add or
delete source code later, but the project should exist enough for
Eclipse to recognize it.
Copy the important parts of the project to your dropbox location.
From inside Eclipse, discard the original project including source
files (it prompts you to be cautious about this).
Create a new project in the same (or a different) workspace. When
the wizard comes up, you can name it what you want, but tell it to get
the source files from another location and not to copy them into the
workspace. Eclipse will consume the project from dropbox, I think.
Repeat this from your other computer from its Eclipse using,
obviously, its own workspace.
The changes you make from one computer will be reflected in the
other. You will have to right-click your project and choose Refresh
when you change computers.
All third-party libraries (JARs) must be copied to a path inside
your project. Otherwise, your
.classpath file will acquire full
filesystem pathnames which will not hold true on both computers.
Another way of causing this problem is to associate Javadoc or source
code with any of those third-party JARs (let's say you wanted Javadoc
for hibernate3.jar, you're screwed as soon as you do that).
I have not done this; there may be a hole in what I'm telling you or,
you may accidentally do something that destroys your ability to do it
this way (as suggested by #7).
It's better to use a version-control system for this (and, obviously,
there are other benefits too).
Note: I know what Dropbox is and have used it very briefly once. I
don't know all the peculiarities of it. So, I may be making unwarranted
assumptions on doing this.
Enabling Java assertions...
Enabling Java assertions.
Start-up dialog workspace names
You've killed a few workspaces, but they keep showing up in Eclipse's
workspace start-up dialog (or when you switch workspaces via
-> Switch Workspace) and you want to forget them.
These are kept in a configuration file on the path
in a variable, <eclipse>/configuration/.settings/org.eclipse.ui.ide.prefs RECENT_WORKSPACES.
But there is a right way to maintain these. Go to
Preferences -> General -> Startup and Shutdown ->
Missing listener when Tomcat starts
I'm writing this note because it's just a nasty problem that happens
all the time in a fakey development/debugging environment when the
slightest thing can go wrong in deployment.
You launch Tomcat in Eclipse to begin testing your web application, but
the listener fails to come up. Attempting to hit your server gives you
an HTTP Status 404 The requested resource is not available. You squint
hard first at your deployment descriptor (
web.xml) contents, at
your ReST or other wiring, and at your URI: there's nothing wrong with
Take a look at what's come out in the Console view, something like:
SEVERE: Error configuring application listener of class
The solution, in this case, was to refresh everything and do a clean
build. However, ...
if the listener comes out of a JAR library you're consuming, this is very
common, perhaps more so than having it come out of your own code. It might
be coming from Spring, for instance. Take a look at this discussion, done as
well as I could do it from
VPN freeze-up and proxy
When using Eclipse on a box working through a VPN, you might encounter
freeze-ups or slowness. Sometimes setting proxy information can fix
this by isolating Eclipse from running any background processes through
the VPN instead of on the box itself.
Window -> Preferences. Type "proxy" into the
Search box. Add stuff from
/etc/hosts such as shown here:
.classpath file lists all the JARs that support your project
and performs some other tasks such as supply links to Javadoc for those JARs
that you set up if in coding you wish to see more usefully the interfaces
therein or, when debugging, sources if you wish to step debug down inside them.
The JARs are thereby considered to be "on your class path" for the purpose of
compilation, but as noted above, also for the Eclipse Java editor's use
Content Assist—Eclipse's version of what
Visual Studio calls Intellisense and for the debugger's use.
When you are in
Build Path -> Configure Build Path ->
Libraries (tab) and making changes, Eclipse needs write access to this
You're led to think that this can be placed into your Java code as if an
annotation, but in fact it's not. You must use it commented out (and it works
as long as you have
Preferences -> Java -> Code Style ->
Formatter -> Edit -> Off/On Tags -> Enable Off/On tags
* This method will perform...
* @param str is the string on which...
* @return the new string.
...or, in Java code...
[nothing here will get reformatted by Eclipse...]
for( String a Title : DvdCreateTestTitles. titlenames )
[...until beginning here again]
Beginning with Eclipse Indigo, I use
Help -> Eclipse Marketplace... to
install plug-ins I want. If you're behind a firewall and need a proxy, this might
simply not work until you tell Eclipse this is what you're doing. Go to
Window -> Preferences -> General -> Network Connections:
Only then can you use this facility.
Solution to adding Eclipse to the Unity task bar
Here's how to get Eclipse with its icon into the Unity task bar.
Download Eclipse first.
Explode to favorite place; you must know the path for the next step.
Create a file,
opt-eclipse.desktop, not in the ~/Desktop
subdirectory, but in another * with the contents below.
Launch the (Nautilus) file explorer and open the subdirectory where you put
the short-cut file.
If the short-cut does not have the proper icon, you may need to
Right-click it and choose
Properties. Click the icon in the properties and navigate to the Eclipse
subdirectory to find
Drag this short-cut into the Unity task bar. You can arrange the order of
icons in the Unity task bar by clicking and dragging the icon out of the
bar, then back to the bar in the place you want. If you attempt to click
and drag up or down within the bar, it will move the whole bar instead.
Comment=Eclipse Integrated Development Environment
* Anything you put into ~/Desktop will show up on the
desktop which is probably not what you want. You cannot "add, then delete
it" since the short-cut is a permanent configuration Unity uses.
If you add a new
ant task, in the Ant view in Eclipse,
you may get to see something like this instead of being able to see and
execute the ant targets:
project-name <taskdef class package-name. task-name cannot be found using the classloader \
AntClassLoader[/home/ user-name/ path/eclipse/plugins/org.apache.ant_1.8...
(A specific example is adding a
findbugs target and seeing:)
MyApp <taskdef class edu.umd.cd.findbugs.anttask.FindBugsTask cannot be found using the classloader \
The solution may be the following:
Windows -> Preferences.
Ant -> Runtime.
Ant Home Entries (Default) -> Add JARs.... (this will go to a local path) Navigate to and add the JAR.
Ant view, kill the project's build.xml and go get it again.
This should fix the problem.
Unsucking Eclipse Juno...
I happen to agree that the Juno user experience leaves just about everything
to be desired as compared to former versions of Eclipse. This is why I refuse
to move up from Indigo.
is a post by someone
who feels the same. While it doesn't leave everything perfect, there's some
new ugliness, it makes the thing less cotton candyish and is a good option
(though not nearly enough to push me forward yet).
Change Eclipse Juno UI to match Eclipse Indigo
Just in case that post goes missing someday, here are the steps.
Locate your Eclipse Juno installation; mine is
Below it, find the
plugins subdirectory. Then type
cd org.eclipse.platform_4.2 and press Tab
to complete. You should arrive at a destination that looks something
css subdirectory so that it can't be used:
mv css css.old The next time you launch Juno, all the fluff will disappear.
If you wish to go back to Netherland, simply restore this subdirectory to
its original name.
Customizing the Project Explorer view
Especially when developing a Dynamic Web Project, the Package Explorer view
is real junky. I turn most of it off this way:
Look for and click a downward-pointing triangle toward the right end of
the pane menu bar containing the Project Explorer view.
Customize View.... Click the
Content tab. Unclick everything except the following:
Enhanced Java Rendering for Web
From this point on, your
src and test subdirectories are
still obfuscated by Java Resources, but that's the worst of it.
Also, a lot of fluff that I don't ever use is gone, which cleans up the
view a lot.
On Eclipse projects and non-Eclipse technology
This is an excerpt from an answer I gave in the Eclipse newcomers' forum
one day. The question was about Eclipse download packages, Python
versus Java development, how to develop on different hosts and the author
was confused by the use of "package".
I have no experience with PyDev. At
one is told to direct questions to
Eclipse isn't responsible for the support of myriad projects and
technologies, the best example of which are the Android Development Tools
(ADT), that have chosen to implement their IDE using Eclipse. It's very
confusing and difficult for newcomers to know when to direct questions to
this forum and when to find another.
Eclipse downloads are best chosen, in my opinion, by starting with the one
closest to what you ultimately want to do. In my case this would be
Eclipse IDE for Java EE Developers rather than choosing Classic,
then adding a whole bunch of plug-ins to reach the point I want. But in
theory, there's nothing lost by starting low and building high, or starting
with Java and adding C/C++, or PyDev, or ADT, etc.
When you create a new project in Eclipse, the new project wizards typically
give you the option of defaulting to create it in the current workspace. If
you create it from existing source or by importing an already existing
Eclipse project, you're given the opportunity to move (or copy) the sources
over into the workspace. (Do not copy project sources by hand over into the
workspace, let Eclipse do it.) Again, I don't know how PyDev works, but I
do know about Java and Java/ADT projects,
If you wish to spread your project development time across more than one
host, you should consider a version-control system like Git. If you cannot
or do not want to set that up on your own server, you can get free space
with Atlassian Bitbucket
—which does not charge) or GitHub
—which does not charge for open/publicly visible projects). I cannot
recommend this too strongly. It will involve learning (yet another)
technology, but this one is well worth your time. On version control: the
world is moving away from CVS and Subversion toward Git (there are others
You cannot transport your Eclipse workspace from one machine to another;
workspaces are filesystem-dependent. Projects are portable, however, but
projects live in a workspace, so short of recreating your project by import
each time you change machines, or carefully clobbering your project with
changed content, which is painful, Git is your best route.
A project is what you're calling a package in your question here.
In Java, packages are a division of your project. Typically, you have more
than one package making up a project.
Window -> Show view ->
Project Explorer is a different way to view what you're doing. It
might make more sense to you.
Window -> Show view ->
Navigator is a filesystem-oriented way to see the same thing. None
of this will probably rehabilitate your Python project. If things don't
work out, you'll have to resort to support from the PyDev community.
Eclipse: Source not found
When debugging, or attempting to access source in the editor, you stumble
upon a message, "Source not found." There's a button,
that you can click. Do this.
If the source is in your workspace (unlikely), then you can click the
If in a file external to your workspace, that is, you have the source
somewhere, you can click
The most common is to have a folder of external source that you want to
use as a resource. Click
External Folder.... Navigate to the
com parent directory to that source, select it and click
OK, then again in the Source Attachment Configuration
dialog, click OK.