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
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.
>
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,
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.
COMPONENTS
The JCR Commons subproject would take over the development and
maintenance of the following
Hi,
On Wed, Dec 3, 2008 at 11:45 AM, Alexander Klimetschek <[EMAIL PROTECTED]>
wrote:
> Well, I guess jcr-commons should really be part of the commons
> subproject, as it is supposed to help with the jcr api in general.
The jcr-commons component has a long history of being more a
collection of u
hi jukka
That should still be possible, though with one caveat: the latest
version of jcr-commons in the build would now be the latest _released_
version.
Is this a problem?
it isn't a problem but it can be pretty cumbersome
if fixes/improvements made to any of the commons project
are float
On Wed, Dec 3, 2008 at 11:36 AM, Jukka Zitting <[EMAIL PROTECTED]> wrote:
> Is this a problem? If yes, then we could keep such upstream
> dependencies with the core for now, only moving those components that
> aren't really related to changes in core components. That would leave
> us with:
>
> *
Hi,
On Wed, Dec 3, 2008 at 9:13 AM, Angela Schreiber <[EMAIL PROTECTED]> wrote:
>> Note that the webdav component is a bit special in that it actually
>> doesn't have much to do with JCR, so eventually it might be useful to
>> find a good home for it for example in Apache HttpComponents.
>
> that
hi jukka
Note that the webdav component is a bit special in that it actually
doesn't have much to do with JCR, so eventually it might be useful to
find a good home for it for example in Apache HttpComponents.
that has been discussed in the past and honestly i don't
want to start that discussi
On Tue, Dec 2, 2008 at 5:42 PM, Alexander Klimetschek <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 2, 2008 at 4:52 PM, Jukka Zitting <[EMAIL PROTECTED]> wrote:
>> * Mailing lists: We create the following new mailing lists for the
>> subproject: commons-{user,dev,[EMAIL PROTECTED]
> ...Not sure if we
Hi,
On Tue, Dec 2, 2008 at 5:42 PM, Alexander Klimetschek <[EMAIL PROTECTED]> wrote:
> Do all these projects solely rely on the JCR API?
Some of them have dependencies to other commons projects and/or to
external components. For example jcr-rmi depends on jcr-commons and
slf4j.
> They shouldn't
On Tue, Dec 2, 2008 at 4:52 PM, Jukka Zitting <[EMAIL PROTECTED]> wrote:
>
> COMPONENTS
>
> The JCR Commons subproject would take over the development and
> maintenance of the following components:
>
>* jackrabbit-jcr-commons
>* jackrabbit-jcr-tests
>* jackrabbit-jcr-benchmark
>* ja
14 matches
Mail list logo