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,[email protected] 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 comm...@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 > d...@jackrabbit list. >
