Monday, October 29, 2012

Eclipse-Java-Maven-Svn Issue Top-N List

Let's do the same for the Eclipse-Java-Maven-Svn accretion as I did in the Javascript-Sucks blog entry: collect list of the most irritating issues.

1) Svn/Subclipse client implementation crappiness. Stuff like:

"Problems reported while synchronizing SVNStatusSubscriber. 0 of 1 resources were synchronized.", "Error getting status for resource", "org.tigris.subversion.javahl.ClientException: Working copy not locked; this is probably a bug, please report",  "svn: Directory '...' containing working copy admin area is missing". 

2) Multi-module maven projects, complaint A: why do they all have to be their own project; or rather: why do they all have to be displayed in a top-level project list?


3) Multi-module maven projects, complaint B: enabling Workspace Resolution (which is a good thing, mostly): why can't I inspect the imported jar as for the jars in Maven Dependencies that are not W.R. enabled? (Solution: temporarily disable; so not a huge deal.)

4) No good svn 'clone' command. What I do now for discrete files is either: Procedure A: 1) usually make sure it's committed, 2) 'rename' and 3) then 'revert' only the old deleted file. Or Procedure B: 1) drag a file 2) revert old location. File contents usually need to then change also, e.g. type name in A, package name in B. There's also Procedure C: use the svn CLI in the terminal.

5) There seem to be no 'fix all package declarations' command. This would be useful after some of the above mentioned svn clone operations. 'Fix imports' does exist. Fixing package declarations would be trivial to implement, easier than 'Fix imports'.

--

6) Subclipse bugs. Sheesh. For instance: renaming a folder. First step is easy: rename the folder. Committing the 'new' folder usually works. But then, Subclipse, or SVN, decides that there is some sort of conflict and refuses to commit without a dance involving at some point the 'Mark as Resolved' command. (Maybe helps if you always to 'update' on the parent folder of the original folder before the rename? Will probably never remember this, so mileage may vary.)


--

I won't ever have to create new blog posts, just keep piling up.

7) The set SVN property dialog. "Another property has the same name". WT*? So why don't you fetch it so I can edit the value? Or at least let me save a new value without going back and removing the property, should I choose to do so?

--

8) You can't just get by with a pom.xml for maven projects, the '.classpath' has to be in sync too. See http://impossible-is-development.blogspot.com/2012/11/basic-maven-project-build-fix-tip.html.

9) The '.classpath' generated for maven projects will include the test path too. Fertile element for spawning build error fallout, unless you also run CLI builds to be sure you don't reference any of the classes or things in the test tree.

--

10) "Working copy not locked; this is probably a bug, please report
svn: Are all the targets part of the same working copy?"

Oh right:
11) The fantastic misdesign where all the svn checks are done _after_ we've filled in the commit dialog.  And the dialog is closed. And the settings are mostly _not_ remembered.

--

This is no longer a Top-N list; it's just a pile of 'dirt'.

12) Dialog "Launch Error": '[editor/selection] does not contain a main type', etc. WT*: I ran it three minutes ago. And I am looking at this: "public static void main(String...args) {". And I haven't changed it. Some internal cache bug? Eclipse exit-relaunch helped none. Clean? Let's try...no. ...stumped.

--

13) This is a classic one: Alt-Click on a project (usually) will unfold the whole tree. This can take...some...time. Usually ends up in killing Eclipse and restarting. Nowadays, with a SSD, it usually never takes that long. But sometimes, like right now; and I don't know what's makes now a bad time to unfold. -- A timeout here would be nice; or simply a limit on the number of unfoldings.


-- MORE TO COME... --

No comments:

Post a Comment