How To Do It; Aka Precipitation From Silver-Lined Cloud

Subject: Good Code: State-of-the-Art Best-Practice Knowledge Diagram
From: http://xkcd.com/844/
Via: http://tech.slashdot.org/story/12/12/21/220255/real-world-code-sucks?utm_source=rss1.0mainlinkanon&utm_medium=feed

The "display" HTML/CSS Misdesign

TBD.

Subclipse Message

This is a message from Subclipse (SVN?): 

    Invalid filesystem path syntax
svn: Cannot replace a directory from within

That's the literal message. All of it. Ends in nothing.

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.

Java Package Reflection

There's no Package.forName() like there is a Class.forName(). Is this an accident? If it's not, only packages that have a class in them, let's call them 'inhabited' packages, can actually be accessed.

There's the Philosophical Question of whether they then 'exist' or not. Platonic package, anyone? But on the other hand, one can probably find out: there is the Package.getPackages().

-- TBD --

Development Is Implannable

It's possible, but not plannable. Let's make a new word: Implannable. Implannable.

That's at least half of what the 'agile' thinking is about.

Must. Write. About. Planning.

Must write about planning soon.

Maven Is Back, Stronger Than Ever

Guess what this does, in proper maven resource plugin context:

<configuration>

<outputDirectory>target/classes</outputDirectory>

<excludes>

<exclude>**/*.java</exclude>

<exclude>**/*.class</exclude>

<exclude>**/.svn</exclude>

</excludes>

<resources>

<resource>

<directory>src/test/java</directory>

<filtering>false</filtering>

</resource>

<resource>

<directory>src/main/java</directory>

<filtering>false</filtering>

</resource>

</resources>

</configuration>

Copies resources out of src/test/java and src/main/java, excluding files matching the specified patterns? 

Wrong. Or, mostly wrong. 

The exclusions will apply to the src/test/java directory paths, but not the src/main/java. Yep, at least in the version we use. 

Caveat utilitor.

Maven Copy Plugin

This (new?) Maven 'copy' plugin: http://evgeny-goldin.com/wiki/Copy-maven-plugin, seems to be a useful tool to simplify some Maven projects. It seems to be a good way to using a minimal number of plugins for common tasks. This is not a deep review; I'm just blogging this as sort of a mental note.

But it could be used for the following problem: I recently learned a second way that the 'real' Maven and running under the Eclipse Maven plugin differs, in that resource files in /src/man/java are copied; but not so with Maven defaults. (The other difference I know of is that Eclipse has only one classpath, the same for both src/test and src/main. Fertile ground for bad imports.) It's easy to add with a standard plugin, but if you have many such small tasks, then possibly this 'copy' plugin will be better than a bunch of disparate plugins. Maven is verbose enough, I think.