Issues Loading Jar as Maven Dependency

[David Hanger]

I'm trying to make a Java Spring service that uses BitCoinJ as its
Bitcoin client connection. Worth noting is that I'm new to Spring and
Maven as of a little over a month ago, so there's some possibility
that their configuration is where my problems lie. But adding the
BitCoinJ dependency is specifically where things break.

running "mvn tomcat:deploy" (codehaus.org's maven-tomcat-plugin)
compiles and "deploys" without any error. However, Tomcat doesn't
show it as running. Looking through the logs, I come across this:

SEVERE: Exception sending context initialized event to listener
instance of class
org.springframework.web.context.ContextLoaderListener
java.lang.SecurityException: Invalid signature file digest for
Manifest main attributes
at [...]

A bit of a Google search tells me that it might be a problem with
packing the .jar, and BouncyCastle seems to come up a few times.
Please briefly check out these two discussions, most notably the last
couple posts in each.

http://www.coderanch.com/t/384144/java/java/Security-Exception-signature-file
https://github.com/wesabe/grendel/issues/2

I somewhat doubt that I'm the only person to actually use BitCoinJ as
a Maven dependency, so I suspect the error is with my setup. But as
above, I'm no guru with these tools. I started with the Spring
tutorial (after fixing it to work for version 3), modifying it to fit
my needs.

I'm using the SpringSource Tool Suite v2.7.1.RELEASE, with the
following dependencies in my pom.xml:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>3.0.5.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>3.0.5.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-jdbc</artifactId>
<version>3.0.5.RELEASE</version>
</dependency>
<dependency>
<groupId>commons-dbcp</groupId>
<artifactId>commons-dbcp</artifactId>
<version>1.4</version>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.17</version>
</dependency>
<dependency>
<groupId>com.google</groupId>
<artifactId>bitcoinj</artifactId>
<version>0.3-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjtools</artifactId>
<version>1.6.2</version>
</dependency>

I've opted to use BitCoinJ's 0.3-SNAPSHOT, as it has some great
additions and changes over 0.2.

[shads]

I had the same problem trying to build the current trunk. After adding the security provider I also had to change the bouncy castle maven dependency to bcprov-jdk16-1.46

My project was set to use 1.6 compiler compliance and with the bcprov-jdk15 it could only resolve some of the classes inside the bc jar (even though I could see the unresolvable ones inside the jar).

[David Hanger]

Would I make those changes from my own project's pom.xml, or would I
need to modify the BouncyCastle project's pom.xml? And by "adding the
security provider" do you just mean having the BouncyCastle as a sub-
dependency of BitCoinJ (I don't explicitly reference it, anywhere), or
are you referring to something else entirely?

[shads]

I meant when I was trying to setup bitcoinj itself in eclipse (using m2eclipse).  It was probably because I was trying to build it as 1.6 compliant.  If you are just linking to a bitcoinj lib it probably won't be an issue.

Sorry I've looked again the links in your first email and I think I'm talking about a completely different issue.  I thought it was something to with registering the BC provider in your JDK: http://www.bouncycastle.org/wiki/display/JA1/Provider+Installation

[David Hanger]

So... I added the following to my project's pom.xml:

<dependency>
<groupId>org.bouncycastle</groupId>
<artifactId>bcprov-jdk16</artifactId>
<version>1.46</version>
</dependency>

Same error. Suggestions?

[David Hanger]

Perhaps, although if BitCoinJ is using the bcprov-jdk15, that might be
what's throwing a tantrum at runtime as I am compiling with JDK 1.6.
I would expect 1.5 code to be adequately compatible with 1.6, but this
would be my first experience with incompatible versions.

I tried also adding BouncyCastle as a provider to java.security (all
installed), as suggested by your link. No change (still the " Invalid
signature file digest" SecurityException).

[Gary Rowe]

Having a quick look at the latest snapshot build on the integration server (0.0.3-SNAPSHOT build 24) it looks like the META-INF/Bckey.sf file is referencing the original BouncyCastle files (e.g. org.bouncycastle.crypto.tls.TlsAuthentication.class) which may indicate a misconfiguration of the Shade plugin.

As I recall, Shade will rewrite internal bytecode in order to ensure that internal references are maintained due to the package renaming. Consequently any externally supplied signature file will be invalid by definition.

I'll have some time over the weekend to look into this more deeply (I'm in GMT+1 currently), but as for a workaround, you might want to build locally from source (mvn clean package) and manipulate the contents of /target/classes to remove the META-INF details. Finally, manually JAR the target/classes directory to make your own unsigned version, ignoring the package artifact.

This is all advice from a cursory look over the situation - I've not directly done any work with the Shade plugin so if anyone else can offer some clue here I'd appreciate it.

[Mike Hearn]

Yes, it's indeed to do with the shade plugin.

Perhaps we should drop this from the bitcoinj POM. It's only relevant on Android, and Andreas doesn't use our build anyway.

--
Google Switzerland GmbH

[Gary Rowe]

How about I take a look at it and attempt to fix it before we give up on the shade plugin? Although Andreas may not be using BitCoinJ other wallet developers may find it useful and as such will need to make use of the BouncyCastle relocation facility.

I could also enable the FindBugs plugin while I'm in there rootling about...

[Jonny Heggheim]

I agree with Mike, I think that problems with other platforms can be handled by them.

But, if we want to continue the route with shading, we can create two artifacts (different classifiers) by adding this to the <configuration> part of the shade plugin (non-Android users would not be affected by these Bouncy Castle hacks):

    <shadedClassifierName>android</shadedClassifierName>

    <shadedArtifactAttached>true</shadedArtifactAttached>

Copied from http://maven.apache.org/plugins/maven-shade-plugin/examples/attached-artifact.html

For the BCKEY.SF it looks like is possible to change it with transformers (I have never tested it)

http://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html

Again, I would consider the complexity before going further down this road...

Jonny

[Andreas Schildbach]

Well, the only reason I am not using the build is that there still is
some delta between BitcoinJ as used by Bitcoin Wallet and main BitcoinJ.
I keep on pushing to reduce that delta, and hope I can use main BitcoinJ
by then. I'm pretty sure I'd like to use Maven at this point.

[Gary Rowe]

Hi all,

I've attached a patch (affects pom.xml based on r204) for the Maven build that follows Jonny's suggestion that we add a classifier for the Android-specific version of the artifact. This greatly simplifies the solution so that we use the following approaches:

The "desktop" BitCoinJ artifact

We don't do any shading and just mandate that the Bouncy Castle classes are made available at runtime through a Maven dependency. Their signature files remain unchanged.

Typical artifact name bitcoinj-0.3-SNAPSHOT.jar

The Android BitCoinJ artifact

We jump through the shading hoops to ensure that a full implementation of Bouncy Castle is available for that platform,. This requires that the Bouncy Castle libraries are relocated from org.bouncycastle.* to com.google.bitcoin.bouncycastle.*. Also, the Bouncy Castle signature files are removed since they no longer apply.

Typical artifact name bitcoinj-0.3-SNAPSHOT-android.jar

I've tested this approach with both the "desktop" and Android versions and they both seemed to run up and work as expected. However, it would be helpful for someone with a more sophisticated setup to give the patch a go and report back any problems.

Cheers,

Gary

[Mike Hearn]

I've tested this approach with both the "desktop" and Android versions and they both seemed to run up and work as expected. However, it would be helpful for someone with a more sophisticated setup to give the patch a go and report back any problems.

Thanks. I checked this in.

[Gary Rowe]

Thanks, Mike. I'll check the CI server picks it up properly shortly.

[David Hanger]

Thanks for looking into this further, everyone.

There seems to be a problem with the artifactory (502 Bad Gateway)
that's referenced on your UsingMaven page (http://code.google.com/p/
bitcoinj/wiki/UsingMaven). Should I point Maven elsewhere, or will
this clear up with time as did the occasional EveryDNS error message
it was giving for a while?

[David Hanger]

Sorry, forgot to put the link on its own line to avoid being chopped.

http://code.google.com/p/bitcoinj/wiki/UsingMaven

[Gary Rowe]

Hi,

Looks like Artifactory was playing up and causing the Jenkins build to fail - nothing to do with BitCoinJ code, just the final deployment stage.

David, you should be able to get hold of the latest snapshots from here (for direct manual download):

http://ci.bitcoinj.org/artifactory/repo/com/google/bitcoinj/0.3-SNAPSHOT/

In Maven, the android version will need to be referenced as follows:

<dependency>

<groupId>com.google</groupId>

<artifactId>bitcoinj</artifactId>

<version>0.3-SNAPSHOT</version>

<scope>compile</scope>

<classifier>android</classifier>

</dependency>

Anyone needing to use the server version, just omit the <classifier> section.

Mike, I imagine the wiki will need updating with this information now that we've got a successful build with the patch. Only the description of the <dependency> section needs to be included for Maven folks to use it.

Cheers,

Gary

[David Hanger]

Should I generally be pointing Maven to:
http://ci.bitcoinj.org/artifactory/repo
... rather than:
http://ci.bitcoinj.org/artifactory/snapshot
... ? I use the snapshot path as per the UsingMaven wiki, and I'm
still getting an "Invalid signature file digest" exception after
updating Maven's dependencies and rebuilding my project. I noticed
that the most recent .jar in my Maven repository folder for bitcoinj
is from 2011-09-12.

And I just tried changing my pom.xml to use the /artifactory/repo
path, and there's still no change. Is it possible with how things are
at the moment to use BitCoinJ as a Maven dependency, or do I need to
manually handle the .jar? Avoiding that hassle is kind of the point
of Maven.

Thanks,
David

On Sep 15, 6:44 pm, Gary Rowe <g.r...@froot.co.uk> wrote:
> Looks like Artifactory was playing up and causing the Jenkins build to fail
> - nothing to do with BitCoinJ code, just the final deployment stage.
>
> David, you should be able to get hold of the latest snapshots from here (for

> direct manual download):http://ci.bitcoinj.org/artifactory/repo/com/google/bitcoinj/0.3-SNAPS...

[David Hanger]

Update:
Between Maven and the SpringSource Tool Suite (Eclipse), three older
versions of the BitCoinJ Jar were left in my project's target/WEB-INF/
lib folder, and it was trying to load one of those instead. I deleted
them, and it's now moving on (to errors in my configuration).

Thanks again for the help.

[Mike Hearn]

OK, I updated the wiki page. How does it look now?

--
Google Switzerland GmbH