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,