Wednesday 30 December 2009

Changing GMail Accounts

I recently decided to ditch my old gmail account in favour of my new gmail account, which is my personal domain name I have had for years (Google Apps for Domain).

In doing so I needed to port all my mail from the old gmail account to the new gmail account.

I setup the appropriate forwards etc, been running that way for about a month now.

The best way I have found to "Move" all the mail from old to new is.

Setup BOTH the GMail accounts in Mail (OSX on the Mac) as an IMAP account. The IMAP bit of course is important. Once they are setup, and you can see the mail in both of them.

Simply: Drag and Drop. Go to Sent Mail, in the old. select all and drag it into the Sent Mail on the new. All the dates and everything is preserved. Similarly, the same for Drafts (yes I had over 50 drafts) .. and All Mail, that caps in at 10,000 emails.

Just drag and drop to the same folder in the new account; Leave it running over night of course as it takes a LONG time. And without needed to state the obvious, the faster your connection, the faster this is. It moves the mail from the OLD to the new, VIA your computer.

Saturday 12 September 2009

Eclipse Galileo java.lang.ClassNotFoundException with JUnit Tests

This post describes my problem, and the solution
Recently I upgraded to Eclipse Galileo 3.5 on my Ubuntu dev box. All was well and I noticed no degradation or changes (new, good or bad) .. until ..
Until I went to run my first testcase in my new ete library. I received the beautiful
java.lang.ClassNotFoundException
.. on the JUnit Test case! :-) yuck.This was the stacktrace in it's entirety
Class not found org.soqqo.ete.source.data.EhCachedDataRowListTest
java.lang.ClassNotFoundException: org.soqqo.ete.source.data.EhCachedDataRowListTest
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.loadClass(RemoteTestRunner.java:693)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.loadClasses(RemoteTestRunner.java:429)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:452)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
It really threw me because on the command line, Maven2 (mvn test) test cases still worked fine. So I knew I havd an Eclipse problem. The upgrade was my key, ie: it was within 20 minutes of starting Galileo that this error occured.

So I ran my test cases in Eclipse 3.4 and it worked. 3.5 I say.. but then, that was too simple. There must be something up.

Much googling around for a good few hours each day and I found nothing. It then struck me that it was NOT eclipse, but rather a plugin I had in Eclipse. As it turned out it was the opposite of that: In that I did NOT have a plugin.

In the project, in the Maven 2 POM I declare some extra eclipse settings, to use the aspectJ Eclipse nature and also something for Spring as part of the Spring IDE. When you run
mvn eclipse:eclipse
the .classpath and .project files generated have all you relevate bits in there for eclipse.
I had this in the POM.


  maven-eclipse-plugin
  
    
       org.eclipse.ajdt.ui.ajnature 
       org.eclipse.jdt.core.javanature 
       org.springframework.ide.eclipse.core.springnature 
    
    
       org.eclipse.ajdt.core.ajbuilder 
       org.springframework.ide.eclipse.core.springbuilder 
    
    
      org.eclipse.jdt.launching.JRE_CONTAINER
      org.eclipse.ajdt.core.ASPECTJRT_CONTAINER
    
  

My guess was that I did not have the AspectJ plugin and the Spring Builder plugins, so the build paths were all screwey, which meant that Eclipse classpaths for JUnit were failing.

I was right, a quick uncomment of the whole extra customisation on the eclipse maven plugin in the pom.xml, and rerun mvn eclipse:eclipse and I was up and running again.

cheers. Hope this finds someone else a short path back to productivity.

Tuesday 7 July 2009

Coffee .. so disappointing

Ok, my first post since moving to the UK. I just walked down the road to my closest, best possible coffee house thus far, and it was Starbucks. How disappointing. not to be dismayed, I will find a solution one day.

All is well, lots to read and understand at my new role. (but without coffee, my goodness, how will I survive ?)

Wednesday 18 February 2009

Importing old mail into GMail

I have a client you needed a good 4 years of emails imported into GMail.

At first I thought, okay there must be a nice way of doing this. Then I found some python scripts which did some magic, and I thought .. ahh it works. And then I found without testing or checking, that perhaps they were not what i was after.

I needed the following to occur
(a) the emails appeared as if it was created when it was
(b) it showed it was sent by or received from as per the original
(c) there was no alteration to subjects or anything etc.

So I managed to try a "rule" in Mac mail to forward all mail under certain criteria to the gmail address, and then apply the rule to the mails in question. But this was a bit dicky. It added the Fwd: subject prefix and amm mail appears as "me".

I then thought about it ad it was simple...

Just attach the Gmail mailbox in question as an IMAP folder in mac mail.

Import (or no need if already there) the old email from wherever to mac mail. Then .. hat kiddies ? .. drag and drop the mail from the various folders to the IMAP folders.

Simple. A quick check and the mail appears as if sent in 2007, from whom, to whom. (this was the sent mail) .

Nice. No scripts or crap.. just time waiting to MacMail to do it's thing. I suspect my client will need to expand their data limit with Google.. but hey, what a service!

Friday 6 February 2009

Maven2 dependency classifier fails

Got a beef with Maven2 classifier today. The classifier is an extra tag/property on the artifact (jar) identifier. Where it is used often is with -sources.jar and -javadoc.jar for a particular jar.

An example of it's use is provided on the maven doco site


classifier:
The classifier allows to distinguish artifacts that were built from the same POM but differ in their content. ...

As a motivation for this element, consider for example a project that offers an artifact targeting JRE 1.5 but at the same time also an artifact that still supports JRE 1.4. The first artifact could be equipped with the classifier jdk15 and the second one with jdk14 such that clients can choose which one to use.

I have two jars which are JDK specific, one depends on the other (version). This means I have 4 jars.

bcprov-jdk16-141.jar
^ depends - bcpg-jdk16-141.jar

bcprov-jdk15-141.jar
^ depends - bcpg-jdk15-141.jar

This is of course, bouncy castle, and am using it with camel-crypto component for Camel. Bouncy castle comes in a version for each JDK, one for JDK 1.5, one for JDK 1.6. Great! The classifier is a case for this.

The code I will be writing primarily depends on bcpg (PGP implementation). So if I just depend on it, it will (should) pull in the parent bcprov.

A few things I noted when creating the pom changes was that
(first) The name of the bouncycastle jar is names as

bcprov-jdk16-141.jar

Maven puts the classifier "after" the version.
arbitrary string that - if present - is appended to the artifact name just after the version number.
So .. under maven, the bouncy castle jar should be

bcprov-141-jdk16.jar
bcprov-${version}-${classifier}.jar

At first, no worries, the bcprov jar up on ibiblio is old anyway and is missing the other jar I need which is bcpg, the PGP implementation. (the bit I want to add for Camel).

Putting this altogether:
in the root pom, we need to get a "property" version string so we can use it in the classifier.

<!-- set a property for the jdk version we are using based on the match of the jdk in use -->
<profile>
<id>jdk16</id>
<activation><jdk>1.6</jdk></activation>
<properties><jdk-version>jdk16</jdk-version></properties>

<profile>
<id>jdk15</id>
<activation><jdk>1.5</activation>
<properties><jdk-version>jdk15</jdk-version></properties>


In doing this, we will have ${jdk-version} as a property. This leads to a dependency like



<dependency>
<groupid>bouncycastle</groupid>
<artifactid>bcpg</artifactid>
<version>${bouncycastle-version}</version>
<classifier>${jdk-version}</classifier>
</dependency>


The last bit to resolve is to install the renamed jars into my local repository and have bcpg depend on bcprov. But this is where maven fell over. One classifer jar and another, share the same "non" classifier pom.

mvn install:install-file -DgroupId=bouncycastle -DartifactId=bcpg -Dversion=141 -Dclassifier=jdk16 -Dpackaging=jar -Dfile=/home/rbuckland/datastore/java/bcpg-jdk16-141.jar


This will then put in the renamed jar bcpg-jdk16-141.jar as bcpg-141-jdk16.jar.

Where it falls over. Maven2 has one pom for all classif(ied)er versions. So the listing for the repository is thus

ls /home/rbuckland/.m2/repository/org/bouncycastle/bcpg/141/
bcpg-141-jdk15.jar
bcpg-141-jdk16.jar
bcpg-141.pom

Not a pom for each. So in the pom (above) i need to declare the dependency on bcprov, but of course , in this repository pom for bcpg,

(a) specificing no classifier, the dependency does not get picked up
(b) tried ${classifier} .. hopeful
(c) tried ${pom.classifier} .. hopeful

I gave up. So instead the workaround is that the "version" of the var encompasses the JDK version instead. ie:

<dependency>
<groupid>bouncycastle
</groupid>

<artifactid>bcpg</artifactid>
<version>${jdk-version}-${bouncycastle-version}</version>


And then we can do what we need (of note, with this, the original naming of the jar by bouncycastle team stays).

Ah well.

Friday 23 January 2009

Apache Camel - Something Fresh

I have been working with Apache Camel for a good 8-9 months now, and have been committing as much as I can more recently. It is amazing as it feels like a breath of fresh air from the complexities of jbi in the servicemix arena.

Of course, many who work on and with servicemix also work on and work with camel and that is why I find camel refreshing. Simply that it is all the goodness of servicemix without the layer of jbi. Not to knock jbi of course, but it was very complex working with myriads of SU and SA Zip files that sometimes did nothing more than bloat your .m2 repository. Ahh those were the days. (edit: I will add that I am looking forward to the new ServiceMix 4.0 kernel as it , from what I can tell, is making large task of simplifying the architecture).

So what am I using Camel for ? Recently a client has had some iteresting gaps in a project that neither the global provided ETL PowerCenter informatica or locally developed scripts were sufficing or could suffice the gap.

Primarily we have been camel riding inside AMQ so we get good cluster support (potential) but it's the out of box nature that I enjoy (used to it from the servicemix days).

So .. good work Camel devs, keep it up, and hopefully I can keep it up.

Monday 12 January 2009

Stick with the masses ( Eclipse 3.4.1 XPCOM error -2147467262 )

There is a lot to be said about sticking with the masses, going with the crowd so to speak. Especially when you are riding the crowd (crowd) surfing for a different purpose .. huh ?

Let me explain ..

I have been an active user of Linux for the best part of 14 years. In that time, I have sat on the bleeding edge of changes and sometimes suffered. But, also I had time to kill, the fix and fix and patch time was kind of fun.

These days I have a lot less time that I allocate to that discretionary IT time budget, as I have a 2 girls and my beautiful wife with whom I enjoy spending time.

I still mass large amounts of work into my time, but when something goes wrong, ancillary to my task, (or, better put - my tools fail), then i get cranky.

Just on Friday I was prepping to make some changes to camel-file/ftp, adding support for commons-vfs and my eclipse failed to load.

It worked on the Thu, but Fri, nothing. My error said look at workspace/.metadata/.log

In there I find an obscure message...

!ENTRY org.eclipse.ui 4 0 2009-01-12 14:23:58.273
!MESSAGE Unhandled event loop exception
!STACK 0
org.eclipse.swt.SWTException: Failed to execute runnable (org.eclipse.swt.SWTError: XPCOM error -2147467262)


As it turned out, this was caused by an incompatibility with my eclipse and (possible Firefox or something in a mozilla stack).

What was my fix ? Well it turns out, the workspace info page at the first startup of eclipse uses a browser (no worries). But it had fundametal issues launching my system default browser. To get past the bug .. you need to unpack a jar

(/opt/eclipse/plugins/org.eclipse.ui.intro_3.2.201.v20080702_34x.jar)

and edit the plugin.xml, commenting out all extension elements, repack it and restart eclipse with a -clean.

See here for details (this link was the 5th attempt at me getting around the problem).

So why stick with the masses ? Well, I can only guess, but I suspect my running of Ubuntu amd64 is the cause of this eclipse issue biting me. Or, put it mildly, the error has not been tested much on this platform and I got stung, I could be wrong, but I can only guess that, surely others have seen the problem, I am not the only one running eclipse on Linux.

Where it failed for me is that Ubuntu automatically updated (something) and then my eclipse broke. I haven't got the time to work out what updated in the last week due to the auto update manager .. ? question: is there such a place to see the install log.. dpkg must know).

Anyways, my problem is gone and I am back to my usual eclipse-ing self. (minus the intro page, but i have never used that anyway).

Current 5 booksmarks @ del.icio.us/pefdus