You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Julian Reschke <ju...@gmx.de> on 2008/01/24 14:31:34 UTC
Modularize Jackrabbit query parser?
Hi,
under org.apache.jackrabbit.core.query, jackrabbit-core currently
contains everything needed to *parse* JSR-170 query statements, both in
"XPath" and "SQL".
This part of the code is completely independent from jackrabbit-core (I
have successfully borrowed it for use in a proprietary, JCR2SPI-based
server).
As a matter of fact, around a year ago when the EG discussed the topic
of query syntaxes, the way Jackrabbit handles queries was mentioned
repeatedly as proof that supporting two different query syntaxes is not
a big deal, as long as they can be parsed into a single internal
representation.
Therefore I'd suggest to either
- move the query parser into a separate top-level project (with a
dependency on jackrabbit-spi-commons), or to
- move it into jackrabbit-spi-commons.
On the other hand, I can think of a few reasons for not doing that now,
such as:
- with the work on the JCR 2.0 RI, query is a moving target, and
- exposing the internal query tree as a "public" API may be problematic.
Feedback appreciated,
Julian
Re: Modularize Jackrabbit query parser?
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Jan 25, 2008 12:53 PM, Julian Reschke <ju...@gmx.de> wrote:
> - duplicate source and build infrastructure from o.a.j.core.query to
> o.a.j.spi.commons.query, deprecate the old stuff
I wouldn't worry about deprecating it. We've made no backwards
compatibility promises on classes within jackrabbit-core, so IMHO it's
better to just "svn move" the query parser to spi-commons.
BR,
Jukka Zitting
Re: Modularize Jackrabbit query parser?
Posted by Julian Reschke <ju...@gmx.de>.
Marcel Reutegger wrote:
> Jukka Zitting wrote:
>>> - move it into jackrabbit-spi-commons.
>>
>> +1 to moving it to jackrabbit-spi-commons.
>
> +1
>
>>> On the other hand, I can think of a few reasons for not doing that now,
>>> such as:
>>>
>>> - exposing the internal query tree as a "public" API may be problematic.
>>
>> I wouldn't worry too much about those. We can label the query parser
>> in spi-commons so that people don't expect the API to be too stable. I
>> don't see any problems in making the query tree public.
>
> the classes are already now partially public and developers use them ;)
OK,
so next steps could be:
- open JIRA issue
- duplicate source and build infrastructure from o.a.j.core.query to
o.a.j.spi.commons.query, deprecate the old stuff
- switch over jackrabbit.core to use spi-commons for query
- remove the old code
- optimally, add specific test cases for the query tree generation.
BR, Julian
Re: Modularize Jackrabbit query parser?
Posted by Marcel Reutegger <ma...@gmx.net>.
Julian Reschke wrote:
> Marcel Reutegger wrote:
>> Jukka Zitting wrote:
>>>> - move it into jackrabbit-spi-commons.
>>>
>>> +1 to moving it to jackrabbit-spi-commons.
>>
>> +1
>> ...
>
> Okay... Just those parts that are needed for JSR170 query parsing (that
> would be the query tree, the XPath and SQL parsers, but not SQL2 and QOM)?
SQL2 and QOM are yet other representations of a query and should be moved as well.
regards
marcel
Re: Modularize Jackrabbit query parser?
Posted by Julian Reschke <ju...@gmx.de>.
Marcel Reutegger wrote:
> Jukka Zitting wrote:
>>> - move it into jackrabbit-spi-commons.
>>
>> +1 to moving it to jackrabbit-spi-commons.
>
> +1
> ...
Okay... Just those parts that are needed for JSR170 query parsing (that
would be the query tree, the XPath and SQL parsers, but not SQL2 and QOM)?
BR, Julian
Re: Modularize Jackrabbit query parser?
Posted by Marcel Reutegger <ma...@gmx.net>.
Jukka Zitting wrote:
>> - move it into jackrabbit-spi-commons.
>
> +1 to moving it to jackrabbit-spi-commons.
+1
>> On the other hand, I can think of a few reasons for not doing that now,
>> such as:
>>
>> - exposing the internal query tree as a "public" API may be problematic.
>
> I wouldn't worry too much about those. We can label the query parser
> in spi-commons so that people don't expect the API to be too stable. I
> don't see any problems in making the query tree public.
the classes are already now partially public and developers use them ;)
regards
marcel
Re: Modularize Jackrabbit query parser?
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Jan 24, 2008 3:31 PM, Julian Reschke <ju...@gmx.de> wrote:
> Therefore I'd suggest to either
>
> - move the query parser into a separate top-level project (with a
> dependency on jackrabbit-spi-commons), or to
>
> - move it into jackrabbit-spi-commons.
+1 to moving it to jackrabbit-spi-commons.
> On the other hand, I can think of a few reasons for not doing that now,
> such as:
>
> - with the work on the JCR 2.0 RI, query is a moving target, and
>
> - exposing the internal query tree as a "public" API may be problematic.
I wouldn't worry too much about those. We can label the query parser
in spi-commons so that people don't expect the API to be too stable. I
don't see any problems in making the query tree public.
BR,
Jukka Zitting