Re: Fwd: SPARQL subset as a PATCH format for LDP

[Andy Seaborne]

On 24/07/14 19:58, Sergio Fernández wrote:

LDPath as influence to LDPatch?

Well, I'm still awaiting what it contributes for what RDF Patch already does...


RDF Patch is certainly at the lower level, machine level with a slant to 
processing issues over "readability".  It combines with binary RDF [1], 
which in my experiments parses at 560K triples/s, or x3 faster than I 
can get N-triples to go.


But these engineering issues are less in the sight of LDP which, 
realistically, is slanted to smaller data as the unit of change.


Andy

[1] https://github.com/afs/rdf-thrift



-- Forwarded message --
From: Alexandre Bertails 
Date: Jul 24, 2014 8:30 PM
Subject: SPARQL subset as a PATCH format for LDP
To: "public-ldp...@w3.org" 
Cc:


All,

I have been thinking a lot about the SPARQL subset idea and I would
like to share some thoughts. As you could have expected from the last
call, I am not in favor of it, so I have taken the time to document my
issues with the approach.

First, let me remind you the scope of LD Patch. It is PATCH format for
partial updates of LDP-RS. So it's only about RDF graphs. It is not
intended for updating quad stores, nor named graphs. Also, it is not
meant to be a high-level language but rather an assembly one. For that
reason, the editors challenged themselves for not adding higher-level
features.

Skolemization is not used. The assumption is that bnodes form tree
structures. The idea is that most of those trees (and the bnodes in
them) can be distinguished by filtering on sub-components of those
trees. I recommend [1] for a recent and thorough analysis confirming
those assumptions.

That is the very reason behind the LD Path (no 'c') algebra, which
shares some similarities with XPath. They are applied left-to-right,
and recursively for path constraints. The semantics formally specifies
the order in which those operations must be evaluated. So LDP
application writers can rely on that semantics for runtime
characteristics, for example by restraining the node sets as early as
possible in the path, by probably starting from the leaves of the
tree, and then moving up in the tree, until reaching the bnode.

So, SPARQL. Yes, you can consider a subset with similar expressive
power. People seem to think that defining the concrete syntax would be
enough, and that it would be as easy if not easier than LD Patch. I
disagree. First, the two concrete syntaxes would share a lot of the
production rules, basically all the ones borrowed from Turtle. The
additional ones are no issue in both cases.

Then, I have heard people saying that we wouldn't need to write down
the operational semantics, because we could say it's the same than
SPARQL Update, but for that subset of the syntax. I disagree. Because
as a developer and as a user, I would have to be sure I understand
well the SPARQL semantics to either implement LD Patch (if I don't
want to depend on an existing SPARQL implementation), or to use it. So
I'd argue that the semantics _has_ to be written. And I'd have to
reject valid SPARQL Update queries which are not in the subset.

Another issue is that we will still need Basic Graph Patterns, the (S
P O .)-s in the WHERE clause, which rely on intermediate ResultSet-s
for their semantics.

For example:

Bind ?event 
/-schema:url[/schema:startDate="2009-02-04"]/schema:location[/schema:name="Long
Beach, California"][/schema:geo[/schema:latitude][/schema:longitude]]

would be equivalent to something like that:

WHERE {
   ?event schema:url  .
   ?event schema:startDate "2009-02-04" .
   ?event schema:location ?loc .
   ?loc schema:name "Long Beach, California" .
   ?loc schema:geo ?geo .
   ?geo schema:latitude [] .
   ?geo schema:longitude [] .
}

If we want the same performance characterics (mainly, predictability),
we would have to refine the SPARQL semantics so that the order of the
clauses matters (ie. no need to depend on a query optimiser). And we
would need to do some static analysis on the query to make sure that
ResultSet-s are not needed. In any case, it goes beyond the idea of
using subset of the syntax + a pointer to SPARQL Update semantics.

Another problem is the support for rdf:list. I have just finished
writing down the semantics for UpdateList and based on that
experience, I know this is something I want to rely on as a user,
because it is so easy to get it wrong, so I want native support for
it. And I don't think it is possible to do something equivalent in
SPARQL Update. That is a huge drawback as list manipulation (eg. in
JSON-LD, or Turtle) is an everyday task.

So to summarize my issues with the approach:

1. semantics is not that easy to define
2. performance characteristics
3. no native support for rdf:list
4. needs to explain to the user how it differs from existing SPARQL
Update

SPARQL Update is good at doing what it was designed for, but there is
little interest in being syntax

Fwd: SPARQL subset as a PATCH format for LDP

[Sergio Fernández]

LDPath as influence to LDPatch?

Well, I'm still awaiting what it contributes for what RDF Patch already does...

-- Forwarded message --
From: Alexandre Bertails 
Date: Jul 24, 2014 8:30 PM
Subject: SPARQL subset as a PATCH format for LDP
To: "public-ldp...@w3.org" 
Cc: 

> All, 
>
> I have been thinking a lot about the SPARQL subset idea and I would 
> like to share some thoughts. As you could have expected from the last 
> call, I am not in favor of it, so I have taken the time to document my 
> issues with the approach. 
>
> First, let me remind you the scope of LD Patch. It is PATCH format for 
> partial updates of LDP-RS. So it's only about RDF graphs. It is not 
> intended for updating quad stores, nor named graphs. Also, it is not 
> meant to be a high-level language but rather an assembly one. For that 
> reason, the editors challenged themselves for not adding higher-level 
> features. 
>
> Skolemization is not used. The assumption is that bnodes form tree 
> structures. The idea is that most of those trees (and the bnodes in 
> them) can be distinguished by filtering on sub-components of those 
> trees. I recommend [1] for a recent and thorough analysis confirming 
> those assumptions. 
>
> That is the very reason behind the LD Path (no 'c') algebra, which 
> shares some similarities with XPath. They are applied left-to-right, 
> and recursively for path constraints. The semantics formally specifies 
> the order in which those operations must be evaluated. So LDP 
> application writers can rely on that semantics for runtime 
> characteristics, for example by restraining the node sets as early as 
> possible in the path, by probably starting from the leaves of the 
> tree, and then moving up in the tree, until reaching the bnode. 
>
> So, SPARQL. Yes, you can consider a subset with similar expressive 
> power. People seem to think that defining the concrete syntax would be 
> enough, and that it would be as easy if not easier than LD Patch. I 
> disagree. First, the two concrete syntaxes would share a lot of the 
> production rules, basically all the ones borrowed from Turtle. The 
> additional ones are no issue in both cases. 
>
> Then, I have heard people saying that we wouldn't need to write down 
> the operational semantics, because we could say it's the same than 
> SPARQL Update, but for that subset of the syntax. I disagree. Because 
> as a developer and as a user, I would have to be sure I understand 
> well the SPARQL semantics to either implement LD Patch (if I don't 
> want to depend on an existing SPARQL implementation), or to use it. So 
> I'd argue that the semantics _has_ to be written. And I'd have to 
> reject valid SPARQL Update queries which are not in the subset. 
>
> Another issue is that we will still need Basic Graph Patterns, the (S 
> P O .)-s in the WHERE clause, which rely on intermediate ResultSet-s 
> for their semantics. 
>
> For example: 
>
> Bind ?event  
> /-schema:url[/schema:startDate="2009-02-04"]/schema:location[/schema:name="Long
>  
> Beach, California"][/schema:geo[/schema:latitude][/schema:longitude]] 
>
> would be equivalent to something like that: 
>
> WHERE { 
>   ?event schema:url  . 
>   ?event schema:startDate "2009-02-04" . 
>   ?event schema:location ?loc . 
>   ?loc schema:name "Long Beach, California" . 
>   ?loc schema:geo ?geo . 
>   ?geo schema:latitude [] . 
>   ?geo schema:longitude [] . 
> } 
>
> If we want the same performance characterics (mainly, predictability), 
> we would have to refine the SPARQL semantics so that the order of the 
> clauses matters (ie. no need to depend on a query optimiser). And we 
> would need to do some static analysis on the query to make sure that 
> ResultSet-s are not needed. In any case, it goes beyond the idea of 
> using subset of the syntax + a pointer to SPARQL Update semantics. 
>
> Another problem is the support for rdf:list. I have just finished 
> writing down the semantics for UpdateList and based on that 
> experience, I know this is something I want to rely on as a user, 
> because it is so easy to get it wrong, so I want native support for 
> it. And I don't think it is possible to do something equivalent in 
> SPARQL Update. That is a huge drawback as list manipulation (eg. in 
> JSON-LD, or Turtle) is an everyday task. 
>
> So to summarize my issues with the approach: 
>
> 1. semantics is not that easy to define 
> 2. performance characteristics 
> 3. no native support for rdf:list 
> 4. needs to explain to the user how it differs from existing SPARQL 
> Update 
>
> SPARQL Update is good at doing what it was designed for, but there is 
> little interest in being syntax compatible with it. 
>
> Regards, 
>
> Alexandre 
>
> [1] http://www.websemanticsjournal.org/index.php/ps/article/view/365 
>

Re: [GSoC] less 1 month left

[Sergio Fernández]

Dear Qihong Lin,

On 24/07/14 14:06, Qihong Lin wrote:

Thanks for your reminder! I've been watching the marmotta's branch
refs/heads/develop (not much changes related to ldp service these
days). As you pointed out, I just checked the ldp branch and updated
my LdpServiceSPARQLImpl accordingly [1]. Now both LdpServiceSPARQLImpl
and LdpServiceImpl passed my unit tests as expected.


It'd be great if you can report the current status of the SPARQL 
implementation, as well as periodically report your progress.



I'll keep a close eye on both the develop and ldp branches in the
coming weeks. With previous experience in the first half part of the
project, I think it's not difficult to translate the remaining changes
to the SPARQL implementations. I'll check and translate the changes
everyday. After the GSoC project, I can also offer contribution
related to this work.


That'd be great! That's one of the goals of GSoC is not always explored 
by the student. Hope you can continue collaborating with us after the 
program ends.



In the meanwhile, I'll work on the documentations and the tests
(performance, w3c test suite, etc), as you mentioned in the mid-term
evaluation. I've been studying JMeter, TestNG and Rest-Assured. I'll
have a try in the next week and keep you posted.


Where are you documenting all your stuff? As I explained you, I'd 
appreciate to have access to it in advance.


Cheers,

--
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 660 2747 925
e: sergio.fernan...@redlink.co
w: http://redlink.co

Re: [GSoC] less 1 month left

[Qihong Lin]

Dear Sergio,

Thanks for your reminder! I've been watching the marmotta's branch
refs/heads/develop (not much changes related to ldp service these
days). As you pointed out, I just checked the ldp branch and updated
my LdpServiceSPARQLImpl accordingly [1]. Now both LdpServiceSPARQLImpl
and LdpServiceImpl passed my unit tests as expected.

I'll keep a close eye on both the develop and ldp branches in the
coming weeks. With previous experience in the first half part of the
project, I think it's not difficult to translate the remaining changes
to the SPARQL implementations. I'll check and translate the changes
everyday. After the GSoC project, I can also offer contribution
related to this work.

In the meanwhile, I'll work on the documentations and the tests
(performance, w3c test suite, etc), as you mentioned in the mid-term
evaluation. I've been studying JMeter, TestNG and Rest-Assured. I'll
have a try in the next week and keep you posted.


Best,
Qihong Lin

[1] 
https://github.com/confidencesun/marmotta/commit/cff11e06c0c13bd8d8a10fea5e9eccf8d31f86ba

On Wed, Jul 23, 2014 at 3:45 PM, Sergio Fernández  wrote:
> According the official time-line:
>
> http://www.google-melange.com/gsoc/events/google/gsoc2014
>
> August 18th is the official 'pencils down' date for GSoC this year.
>
> Please, Qihong Lin, remember to continue pushing hard. I did not see some
> much activity or reporting in the last weeks, and you still have so much to
> do for achieving the goals of the project.
>
> We had been working at the ldp branch, fixing details discovered by the W3C
> test suite. They mainly affect the web service layer, but I think we
> extended the service api with some new methods. Next week Jakob and myself
> we plan to continue working on that, with the idea of merging stable changes
> back to develop during the week. Please, stay tune to the changes, and
> decide whether you can afford or not to adopt them at this stage.
>
> Personally I'll offline 6th to 20th, so everything that you deliver before
> would make my final evaluation much easier.
>
> Thanks for your contribution to the Apache Marmotta project.
>
> Cheers,
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 660 2747 925
> e: sergio.fernan...@redlink.co
> w: http://redlink.co

[jira] [Updated] (MARMOTTA-499) CSS not working with JRE 8

[JIRA]

 [ 
https://issues.apache.org/jira/browse/MARMOTTA-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergio Fernández updated MARMOTTA-499:
--

Summary: CSS not working with JRE 8  (was: CSS not working)

> CSS not working with JRE 8
> --
>
> Key: MARMOTTA-499
> URL: https://issues.apache.org/jira/browse/MARMOTTA-499
> Project: Marmotta
>  Issue Type: Bug
>  Components: Admin Interface
>Affects Versions: 3.2.0
> Environment: Mac OS X
>Reporter: Alvaro Graves
>Assignee: Sergio Fernández
>Priority: Trivial
>  Labels: easyfix
>
> No CSS seems to work in the interface. I downloaded marmotta 3.2.0 and it is 
> running on a Mac OS X Mavericks machine.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (MARMOTTA-499) CSS not working

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/MARMOTTA-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14073072#comment-14073072
 ] 

ASF subversion and git services commented on MARMOTTA-499:
--

Commit 0d3bdf8cfc11dc047603fbd306aed338f2efd4d3 in marmotta's branch 
refs/heads/MARMOTTA-499 from [~wikier]
[ https://git-wip-us.apache.org/repos/asf?p=marmotta.git;h=0d3bdf8 ]

Merge branch 'develop' into MARMOTTA-499


> CSS not working
> ---
>
> Key: MARMOTTA-499
> URL: https://issues.apache.org/jira/browse/MARMOTTA-499
> Project: Marmotta
>  Issue Type: Bug
>  Components: Admin Interface
>Affects Versions: 3.2.0
> Environment: Mac OS X
>Reporter: Alvaro Graves
>Assignee: Sergio Fernández
>Priority: Trivial
>  Labels: easyfix
>
> No CSS seems to work in the interface. I downloaded marmotta 3.2.0 and it is 
> running on a Mac OS X Mavericks machine.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (MARMOTTA-499) CSS not working

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/MARMOTTA-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14073068#comment-14073068
 ] 

ASF subversion and git services commented on MARMOTTA-499:
--

Commit 1dd77c478c1c8771af966e4e0352c94213e6154c in marmotta's branch 
refs/heads/MARMOTTA-499 from [~wikier]
[ https://git-wip-us.apache.org/repos/asf?p=marmotta.git;h=1dd77c4 ]

MARMOTTA-499: remove debug logging


> CSS not working
> ---
>
> Key: MARMOTTA-499
> URL: https://issues.apache.org/jira/browse/MARMOTTA-499
> Project: Marmotta
>  Issue Type: Bug
>  Components: Admin Interface
>Affects Versions: 3.2.0
> Environment: Mac OS X
>Reporter: Alvaro Graves
>Assignee: Sergio Fernández
>Priority: Trivial
>  Labels: easyfix
>
> No CSS seems to work in the interface. I downloaded marmotta 3.2.0 and it is 
> running on a Mac OS X Mavericks machine.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (MARMOTTA-499) CSS not working

[JIRA]

[ 
https://issues.apache.org/jira/browse/MARMOTTA-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14073071#comment-14073071
 ] 

Sergio Fernández commented on MARMOTTA-499:
---

No [~dunham], in the MARMOTTA-499 we already moved out from mime-utils in favor 
of Apache Tika, which is a well maintained and reliable library. 

Anyway, the unit tests work fine with both Java7 and Java8, so we can discard 
an issue from Tika. I'll update to users@tomcat.a.o with our latest inquiries, 
and come back with the conclusions.




> CSS not working
> ---
>
> Key: MARMOTTA-499
> URL: https://issues.apache.org/jira/browse/MARMOTTA-499
> Project: Marmotta
>  Issue Type: Bug
>  Components: Admin Interface
>Affects Versions: 3.2.0
> Environment: Mac OS X
>Reporter: Alvaro Graves
>Assignee: Sergio Fernández
>Priority: Trivial
>  Labels: easyfix
>
> No CSS seems to work in the interface. I downloaded marmotta 3.2.0 and it is 
> running on a Mac OS X Mavericks machine.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (MARMOTTA-513) JAX-RS Doclet is not compatible with the javadoc from JDK8

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/MARMOTTA-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14073070#comment-14073070
 ] 

ASF subversion and git services commented on MARMOTTA-513:
--

Commit d5241ed9f6f88598f0973d0bfda75c6add2fca9b in marmotta's branch 
refs/heads/MARMOTTA-499 from [~wikier]
[ https://git-wip-us.apache.org/repos/asf?p=marmotta.git;h=d5241ed ]

MARMOTTA-513: updated to com.lunatech.jax-doclets.doclets:doclets:0.10.1


> JAX-RS Doclet is not compatible with the javadoc from JDK8
> --
>
> Key: MARMOTTA-513
> URL: https://issues.apache.org/jira/browse/MARMOTTA-513
> Project: Marmotta
>  Issue Type: Bug
>  Components: Build Environment
>Affects Versions: 3.2.1
>Reporter: Sergio Fernández
>Assignee: Sergio Fernández
>  Labels: doclet, javadoc, jdk8
> Fix For: 3.3.0
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> A user has reported issues generating the javadoc with JDK8:
> http://mail-archives.apache.org/mod_mbox/marmotta-users/201407.mbox/%3C2D26C375-2602-49EF-BFC0-8801EA13C6A5%40vrtx.com%3E
> {quote}
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 35.621 s
> [INFO] Finished at: 2014-07-07T12:32:48-04:00
> [INFO] Final Memory: 104M/265M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-javadoc-plugin:2.9:javadoc (restapi) on 
> project marmotta-core: An error has occurred in REST API report generation:
> [ERROR] Exit code: 1 - javadoc: error - In doclet class 
> com.lunatech.doclets.jax.jaxrs.JAXRSDoclet,  method start has thrown an 
> exception java.lang.reflect.InvocationTargetException
> [ERROR] java.lang.NullPointerException
> [ERROR] at 
> com.lunatech.doclets.jax.jaxrs.JAXRSDoclet.(JAXRSDoclet.java:84)
> [ERROR] at 
> com.lunatech.doclets.jax.jaxrs.JAXRSDoclet.start(JAXRSDoclet.java:78)
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [ERROR] at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [ERROR] at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [ERROR] at java.lang.reflect.Method.invoke(Method.java:483)
> [ERROR] at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:310)
> [ERROR] at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:189)
> [ERROR] at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:366)
> [ERROR] at com.sun.tools.javadoc.Start.begin(Start.java:219)
> [ERROR] at com.sun.tools.javadoc.Start.begin(Start.java:205)
> [ERROR] at com.sun.tools.javadoc.Main.execute(Main.java:64)
> [ERROR] at com.sun.tools.javadoc.Main.main(Main.java:54)
> [ERROR]
> [ERROR] Command line was: /app/java/jdk1.8.0_05/jre/../bin/javadoc @options 
> @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in 
> '/home/dunham/marmotta-src/marmotta/platform/marmotta-core/target/classes/web/doc/rest'
>  dir.
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-javadoc-plugin:2.9:javadoc (restapi) on 
> project marmotta-core: An error has occurred in REST API report generation:
> Exit code: 1 - javadoc: error - In doclet class 
> com.lunatech.doclets.jax.jaxrs.JAXRSDoclet,  method start has thrown an 
> exception java.lang.reflect.InvocationTargetException
> java.lang.NullPointerException
> at 
> com.lunatech.doclets.jax.jaxrs.JAXRSDoclet.(JAXRSDoclet.java:84)
> at 
> com.lunatech.doclets.jax.jaxrs.JAXRSDoclet.start(JAXRSDoclet.java:78)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:310)
> at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:189)
> at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:366)
> at com.sun.tools.javadoc.Start.begin(Start.java:219)
> at com.sun.tools.javadoc.Start.begin(Start.java:205)
> at com.sun.tools.javadoc.Main.execute(Main.java:64)
> at com.sun.tools.javadoc.Main.main(Main.java:54)
> Command line was: /app/java/jdk1.8.0_05/jre/../bin/javadoc @options @packages
> Refer to the generated Javadoc files in 
> '/home/dunham/marmotta-src/marmotta/platform/marmotta-core/target/classes/web/doc/rest'
>  dir.
> at 
> org.apache.maven.lifecycle.internal.

[jira] [Commented] (MARMOTTA-513) JAX-RS Doclet is not compatible with the javadoc from JDK8

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/MARMOTTA-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14073069#comment-14073069
 ] 

ASF subversion and git services commented on MARMOTTA-513:
--

Commit 42f5db0588112ab17974e42142a9c280dc729dcf in marmotta's branch 
refs/heads/MARMOTTA-499 from [~wikier]
[ https://git-wip-us.apache.org/repos/asf?p=marmotta.git;h=42f5db0 ]

MARMOTTA-513: preparing the build for the transition towards a jax-doclets 
release which solves the issue


> JAX-RS Doclet is not compatible with the javadoc from JDK8
> --
>
> Key: MARMOTTA-513
> URL: https://issues.apache.org/jira/browse/MARMOTTA-513
> Project: Marmotta
>  Issue Type: Bug
>  Components: Build Environment
>Affects Versions: 3.2.1
>Reporter: Sergio Fernández
>Assignee: Sergio Fernández
>  Labels: doclet, javadoc, jdk8
> Fix For: 3.3.0
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> A user has reported issues generating the javadoc with JDK8:
> http://mail-archives.apache.org/mod_mbox/marmotta-users/201407.mbox/%3C2D26C375-2602-49EF-BFC0-8801EA13C6A5%40vrtx.com%3E
> {quote}
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 35.621 s
> [INFO] Finished at: 2014-07-07T12:32:48-04:00
> [INFO] Final Memory: 104M/265M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-javadoc-plugin:2.9:javadoc (restapi) on 
> project marmotta-core: An error has occurred in REST API report generation:
> [ERROR] Exit code: 1 - javadoc: error - In doclet class 
> com.lunatech.doclets.jax.jaxrs.JAXRSDoclet,  method start has thrown an 
> exception java.lang.reflect.InvocationTargetException
> [ERROR] java.lang.NullPointerException
> [ERROR] at 
> com.lunatech.doclets.jax.jaxrs.JAXRSDoclet.(JAXRSDoclet.java:84)
> [ERROR] at 
> com.lunatech.doclets.jax.jaxrs.JAXRSDoclet.start(JAXRSDoclet.java:78)
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [ERROR] at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [ERROR] at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [ERROR] at java.lang.reflect.Method.invoke(Method.java:483)
> [ERROR] at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:310)
> [ERROR] at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:189)
> [ERROR] at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:366)
> [ERROR] at com.sun.tools.javadoc.Start.begin(Start.java:219)
> [ERROR] at com.sun.tools.javadoc.Start.begin(Start.java:205)
> [ERROR] at com.sun.tools.javadoc.Main.execute(Main.java:64)
> [ERROR] at com.sun.tools.javadoc.Main.main(Main.java:54)
> [ERROR]
> [ERROR] Command line was: /app/java/jdk1.8.0_05/jre/../bin/javadoc @options 
> @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in 
> '/home/dunham/marmotta-src/marmotta/platform/marmotta-core/target/classes/web/doc/rest'
>  dir.
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-javadoc-plugin:2.9:javadoc (restapi) on 
> project marmotta-core: An error has occurred in REST API report generation:
> Exit code: 1 - javadoc: error - In doclet class 
> com.lunatech.doclets.jax.jaxrs.JAXRSDoclet,  method start has thrown an 
> exception java.lang.reflect.InvocationTargetException
> java.lang.NullPointerException
> at 
> com.lunatech.doclets.jax.jaxrs.JAXRSDoclet.(JAXRSDoclet.java:84)
> at 
> com.lunatech.doclets.jax.jaxrs.JAXRSDoclet.start(JAXRSDoclet.java:78)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:310)
> at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:189)
> at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:366)
> at com.sun.tools.javadoc.Start.begin(Start.java:219)
> at com.sun.tools.javadoc.Start.begin(Start.java:205)
> at com.sun.tools.javadoc.Main.execute(Main.java:64)
> at com.sun.tools.javadoc.Main.main(Main.java:54)
> Command line was: /app/java/jdk1.8.0_05/jre/../bin/javadoc @options @packages
> Refer to the generated Javadoc files in 
> '/home/dunham/marmotta-src/marmotta/platform/marmotta-core/target/classes/web/doc/rest'
>  dir.
> at 
> or