This is done primarily for concision. This change also repackages
bisq.grpc => bisq.proto.grpc in anticipation of repackaging the
definitions in pb.proto from 'protobuf' to 'bisq.proto'. There should
not be any compatibility issues with doing this, but it's out of scope
here. When complete, the relationship between bisq.proto.grpc and
bisq.proto will be more intuitively clear, i.e. that bisq.proto.grpc has
certain dependencies on bisq.proto classes, but not the other way
around.
Prior to this commit, BisqExecutable has been responsible for parsing
command line and config file options and BisqEnvironment has been
responsible for assigning default values to those options and providing
access to option values to callers throughout the codebase.
This approach has worked, but at considerable costs in complexity,
verbosity, and lack of any type-safety in option values. BisqEnvironment
is based on the Spring Framework's Environment abstraction, which
provides a great deal of flexibility in handling command line options,
environment variables, and more, but also operates on the assumption
that such inputs have String-based values.
After having this infrastructure in place for years now, it has become
evident that using Spring's Environment abstraction was both overkill
for what we needed and limited us from getting the kind of concision and
type saftey that we want. The Environment abstraction is by default
actually too flexible. For example, Bisq does not want or need to have
environment variables potentially overriding configuration file values,
as this increases our attack surface and makes our threat model more
complex. This is why we explicitly removed support for handling
environment variables quite some time ago.
The BisqEnvironment class has also organically evolved toward becoming a
kind of "God object", responsible for more than just option handling. It
is also, for example, responsible for tracking the status of the user's
local Bitcoin node, if any. It is also responsible for writing values to
the bisq.properties config file when certain ban filters arrive via the
p2p network. In the commits that follow, these unrelated functions will
be factored out appropriately in order to separate concerns.
As a solution to these problems, this commit begins the process of
eliminating BisqEnvironment in favor of a new, bespoke Config class
custom-tailored to Bisq's needs. Config removes the responsibility for
option parsing from BisqExecutable, and in the end provides "one-stop
shopping" for all option parsing and access needs.
The changes included in this commit represent a proof of concept for the
Config class, where handling of a number of options has been moved from
BisqEnvironment and BisqExecutable over to Config. Because the migration
is only partial, both Config and BisqEnvironment are injected
side-by-side into calling code that needs access to options. As the
migration is completed, BisqEnvironment will be removed entirely, and
only the Config object will remain.
An additional benefit of the elimination of BisqEnvironment is that it
will allow us to remove our dependency on the Spring Framework (with the
exception of the standalone pricenode application, which is Spring-based
by design).
Note that while this change and those that follow it are principally a
refactoring effort, certain functional changes have been introduced. For
example, Bisq now supports a `--configFile` argument at the command line
that functions very similarly to Bitcoin Core's `-conf` option.
The recent changes breaks current formatting radically and does not
lead to better results as it was before.
Before applying new changes, please test it with bigger classes to see
if the result is as intended.
- Remove assets from META-INF/services/bisq.asset.Asset
- Preserve asset types but mark as @Deprecated
- @Ignore asset tests
Preserving the types is important from a compatibility perspective.
Users who have traded these assets in the past, however few there may
be, need to be able to classload the asset type(s) in order to avoid
errors when browsing through their trade portfolio history.
Problem: bisq-network/style#3 indicates code should be wrapped at 120
characters, but it is likely that people will forget and that this habit
will only change slowly.
Solution: Configure IDEA to wrap lines automatically when typing past
120 characters, forcing the reminder to happen in real time. If this
becomes a nuisance, we can remove it later.
Note that this change also explicitly sets the RIGHT_MARGIN value to
120, even though this is already IDEA's default value. This is simply
to be explicit and self-documenting.
This setting is actually necessary only in bisq-common, but it has been
added to the shared codeStyles/Project.xml in bisq-network/dao so as to
be able to copy the same configuration file to all bisq-* projects.
IDEA does strips EOF newlines in these files, so this commit adds an
exception to the usual rule about inserting them. This will avoid
spurious whitespace diffs on these files in the future.
This change adds a .idea/codeStyles/Project.xml file that orders all
imports from higher-level layers to lower-level layers, with blank lines
between different major packages.
The purpose of this approach is to allow the reader to scan the imports
in a file efficiently to understand what kind of work the class does,
what layers it touches, and so forth. Keeping imports clean and ordered
by layer can be a powerful tool in keeping a codebase well organized and
tangle-free over time.
bisq.* packages are always sorted at the top.
