search

dexX7 / java-libbitcoinconsensus

JNA binding and Java wrapper for libbitcoinconsensus
Other
9 stars 3 forks source link

Use jcenter(), not mavenCentral() for Gradle build #2

Closed msgilligan closed 9 years ago

msgilligan commented 9 years ago

jcenter() is faster than mavenCentral() and will use https://

(I'm not sure what the corresponding change to pom.xml would be.)

msgilligan commented 9 years ago

@dexX7

p.s. I did a checkout, build and test on Mac OS X Yosemite. The tests all passed!

One little nit is that the Gradle build didn't seem to notice if I move or change (touch) the libbitcoinconsensus.dylib file. I also discovered that it works if the dylib is in project root or in src/main/resources

dexX7 commented 9 years ago

One little nit is that the Gradle build didn't seem to notice if I move or change (touch) the libbitcoinconsensus.dylib file. I also discovered that it works if the dylib is in project root or in src/main/resources

That's interesting. I tested it on Ubuntu and this doesn't work for me. Could it be that libbitcoinconsensus is available as system library on your system? When using make install on Ubuntu, then the library is installed and available globally, so this would be my guess. Or OS X is a bit smarter here..

I was also wondering how we should handle this in general. I'm currently hosting the lib for Travis, but I don't really like it. As alternative I tested to download the offical Bitcoin release from bitcoin.org, but this comes at the cost of more traffic. It can be cached though.

Ideally the lib would be shipped with this project, but that adds a lot of more risk/responsibility in my opinon. What do you think?

I'm not sure what the corresponding change to pom.xml would be.

See #3. Depending on where the whole project is going, I'm wondering whether we should maintain the synchronization, or drop mvn instead.

msgilligan commented 9 years ago

Could it be that libbitcoinconsensus is available as system library on your system?

I'm pretty sure that's not the case (I did a global search just in case) I also moved it from projectRoot to a different directory and the test failed.

Or OS X is a bit smarter here..

I suspect it is a platform difference.

Ideally the lib would be shipped with this project, but that adds a lot of more risk/responsibility in my opinion. What do you think?

It would be nice if the libs for the major platforms were inside the jar. I think we can delay the decision about how to do that until later, though. We may also want to talk to the Bitcoin Core developers to find out what they recommend.

I'm wondering whether we should maintain the synchronization, or drop mvn instead.

We should drop one or the other, it seems like extra work to maintain both. My vote is to drop mvn and stick with Gradle, of course. Did you pick up both build files from a JNA sample?

dexX7 commented 9 years ago

It would be nice if the libs for the major platforms were inside the jar. I think we can delay the decision about how to do that until later, though.

Yup, I agree. Sounds good to me!

Did you pick up both build files from a JNA sample?

Sort of. I looked at an example for JNA and then searched for the dependency. I created the project via mvn archetype:generate and Gradle init, with some manual adjustments.