Hello everyone,
I'm new to BaseX. Just evaluating if it fits in my current project.
Looks great.
My project uses maven, BaseX 6.3.2 is added as a dependency according to
your documentation.
Here comes the problem:
The resolution of the Prop.HOME-Directory (thus the location of the
props-file ".basex") doesn't fit the intended behavior (as far as I got
the intention), when using (Netbeans and) maven for build and run. And
it should not work as intended when placing the basex-jars in a
lib-directory as well.
AFAIK, it's supposed to be a directory relative to the path in which the
application got executed (if props ".basex" are found there, otherwise
the users home directory).
(If however the current path should be the intended one, then I'd say
it's not very intuitive or practical)
Using (Netbeans and) maven for build and run, causes the relative path
to result in the maven-repository-location of the xbase-jar. (e.g.
"{repository-root}/.m2/...")
That's definitely no place for a props-file, so it will always result in
the user-home-directory.
I don't want to pollute the users home directory however (besides we
plan to make the app portable), that's why I was wondering if you could
detect the relative path in another way.
Here's the details of what's currently happening:
The creation of the Database:
Class<?> c = Class.forName(DRIVER);
Database db = (Database) c.newInstance();
causes several initializations to happen. Among others, there's the
static initializer of Prop (line 38), which calls Util.applicationPath()
to calculate the HOME directory.
The method body of applicationPath starts with
final String path = Util.class.getProtectionDomain().
getCodeSource().getLocation().getPath();
which returns the location of the jar in the maven repository, which is
not the application path (and could result in a completely unintended
path when using custom-classloaders).
Suggestion:
Could you just calculate the working directory like this:
final String path = new File(".").getPath();
or
final String path = new File(".").getAbsolutePath();
This would IMHO result in a more intuitive location for the working- (or
config-)directory.
I'd suggest to put that into a new method, say Util.workingPath() (or
Util.configPath()), to prevent trouble with code, that actually needs to
receive the jar-file-location (if such code exists at all).
To stay compatible with the old resolution strategy, you could just add
this line of code on top of the old resolution, thus provide a third
location for props.
I'd contribute this patch by myself, if you'd agree.
Future needs for my application are dynamic configuration of port-ranges
and stuff, that's why I'd also love to have the opportunity to configure
BaseX completely by the use of the API, without having to deal with
config-files for "third-party-libs".
BaseX looks great and I'd love to use it for my project if it proves to
be adequate. Great work!
Greetings,
--
Thomas