Juno Again

Trying my Eclipse Juno again. What caused this adventurousness is that I discovered that my old Eclipse didn't support 'Refresh on Access' (which is when a file has changed on disk, and not in the editor, so you can simply update the editor copy to match the version on disk).

I have the following message of hope: if you switch Project Explorer's presentation from 'Flat' to 'Hierarchical', and you get beach-balled, don't kill it; instead keep your hopes up, go write a blog post, get some coffe, tell Juno to text you when it's done. It can take a few minutes.

Subclipse Purple/Blue Cylinder: Normal, Copied...and Switched

New Subclipse stuff I didn't know I didn't want to know: purple cylinder icon. Using the properties dialog, and clicking the 'Subversion' label, this seems to mean "Status: normal, switched, copied"; instead of what the yellow cylinder means: "Status: normal, copied". Now how did this happen? I just tried to clone a folder as usual. The files in that folder has these purple cylinders.

(And why does it show a spinning beachball just to pop up that Properties dialog? Does it fetch all the data before popping up the dialog? WT*?)

Googling for purple cylinder...I found this link, although it is referred to as 'blue'.

http://svn.haxx.se/subusers/archive-2007-06/0052.shtml

The meaning of the blue is simple - the affected resources is "switched",
i.e. the working copy is mixed and the blue file is from different branch
than its parent directory. 

So, clearly something went wrong during the clone (actually, I use 'rename' to clone). I remember an error popup (there is an error popup I'd say 30-50% of the time with Subclipse), but then the renamed/cloned folder showed up anyway, as it does in cases. 

Simple solution would be to delete and revert the children, right? Tried it, the purple/blue cylinders show up again! After a revert, how can the working copy be mixed?!?

Deleted the whole folder, reverted, still mixed. WT*? 

Do I dare commit it? First, let's make a screenshot. 

Now then. 

Ah, could commit, they are not changed. Odd. 

Ok, this is fun: just made a 'Synchronize' on the 'site' folder, and now there's question marks instead! Well, that makes a lot more sense; either the revert or something else fixed this, but Subclipse failed to notice. 

Tried to rename the folder into _lib again. As usual: 

But this time, I get the folder with blue cylinder too!

Let's see if they're really what they say they are...

Nope, this time, brining the Synchronize to bear didn't change the looks. And nothing else I tried.
Errors. Cleanup menu item gone.

So, this means Terminal. This is why I have files called "shell_in_this_dir.command" containing this code in strategic positions in the source tree:

cd $(dirname $0)
$SHELL 

And then "svn cleanup". Refresh, Subclipse icons back to question marks again.

--

Anyway, I think the unerlying problem here is that I am doing operations that svn or Subclipse does not support: making these changes inside a cloned folder. I'll have to commit the clone first.

--

Yes, worked better. So the point of this article... reduces to:

(*) screenshots of blue icons.
(*) always commit clones before starting moving folders around in them.


No wonder the revision numbers keep rising so fast, when you have to commit all the time to feel and/or be safe.

Tilded Target Folder

I think I finally grokked the following unexpected interaction between svn and Maven/Eclipse Workspace Resolution feature. First, a bash illustration:

bash-3.2$ svn stat
?       .classpath
?       .project
?       .settings
~       target

See the "~       target"? That is what I believe was the cause of a mysterious build problem. (The tilde is probably due to me changing from "svn:ignore *" inside target dir, to "svn:ignore target", after discovering that the former doesn't work well. Maybe more in other blog post.)

The symptom of the problem I've been having for a few hours can be demonstrated and summarized like this: 

No problem building in maven. 

Lots of errors in red in Eclipse, as if a Maven dependency is not resolved somehow. 

Turning off Workspace Resolution makes the errors go away. 

Conclusion: something is up with Workspace Resolution. 

Theory: 1) there is something wrong with the target directory; 2) workspace resolution uses a project's target directory for dependencies (perhaps just points to $dependee_project/target/classes on the classpath). 

But that seems crazy. Surely the build should care how SVN flags the target directory? But the coincidence is a bit too strong to ignore. 

--

Turns out that Eclipse clean + build fixed it. Don't know why.

But the target folder had a severe SVN weirdness...


Doing "svn update target" failed bizarrely: "svn: Unable to lock 'src'". Huh?

Finally it got unstuck, inside Eclipse: 

    E   .../target

    Updated to revision 23696.

    ===== File Statistics: =====

    Existing: 1

I've never seen this 'E', existing, before. I must've managed to set a svn:ignore on it, but it existed in the repo. Or something.

E-Maven Update Project Configuration Problem

Eclipse/Maven "Update Project Configuration" problem: "can't update ... because '.project' is not in sync with file system." The "not in sync with file system" usually means that Refresh helps, but not so in this case. Turns out that Eclipse somehow thought I had unsaved changes; saved, and that seems to have solved the problem for Eclipse.

Maven Idea

Here's a radical idea to simplify the usage of Maven, especially when considering Eclipse cooperation.

How about not using test scope, but instead create a 'project-test' for every 'project'? Some advantages:

The pom.xml files will be cleaner.

The single-classpath Eclipse will not be a problem any more.

One will not have to think about the interaction between the declared dependency scope and the importing dependency scope. (Unfortunately, the 'provided' scope is still needed, but that is pretty simple.)

If one would want to import test code into another project, no need to fiddle with '-tests' attachment.

One can build with-out tests, which is quicker, and could likely allow tests to be run quicker, ironically, because of parallel execution. Or you could collect all tests before running them.

The odd thing is that maven wasn't designed this way from the start. It would have dispensed with a lot of extra complexity. Etcetera.

Maven Source Properties That Don't Work

When I do 'Maven > Update Project Configuration' in Eclipse, this seems not to work: 

    <properties>

        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

        <project.build.source>1.6</project.build.source>

        <project.build.target>1.6</project.build.target>

    </properties>

    

But this seems to work: 

    <build>

        <plugins>

            <plugin>

                <artifactId>maven-compiler-plugin</artifactId>

                <configuration>

                    <source>1.6</source>

                    <target>1.6</target>

                </configuration>

            </plugin>

     ...

    

Too bad, since the first xml is neater. 

---

PS. One sign that there is some mix-up with 1.5/1.6, is that the @Override annotation acts up.

Eclipse Is Back

That's a new one, served fresh in a modal popup close to my face: 

An internal error occurred during: "Launching TestTemplate".
java.lang.NullPointerException

Restart, clean, refresh, nothing helped so far. Is it something in the code itself? Weird. Only other symptoms: 'misplaced' breakpoint (due to quick edit somehow) can't be removed, and no new breakpoints can be added anywhere.

Getting new issues from Eclipse is getting old.

---

(Expletive deleted), this is annoying. Deleted various project files. Open/Closed project, committed all uncommitted, tried the trick "Disable-Enable Dependencies" described in earlier posts, et-f5g-cetera. No go.

---

Found a clue: after deleting the contents of target/, the classes/ and test-classes/ folders are recreated, but they don't get populated. Is it my deletion of the .settings project files, or is it the original problem?

...no, the .settings/ files are actually back (org.eclipse.jdt.core.prefs, org.maven.ide.eclipse.prefs).

---

Two more clues: the process roster has a large number of zombie-like processes in it. When they are terminated, they take a long time, then both die, and a dialog "Termination Failed" is shown.

And shifting to 'Run' instead of 'Debug As..' I get this:

Exception in thread "main" java.lang.NoClassDefFoundError: org/pub/TemplateTest
Caused by: java.lang.ClassNotFoundException: org.pub.TemplateTest
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)

Yeah, if the build isn't working, that's not totally weird.

It's interesting that this causes the debugger to not be able to connect to the child process! Is it that it fails so fast, that there's no time? Or does it depend on a working classpath? Would be interesting to know...

---

Solution: rename the project. Don't ask me why it works. My guess is that some cache or setting is associated with the project name.

Repugnant shit...

Eclipse Drag-And-Drop Idea

Just realized that the serious usability problems with drag-and-drop in Eclipse has a surprisingly obvious solution!

If you have a large number of files and folders in your project source trees, drag-and-drop is a serious pain in the rear, because you may have to wait for scrolling, which is slow and a bit finicky to control. And if you over-scroll, you have to move the drag to the other end of the scrolled pane. Etcetera. And even remembering the target is difficult.

For moves within the same 'classpath entry' (e.g. src/main/java) there is at least the alternative of typing a new package name -- with auto-completion assisting you -- and then using the quick fix 'move', but for moves between projects, for instance, the problem remains.

However, I just got this really simple and in-hindsight-ly obvious idea: why not open a second 'Navigator' view? Turns out I don't know how to do that. But there is a an almost-as-good solution: the possibility to drag-and-drop into panes of other kinds! At least into the 'Project Explorer', just tried it.

Well, one simple trick closer to peaceful cooperation with Eclipse. Many annoyances remain to be worked around.

Fix Maven Source Version Having No Effect

In a recent article at http://impossible-is-development.blogspot.com/2012/11/basic-maven-project-build-fix-tip.html, I wrote about a trick to get the .classpath file to reflect the src/main/java etcetera build structure. This trick actually helps in another not-to-uncommon situation: unsyncronized source versions.

If you create a new pom.xml, it may happen that there is no Java versions information given. The version can be given in two ways; via some xml using a 'properties' tag, or via more xml. 

Plugin config: 

<build>

<plugins>

<plugin>

maven-compiler-plugin

<configuration>

<source>1.6</source>

<target>1.6</target>

</configuration>

</plugin></plugins>

Sorry about the formatting. (Doesn't the Blogger editor suck something awful for quotes and code? ...hmm...can one blog on Github?)

<project.build.source>1.6</project.build.source> <project.build.target>1.6</project.build.target>

(Again, sorry about the formatting.)

Now; if you add this to an existing pom.xml, Eclipse may fail to take note of this change automatically. Maybe it never takes note. In any case, the same solution applies here as in the earlier blog post: just disable and enable dependency management.

Missing Quick Fix In Package-Info File

Creating a package-info.java is useless without the package declaration. But strangely, in Eclipse, you get no error if you leave the file empty. And the usual Quick Fix to mend the package declaration is absent. Odd.

But the solution is simple: just add a "class X {}". It's legal syntax, and when that class declaration is present, you'll get that helpful Quick Fix. You can then remove the class if you want -- after you invoke the 'Add Package Declaration' Quick Fix.

Basic Maven Project Build Fix Tip

Sometimes, in Eclipse, a maven project will not be properly set up. For instance, when you create a maven project by creating a pom.xml file inside a folder. This can be seen by inspecting the '.classpath' file -- it will contain only these three items (or similar):

<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5"/> 

<classpathentry kind="con" path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/> 

<classpathentry kind="output" path="target/classes"/>

Then, what you do is this: simply "Disable Dependency Management" and then "Enable Dependency Management" from the "Maven" menu in the contextual menu from the project. If you keep the ".classpath" file open, you'll be able to see the what happens.

In the 'Disable' step, the Maven entry disappears:

<classpathentry kind="con" path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/>

Then, in the 'Enable' step, the entries which enable the build appears:

kind="src" output="target/classes" path="src/main/java"> 

<classpathentry kind="src" output="target/test-classes" path="src/test/java">

 along with the 'MAVEN2_CLASSPATH_CONTAINER' thing mentioned above. Done!

--

Today I discovered that the above maneuver is in fact useful to handle another problem involving mis-synchronization between ".classpath" and the "pom.xml" file. Article forthcoming.

4 Min

See if I can make it while downloading another Eclipse download...

Apparently, there is an Eclipse download with Maven built in. Name ends in "for Java".

That's good; I didn't know. Installing via the 'Software Update' always irritates me, with first adding a url to a download site, which you can't find via the GUI (I think?), and which is hard to google up anyway.

--

No, download still downloading. What can I add in 1:22, ..., 1:14, ..., never mind.

Double Period Brings Completion

Context: Eclipse JS Editor. 

The "|" in below examples is the caret. Cmd-Space in this situation: 

list_elem.|

does not bring up any proposals. But in this situation: 

list_elem..|

...useful proposals are shown! Wt*?

Maven Dependency Type 'jar' Not Added Automatically

After a half-hour or so of not understanding why some Java imports didn't work.

I noticed that the letters 'jar' was missing from the dependency listing.

I had tried using the Eclipse maven assist GUI to add a dependency.

And apparently the it's not enough to just search for the dependency and say OK when selected.

Which is Odd because I've done it a few times and it's worked fine.

All these little things.

All. These. Little. Things.

That.

Add.

Up.

To.

A.

Large Amount Of Wasted Life And Time And Money.

Yesterday Eclipse, Today Eclipse; Extra Character

Just had a weird error, where it looked like Eclipse thought that a Java file was at the source root level, aka default package, and Quick Fix wanted to remove the package declaration. "Oh god, not another one" would be a nice description of the sentiment.

Thought it was another Svn problem, so I opened the Properties dialog, to find out what could be found out. Today is a much better day than yesterday, so it had nothing to do with Svn. The end of the path looked like this:

api/pub/annot%C2%A8/ApiPath.java

So then I looked in the GUI, and sure enough, there is some trema-looking extra character there that I didn't see, that I must've added inadvertently.

But I don't know why it made Eclipse think wrong about the packages.

This might mean that package names aren't allowed to be any unicode? If so, that's an unfortunate irregularity: other Java identifiers can be in unicode. But it's probably just that diacriticals are not allowed as characters in their own, which is very sensible. The Character.isJavaIdentifierPart method tells which characters are allowed, which is what I learned from this incident.

--

Today's UTF-8 character is: http://en.wikipedia.org/wiki/Diaeresis_(diacritic).

And as you can see at  http://www.fileformat.info/info/unicode/char/a8/index.htm, this character cannot be part of a Java identifier; the Character.isJavaIdentifierPart is false.

IntelliJ And Eclipse (Mis)Feature

Trying IntelliJ 11 CE (Community Edition, Free or something).

Partial word search is just as wrong as in Eclipse: no reordered matching, no initial wildcard by default.

Amazing. Does such a vast majority of all developers remember what their names start with? And the ordering of the words of their RatherLongMultiWordCamelCaseIdentifiers?

Weird Eclipse Open Resource Matching

In Eclipse's Open Resource dialog, "*TEU", or even "*TEvalU" should match 'DjangoTemplateEvalUtil.java', should it not? Well it does not. My little theory is that the 'E' is used up by the 'e' in 'Template'. Which must be seen as a bug.

However, "DTEU" matches on the subword initial capitals. I'd say 'go figure', but hey. 

Can't trust anything these days :). It looks minor, but it's really a pretty serious problem, if you rely on your names to be able to find stuff. And not wasting time trying to figure out why something that you feel should be found. If it matches "DTEU", you're expecting it to match the looser (loser) pattern "*TEU".

Eclipse Great Feature: Move Updating References And Commit

Some of the lists in Eclipse allow for bulk operations on them. Find references is one of them.

This allows for the following extremely useful procedure to work: you move and/or rename your Java type definition. This causes uncommitted edits. If you're a mis-en-place, clean, only-does-one-thing-at-a-time operator, you'll just do a commit all to commit these changes. But, if you're like me, you usually discover out-of-place types (classes, interfaces) while working on something else. Anyhow; there may for many possible reasons be uncommitted changes that you're not ready to commit. This makes it difficult to separate the files to commit from the files to keep 'dirty' (let's not consider the case where the same file contains both kinds of changes right now).

That's where for move refactoring operations, the 'Find References' feature will (may?) work fine: the list of found references seems to allow bulk commit. Select all the files you want, and then pop up (left mouse button click or Ctrl-click) the contextual menu. Team > Commit, and you will have your referencing occurrences committed.

This leaves the moved definition file changes, unfortunately. So of course the commit-all is really preferable, if appropriate for your situation.

It would be great if Eclipse would give you an option like: "Would you like to commit all the changes caused by your last action, File moved?".

And if it'd separate relevant changes from irrelevant changes in the same file, that'd be magic.

And if it'd allow selecting actions to commit, from a list of recent actions, that'd be more magic.

Anyway, there is actually a simple two-thirds-of-the-value solution for this: list files in "mtime" (last changed time) order, and allow selecting a range to commit. (Deleted files will be an wrinkle, though.)

I have some more tips on moving files in Eclipse, but they'll have to wait.

So that's that. Consider this a first in a (potential, no promises) series of Eclipse workflow posts. I'd like to know if there are already such things written, so please comment if you know.

Eclipse Call Graph (You Can Sometimes Get What You Want)

Just stumbled upon a blog post. The usual list of the usual tricks. All the usual shortcuts mentioned, refactoring, Find Type, etcetera. Yawn, seen it, used it.

But at the end of the section I was reading, the Ctrl-Alt-H key combination in Eclipse was mentioned, which shows a static Call Graph (a tree really). Yes!

The thing is that I've been wanting this and been looking for this, but not been able to find it, and given up. In my Eclipse, it's not shown in the context menu, oddly. That's some really bad 'discoverability', grumble, grumble. So I thats why I make a blog post simply to repeat the message. 

Thanks Cygni blogger, whose name I've forgotten already! (Not in English: http://cygni.se/2007/11/27/eclipse-tips-och-tricks/.) 

Juno II, The Brightening Up

Back in Eclipse Juno, incidentally, had to use a new Eclipse due to a mysterious error with a cryptography module not getting found. Stopped using it a couple months ago because it seemed to have small bugs. Possibly one of them was that Subclipse seemed badly integrated. The small file status symbols didn't show; or sometimes all files appeared with the question mark symbol making me think it didn't work.

But today it is looking fine, after both things happening at first; no symbols, then question marks. Then after a restart and a "Could not write metadata for '/RemoteSystemsTempFiles' modal dialog, and a while, and now they are showing. It might be the synchronization command I invoked was needed to finally get them showing.

So if you're seeing the same thing, just be a bit patient, do a 'Synchronize', and your day may brighten up some.


---

Oh, no, not bright. Installed the 'm2e' Maven Plugin (I think). Going from not finding "javax.persistence", to:

 The type java.lang.Object cannot be resolved. It is indirectly referenced from required .class files

And 'java.lang.Object' would probably be the most resolvable class in Java. 

---

Had to explicitly convert the project to a maven project. Odd, because: 

1) the .project had a couple of maven-related settings; maven2Nature and whatnot. 

2) ISTR that .pom files are auto-detected? I probably remember wrong. 

Better. 

...except: 

maven-dependency-plugin (goals "copy-dependencies", "unpack") is not supported by m2e
Plugin execution not covered by lifecycle configuration: org.codehaus.mojo:exec-maven-plugin:1.2.1:exec (execution: default, phase: initialize)
Plugin execution not covered by lifecycle configuration: org.codehaus.mojo:exec-maven-plugin:1.2.1:exec (execution: create_db_and_user, phase: initialize)
Plugin execution not covered by lifecycle configuration:
 org.codehaus.mojo:exec-maven-plugin:1.2.1:exec (execution:
 create_test_db_and_user, phase: initialize)

Great. Well,  I believe we had at least the copy-dependencies those to support an old ant project setup, copying maven lib dependencies into some folder for ant to deal with, so that might be ok.

...maybe I should have installed m2eclipse instead? I thought they were practically the same thing. But 

here is an article that begs to differ: http://java.dzone.com/articles/migrating-m2eclipse-m2e. 

(Original: http://blog.frankel.ch/migrating-from-m2eclipse-to-m2e.)

Ok, so how do I uninstall m2e and change to m2eclipse? The menus give no clue. 

...ah got it: select "Install Software..." menu item; the install dialog contains a "already installed" link. It has "Uninstall..." buttons. Of course, why didn't I think of that first? 

Selected the two items that seemed to have to do with m2e. (Restart, problems saving state modal dialog...)

---

Ok, Eclipse Marketplace, what have you got for me? m2eclipse-wtp seems to be the closest match for m2eclipse. ...ouch, "unsigned content". 

Let's try the other one, "Install New Software...". m2eclipse-wtp -- what the, it contains only m2e? Maybe I can't get an older m2eclipse with Juno? 

-- 

The blog I found above has a nice article here: 

http://blog.frankel.ch/better-maven-integration-leads-to-unforeseen-consequences-bugs

which seems kind of relevant; for instance this passage: 

However, the problem is much more widespread than m2eclipse. It’s very similar to issues adressed in Andrew Spencer’s post, only more so since if we don’t upgrade, we may have to keep an Eclipse instance for each project, that has to be shared between all team members. Right now, I don’t have any solutions for this problem, apart from changing the code to keep in synch with the tool.

---

Tried the "Discover new m2e connectors" link in quick tip. I don't know what those are, because nothing showed up.