Hudson build is back to stable: Ja ckrabbit-1.5 » Jackrabbit Core #14
See http://hudson.zones.apache.org/hudson/job/Jackrabbit-1.5/org.apache.jackrabbit$jackrabbit-core/14/changes
Re: Hudson build is back to stable: Jackrabbit-1.5 » Jackrabbit Core #14
Hi, Some query tests were temporarily failing in the 1.5 branch. The build got back to stable simply by re-running it, so it looks like a random failure, perhaps due to some synchronization issue. I'm going to push forward with the 1.5 release. If this problem reappears we can treat it as a known issue in the release. BR, Jukka Zitting
[jira] Created: (JCR-1892) Unique ID for org.apache.jackrabbit.value.BinaryValue
Unique ID for org.apache.jackrabbit.value.BinaryValue - Key: JCR-1892 URL: https://issues.apache.org/jira/browse/JCR-1892 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-jcr-commons Reporter: Thomas Mueller Assignee: Thomas Mueller BinaryValue should have a method get the unique identifier (if one is available). That way an application may not have to read the stream if that value is already processed. When the DataStore is used, a unique identifier is available, so probably this feature is quite simple to implement. See also http://www.nabble.com/Workspace.copy()-Question-...-td20435164.html (but please don't reply to this thread from now on - instead add comments to this issue). Another feature is getFileName() to get the file name if it is stored in the file system. This method may need a security mechanism, for example getFileName(Session s) so that the system can check it. In any case the file should not be modified, but maybe knowing the file name is already too dangerous in some cases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Open the sandbox to all Apache committers
+1 cheers stefan On 02.12.2008, at 11:24, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, Opening up the Jackrabbit sandbox area for all Apache committers is something I've been thinking about for some while, and now with the CMIS implementation effort I think we have a good case where doing so would clearly be helpful. Thus I propose that we grant all Apache committers write access to the Jackrabbit sandbox. A similar setup is used already at least in CXF and Maven. In the sandbox we have various bits of more or less experimental code that's currently not targeted for release. It would be helpful to lower the barriers for people to come together and work on such code, and giving more people commit access is one way to do that. Existing Apache committers already have a CLA on file and have demonstrated enough merit so that we don't need to worry about things getting messed up. As an informal rule I'd still expect external committers who choose to commit to our sandbox to be subscribed on dev@ and to follow at least the relevant parts of [EMAIL PROTECTED] So, please vote on changing the write access settings on repos/asf/jackrabbit/sandbox. The vote is open for the next 72 hours and votes from Jackrabbit PMC members are binding. [ ] +1 Open the sandbox to all Apache committers [ ] -1 Keep the current authorization settings Here's my +1. BR, Jukka Zitting
Re: [VOTE] Open the sandbox to all Apache committers
[X] +1 Open the sandbox to all Apache committers regards marcel
[jira] Commented: (JCR-1890) spi2dav: create RepositoryFactory implementation
[ https://issues.apache.org/jira/browse/JCR-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12652362#action_12652362 ] angela commented on JCR-1890: - should we qualify those two with jcr2spi in their name somewhere? why not... wouldn't it be more useful to have a file name where the log is written to? whatever you prefer... angela spi2dav: create RepositoryFactory implementation Key: JCR-1890 URL: https://issues.apache.org/jira/browse/JCR-1890 Project: Jackrabbit Issue Type: New Feature Components: sandbox Reporter: angela Assignee: angela Priority: Minor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[VOTE] Release Apache Jackrabbit 1.5.0
Hi, I have posted a candidate for the Apache Jackrabbit 1.5.0 release at http://people.apache.org/~jukka/jackrabbit/1.5.0/ See the RELEASE-NOTES.txt file (also included at the end of this message) for details on release contents and latest changes. The release candidate is a jar archive of the sources in http://svn.apache.org/repos/asf/jackrabbit/tags/1.5.0. The SHA1 checksum of the jackrabbit-1.5.0-src.jar release package is 3a5cd606379052282c03a5f70bd34f9470b798fc. Please vote on releasing this package as Apache Jackrabbit 1.5.0. The vote is open for the next 72 hours and passes if a majority of at least three +1 Jackrabbit PMC votes are cast. [ ] +1 Release this package as Apache Jackrabbit 1.5.0 [ ] -1 Do not release this package because... With the source release I have also included pre-compiled binaries for the main deployment packages (webapp, jca, standalone) as well as a staged Maven repository containing pre-compiled versions of all included components. If this vote passes, I will make the source release and the deployment packages available on the Jackrabbit download page and publish the other binaries in the central Maven repository. Here's my +1 vote. BR, Jukka Zitting Release Notes -- Apache Jackrabbit -- Version 1.5.0 Introduction Apache Jackrabbit is a fully conforming implementation of the Content Repository for Java Technology API (JCR). A content repository is a hierarchical content store with support for structured and unstructured content, full text search, versioning, transactions, observation, and more. Typical applications that use content repositories include content management, document management, and records management systems. Apache Jackrabbit 1.5 is an incremental feature release. While remaining compatible with previous releases, Jackrabbit 1.5 introduces a number of new features, improvements and fixes to known issues. The most notable changes in this release are: * The standalone Jackrabbit server component. The runnable jackrabbit-standalone jar makes it very easy to start and run Jackrabbit as a standalone server with WebDAV and RMI access. * Search performance improvements. The performance of certain kinds of hierarchical XPath queries has improved notably. * Simple Google-style query language. The new GQL query syntax makes it very easy to express simple full text queries. * Transaction-safe versioning. Mixing transactions and versioning operations has traditionally been troublesome in Jackrabbit. This release contains a number of improvements in this area and has specifically been reviewed against potential deadlock issues. * Clustered workspace creation. A new workspace created in one cluster node will now automatically appear also in the other nodes of the cluster. * SPI improvements. The SPI layer introduced in Jackrabbit 1.4 has seen a lot of improvements and bug fixes, and is shaping up as a solid framework for implementing JCR connectors. * Development preview: JSR 283 features. We have implemented a number of new features defined in the public review draft of JCR 2.0, created in JSR 283. These new features are accessible through special jsr283 interfaces in the Jackrabbit API. Note however that none of these features are ready for production use, and will be replaced with final JCR 2.0 versions in Jackrabbit 2.0. See the Apache Jackrabbit website at http://jackrabbit.apache.org/ for more information. Release Contents This release consists of a single source archive (jackrabbit-1.5.0-src.jar) that contains all the Apache Jackrabbit components. Use the following commands (or the equivalent in your system) to build the release with Maven 2 and Java 1.4 or higher: jar xf jackrabbit-1.5.0-src.jar cd jackrabbit-1.5.0-src mvn install Note that the OCM components require Java 5 or higher, and are not included in the build when using Java 1.4. The source archive is accompanied by SHA1 and MD5 checksums and a PGP signature that you can use to verify the authenticity of your download. The public key used for the PGP signature can be found at https://svn.apache.org/repos/asf/jackrabbit/dist/KEYS. The build will result in the following components (with artifactIds in parenthesis) being built and installed in your local Maven repository. Pre-built binary artifacts of these components are also available on the on the central Maven repository. * Jackrabbit Parent POM (jackrabbit-parent) The Maven parent POM for all Jackrabbit components. * Jackrabbit API (jackrabbit-api) Interface extensions that Apache Jackrabbit supports in addition to the standard JCR API. * Jackrabbit JCR Commons (jackrabbit-jcr-commons) General-purpose classes for use with the JCR API. * Jackrabbit JCR Tests (jackrabbit-jcr-tests) Set of JCR API test cases designed for testing the compliance of an
Re: jcr-cmis sandbox
On 2 Dec 2008, at 20:04, Dominique Pfister wrote: -- + rest + ws Just as an observation, I think it's insane having two different protocols for this standard. It sounds like two factions in the standards group that could never agree. -- Torgeir Veimo [EMAIL PROTECTED]
[jira] Created: (JCR-1890) spi2dav: create RepositoryFactory implementation
spi2dav: create RepositoryFactory implementation Key: JCR-1890 URL: https://issues.apache.org/jira/browse/JCR-1890 Project: Jackrabbit Issue Type: New Feature Components: sandbox Reporter: angela Assignee: angela Priority: Minor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Open the sandbox to all Apache committers
[X] +1 Open the sandbox to all Apache committers As an informal rule I'd still expect external committers who choose to commit to our sandbox to be subscribed on dev@ and to follow at least the relevant parts of [EMAIL PROTECTED] Yes, that rule should be clearly given, it's good to see what and why people are committing to it. Maybe we should also require JIRA to track things (although that might be overkill for experimental code). Regards, Alex -- Alexander Klimetschek [EMAIL PROTECTED]
[jira] Resolved: (JCR-1836) Persistence: support property databaseType
[ https://issues.apache.org/jira/browse/JCR-1836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved JCR-1836. - Resolution: Fixed Committed in revision 722463 (trunk) Persistence: support property databaseType -- Key: JCR-1836 URL: https://issues.apache.org/jira/browse/JCR-1836 Project: Jackrabbit Issue Type: Improvement Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Attachments: databaseType.patch In persistence managers and cluster journal the term 'schema' is used to mean 'database type'. Using the term 'schema' for that is actually quite confusing (in my view): The definition of schema http://en.wikipedia.org/wiki/Database_schema is the schema defines the tables, the fields in each table, and the relationships between fields and tables. Additionally in most databases a schema is is a name space within a database: http://java.sun.com/j2se/1.4.2/docs/api/java/sql/DatabaseMetaData.html#getSchemas() . I suggest to support the property 'databaseType' in addition to 'schema' for the persistence managers and the cluster journal. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1891) jcr2spi: use Soft refs for hierarchy
jcr2spi: use Soft refs for hierarchy Key: JCR-1891 URL: https://issues.apache.org/jira/browse/JCR-1891 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-jcr2spi Reporter: angela Assignee: angela Priority: Minor Fix For: 1.6.0 stefan suggested to use soft refs for the hierarchy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1886) jcr2spi: Unprocessed ItemInfos call to RepositoryService#getItemInfos
[ https://issues.apache.org/jira/browse/JCR-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved JCR-1886. - Resolution: Fixed jcr2spi: Unprocessed ItemInfos call to RepositoryService#getItemInfos - Key: JCR-1886 URL: https://issues.apache.org/jira/browse/JCR-1886 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr2spi Reporter: angela Fix For: 1.6.0 stefan reported the following problem: - batchread config reads with depths infinity - invalidate tree by calling Node.refresh(false) - force loading of the tree (e.g. Node.getPath()) afterwards, there may still be invalidated item states indicating that not all ItemInfos were processed. consequently, there are additional calls to getItemInfos that should have been covered by the loading of the tree. the problem occuring is not related to limitation of the item-cache size. problem analysis: there is a bug in WorkspaceItemStateFactory#createItemStates. there is a wrapper built around the ItemInfo-Iterator but later on the ItemInfo-Iterator is used instead of the wrapper, which pre-fetches items from the underlying iterator and process them upon hasNext()/next(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1891) jcr2spi: use Soft refs for hierarchy
[ https://issues.apache.org/jira/browse/JCR-1891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved JCR-1891. - Resolution: Fixed jcr2spi: use Soft refs for hierarchy Key: JCR-1891 URL: https://issues.apache.org/jira/browse/JCR-1891 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-jcr2spi Reporter: angela Assignee: angela Priority: Minor Fix For: 1.6.0 stefan suggested to use soft refs for the hierarchy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Files for binary properties
Hi, Just recently there was a discussion about getting the unique identifier for a binary value. I created an issue: https://issues.apache.org/jira/browse/JCR-1892 I am currently using the XMLPersistenceManager. You should consider using a bundle database persistence manager. See also http://wiki.apache.org/jackrabbit/PersistenceManagerFAQ - XMLPersistenceManager: If the JVM process is killed the repository might turn inconsistent; Status: obsolete, mature Listed below is the code I've used to obtain file paths. One problem is that BLOBInResource does not have a getFileSystem() method - is there a reason for this? BLOBInResource is not used if you use a data store. I would consider using a data store. Unfortunately, you can't get the identifier from the BLOBInDataStore. But using Jackrabbit internal classes directly is anyway problematic as they change in future versions. Regards, Thomas
Re: Files for binary properties
Hi, On Tue, Dec 2, 2008 at 2:19 PM, Charles Brooking [EMAIL PROTECTED] wrote: When using a datastore I assumed files might not be directly stored on the (operating system) filesystem. Currently, I need a direct mapping to files so I can pass file paths to other programs for processing. Basically, I want files uploaded by users through WebDAV to be stored as actual files in the operating system, and to be able to get their path. How about just mounting the workspace as a WebDAV share to your normal file system? That way you can access the files without extra hacks. BR, Jukka Zitting
Re: Files for binary properties
Thomas Müller wrote: Just recently there was a discussion about getting the unique identifier for a binary value. I created an issue: https://issues.apache.org/jira/browse/JCR-1892 I am currently using the XMLPersistenceManager. You should consider using a bundle database persistence manager. See also http://wiki.apache.org/jackrabbit/PersistenceManagerFAQ - XMLPersistenceManager: If the JVM process is killed the repository might turn inconsistent; Status: obsolete, mature If it does become inconsistent, though, I would assume things could be fixed quite easily given the XML representation is spread across several files and is in a simple human-readable format. Listed below is the code I've used to obtain file paths. One problem is that BLOBInResource does not have a getFileSystem() method - is there a reason for this? BLOBInResource is not used if you use a data store. I would consider using a data store. Unfortunately, you can't get the identifier from the BLOBInDataStore. But using Jackrabbit internal classes directly is anyway problematic as they change in future versions. When using a datastore I assumed files might not be directly stored on the (operating system) filesystem. Currently, I need a direct mapping to files so I can pass file paths to other programs for processing. Basically, I want files uploaded by users through WebDAV to be stored as actual files in the operating system, and to be able to get their path. As you say, my code is a hack right now - even down to accessing a private field - but I wondered if we could create a proper interface based on what the code illustrates. The getFileName part of your ticket is good, although I would further if it is stored in the file system with a suggestion that in some applications people will want assurance that all nt:files are stored as actual files. This is the I want a normal WebDAV server kind of use case. Later Charlie
[jira] Commented: (JCR-1890) spi2dav: create RepositoryFactory implementation
[ https://issues.apache.org/jira/browse/JCR-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12652360#action_12652360 ] Marcel Reutegger commented on JCR-1890: --- org.apache.jackrabbit.repository.itemCacheSize : int org.apache.jackrabbit.repository.cacheBehaviour : o.a.j.jcr2spi.config.CacheBehaviour should we qualify those two with jcr2spi in their name somewhere? org.apache.jackrabbit.repository.spilog.writer : java.io.Writer wouldn't it be more useful to have a file name where the log is written to? spi2dav: create RepositoryFactory implementation Key: JCR-1890 URL: https://issues.apache.org/jira/browse/JCR-1890 Project: Jackrabbit Issue Type: New Feature Components: sandbox Reporter: angela Assignee: angela Priority: Minor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1890) spi2dav: create RepositoryFactory implementation
[
https://issues.apache.org/jira/browse/JCR-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved JCR-1890.
-
Resolution: Fixed
added initial draft of a RepositoryFactory implementation based on the factory
interface present with jackrabbit-api.
see:
http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-api/src/main/java/org/apache/jackrabbit/api/jsr283/RepositoryFactory.java
the getRepository call takes a Map containing the parameters used to build the
repository.
currently the following parameters are supported:
org.apache.jackrabbit.repository.itemCacheSize : int
org.apache.jackrabbit.repository.cacheBehaviour :
o.a.j.jcr2spi.config.CacheBehaviour
org.apache.jackrabbit.repository.spi2rmi.url :
//{rmi-host}:{rmi-port}/{repository-name}
org.apache.jackrabbit.repository.spi2dav.url : used to build spi2dav
org.apache.jackrabbit.repository.config : o.a.j.jcr2spi.config.RepositoryConfig
org.apache.jackrabbit.repository.spilog.writer : java.io.Writer
note:
- the first 4 params are used to built a specific RepositoryConfig.
- if org.apache.jackrabbit.repository.config is present the other params except
for
log-writer are ignored.
- if org.apache.jackrabbit.repository.spilog.writer is present the repo-config
built
from the other parameters is wrapped with another config, that returns an
spi-logger repository service (which again wraps the service obtained by the
base config.
spi2dav: create RepositoryFactory implementation
Key: JCR-1890
URL: https://issues.apache.org/jira/browse/JCR-1890
Project: Jackrabbit
Issue Type: New Feature
Components: sandbox
Reporter: angela
Assignee: angela
Priority: Minor
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
jcr-cmis sandbox
Hi, After having had a first look at the CMIS specification, I decided to start off with the jcr-cmis implementation. I therefore created a jcr-cmis sandbox with the following initial structure: jcr-cmis -- + server + rest + ws I intend to start working on the server/rest subtree (where the REST API binding will reside). Any comment/feedback and - even better :) - any contribution/participation on the the server/ws subtree (containing the Web Services Binding) are more than welcome! Kind regards Dominique
Re: jcr-cmis sandbox
Dominique Pfister wrote: Hi, After having had a first look at the CMIS specification, I decided to start off with the jcr-cmis implementation. I therefore created a jcr-cmis sandbox with the following initial structure: jcr-cmis -- + server + rest + ws I intend to start working on the server/rest subtree (where the REST API binding will reside). Any comment/feedback and - even better :) - any contribution/participation on the the server/ws subtree (containing the Web Services Binding) are more than welcome! I guess it'll be harder to find volunteers for the ws part :-) Two thoughts: 1) At some point of time, we'll have to define a mapping from CMIS to JCR (relatively simple) *and* the other way around (now that's harder). So, how to map identifiers (types, paths), what to do with the CMIS relation objects and so on. Should we start a design document (a text file) for that, or would a Wiki work better? 2) I think that having a separate connector for CMIS in addition to WebDAV should be avoided. We essentially would mint different HTTP URLs for the same thing. So maybe not now, but at a later point of time it would be good if we could merge the new functionality into the existing WebDAV stack. BR, Julian
[VOTE] Open the sandbox to all Apache committers
Hi, Opening up the Jackrabbit sandbox area for all Apache committers is something I've been thinking about for some while, and now with the CMIS implementation effort I think we have a good case where doing so would clearly be helpful. Thus I propose that we grant all Apache committers write access to the Jackrabbit sandbox. A similar setup is used already at least in CXF and Maven. In the sandbox we have various bits of more or less experimental code that's currently not targeted for release. It would be helpful to lower the barriers for people to come together and work on such code, and giving more people commit access is one way to do that. Existing Apache committers already have a CLA on file and have demonstrated enough merit so that we don't need to worry about things getting messed up. As an informal rule I'd still expect external committers who choose to commit to our sandbox to be subscribed on dev@ and to follow at least the relevant parts of [EMAIL PROTECTED] So, please vote on changing the write access settings on repos/asf/jackrabbit/sandbox. The vote is open for the next 72 hours and votes from Jackrabbit PMC members are binding. [ ] +1 Open the sandbox to all Apache committers [ ] -1 Keep the current authorization settings Here's my +1. BR, Jukka Zitting
Re: [VOTE] Open the sandbox to all Apache committers
+1 Cheers Dominique On Tue, Dec 2, 2008 at 11:24 AM, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, Opening up the Jackrabbit sandbox area for all Apache committers is something I've been thinking about for some while, and now with the CMIS implementation effort I think we have a good case where doing so would clearly be helpful. Thus I propose that we grant all Apache committers write access to the Jackrabbit sandbox. A similar setup is used already at least in CXF and Maven. In the sandbox we have various bits of more or less experimental code that's currently not targeted for release. It would be helpful to lower the barriers for people to come together and work on such code, and giving more people commit access is one way to do that. Existing Apache committers already have a CLA on file and have demonstrated enough merit so that we don't need to worry about things getting messed up. As an informal rule I'd still expect external committers who choose to commit to our sandbox to be subscribed on dev@ and to follow at least the relevant parts of [EMAIL PROTECTED] So, please vote on changing the write access settings on repos/asf/jackrabbit/sandbox. The vote is open for the next 72 hours and votes from Jackrabbit PMC members are binding. [ ] +1 Open the sandbox to all Apache committers [ ] -1 Keep the current authorization settings Here's my +1. BR, Jukka Zitting
Apache JCR Commons
Hi,
Based on earlier discussion [1] I would like to propose that we start
a new Apache JCR Commons subproject within Jackrabbit. See below
what this could mean in practice. As usual, comments are welcome!
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
* jackrabbit-jcr-rmi
* jackrabbit-jcr-servlet
* jackrabbit-webdav
* jackrabbit-jcr-server
* jackrabbit-classloader
* jackrabbit-ocm
* jackrabbit-ocm-nodemanagement
This would leave the jackrabbit-core component and the deployment
packages (webapp, jca, standalone) as the clear core of the remaining
Jackrabbit repository project. For now I think the SPI layer is so
close in scope to the repository implementation that we should keep it
close to the core. The text-extractors component has very limited use
outside Jackrabbit (especially now that Apache Tika is available), so
I'd keep it with the repository implementation until we can phase it
out entirely in favor of using Tika. Everything else goes to the JCR
Commons subproject.
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. Anyway,
for now I think the best home for it is still within Jackrabbit, and
by moving it to the commons subproject we give it a better chance to
evolve without ties to the Jackrabbit core release cycle.
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.
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 create the following new mailing lists for the
subproject: commons-{user,dev,[EMAIL PROTECTED] Again,
following the example of Apache Commons in how to organize the mailing
lists (for example use a [rmi] subject prefix for all messages
regarding JCR-RMI) is probably a good idea.
* 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 new commons-commits@ list.
* Issue tracker: We create separate Jira projects for each component
in the subproject. These projects will be grouped using a new JCR
Commons category in Jira. Update messages will be sent to the new
commons-dev@ list.
[1] http://markmail.org/message/dmvi7dtjeknkiuzl
BR,
Jukka Zitting
Re: Apache JCR Commons
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
* jackrabbit-jcr-rmi
* jackrabbit-jcr-servlet
* jackrabbit-webdav
* jackrabbit-jcr-server
* jackrabbit-classloader
* jackrabbit-ocm
* jackrabbit-ocm-nodemanagement
Do all these projects solely rely on the JCR API? They shouldn't be
dependent on anything from core (or the deployment packages + the SPI
stuff), because - as the core already depends on some of them, eg.
jcr-commons - we would have circular dependencies. I don't have an
overview of the dependencies at the moment, that's why I am asking.
This clear separation should be the guide for everything in the
commons subproject.
INFRASTRUCTURE
* Mailing lists: We create the following new mailing lists for the
subproject: commons-{user,dev,[EMAIL PROTECTED] Again,
following the example of Apache Commons in how to organize the mailing
lists (for example use a [rmi] subject prefix for all messages
regarding JCR-RMI) is probably a good idea.
Not sure if we should create more mailing lists, as many mailing lists
make it difficult for beginners to get a start (which one shall I
subscribe to for a quick question?). Maybe we can re-use the existing
ones and work with the mentioned [commons-rmi] prefix there.
If we have separate svn trunks and a separate jira project, this would
be kind of a mismatch, but I suggest that in the beginning we should
force people to cross-talk on commons and core. Only if commons
becomes active on its own, we could separate the lists as well. WDYT?
Otherwise my ACK to all other points!
Regards,
Alex
--
Alexander Klimetschek
[EMAIL PROTECTED]
Re: Apache JCR Commons
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 be dependent on anything from core (or the deployment packages + the SPI stuff), because - as the core already depends on some of them, eg. jcr-commons - we would have circular dependencies. There are optional dependencies to jackrabbit-api and jackrabbit-core from some of the proposed commons components. For example jcr-rmi has an optional dependency to jackrabbit-api so it's able to expose the extra methods when the extra API interfaces are available. Similarly, jcr-servlet has an optional dependency to jackrabbit-core so it can be used to instantiate a Jackrabbit repository when all the required libraries are available. I don't see such optional dependencies as troublesome as they don't affect downstream projects (i.e. they are not transitive) and are only used for extra functionality when the client explicitly asks for it. Also, many of the components have test dependencies to jackrabbit-core, but since those are also non-transitive I don't see any problems with that. Not sure if we should create more mailing lists, as many mailing lists make it difficult for beginners to get a start (which one shall I subscribe to for a quick question?). Maybe we can re-use the existing ones and work with the mentioned [commons-rmi] prefix there. Yeah, we could do that. Using separate mailing list might encourage more cooperation from other JCR implementation projects as they wouldn't need to filter out all the Jackrabbit-specific stuff. BR, Jukka Zitting
Re: jcr-cmis sandbox
Also, I don't think we should implement any of the HTTP extensions in the AtomPub binding -- they are neither necessary nor desirable. We should show the TC how to implement it right, not just implement whatever they suggest. very good point! this also puts us into a good position to file issues for the CMIS jira ;) regards, david
