Hi Marc,
Thanks for the hint! We're currently on the way back from Prague; I'll most probably look at this tomorrow.
All the best, Christian Am 16.02.2015 10:11 schrieb "Marc van Grootel" <marc.van.grootel@gmail.com
:
I'm sending this again as my first try it didn't get picked up on the list.
--Marc
---------- Forwarded message ---------- From: Marc van Grootel marc.van.grootel@gmail.com Date: Fri, Feb 13, 2015 at 12:00 PM Subject: Re: [basex-talk] BaseX in maven To: BaseX basex-talk@mailman.uni-konstanz.de
Hi,
I have dealt with various ways to include BaseX in a project using Gradle which uses Maven compatible dependency resolution. This thread does provide me some info that I can also apply to Gradle based builds. I was never a big fan of Maven and I found it to be too Java centric to handle projects that include XML system components such as BaseX. Anyways. What I did find though was a little issue with the dependency resolution that I don't see anyone reporting for Maven. Maybe Gradle handles dependency metadata a little bit differently.
The trouble is with a transitive dependency of basex-api. It uses com.ettrema:milton-api:1.8.1.4.
However, when I only specify http://files.basex.org/maven and http://xqj.net/maven (next to Maven Central) then it cannot resolve the above dependency. I fixed this issue by also adding https://raw.github.com/eXist-db/mvn-repo/master as a repository.
I looked at the metadata in http://files.basex.org/maven/com/ettrema/milton-api/maven-metadata.xml which has:
<metadata> <groupId>com.ettrema</groupId> <artifactId>milton-api</artifactId> <versioning> <latest>1.8.1.4</latest> <release>1.8.1.4</release> <versions> <version>1.7.2</version> <version>1.8.0.1</version> </versions> <lastUpdated>20120904214734</lastUpdated> </versioning> </metadata>
It seems that when I use Gradle it uses versions/version to determine if the dependency exists so it concludes that 1.8.1.4 isn't available. I don't know the exact semantics of maven metadata files but isn't this metadata inconsistent? 1.7.2 and 1.8.0.1 is in fact the only version available on files.basex.org/maven.
I will publish some Gradle related scripts once I have ironed out some more details. But here's a teaser which is a lot sexier than a Maven POM (as much as I like angled brackets, POM's are dead-ugly).
I transscribed one of Dirk's examples of running a query with Maven to Gradle.
repositories { maven { url "http://files.basex.org/maven" } maven { url "http://xqj.net/maven" } maven { url "https://raw.github.com/eXist-db/mvn-repo/master" } mavenCentral() }
configurations { basex }
dependencies { basex "org.basex:basex:8.0" basex "org.basex:basex-api:8.0" }
task query(type: JavaExec) { classpath configurations.basex main = "org.basex.BaseX" args "-q", "4+2" }
Nice.
btw have a nice conference, hope to be there next time.
Cheers, --Marc
On Fri, Feb 13, 2015 at 10:57 AM, Dirk Kirsten dk@basex.org wrote:
Hi Wendell,
Including the following snippet into your configuration element should
be enough to set the database path as you see it fit:
<systemProperties> <systemProperty> <key>org.basex.dbpath</key> <value>your/path/to/db</value> </systemProperty> </systemProperties>
More details can be found at
http://mojo.codehaus.org/exec-maven-plugin/usage.html It also explains there how to set the memory allocation.
In general, how the home directory for BaseX is computed is explained in
http://docs.basex.org/wiki/Configuration#Home_Directory
The project path can be set in your .basexgui directory setting
PROJECTPATH = somevalue
I am actually not sure whether it is possible to set this from the
command line or maven, but I don't think so. Of course, using maven it would always be possible to create such a .basexgui file by yourself in an automated fashion.
We are currently at XML Prague, so answering could get a bit slow. For
everyone who is also here you are of course welcome to speak to us, especially at our BaseX User Meetup today in the afternoon ( http://www.xmlprague.cz/preconf2015/#basex). You won't get a better chance at personal debugging help than this, I guess.
Cheers Dirk
-- --Marc
-- --Marc