Getting help with Jena

We are always happy to help you get your Jena project going. Jena has been around for many years, there are many archives of past questions, tutorials and articles on the web. A quick search may well answer your question directly! If not, please feel free to post a question to the user support list (details below).

Email support lists

The main user support list is users@jena.apache.org. To join this list, please send an email to: users-subscribe@jena.apache.org from the email account you want to subscribe with. This list is a good place to ask for advice on developing Jena-based applications, or solving a problem with using Jena. Please see below for notes on asking good questions. The list is archived at jena.markmail.org or mail-archives.apache.org.

The developers list is dev@jena.apache.org. To join this list, please send an email to: dev-subscribe@jena.apache.org from the email account you want to subscribe with. This list is a good place to discuss the development of the Jena platform itself, including patches you want to submit.

Full details of Apache mailing lists: http://www.apache.org/foundation/mailinglists.html.

Other channels

Some Jena developers hang out on #jena on irc.freenode.net.

Other resources

There are curated collections of Jena questions on StackOverflow and answers.semanticweb.com.

How to ask a good question

Asking good questions is the best way to get good answers. Try to follow these tips:

• Make the question precise and specific. "My code doesn't work", for example, does not help us to help you as much as "The following SPARQL query gave me an answer I didn't expect".

• Show that you've tried to solve the problem yourself. Everyone who answers questions on the list has a full-time job or study to do; no-one gets paid for answering these support questions. Spend their goodwill wisely: "Here's the code I tried..." or "I read in the documentation that ..." shows that you've at least made some effort to find things out for yourself.

• Where appropriate show a complete test case. Seeing where your code goes wrong is generally much easier if we can run it our our computers. Corollaries: don't post your entire project - take some time to reduce it down to a minimal test case. Include enough data - runnable code is no help if critical resources like *.rdf files are missing. Reducing your code down to a minimal test case is often enough for you to figure out the problem yourself, which is always satisfying!

• Don't re-post your question after only a few hours. People are busy, and may be in a different timezone to you. If you're not sure if your question made it to the list, look in the archive.

• Adding lots of exclamation marks or other punctuation will not move your question up the queue. Quite the reverse, in fact.

• Ask questions on the list, rather than emailing the developers directly. This gives us the chance to share the load of answering questions, and also ensures that answers are archived in case they're of use to others in the future.