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!

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.