I personally think a a sub-module is a great approach. For the applications/projects I've seen so far, I see no need for it to be a separate project. Other projects could submit unit tests and pull requests where appropriate, but if it's in a Maven repo as a separate JAR, that's all they need. In either case, a submodule would be the least disruptive way to start.
Marvin has clearly worked this through much further than I have -- I've mostly needed subclasses of `MainNetParams` with different `addressHeader` values and it would be nice to get this without pulling in all of bitcoinj-core. I'm not sure what Jeremy Rand needs or has been pulling from libdohj. Even for some of the mostly Bitcoin-focused components of ConsensusJ, it would be nice to be able to get some of the core bitcoinj types (e.g. Address, Sha256Hash, ECKey) without getting the transitive networking dependencies, etc. So I really like the idea of a base or types submodule -- even independent of support for pluggable coin types. -- Sean On 1/5/18 7:30 AM, Andreas Schildbach wrote: > I'm not against this idea, but it can be quite some work and potentially > be disruptive on the API. > > We could probably start by a submodule in bitcoinj and once that > stabilizes it could be extracted to a separate project. > > > On 12/12/2017 01:30 AM, Sean Gilligan wrote: >> Hi Marvin, >> >> Sorry for not responding sooner. We have a need for something like this >> in the ConsensusJ [0] project (formerly called bitcoinj-addons) and were >> thinking about making a proposal similar to yours. You can see some of >> the discussion on Issue #14 [1] and Issue #25 [2]. We've dabbled with >> Litecoin, Namecoin, and a couple of other chains - -and there's some >> significant Namecoin work that JeremyRand wants to merge. JeremyRand has >> been using and brought to my attention the libdohj [3] (pronounced "lib >> doge" -- like the coin) which addresses some of these issues. >> >> The ideal solution IMO would be for bitcoinj to split of some of these >> foundational classes into a separate jar (smaller and with fewer >> dependencies than bitcoinj-core) that can be used by bitcoinj and other >> chains. I haven't had much time lately to look at the latest >> alternatives, but would love to see a great, standard, open source >> solution for some common code. >> >> -- Sean >> >> [0] https://github.com/ConsensusJ/consensusj >> [1] https://github.com/ConsensusJ/consensusj/issues/14 >> [2] https://github.com/ConsensusJ/consensusj/issues/25 >> [3] https://github.com/dogecoin/libdohj >> >> >> On 12/11/17 12:00 PM, Marvin wrote: >>> I've started to setup a repo for this >>> idea: https://github.com/marvin-we/crypto-core >>> >>> Am Sonntag, 3. Dezember 2017 10:44:41 UTC+1 schrieb Marvin: >>> >>> Hello together, >>> >>> I initially created the following ticket: >>> https://github.com/bitcoinj/bitcoinj/issues/1486 >>> <https://github.com/bitcoinj/bitcoinj/issues/1486> And was asked >>> to publish this idea on the mailing list - So I hope this group is >>> the right place :) >>> >>> _____________________ >>> >>> Original Ticket: >>> >>> Hello together and a big thanks for providing this library. >>> >>> I have the follownig "feature" request: >>> >>> I develop a Java-Library for the >>> [Steem-Blockchain](https://github.com/steemit/steem/ >>> <https://github.com/steemit/steem/>) called >>> [SteemJ](https://github.com/marvin-we/steem-java-api-wrapper >>> <https://github.com/marvin-we/steem-java-api-wrapper>) and I try >>> to reuse as much parts of bitcoinJ as possible - Why? Because this >>> project is well documented, the code quality is really great and >>> the lib itself is bulletproof. >>> >>> A lot of your implementations (e.g. the ECKey object or the Utils >>> class) provide functionallities required in nearly all Blockchain >>> libs out there. Due to that a lib developer has three options: >>> >>> 1. Implement something on his/her own (e.g. IOTA) >>> 2. Use the whole bitcoinJ project (e.g. SteemJ) >>> 3. Copy your code (e.g. EtheriumJ) >>> >>> I guess number one can be pretty time consuming as it will require >>> a lot of time until the developer gained the knowledge that you >>> already have and will also not reach the code quality you offer. >>> >>> Number two is what I am currently doing. This solution has one >>> disadvantage: I need to add the whole BitcoinJ library while only >>> using some specific classes. >>> >>> Number three solves this problem, but you manually need to take >>> care of updates and merge those changes. >>> >>> So I was wondering if it would be possible to put classes that are >>> not bitcoin specific into a separate package? >>> >>> _____________________ >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "bitcoinj" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected] >>> <mailto:[email protected]>. >>> For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google >> Groups "bitcoinj" group. >> To unsubscribe from this group and stop receiving emails from it, send >> an email to [email protected] >> <mailto:[email protected]>. >> For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "bitcoinj" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
