We have several new projects spinning up in my group, as well as several new releases or add-ons for existing projects. It's good when your products are popular and are needed by many different contracts/customers. It's bad when you are one of the very few people who has worked on (or led, in my case) nearly all of these products and so people keep asking for "just a little bit of time" to review a design or answer a question from the field or interview some new folks. I haven't been able to touch my "real" assignment (designing a replacement for our geospatial + full text alerting app) in a couple of weeks.
When another developer here in my group suggested me along with another overloaded teammate as folks who may be able to do some testing of a new REST api on one of the products, he was kind enough to phrase the request as "tossing some names under the bus," indicating that he knew the people attached to the names were overbooked. My response? "There have to be more bus carpet names than Jeff and I for everything."
While not a full Googlenope as defined by Gene Weingarten, I think it is original in its usage. So I hereby submit my addition to the blogsphere lexicon:
Bus Carpet - Someone who is tossed under the bus with great frequency.
Monday, June 29, 2009
Wednesday, June 3, 2009
Eclipse, Maven, and Groovy, oh my!
The groovy support in Eclipse leaves a bit to be desired. "Tell me something new" you say. How about - The groovy support in maven projects within eclipse leaves a lot to be desired, but it does at least exist, so long as you are willing to work at it a bit.
Rather than posting the details off in the wilderness of my own blog, I responded to a post on the m2eclipse (the maven-eclipse plugin) mail list from last Fall where someone was asking how to add groovy support to maven projects. The author of the m2eclipse plugin stated that the groovy plugin needed to support some hooks into m2eclipse. While that may be true to get fully automated setup and synchronization, you can get the two plugins working together. See this thread for the info:
http://www.nabble.com/Using-M2Eclipse-together-with-Groovy-td19261256.html
Rather than posting the details off in the wilderness of my own blog, I responded to a post on the m2eclipse (the maven-eclipse plugin) mail list from last Fall where someone was asking how to add groovy support to maven projects. The author of the m2eclipse plugin stated that the groovy plugin needed to support some hooks into m2eclipse. While that may be true to get fully automated setup and synchronization, you can get the two plugins working together. See this thread for the info:
http://www.nabble.com/Using-M2Eclipse-together-with-Groovy-td19261256.html
Subversion (subclipse) corruption in Eclipse
I use subclipse to manage my subversion interactions in eclipse. I also use TortoiseSVN for pulling clean source code trees that are separate from my development workspace to produce releases. Normally, "never the two shall meet" is my policy. Eclipse/subclipse manage projects in my workspace directory and Tortoise handles everything else. I just found out what happens if you let them cross paths.
I had a project in eclipse that seemed to have corrupted it's svn meta-data. The Synchronize view insisted that I had added some files when I hadn't. After restarting eclipse, the Synchronize view insisted that the whole source tree had changed. Trying to narrow the problem, I quit eclipse, opened Windows Explorer, and told Tortoise to check for updates and local mods in the project. Tortoise turned up a big nothing; it didn't think there were any changes (which was correct). So I went back into Eclipse to see if I could find a pattern to it's madness. (I know, I know - "This is eclipse, " you say, "to which madness are you referring?"). Trying to synchronize the project again resulted in this helpful messages in the SVN console:
update C:/Dev/workspace/myproject -r HEAD --force svn:
'C:\Dev\workspace\myproject' is not a working copy
svn: Cannot read from 'C:\Dev\workspace\myproject\.svn\format': C:\Dev\workspace\myproject\.svn\format (The system cannot find the file specified)
For any who don't know the inner workings of subversion (like me), under subversion 1.4 and below, the format file contains the version of the meta-data. 9 for version 1.4, 8 for 1.2 (I think), etc. With subversion 1.6, that file is removed and the meta-data version is written in the top line of the entries file.
Lesson #1: The subversion version used by eclipse may be different from the version used by your standalone subversion client.
I use Tortoise 1.6.2. This uses subversion client 1.6 libraries. My subclipse plugin is from the 1.4.x branch. As the Tortoise FAQ will tell you, subversion versions 1.4 and above will automatically upgrade the working copy format of your meta-data. So the message was correct - the format file wasn't there. I just didn't yet understand what had happened to cause that. I thought I was still dealing with the same unknown error that I started with when, in fact, I had managed to create a whole other problem to deal with.
Somehow (and the steps get blurry here) I got Eclipse to give me a better error:
Problems reported while synchronizing SVNStatusSubscriber. 0 of 1 resources were synchronized. An error occurred synchronizing /myproject: Error getting status for resource P/myproject org.tigris.subversion.javahl.ClientException: Unsupported working copy format
svn: This client is too old to work with working copy 'C:\Dev\workspace\myproject'. You need to get a newer Subversion client, or to downgrade this working copy.
See http://subversion.tigris.org/faq.html#working-copy-format-change
for details.
Ah-hah! So I at least knew what had caused the latest behavior. Upgrading my subclipse plugin to the 1.6.x branch got me back to my original problem. Nice to be back in known territory.
I knew that the subversion meta-data that I could see (stuff in the .svn directories) was okay since Tortoise functioned. So eclipse must keep some other meta-data about the synchronization state of a project. Time to delve into the dark world of the workspace .metadata directory. I searched through that directory for anything with the name of my project. After eliminating a few hundred hits in .markers and .history files and whatnot, I found a likely sounding culprit - .syncinfo. Sure enough, armed with that file name, I searched the web for references to my problem and turned up an archive of the subclipse-users mail list with exactly what I needed.
Lesson #2: If the subversion integration in Eclipse ever goes haywire for a project, delete this file:
[workspace dir]\.metadata\.plugins\org.eclipse.core.resources\.projects\[project name]\.syncinfo
Problem solved. Now I just have to get maven, eclipse, and groovy playing nicely with each other...
I had a project in eclipse that seemed to have corrupted it's svn meta-data. The Synchronize view insisted that I had added some files when I hadn't. After restarting eclipse, the Synchronize view insisted that the whole source tree had changed. Trying to narrow the problem, I quit eclipse, opened Windows Explorer, and told Tortoise to check for updates and local mods in the project. Tortoise turned up a big nothing; it didn't think there were any changes (which was correct). So I went back into Eclipse to see if I could find a pattern to it's madness. (I know, I know - "This is eclipse, " you say, "to which madness are you referring?"). Trying to synchronize the project again resulted in this helpful messages in the SVN console:
update C:/Dev/workspace/myproject -r HEAD --force svn:
'C:\Dev\workspace\myproject' is not a working copy
svn: Cannot read from 'C:\Dev\workspace\myproject\.svn\format': C:\Dev\workspace\myproject\.svn\format (The system cannot find the file specified)
For any who don't know the inner workings of subversion (like me), under subversion 1.4 and below, the format file contains the version of the meta-data. 9 for version 1.4, 8 for 1.2 (I think), etc. With subversion 1.6, that file is removed and the meta-data version is written in the top line of the entries file.
Lesson #1: The subversion version used by eclipse may be different from the version used by your standalone subversion client.
I use Tortoise 1.6.2. This uses subversion client 1.6 libraries. My subclipse plugin is from the 1.4.x branch. As the Tortoise FAQ will tell you, subversion versions 1.4 and above will automatically upgrade the working copy format of your meta-data. So the message was correct - the format file wasn't there. I just didn't yet understand what had happened to cause that. I thought I was still dealing with the same unknown error that I started with when, in fact, I had managed to create a whole other problem to deal with.
Somehow (and the steps get blurry here) I got Eclipse to give me a better error:
Problems reported while synchronizing SVNStatusSubscriber. 0 of 1 resources were synchronized. An error occurred synchronizing /myproject: Error getting status for resource P/myproject org.tigris.subversion.javahl.ClientException: Unsupported working copy format
svn: This client is too old to work with working copy 'C:\Dev\workspace\myproject'. You need to get a newer Subversion client, or to downgrade this working copy.
See http://subversion.tigris.org/faq.html#working-copy-format-change
for details.
Ah-hah! So I at least knew what had caused the latest behavior. Upgrading my subclipse plugin to the 1.6.x branch got me back to my original problem. Nice to be back in known territory.
I knew that the subversion meta-data that I could see (stuff in the .svn directories) was okay since Tortoise functioned. So eclipse must keep some other meta-data about the synchronization state of a project. Time to delve into the dark world of the workspace .metadata directory. I searched through that directory for anything with the name of my project. After eliminating a few hundred hits in .markers and .history files and whatnot, I found a likely sounding culprit - .syncinfo. Sure enough, armed with that file name, I searched the web for references to my problem and turned up an archive of the subclipse-users mail list with exactly what I needed.
Lesson #2: If the subversion integration in Eclipse ever goes haywire for a project, delete this file:
[workspace dir]\.metadata\.plugins\org.eclipse.core.resources\.projects\[project name]\.syncinfo
Problem solved. Now I just have to get maven, eclipse, and groovy playing nicely with each other...
Subscribe to:
Posts (Atom)