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
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,
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
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
Hi,
On Jan 25, 2008 12:53 PM, Julian Reschke [EMAIL PROTECTED] 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
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,
Hi,
On Jan 24, 2008 3:31 PM, Julian Reschke [EMAIL PROTECTED] 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
