Make observation polling time configurable
--
Key: JCR-1906
URL: https://issues.apache.org/jira/browse/JCR-1906
Project: Jackrabbit
Issue Type: Improvement
Components: jackrabbit-jcr2spi
Hi,
On Tue, Dec 9, 2008 at 5:40 PM, Alexander Klimetschek <[EMAIL PROTECTED]> wrote:
> As it seems, releases are the major driver for this decision, [...]
Yep, the demand for smaller and quicker releases (see [1]) started the
whole component release debate almost a year ago, and with this
proposa
On Tue, Dec 9, 2008 at 4:21 PM, Jukka Zitting <[EMAIL PROTECTED]> wrote:
> Managing separate release cycles within a single Jira project is quite
> painful. Just look at the version fields in the SLING project for an
> example. And that's just a single release per component so far...
Looks a bit w
[
https://issues.apache.org/jira/browse/JCR-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654836#action_12654836
]
Thomas Mueller commented on JCR-1883:
-
There are multiple solutions to the problem.
One
Hi,
On Tue, Dec 9, 2008 at 4:09 PM, Alexander Klimetschek <[EMAIL PROTECTED]> wrote:
> A separate Jira project for each of it? That somehow adds a lot of
> projects to Jira, which doesn't feel right to me. I would prefer a
> JCRCOMMONS project with each of the maven projects being a subproject.
>
Hi,
On Tue, Dec 9, 2008 at 3:00 PM, Jukka Zitting <[EMAIL PROTECTED]> wrote:
> How about if I created a new Jira project like JCRCMIS for this?
Jira projects are cheap so I just went ahead and created the JCRCMIS
project, see [1].
I've given the "all-developers" group the "Committer" role in JCR
On Tue, Dec 9, 2008 at 3:31 PM, Jukka Zitting <[EMAIL PROTECTED]> wrote:
> c) Here's a list of Jira project keys that I think we could use:
>
> * jackrabbit-parent / JCRPARENT
> * jackrabbit-jcr-tests / JCRTEST
> * jackrabbit-jcr-benchmark / JCRBENCH
> * jackrabbit-jcr-rmi / JCRRMI
> * jackrab
Hi,
On Thu, Dec 4, 2008 at 4:40 PM, Jukka Zitting <[EMAIL PROTECTED]> wrote:
> Thanks for all the comments, keep 'em coming! Here's an updated
> version of the JCR Commons subproject proposal. This version should
> address most of the concerns and issues that were raised.
I plan to call a vote on
Hi Jukka,
On Tue, Dec 9, 2008 at 3:00 PM, Jukka Zitting <[EMAIL PROTECTED]> wrote:
> How about if I created a new Jira project like JCRCMIS for this?
>
> Having sandbox issues in the JCR project has always been a bit
> distracting for release management purposes, and with a specialized
> Jira proj
Hi,
On Tue, Dec 9, 2008 at 1:35 PM, Dominique Pfister
<[EMAIL PROTECTED]> wrote:
> On Tue, Dec 9, 2008 at 1:13 PM, Gabriele Columbro
>> __'jcr-cmis' component in Jira
>> As I mentioned before, does it make sense to have a specific component for
>> this bit of the sandbox or just use the 'sandbox'
Hi all,
find my comments below.
> By the time, I created this pom.xml, 1.5 was not officially released
> yet, and I copied a pom.xml from some other sandbox project. We could
> very well depend on the latest development version or on the released
> version, whatever seems more appropriate, or eve
Dominique Pfister wrote:
> On Tue, Dec 9, 2008 at 1:13 PM, Gabriele Columbro
> <[EMAIL PROTECTED]> wrote:
>> __Core technologies (Axis or CXF)
>> Which WS framework would you suggest? At the moment I have a better feeling
>> for CXF with respect to Axis(2), maybe for the lower footprint it seems to
Hi,
On Tue, Dec 9, 2008 at 1:49 PM, Thomas Müller <[EMAIL PROTECTED]> wrote:
> Did you have a look at the JDBC to JCR bridge:
> http://wiki.apache.org/jackrabbit/QueryUsingJdbc
Yes, I saw that. I'm looking for a more generic alternative, one that
exposes all available node types (or other criteri
Hi,
Did you have a look at the JDBC to JCR bridge:
http://wiki.apache.org/jackrabbit/QueryUsingJdbc
Regards,
Thomas
On Tue, Dec 9, 2008 at 1:46 PM, Jukka Zitting <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Tue, Dec 9, 2008 at 12:52 PM, Alexander Klimetschek <[EMAIL PROTECTED]>
> wrote:
>> Interest
Hi,
On Tue, Dec 9, 2008 at 12:52 PM, Alexander Klimetschek <[EMAIL PROTECTED]>
wrote:
> Interesting ;-) Is the way using these virtual function tables simpler
> than directly implementing the JDBC API? I think the JDBC API is not
> so difficult
The benefit of using Derby "saucer separation"
Hi Gabriele,
On Tue, Dec 9, 2008 at 1:13 PM, Gabriele Columbro
<[EMAIL PROTECTED]> wrote:
> Hi all,
> as this is my first post on the JackRabbit @dev list, I guess a bit of
> introduction is needed: together with my colleague Paolo Mottadelli, I have
> been following the jcr-cmis sandbox thread wi
Hi all,
as this is my first post on the JackRabbit @dev list, I guess a bit of
introduction is needed: together with my colleague Paolo Mottadelli, I have
been following the jcr-cmis sandbox thread with a lot of interest.
Searching how we could help, we noticed the WS component of the jcr-cmis
con
On Tue, Dec 9, 2008 at 12:46 PM, Jukka Zitting <[EMAIL PROTECTED]> wrote:
> I'm planning to do some experiments with the Derby "saucer separation"
> mechanism (see [1]) as a way to implement a JDBC driver for accessing
> JCR content repositories. :-)
Interesting ;-) Is the way using these virtual
Hi,
I'm planning to do some experiments with the Derby "saucer separation"
mechanism (see [1]) as a way to implement a JDBC driver for accessing
JCR content repositories. :-)
Let's see how it turns out... I'll be setting up a jdbc2jcr component
in the sandbox for any prototype code I come up with
On Mon, Dec 8, 2008 at 11:13 PM, pkrishna <[EMAIL PROTECTED]> wrote:
> String query = "//*[jcr:contains(jcr:content, 'Test')]";
> String query = "//jcr:content[jcr:contains(., 'Test')]";
The first argument of jcr:contains() is either ".", which refers to
the local node and by default means all
20 matches
Mail list logo
