[VOTE] Create the JCR Commons subproject

[Jukka Zitting <ju...@gmail.com>]

Hi,

As recently discussed, I would like us to create a Jackrabbit
subproject called Apache JCR Commons for developing and maintaining
selected Jackrabbit components that are not tightly coupled with our
content repository implementation.  See the full proposal below.

Please vote on creating the proposed subproject. The vote is open for
the next 72 hours and the votes from Jackrabbit PMC members are
binding.

    [ ] +1 Create the JCR Commons subproject
    [ ] -1 Don't create the JCR Commons subproject

Here's my +1.

BR,

Jukka Zitting

----

COMPONENTS

The JCR Commons subproject would take over the development and
maintenance of the following components:

  * jackrabbit-parent
  * jackrabbit-jcr-tests
  * jackrabbit-jcr-benchmark
  * jackrabbit-jcr-rmi
  * jackrabbit-jcr-servlet
  * jackrabbit-classloader
  * jackrabbit-ocm (including ocm-nodemanagement)

Most notably (and a bit surprisingly), the jcr-commons component would
remain with the core project for now to avoid complicating the
development workflow for issues that may range over component
boundaries. We may need to split the jcr-commons component to be able
to move parts of the code to the proposed subproject, but that's a
separate discussion that we don't need to solve now.

Similarly, the jcr-server and webdav components will be kept with core
for now until we have better idea about what to do there (see
JCR-417).

I also decided to put the jackrabbit-parent component into the commons
subproject. The parent POM does contain some core-specific parts, but
I believe we can move those back to the core components and make the
parent POM contain only truly Jackrabbit-wide information and
settings.

For comparison, the following components would remain as the core
Jackrabbit project:

   * jackrabbit-api
   * jackrabbit-core
   * jackrabbit-text-extractors
   * jackrabbit-webdav
   * jackrabbit-jcr-server
   * jackrabbit-webapp
   * jackrabbit-jca
   * jackrabbit-spi
   * jackrabbit-spi-commons
   * jackrabbit-jcr2spi
   * jackrabbit-spi2jcr
   * jackrabbit-standalone

COMMUNITY

* Committers: For now there will be just a single set of Jackrabbit
committers. Later on we may want to consider adopting a "subproject
committer" concept for making it easier to grant someone committership
to just the commons components.

* PMC: The Jackrabbit PMC will govern also this new subproject.

* Apache Commons: We will work with the Apache Commons project to find
whether and how these JCR Commons components could be included in the
recently proposed "federated commons" concept. This would likely mean
us following some Apache Commons practices and having a link to the
JCR Commons site listed somewhere on the Apache Commons web site.

DEVELOPMENT

* Initial code: The initial code for the new subproject would come
from the selected existing components in Jackrabbit trunk.

* Releases: Each component within the new subproject would have it's
own independent release cycle. To avoid confusion with the existing
1.x releases, the release numbering of the moved components would
start at 2.0. Since all these components are relatively small and
tightly scoped, it would probably be useful to keep their version
numbering down to just two levels, i.e. use x.y instead of x.y.z as
the numbering scheme.

INFRASTRUCTURE

* Web site: The subproject will have its own web site at
http://jackrabbit.apache.org/commons/. We might want to follow the
example of Apache Commons in organizing this web site.

* Mailing lists: We will use the existing
{user,dev,commits}@jackrabbit.apache.org mailing lists for the new
subproject. To make it easier to track topics about selected commons
components, we should adopt a practice of prefixing related email
subjects, for example using [rmi] for messages about JCR-RMI.

* Subversion: We create a new asf/jackrabbit/commons directory that
will contain all the code of the new subproject. Each component will
have it's own {trunk,branches,tags} structure within this subtree. For
example, the JCR-RMI component would be developed in
asf/jackrabbit/commons/jcr-rmi/trunk. All Jackrabbit committers will
have write access to this subtree. Notifications of commits to this
subtree will be sent to the commits@jackrabbit list.

* Issue tracker: We create separate Jira projects for each component
in the subproject. These projects will be grouped using the
"Jackrabbit" category in Jira. Update messages will be sent to the
dev@jackrabbit list.

[RESULT] [VOTE] Create the JCR Commons subproject

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Tue, Jan 6, 2009 at 2:40 PM, Jukka Zitting <ju...@gmail.com> wrote:
> Please vote on creating the proposed subproject. The vote is open for
> the next 72 hours and the votes from Jackrabbit PMC members are
> binding.

The vote passes as follows:

    +1 Alexander Klimetschek
    +1 Claus Köll
    +1 Felix Meschberger
    +1 Jukka Zitting
    +1 Tobias Bocanegra

Thanks for voting! I'll start setting this up. We can work out the
details as we proceed.

BR,

Jukka Zitting

Re: [VOTE] Create the JCR Commons subproject

[Alexander Klimetschek <ak...@day.com>]

+1 Create the JCR Commons subproject

For the jackrabbit-jcr-commons, jcr-server, webdav and also spi
components we should try to move them to the commons as soon as
possible after the split. It would be good to have the spi separate
and more "open" for use to the public (ie. building "connectors"), as
an alternative to the JBoss DNA stuff :-)

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

AW: [VOTE] Create the JCR Commons subproject

[KÖLL Claus <C....@TIROL.GV.AT>]

my +1

greets
claus

Re: [VOTE] Create the JCR Commons subproject

[Tobias Bocanegra <tr...@day.com>]

>  As recently discussed, I would like us to create a Jackrabbit
>  subproject called Apache JCR Commons for developing and maintaining
>  selected Jackrabbit components that are not tightly coupled with our
>  content repository implementation.  See the full proposal below.
>
>  Please vote on creating the proposed subproject. The vote is open for
>  the next 72 hours and the votes from Jackrabbit PMC members are
>  binding.
>
>     [ ] +1 Create the JCR Commons subproject
>     [ ] -1 Don't create the JCR Commons subproject
>
>  Here's my +1.
+1

regards, toby

Re: [VOTE] Create the JCR Commons subproject

[Felix Meschberger <fm...@gmail.com>]

Hi,

Thanks Jukka for bringing this up.

Here is my +1

And here are my comments (you would have expected ;-) )

jackrabbit-parent
-----------------
I think the parent project is truly Jackrabbit global. As such it does
not belong to the Commons subproject. In fact, the projects not being
moved to Commons are just kind of "subprojects", too. Namely three: Core
(the actual implementation), SPI and WebDAV support. In this concept the
parent pom is just like the parent to all. If not, we need two parent
poms, probably: A "root" parent and a commons parent. Whether this makes
sense, I am not sure.

Yet, since, this is only the first step towards a more subproject
oriented Jackrabbit TLP, it is probably ok to move it.

Version numbers
---------------
I think we should keep the three-level version numbers major.minor.micro
for the commons sub-projects. We might want define as follows:

* Normal release off trunk: minor++, micro=0
* Bug fix release off branch for back release: micro++

So we always can identify a regular release (micro is zero) from a
bugfix release off a branch (micro not zero), should that ever be required.

Starting from 2.0.0 for the new commons projects is a good idea.

Regards
Felix

Jukka Zitting schrieb:
> Hi,
> 
> As recently discussed, I would like us to create a Jackrabbit
> subproject called Apache JCR Commons for developing and maintaining
> selected Jackrabbit components that are not tightly coupled with our
> content repository implementation.  See the full proposal below.
> 
> Please vote on creating the proposed subproject. The vote is open for
> the next 72 hours and the votes from Jackrabbit PMC members are
> binding.
> 
>     [ ] +1 Create the JCR Commons subproject
>     [ ] -1 Don't create the JCR Commons subproject
> 
> Here's my +1.
> 
> BR,
> 
> Jukka Zitting
> 
> ----
> 
> COMPONENTS
> 
> The JCR Commons subproject would take over the development and
> maintenance of the following components:
> 
>   * jackrabbit-parent
>   * jackrabbit-jcr-tests
>   * jackrabbit-jcr-benchmark
>   * jackrabbit-jcr-rmi
>   * jackrabbit-jcr-servlet
>   * jackrabbit-classloader
>   * jackrabbit-ocm (including ocm-nodemanagement)
> 
> Most notably (and a bit surprisingly), the jcr-commons component would
> remain with the core project for now to avoid complicating the
> development workflow for issues that may range over component
> boundaries. We may need to split the jcr-commons component to be able
> to move parts of the code to the proposed subproject, but that's a
> separate discussion that we don't need to solve now.
> 
> Similarly, the jcr-server and webdav components will be kept with core
> for now until we have better idea about what to do there (see
> JCR-417).
> 
> I also decided to put the jackrabbit-parent component into the commons
> subproject. The parent POM does contain some core-specific parts, but
> I believe we can move those back to the core components and make the
> parent POM contain only truly Jackrabbit-wide information and
> settings.
> 
> For comparison, the following components would remain as the core
> Jackrabbit project:
> 
>    * jackrabbit-api
>    * jackrabbit-core
>    * jackrabbit-text-extractors
>    * jackrabbit-webdav
>    * jackrabbit-jcr-server
>    * jackrabbit-webapp
>    * jackrabbit-jca
>    * jackrabbit-spi
>    * jackrabbit-spi-commons
>    * jackrabbit-jcr2spi
>    * jackrabbit-spi2jcr
>    * jackrabbit-standalone
> 
> COMMUNITY
> 
> * Committers: For now there will be just a single set of Jackrabbit
> committers. Later on we may want to consider adopting a "subproject
> committer" concept for making it easier to grant someone committership
> to just the commons components.
> 
> * PMC: The Jackrabbit PMC will govern also this new subproject.
> 
> * Apache Commons: We will work with the Apache Commons project to find
> whether and how these JCR Commons components could be included in the
> recently proposed "federated commons" concept. This would likely mean
> us following some Apache Commons practices and having a link to the
> JCR Commons site listed somewhere on the Apache Commons web site.
> 
> DEVELOPMENT
> 
> * Initial code: The initial code for the new subproject would come
> from the selected existing components in Jackrabbit trunk.
> 
> * Releases: Each component within the new subproject would have it's
> own independent release cycle. To avoid confusion with the existing
> 1.x releases, the release numbering of the moved components would
> start at 2.0. Since all these components are relatively small and
> tightly scoped, it would probably be useful to keep their version
> numbering down to just two levels, i.e. use x.y instead of x.y.z as
> the numbering scheme.
> 
> INFRASTRUCTURE
> 
> * Web site: The subproject will have its own web site at
> http://jackrabbit.apache.org/commons/. We might want to follow the
> example of Apache Commons in organizing this web site.
> 
> * Mailing lists: We will use the existing
> {user,dev,commits}@jackrabbit.apache.org mailing lists for the new
> subproject. To make it easier to track topics about selected commons
> components, we should adopt a practice of prefixing related email
> subjects, for example using [rmi] for messages about JCR-RMI.
> 
> * Subversion: We create a new asf/jackrabbit/commons directory that
> will contain all the code of the new subproject. Each component will
> have it's own {trunk,branches,tags} structure within this subtree. For
> example, the JCR-RMI component would be developed in
> asf/jackrabbit/commons/jcr-rmi/trunk. All Jackrabbit committers will
> have write access to this subtree. Notifications of commits to this
> subtree will be sent to the commits@jackrabbit list.
> 
> * Issue tracker: We create separate Jira projects for each component
> in the subproject. These projects will be grouped using the
> "Jackrabbit" category in Jira. Update messages will be sent to the
> dev@jackrabbit list.
>