bitcoinj
bitcoinj copied to clipboard
bitcoinj
Set multi-project version in gradle.properties with bitcoinjVersion
- Add gradle.properties with bitcoinjVersion
- Set version in allprojects{} in root build.gradle
- Remove version setting in core/build.gradle
I assume you're doing this so wallettemplate has a version? I'd rather not revert to versioning the whole project. We were at that point before the Gradle migration and it was painful.
I assume you're doing this so wallettemplate has a version?
Without this change wallettemplate gets a version of 1.0. I figured we wanted all modules to have the same version number (at least by default) and this is the standard Gradle way to do that.
Note that it is also typical to create variables for common dependencies in the root gradle.properties file as well.
I'd rather not revert to versioning the whole project. We were at that point before the Gradle migration and it was painful
What were the problems? With Gradle (and the approach in this PR) it is easy enough to override the default version in any subprojects.
I thought by default Gradle projects don't have a version at all? And the Gradle documentation says so too: The version defaults to unspecified.
I thought by default Gradle projects don't have a version at all? And the Gradle documentation says so too: The version defaults to unspecified.
That's not the behavior I saw -- at least in the generated filename for the JAR. So either one of the plugins was setting version or the filename generation code uses 1.0 when version is unspecified.
In any event, Gradle provides a lot of flexibility in managing a global version and/or versions for each subproject. What are you concerns? How would you like to manage versions across subprojects?
Well I simply think examples don't need a version. Wallet-template for me is also an example, that got moved to its own subproject only because Mike wanted to use the latest JDK, JFX etc. I think the only artifact besides bitcoinj-core that warrants being versioned is wallet-tool. It might even make sense to publish binaries of it. But that's another story.
But of course if due to bugs in plugins a fake '1.0' version starts appearing, it may make sense to override that.
Another aspect of this PR is the usage of a gradle.properties variable. We haven't done this for the other properties yet; what's the use of it? A simple versiion = '0.16-SNAPSHOT' in the top-level build.gradle should suffice?
Wallet-template for me is also an example
I'm trying to make it into more of a re-usable library, which is the end-goal of the changes I've been submitting lately and is addressed directly by Issue #1819. Maybe it doesn't make sense for me to do that here, but to create a new repository -- perhaps under ConsensusJ?
I like the idea of having these JavaFX components in this repository because it makes sure the bitcoinj is well-integrated and tested. I want to build a full desktop wallet separately, but I also want core libraries and possibly even some form of framework to be available as well and I was hoping to do (at least some of that) here. Perhaps we should discuss on the mailing list?
Well I simply think examples don't need a version. Wallet-template for me is also an example, that got moved to its own subproject only because Mike wanted to use the latest JDK, JFX etc. I think the only artifact besides bitcoinj-core that warrants being versioned is wallet-tool. It might even make sense to publish binaries of it. But that's another story.
I still think we should define a version at the "root" level and then override it if necessary. I don't think it hurts to version the examples. I'm playing around with trying to build a native-image wallet tool and needing/wanting a version for it. And, of course, we're moving towards having wallet lib/template in its own repo with its own version.
I'd rather not revert to versioning the whole project. We were at that point before the Gradle migration and it was painful
Still not sure what kinds of problems you were having. Can you provide some detail?
@schildbach I'd like to try to move forward with this one if we can come up with an approach that you think will work.