I am concerned about the name. Jena JDBC implies a level of interoperability with existing JDBC based tools. I also note that JDBC is a trademark which I believe is owned by Oracle.
But I have a few questions: 1. Am I able to use the Jena JDBC driver to access a Jena based triple store using a standard JDBC tool like SquirlSQL? 2. Am I able to use the Jena JDBC driver within a JPA framework like Hibernate? 3. Does it pass the JDBC test suite (mentioned here: http://docs.oracle.com/javase/tutorial/jdbc/overview/index.html) or at least a major subset of the tests? I have not yet located the test suite itself. If the answer is no to any of these questions I wonder if the name is not going to confuse potential users. Claude On Fri, Aug 23, 2013 at 11:16 PM, Stephen Allen <[email protected]> wrote: > Hi Rob, > > Looks pretty good. A few comments: > > a) Typo in second code block in section "Basic Usage | Making a > Connection": s/"jdbc:jena:men:empty=true"/"jdbc:jena:mem:empty=true". > Same error on drivers.html in the second code block of the > "Available Drivers | In-Memory" section. > > b) Would suggest changing the section titles under Basic Usage to > instead read: "Establishing a Connection", "Performing Queries", and > "Performing Updates". > > c) Suggest adding try/finally blocks for both the Query and Update > examples. > > d) Suggest adding an example of transactions for TDB connections > (one that contains both read/update queries would be cool). > > > -Stephen > > > On Fri, Aug 23, 2013 at 5:58 PM, Rob Vesse <[email protected]> wrote: > > I've put together some basic documentation which is in staging at > > http://jena.staging.apache.org/documentation/jdbc/index.html if anyone > > wants to review > > > > Rob > > > > > > On 8/23/13 11:26 AM, "Rob Vesse" <[email protected]> wrote: > > > >>On the JDBC front I think it is essentially ready to go in this release, > >>my main concern is integrating it into the build. > >> > >>Right now it is not called out as a module of the top level POM so does > >>not automatically get built by mvn unless you go and build in the > >>jena-jdbc directory yourself. > >> > >>However it is a slow build at ~5 mins or a modern machine like my 2011 > >>MacBook Pro, and much longer on older/heavily contended machines like > >>Apache build servers. Therefore my concern is whether developers are > >>willing to stomach a longer build on their local machines? > >> > >>One thought I had was about using maven profiles, right now I have the > >>following in my local uncommitted top level POM: > >> > >><profiles> > >><profile> > >><!-- > >>This is the dev profile, it only builds the common modules and > >>does not build the slow building JDBC modules or the distribution > packages > >>--> > >><id>dev</id> > >><activation> > >><activeByDefault>true</activeByDefault> > >></activation> > >><modules> > >><module>jena-parent</module> > >><module>jena-iri</module> > >><module>jena-core</module> > >><module>jena-arq</module> > >><module>jena-tdb</module> > >><module>jena-text</module> > >><module>jena-sdb</module> > >><module>jena-fuseki</module> > >><!-- Slow to build - exclude from default dev build --> > >><!-- <module>jena-jdbc</module>--> > >><module>apache-jena-libs</module> > >><!-- Don't build distro package every time --> > >><!-- <module>apache-jena</module> --> > >></modules> > >></profile> > >><profile> > >><!-- > >>This is the complete profile, it builds everything including slow > >>building modules and > >>the distribution packages. > >>This profile should be enabled when cutting a release > >>-P apache-release,complete > >>--> > >><id>complete</id> > >><modules> > >><module>jena-parent</module> > >><module>jena-iri</module> > >><module>jena-core</module> > >><module>jena-arq</module> > >><module>jena-tdb</module> > >><module>jena-text</module> > >><module>jena-sdb</module> > >><module>jena-fuseki</module> > >><module>jena-jdbc</module> > >><module>apache-jena-libs</module> > >><module>apache-jena</module> > >></modules> > >></profile> > >></profiles> > >> > >>Would people be OK with going with something like this? It would mean > >>that by default we only build the common modules and then when we come to > >>do releases or want a more thorough build we can build the complete thing > >>(or even add a third release specific profile?). We may want to have a > >>little more discussion about which modules go in which profile and how > >>many profiles we want to have. I can commit what I have now and people > >>can iterate on it? > >> > >>Getting back to JDBC specifics, no there is not any website documentation > >>yet. However the javadoc is pretty comprehensive so with a couple of > >>basic web pages written up may be sufficient, I will try and at least > >>stub those pages out today. > >> > >>Rob > > > -- I like: Like Like - The likeliest place on the web<http://like-like.xenei.com> Identity: https://www.identify.nu/[email protected] LinkedIn: http://www.linkedin.com/in/claudewarren
