Re: resigning from Apache Jackrabbit and Sling PMCs
Yes, I prefer to keep that Committer = PMC to the extent that it is possible, so please remove my commit bit as well. We have a longstanding tradition for HTTP Server that any of the emeritus folks are welcome to come back at any time in the future. I expect that will be the case for Jackrabbit as well. I think of the PMC as the folks actively watching over the project, which I just don’t have the bandwidth to do right now. If it were only a temporary leave, I wouldn’t bother to change my status, but I plan to spend the next few years a little closer to the operating system and network protocols. Cheers, Roy > On Feb 27, 2018, at 1:58 AM, Michael Dürig <mdue...@apache.org> wrote: > > > Hi Roy, > > Let me thank you for all the hard work you put into Jackrabbit and its > related projects! While it is sad to see long time members go, I'm sure we > are still going to see you around with all your involvement in the ASF. I > certainly hope to continue receiving guidance from your side if necessary. > Your voice will always be heard in this PMC. > > So far we had the (unwritten and implicit rule) to make all our committers > PMC members and vice versa. Before I move forward, could you let me know > whether you also resign from being a committer? There is no pressure in doing > so, but I would like to notify the PMC in case we deviate from a long > standing habit. > > Michael > >> On 23.02.18 23:15, Roy T. Fielding wrote: >> Hi, >> It's been a long time since I made any significant contributions to these >> projects and >> I find myself unable to keep up with the email load. So, I am finally >> removing myself >> from the lists. I'll still be around, if needed, but please remove me from >> the official >> PMC memberships. >> Cheers, and thanks for all the +1s >> Roy
resigning from Apache Jackrabbit and Sling PMCs
Hi, It's been a long time since I made any significant contributions to these projects and I find myself unable to keep up with the email load. So, I am finally removing myself from the lists. I'll still be around, if needed, but please remove me from the official PMC memberships. Cheers, and thanks for all the +1s Roy
Re: svn commit: r1299243 - in /jackrabbit/sandbox/jackrabbit-mongo-persistence: README.txt pom.xml src/main/java/org/apache/jackrabbit/core/persistence/mongo/MongoPersistenceManager.java
Why MongoDB? It is under an incompatible license, so we'd never be able to
distribute this pm.
Roy
On Mar 10, 2012, at 9:56 AM, ste...@apache.org wrote:
Author: stefan
Date: Sat Mar 10 17:56:34 2012
New Revision: 1299243
URL: http://svn.apache.org/viewvc?rev=1299243view=rev
Log:
experimental mongo-based pm ds
allow for db per pm
Modified:
jackrabbit/sandbox/jackrabbit-mongo-persistence/README.txt
jackrabbit/sandbox/jackrabbit-mongo-persistence/pom.xml
jackrabbit/sandbox/jackrabbit-mongo-persistence/src/main/java/org/apache/jackrabbit/core/persistence/mongo/MongoPersistenceManager.java
Modified: jackrabbit/sandbox/jackrabbit-mongo-persistence/README.txt
URL:
http://svn.apache.org/viewvc/jackrabbit/sandbox/jackrabbit-mongo-persistence/README.txt?rev=1299243r1=1299242r2=1299243view=diff
==
--- jackrabbit/sandbox/jackrabbit-mongo-persistence/README.txt (original)
+++ jackrabbit/sandbox/jackrabbit-mongo-persistence/README.txt Sat Mar 10
17:56:34 2012
@@ -6,8 +6,9 @@ committing changes the workspace may bec
Both MongoPersistenceManager and MongoDataStore support the following
parameters:
-- host - defaults to 127.0.0.1
-- port - defaults to 27017
+- host - defaults to 127.0.0.1
+- port - defaults to 27017
+- dbName - defaults to rep
- TODO document all configuration parameters
MongoPersistenceManager also supports the following parameters:
Modified: jackrabbit/sandbox/jackrabbit-mongo-persistence/pom.xml
URL:
http://svn.apache.org/viewvc/jackrabbit/sandbox/jackrabbit-mongo-persistence/pom.xml?rev=1299243r1=1299242r2=1299243view=diff
==
--- jackrabbit/sandbox/jackrabbit-mongo-persistence/pom.xml (original)
+++ jackrabbit/sandbox/jackrabbit-mongo-persistence/pom.xml Sat Mar 10
17:56:34 2012
@@ -35,7 +35,7 @@
groupIdorg.apache.jackrabbit/groupId
artifactIdjackrabbit-mongo-persistence/artifactId
- nameApache Jackrabbit/name
+ nameApache Jackrabbit MongoDB Persistence/name
version2.6-SNAPSHOT/version
packagingjar/packaging
Modified:
jackrabbit/sandbox/jackrabbit-mongo-persistence/src/main/java/org/apache/jackrabbit/core/persistence/mongo/MongoPersistenceManager.java
URL:
http://svn.apache.org/viewvc/jackrabbit/sandbox/jackrabbit-mongo-persistence/src/main/java/org/apache/jackrabbit/core/persistence/mongo/MongoPersistenceManager.java?rev=1299243r1=1299242r2=1299243view=diff
==
---
jackrabbit/sandbox/jackrabbit-mongo-persistence/src/main/java/org/apache/jackrabbit/core/persistence/mongo/MongoPersistenceManager.java
(original)
+++
jackrabbit/sandbox/jackrabbit-mongo-persistence/src/main/java/org/apache/jackrabbit/core/persistence/mongo/MongoPersistenceManager.java
Sat Mar 10 17:56:34 2012
@@ -77,8 +77,18 @@ public class MongoPersistenceManager ext
protected MongoBlobStore blobStore;
+protected String dbName = rep;
+
//-- configuration getters setters
+public String getDbName() {
+return dbName;
+}
+
+public void setDbName(String dbName) {
+this.dbName = dbName;
+}
+
public String getHost() {
return conf.getHost();
}
@@ -222,7 +232,9 @@ public class MongoPersistenceManager ext
log.error(failed to connect to mongodb, e);
throw new RepositoryException(failed to initialize
MongoPersistenceManager, e);
}
-db = con.getDB(rep);
+
+
+db = con.getDB(encodeName(dbName));
db.setWriteConcern(WriteConcern.SAFE);
bundles = db.getCollection(bundles);
@@ -428,6 +440,67 @@ public class MongoPersistenceManager ext
return (refs.findOne(key) != null);
}
+//---
implementation
+
+protected final static String ENCODED_DOT = _x46_;
+protected final static String ENCODED_DOLLAR_SIGN = _x36_;
+
+/**
+ * see http://www.mongodb.org/display/DOCS/Legal+Key+Names
+ *
+ * @param name
+ * @return
+ */
+protected static String encodeName(String name) {
+StringBuilder buf = null;
+for (int i = 0; i name.length(); i++) {
+if (i == 0 name.charAt(i) == '$') {
+// mongodb field names must not start with '$'
+buf = new StringBuilder();
+buf.append(ENCODED_DOLLAR_SIGN);
+} else if (name.charAt(i) == '.') {
+// . is a reserved char for mongodb field names
+if (buf == null) {
+buf = new StringBuilder(name.substring(0, i));
+}
+buf.append(ENCODED_DOT);
+} else {
+if (buf != null) {
+
Re: svn commit: r1299243 - in /jackrabbit/sandbox/jackrabbit-mongo-persistence: README.txt pom.xml src/main/java/org/apache/jackrabbit/core/persistence/mongo/MongoPersistenceManager.java
It matters. Assuming we limit access to the MongoDB server to those drivers and we don't need to include other MongoDB code in the Jackrabbit server, then we should be able to include the code in Jackrabbit as an optional PM. However, we might want to include a warning to folks who use it that MongoDB itself is under a different license. Roy On Mar 10, 2012, at 1:18 PM, Dave Brosius wrote: The drivers are apache2 if that matters any. On 03/10/2012 02:38 PM, Roy T. Fielding wrote: Why MongoDB? It is under an incompatible license, so we'd never be able to distribute this pm. Roy
Re: [VOTE] Codename for the jr3 implementation effort (Was: [jr3] Codename)
On Mar 2, 2012, at 10:07 AM, David Nuescheler wrote: [ ] Blackrabbit [x] Oak The oak is a common symbol of strength and endurance ... - wikipedia Yeah, it's also one of the more commonly used codenames. Java itself was called Oak before its release. But that's okay as long as we don't plan on releasing it under that name. http://en.wikipedia.org/wiki/Oak_%28programming_language%29 Roy
Re: [jr3] Codename
On Feb 24, 2012, at 2:36 AM, Jukka Zitting wrote: My personal favorite so far is Jonsai (as in Java + Bonsai) that Michael D. suggested in a lunch conversation last week. Any other ideas? I suggest we collect ideas over the next few days, check how well the measure against the above guidelines, and then next week come up with consensus on which one of the candidates we should use as the codename. Jackalope http://en.wikipedia.org/wiki/Jackalope Roy
nabble posting
It looks like someone at nabble changed their configuration, since the subscription changed just before that spam. I removed the junk from our archive and added them to the deny list. If anyone remembers how nabble's config works, please tell it to deny posting to our list. Roy
Re: CMIS / Camaieu
On Feb 25, 2009, at 9:40 AM, Florent Guillaume wrote: On 25 Feb 2009, at 12:49, Angela Schreiber wrote: Florent Guillaume wrote: On 25 Feb 2009, at 12:16, Alexander Klimetschek wrote: On Fri, Feb 20, 2009 at 2:25 PM, Florent Guillaume f...@nuxeo.com wrote: What do you guys think of CloudMist? It's nice in English, but in German Mist means dung/rubbish/bullshit, which has a bit of a negative meaning ;-) Thanks, it's good to know. Would you say that an english-speaking German (or Swiss) hearing about cloudmist would have definitive negative feelings, or just that he would be amused at the double-meaning, or would not care or not notice? for me it doesn't sound promising at all... i thought that was by intention ;) Thanks. Following this valuable input, we've renamed the project to Apache Camaieu. You'll find it at http://hg.nuxeo.org/sandbox/apache-camaieu Sorry, I know this is in some interim state, but you cannot call something Apache X if X isn't being actively managed by the Apache Software Foundation, hosted on our infrastructure, and subject to all of our processes. The Apache name can only be added after it is adopted by an Apache project, whether that be Jackrabbit or the Incubator. Roy
[jira] Closed: (JCR-1628) Put HTML version of JCR spec on website (for search indexing)
[ https://issues.apache.org/jira/browse/JCR-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roy T. Fielding closed JCR-1628. Resolution: Invalid No, the JSR 170 specification is not licensed to the ASF except under the terms of the Specification License. It is specifically excluded from the Day CCLA. It should not have been posted here. Put HTML version of JCR spec on website (for search indexing) - Key: JCR-1628 URL: https://issues.apache.org/jira/browse/JCR-1628 Project: Jackrabbit Issue Type: New Feature Components: docs Reporter: Alexander Klimetschek Attachments: jsr-170-html.zip It would be good to have the JCR spec online (starting with 1.0 now) in an HTML version. This has several benefits: - no need to go through the many steps needed to download the JCR 1.0 pdf from the JSR site - more visibility of the one-and-only documentation on JCR - less discussion about JCR spec parts because users can inform themselves easier than before - HTML content will be indexed by search engines, finding JCR information will be much better -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1628) Put HTML version of JCR spec on website (for search indexing)
[ https://issues.apache.org/jira/browse/JCR-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roy T. Fielding updated JCR-1628: - Attachment: (was: jsr-170-html.zip) Put HTML version of JCR spec on website (for search indexing) - Key: JCR-1628 URL: https://issues.apache.org/jira/browse/JCR-1628 Project: Jackrabbit Issue Type: New Feature Components: docs Reporter: Alexander Klimetschek It would be good to have the JCR spec online (starting with 1.0 now) in an HTML version. This has several benefits: - no need to go through the many steps needed to download the JCR 1.0 pdf from the JSR site - more visibility of the one-and-only documentation on JCR - less discussion about JCR spec parts because users can inform themselves easier than before - HTML content will be indexed by search engines, finding JCR information will be much better -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Concerns about release vote behaviour
On Apr 20, 2008, at 6:03 AM, Felix Meschberger wrote: I have a growing concern about our latest releases. Most of the time we barely get the required minimum of 3 +1 votes to release the stuff. Take as an example some recent release vote results: * Jackrabbit 1.3.4 - 3 votes * jackrabbit-core 1.4.2 - 4 votes (of which 1 non-binding) * Jackrabbit 1.4 - 4 votes (of which one non-binding -1) * jackrabbit-jcr-commons 1.4.2 - 4 votest * jackrabbit-core 1.4.1 - 4 votes * Jackrabbit 1.3.3 - 5 votes (of which 1 non-binding) * Jackrabbit 1.3.1 - 5 votes (of which 2 non-binding) Now, compared to the number of committers/PMC members we have - 20 according to [1] - this is IMHO not enough backing for releases. Three people giving a true +1 to a release is adequate. Not ideal, but still adequate, providing that none of those +1s are bogus. How come ? Could it be that we just don't feel comfortable enough with the code base we are working on day-on and day-off ? Is it, that we cannot bear the responsibility of releasing some code, we could not test thorougly ourselves ? I cannot tell. And the reasons for these abstentions are probably none of my business. The Apache release process is designed to work with part-time volunteers. We only need enough attention, not absolute attention. What I really am looking for is more votes on our releases to show our user community that the Jackrabbit PMC is in fact proud and confident of its product. It is true, that the PMC is responsible for the published releases: The main role of the PMC is not code and not coding - but to ensure that all legal issues are addressed, that procedure is followed, and that each and every release is the product of the community as a whole (see [2]). So a release vote, as I understand it, is not primarily about whether the product code is 100% correct. Rather the question is whether the code was developped correctly with respect to the community and that legal issues have been addressed, e.g. required files such as LICENSE and NOTICE files are in place. And this is actually, what I do when considering my vote: * I get the complete release from the release candidate location * I check all checksums and signatures * I run rat to check for the license headers ([3] and [4]) * Check NOTICE files If all goes well, which it normally does, I vote +1. There is nothing more I do. Sorry, that is a bogus +1. All of your release votes are now invalid. Each time you do that you decrease the ability of the team as a whole to verify that at least three people have built the source code on their own system and run whatever normal tests that they consider sufficient to verify that the SOURCE CODE provided does indeed build into a release that is, in their opinion, at least as good if not better than the prior release of that product. That's what +1 means for a release. The binaries are irrelevant. Aside from checking the signatures, just trust that the RM built them from the same source. What matters for the release vote is that the source code matches what we have in subversion, is buildable, and runs on your own platform. I stopped voting because my platform stopped working, but I should be able to rely on the others to verify that it is just my personal install of java that sucks and not our released code. I don't care how often a release gets delayed because not enough people have built and tested it -- they will show up when progress is delayed. I do care a great deal when folks say that they will submit bogus +1s just to make up the appearance of progress. That simply is not good enough. If it persists, you will be removed from the PMC. Apache cannot afford to allow releases to become an exercise in marketing. Roy
Re: Concerns about release vote behaviour
On Apr 21, 2008, at 11:47 AM, Thomas Mueller wrote: Hi, The important release artifact to check is the source archive, the binary artifacts are mostly a convenience to users. The binaries are irrelevant. OK, I understand, but I don't agree. Most users download the binaries; very few download the source code and even less build the binaries Apache's users download the source code and build from source. Jukka's users may just run the binaries. themselves. I think the binaries are important. If the release scripts are correct the binaries should be correct. But then, if the release scripts are correct then 'rat' is already run and I don't need to do that again... The binaries could contain a virus (there are some Java viruses). I know that some developers disabled the virus scanner (well I do that sometimes). Probably it's not that urgent, but maybe when we have time to improve the release process we find a solution for that as well. Thomas, there is no way to verify that a binary is redistributable without building the entire computer from trusted sources each time. That's why we don't vote on binaries. Don't waste your abilities on testing binaries when we need them to test the source code. Allow me to repeat: WE DON'T VOTE ON BINARIES. We CAN'T vote on binaries. To vote would imply that we have the magical ability to evaluate them on behalf of the ASF. None of us has that ability. That's why the ASF does not release binaries! If it really becomes too hard for folks to understand that the binaries do not matter, then I will ask the RM to stop building binaries. They don't belong in the release vote, period. Is that clear? The HTTP Server project has never, in its entire history, voted on the release of binaries. Apache Jackrabbit has no reason to do so now. We let Jukka upload binaries that he has built from the released source code bits because we trust Jukka, not because we trust the binaries. Roy
[jira] Commented: (JCR-1161) Export test cases fail with Java 5 on Mac OS X
[ https://issues.apache.org/jira/browse/JCR-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532265 ] Roy T. Fielding commented on JCR-1161: -- BTW, the test case is also bogus because it is using a round-trip through an import to decide if the test succeeded. It should be comparing the results to a static file/array of bytes. Export test cases fail with Java 5 on Mac OS X -- Key: JCR-1161 URL: https://issues.apache.org/jira/browse/JCR-1161 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr-tests Affects Versions: 0.9, 1.0, 1.0.1, 1.1, 1.1.1, 1.2.1, 1.2.2, 1.2.3, 1.3, 1.3.1 Reporter: Jukka Zitting Assignee: Jukka Zitting Priority: Minor As reported by Roy during the Jackrabbit 1.3.1 release vote: I am getting test failures on OS X 10.4.10 (PPC) with java version 1.5.0_07 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164) Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing). All failures are because of junit.framework.AssertionFailedError: namespace: http://www.jcp.org/ jcr/mix/1.0 not exported More details below. Roy Running org.apache.jackrabbit.test.TestAll [Fatal Error] :1:10: Attribute name is associated with an element type this must be followed by the ' = ' character. [Fatal Error] :1:10: Attribute name is associated with an element type this must be followed by the ' = ' character. [Fatal Error] :-1:-1: Premature end of file. [Fatal Error] :-1:-1: Premature end of file. Tests run: 1055, Failures: 8, Errors: 0, Skipped: 0, Time elapsed: 119.126 sec FAILURE! Results : Failed tests: testExportDocView_handler_session_skipBinary_noRecurse (org.apache.jackrabbit.test.api.ExportDocViewTest) testExportDocView_handler_session_skipBinary_recurse (org.apache.jackrabbit.test.api.ExportDocViewTest) testExportDocView_handler_session_saveBinary_noRecurse (org.apache.jackrabbit.test.api.ExportDocViewTest) testExportDocView_handler_session_saveBinary_recurse (org.apache.jackrabbit.test.api.ExportDocViewTest) testExportDocView_stream_session_skipBinary_recurse (org.apache.jackrabbit.test.api.ExportDocViewTest) testExportDocView_stream_session_skipBinary_noRecurse (org.apache.jackrabbit.test.api.ExportDocViewTest) testExportDocView_stream_session_saveBinary_noRecurse (org.apache.jackrabbit.test.api.ExportDocViewTest) testExportDocView_stream_session_saveBinary_recurse (org.apache.jackrabbit.test.api.ExportDocViewTest) Tests run: 1248, Failures: 8, Errors: 0, Skipped: 0 --- Test set: org.apache.jackrabbit.test.TestAll --- Tests run: 1055, Failures: 8, Errors: 0, Skipped: 0, Time elapsed: 119.124 sec FAILURE! testExportDocView_handler_session_skipBinary_noRecurse (org.apache.jackrabbit.test.api.ExportDocViewTest) Time elapsed: 0.07 sec FAILURE! junit.framework.AssertionFailedError: namespace: http://www.jcp.org/ jcr/mix/1.0 not exported -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Digests
On Sep 6, 2007, at 12:42 AM, Arje Cahn wrote: Does anyone know what's up with those digest emails? Or does this only happen to me... All Jira messages are suddenly credited to Ard Schrijvers. I guess he didn't change *all* of the Jira issues below, did he???! ezmlm caches the author text by email address. Since the jira notices all go out with the same email address, the first author is cached and reused by the index. Depending on how you look at it, this is either a bug in ezmlm or a bug in jira. No, it won't be fixed. Digests are for weenies. :-p Roy
Re: [Proposal] Sling
I would just add that JSR-311 might also be an option. As an aside (and since you folks are on the Expert Group), do we know if JAX-RS will be under a suitable specification license, or has Sun encumbered it as they have other Sun-led specifications? We don't know. We won't implement JSR-311 if it isn't open, but at this point I wouldn't trust Sun even if they promised a BSD license. Roy
Re: [VOTE] Release Apache Jackrabbit 1.3.1
On Jul 27, 2007, at 11:57 PM, Jukka Zitting wrote: If my reasoning is correct, I would treat the issue as a test case bug to be fixed in a future release, and not a blocker to 1.3.1. I don't consider it a blocker. I think it may have existed on 1.3.0 as well, since I remember trying to test it and being unable to vote because of the failure (and not enough time to investigate it). Since nobody else has seen it, I just assume it is a local setup issue with maven. Roy
Re: [VOTE] Release Apache Jackrabbit 1.3.1
I have posted a candidate for the Apache Jackrabbit 1.3.1 release at http://people.apache.org/~jukka/jackrabbit/1.3.1/ All sigs and hashes good. However, I am getting test failures on OS X 10.4.10 (PPC) with java version 1.5.0_07 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164) Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing). All failures are because of junit.framework.AssertionFailedError: namespace: http://www.jcp.org/ jcr/mix/1.0 not exported More details below. Roy Running org.apache.jackrabbit.test.TestAll [Fatal Error] :1:10: Attribute name is associated with an element type this must be followed by the ' = ' character. [Fatal Error] :1:10: Attribute name is associated with an element type this must be followed by the ' = ' character. [Fatal Error] :-1:-1: Premature end of file. [Fatal Error] :-1:-1: Premature end of file. Tests run: 1055, Failures: 8, Errors: 0, Skipped: 0, Time elapsed: 119.126 sec FAILURE! Results : Failed tests: testExportDocView_handler_session_skipBinary_noRecurse (org.apache.jackrabbit.test.api.ExportDocViewTest) testExportDocView_handler_session_skipBinary_recurse (org.apache.jackrabbit.test.api.ExportDocViewTest) testExportDocView_handler_session_saveBinary_noRecurse (org.apache.jackrabbit.test.api.ExportDocViewTest) testExportDocView_handler_session_saveBinary_recurse (org.apache.jackrabbit.test.api.ExportDocViewTest) testExportDocView_stream_session_skipBinary_recurse (org.apache.jackrabbit.test.api.ExportDocViewTest) testExportDocView_stream_session_skipBinary_noRecurse (org.apache.jackrabbit.test.api.ExportDocViewTest) testExportDocView_stream_session_saveBinary_noRecurse (org.apache.jackrabbit.test.api.ExportDocViewTest) testExportDocView_stream_session_saveBinary_recurse (org.apache.jackrabbit.test.api.ExportDocViewTest) Tests run: 1248, Failures: 8, Errors: 0, Skipped: 0 --- Test set: org.apache.jackrabbit.test.TestAll --- Tests run: 1055, Failures: 8, Errors: 0, Skipped: 0, Time elapsed: 119.124 sec FAILURE! testExportDocView_handler_session_skipBinary_noRecurse (org.apache.jackrabbit.test.api.ExportDocViewTest) Time elapsed: 0.07 sec FAILURE! junit.framework.AssertionFailedError: namespace: http://www.jcp.org/ jcr/mix/1.0 not exported
Re: JSR-283 TCK?
On Jul 4, 2007, at 12:42 AM, Arje Cahn wrote: I'm not sure whether this has been discussed on the list already, but what happens to Jackrabbit when the Apache JCP policy proposal gets voted in and the ASF will no longer accept a JSR-283 TCK? (or is that not the case..?) Day published the JSR 170 TCK under a completely open license. AFAIK (and I should know), Day is going to use the same license for JSR 283. All of the tests for 170 are the same as those used in the Jackrabbit maven build, though some are on the exclusion list by now (meaning other implementations don't have to pass them). And the work products of the EG are all public on java.net. In order to do all that, Day had to develop our own test harness that would not be encumbered by Sun's proprietary harness and NDA, and our own license that would allow self-testing under the official TCK (which can be downloaded for free at www.day.com). You can find that harness in the Jackrabbit subversion as well. Note that you only need the TCK if you are implementing an independent implementation, or if you want to certify a forked version of Jackrabbit. The Apache Jackrabbit release builds are already tested against the TCK. Will this have any negative consequences for the progress of Jackrabbit 2.0? I don't think so. Even if Apache were to completely exit the JCP, David's policy has been to add individuals to the expert group. Roy
Re: Re JSR170 license
On Jun 23, 2007, at 4:17 AM, Randy Gordon wrote: Mr Fielding, I apologize for sending this directly to the list, but since I saw your reply only on reading GMANE on the web and not in my emailed jackrabbit dev digests, I don't know where else to send it. My reply to your comments is: As I said, I am not a lawyer, and this is not legal advice, just simply voicing my concerns in an appropriate forum. Basically, I just want Day software to incorpate into their license the assurances you mentioned. All Day software has to do is state unconditionally that the Apache License terms replace theirs for anyone using Apache JackRabbit or incorporating Apache JackRabbit into their products. Apache Jackrabbit is under the Apache License. Every single bit. The only stuff under the Day JSR license is the JSR specification, which consists of an interface jar and documentation under the broadest possible terms allowed by Sun Microsystems for Java standards). The JCR jar is intended to be part of the Java infrastructure, just like servlets, and thus not redistributed with every application. It is not included with Jackrabbit. The official interface jar is not open source because Sun does not allow us to release it as such. Any copy of Apache Jackrabbit, including anything you might create through derivation of the Apache Jackrabbit code, is only under the Apache License. The fact that there exists some other license out there for some other piece of code is irrelevant. Day licensed the Jackrabbit implementation to the ASF under the Apache contribution agreement and the ASF licenses it to everyone under the Apache License. I am reading the license the way I think a judge would read it. Thats because. should there be litigation, your statements are not admissible in court, only the actual licenses. Please seek a lawyer's opinion. A lawyer will tell you that anything is admissible in court, especially written communication like this one. I did read the second clause, but I didn't include the second clause, because the fair use exemption only allows me reproduce one clause at a time. But since you brought it up, it is now fair game. The fair use exemption applies to copyrightable work, not the text of a license to you (which is inherently unrestricted by copyright), and in any case there is no such thing as a reproduce one clause at a time limitation to fair use. You don't need an exemption to have a public conversation about a public document offered to you as a license. Seriously, stop making this stuff up. .2. License for the Distribution of Compliant Implementations. Licensor also grants you a perpetual, non-exclusive, non- transferable, worldwide, fully paid-up, royalty free, limited license (without the right to sublicense) under any applicable copyrights or, subject to the provisions of subsection 4 below, patent rights it may have covering the Specification to create and/ or distribute an Independent Implementation of the Specification that: (a) fully implements the Specification including all its required interfaces and functionality; (b) does not modify, subset, superset or otherwise extend the Licensor Name Space, or include any public or protected packages, classes, Java interfaces, fields or methods within the Licensor Name Space other than those required/ authorized by the Specification or Specifications being implemented; and (c) passes the Technology Compatibility Kit (including satisfying the requirements of the applicable TCK Users Guide) for such Specification (Compliant Implementation). In addition, the foregoing license is expressly conditioned on your not acting outside its scope. No license is granted hereunder for any other purpose (including, for example, modifying the Specification, other than to the extent of your fair use rights, or distributing the Specification to third parties). a) and b) don't particularly bother me, though a definition of what constitutes fully implements is a little worrying. An argument can easily be made that even a single bug constitutes not fully implementing the specification, and thus invalidates the license, subjecting companies (or their customers) utilizing any software implementing the JSR-170 specification, including Jackrabbit) to the threat pf litigation. Please go to http://www.jcp.org/ and lodge your complaint. These terms are mandated by Sun on all specification leads in order to retain Java compatibility. Day has no choice in the matter aside from the choice of choosing more restrictive terms. The specification license is only one of many licenses issued by Day. What I am concerned about is c, TCK compliance and the foregoing license is expressly conditioned on your not acting outside its scope. You see, in clause 3 (not reproduced here) the pass through conditions expressly state that any subsidiary license (such as JackRabbits Apache license)
Re: JSR-170 license
On Jun 20, 2007, at 5:35 PM, Randy Gordon wrote: I started writing a JackRabbit Eclipse plugin, and decided to include the JSR-170 javadocs. As I read the license for the JSR-170 specification on http:// www.day.com/maven/jsr170/licenses/day-spec-license.htm. it seems pretty clear you cannot, under any conditions, use any product implementing a JSR-170 implementation for other than evaluation uses. Umm, is this correct? No. Read clause 2. It really kinda limits the use of Jackrabbit, since it falls under the license as a JSR-170 implementation and, well, I don't mind doing a plugin for the Open Source community, but I draw the line at donating it to a commercial company. Jackrabbit is under the Apache License. As near as I can tell (I am no lawyer) it is viral, it also claims rights to any product that merely uses the JSR-170 specification No, it is not viral in any sense, and cannot claim rights on other people's software. What on earth are you reading? It is the most liberal of the standard spec licenses allowed by the JSPA. All JSRs are implemented under those terms (at best) or far more restrictive terms. However, I did a BI application for a patent search company a while back, and, learned a little bit about patent squatting. While this license COULD be interpreted to apply only to the specification itself, the courts tend to take a narrower view. Finally, I am at a loss as to why why this license is even necessary for a specification that is intended for use by other commercial companies. The JSPA requires it for compatibility restrictions. Talk to Sun. The relevant passages are below: 1. License for Purposes of Evaluation and Developing Applications. Licensor hereby grants you a fully-paid, non-exclusive, non- transferable, worldwide, limited license (without the right to sublicense), under Licensor's applicable intellectual property rights to view, download, use and reproduce the Specification only for the purpose of internal evaluation. This includes developing applications intended to run on an implementation of the Specification provided that such applications do not themselves implement any portion(s) of the Specification. No, that's only the first clause. Try reading the other clauses. In any case, that license only applies to the JCR jar file and javadocs (the specification) distributed by Day. Apache Jackrabbit is separate and completely under the Apache License. Roy
Re: [VOTE] Accept JCR Mapping from Graffito
+1 Roy
Re: Next Generation Persistence
On Apr 13, 2007, at 2:59 AM, Jukka Zitting wrote: On 4/13/07, Marcel Reutegger [EMAIL PROTECTED] wrote: hmm, I see. there seems to be a fundamental mismatch between the spi and the ngp design. The spi clearly decouples the transient changes from the server whereas the ngp rather integrates them more tightly into the core. Agreed. I think the mismatch is an example of the more general tradeoffs between remote and local access. For a remote client it definitely makes sense to keep the transient space local as long as possible, but for a local client this is not a strict requirement, just one design option among others. It sounds to me more like the transient space needs its own backing store mechanism. It doesn't make sense for unsaved changes to be sent across the SPI, for the same reason it doesn't make sense to send workspace edits to the subversion repo before an explicit commit. Ideally, we should be able to support offline editing of the workspace for any nodes that are already copied to the client, without having to worry about the memory size. Usually that means keeping only a window of memory active and persisting changes outside that window to the local disk. Roy
Re: svn commit: r522174 - in /jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit: LICENSE.txt NOTICE.txt
On Mar 25, 2007, at 1:14 AM, Jukka Zitting wrote: On 3/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Log: Removed the LICENSE.txt and NOTICE.txt files from the source tree. These files are located in the project base directory and automatically included in the jar artifacts by extra Maven rules. Removed: jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/ jackrabbit/LICENSE.txt jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/ jackrabbit/NOTICE.txt I assume these files were leftovers from earlier times when we didn't have Maven rules to include the license and notice in the jar artifacts. Actually, they were there because some people were using svn:externals to copy the tree into other distributions. They are not needed any more. Roy
Re: Bundle Persistence Manager
On Feb 20, 2007, at 7:18 AM, Jukka Zitting wrote: 3. Day files a software grant (http://www.apache.org/licenses/software-grant.txt) for the contributed code. It is sufficient for Day to send an addendum to the existing grant. In other words, ask David to send email to Jim Jagielski (and cc the jackrabbit dev list) that says the additional code also falls under our existing grant agreement. While he is doing that, he should also add the names of our new employees to the Day CCLA. PS. We should have done this already when the SPI codebase was introduced. The ASF board noted about this, but the issue was not critical enough to require after-the-fact actions. In any case we should do things by the book this time. I thought we did. David Nuescheler sent his message to this list saying that it was a contribution under the existing CCLA, and that is sufficient for Apache legal. David is the official contact. Roy
Re: [VOTE] Include BundlePersistenceManager Contribution [JCR-755]
+1 Roy
Re: [VOTE] Release Apache Jackrabbit 1.2
On Jan 17, 2007, at 5:47 AM, Carsten Ziegeler wrote: Raphael Wegmueller wrote: the usage of the 3rd version digit as a sort of rc counter sounds rather confusing to me, too... how about always suffixing release candidates that are voted on with -rcN, and after acceptance releasing the same binaries again, this time without suffixes? their md5 checksums would be identical, so there should be no confusion as to which rc it is, and the release would have the proper version. This is the way how other projects at Apache perform the release process (preparing everything as version x.y(.z)-rcN, building the dist with this version information and also creating this tag/branch in svn). If the vote is successful, the suffix is just removed. Release votes are on the final source package as built and signed by one of the trusted PMC members. Voting on anything other than that is a waste of time, as the vote would have to be repeated for the final package testing. The votes are an indication of the number of people who have downloaded the source package, verified the signature, unpacked it, built it from the source, and then run whatever tests that individual feels are sufficient to earn that person's +1. No source package can be released without three binding +1s from the PMC on *that* package. Version numbers are cheap. It costs nothing to increment the third (a.k.a., patch-level) number every time a change is made to the posted packages. It costs a great deal to repeat all of the source-based testing and votes just because someone has to go back and remove a bunch of worthless rcN suffixes. Speaking as the former chairman, any ASF project that is voting on packages and then changing them before release is violating Apache guidelines on how to prepare a release. They should learn how to do it right. And, yes, I am aware that some Jakarta projects have never produced a valid release. Roy
Re: [VOTE] Release Apache Jackrabbit 1.2
On Jan 17, 2007, at 5:29 AM, Raphael Wegmueller wrote: so what would happen if you had to release a real patch to jackrabbit 1.2.1? would it be versioned 1.2.1.1 then? or 1.2.2? This is an open source project. Patches are source code diff files and don't have versions. They just apply to versions. http://www.apache.org/dist/httpd/patches/ We only produce releases from minor branches. Branching on each patch-level is suicidal -- the kind of thing you only want to do when someone is paying for support. Roy
Re: [VOTE] Release Apache Jackrabbit 1.2
On Jan 16, 2007, at 3:38 PM, Jukka Zitting wrote: I have posted an updated candidate for the Apache Jackrabbit 1.2 release at http://people.apache.org/~jukka/jackrabbit/1.2/ See the included RELEASE-NOTES.txt file for details on release contents and latest changes. The JCR-707 fix is the only change after the previous cancelled release vote. Er, then the packages should be named 1.2.1. The problem with doing all of our laundry in public is that the public often download our unreleased packages even when we tell them not to. For that reason, most Apache projects increment the patch-level number each time a new package is produced (releases do not need to be sequential). So, for that reason, I am -1. I know that keeping the version number consistent across all of the maven packages could be a pain in the ass, but we really should adhere to a policy of giving a unique version to each releasable package set (even if it doesn't get released). Otherwise, we have no real way to ensure that people posting bug reports about 1.2 have actually installed what we think of as 1.2. Roy
Re: Jackrabbit and Maven
Are we going to move the site generation from core to the parent? [EMAIL PROTECTED] egrep jackrabbit-site jackrabbit-core/* jackrabbit-core/project.properties:# Site Deploy (into ../jackrabbit- site for checkout on jackrabbit.apache.org) jackrabbit-core/project.xml:siteDirectory../jackrabbit-site/ siteDirectory It would be nice to start documenting those projects that have moved up out of the contrib section. Roy
Re: svn commit: r473755 [1/43] - in /jackrabbit/trunk/contrib/jcr-browser: ./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/apache/jackrabbit/ src/main/j
Why do we need the dojo library in our subversion? Roy
Re: svn commit: r473755 [1/43] - in /jackrabbit/trunk/contrib/jcr-browser: ./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/apache/jackrabbit/ src/main/j
On Nov 12, 2006, at 4:21 PM, Jukka Zitting wrote: On 11/13/06, Edgar Poce [EMAIL PROTECTED] wrote: On 11/12/06, Roy T. Fielding [EMAIL PROTECTED] wrote: Why do we need the dojo library in our subversion? It's not something we need, it's not a hard task to add dojo manually to a webapp. However, I thought that adding javascript libraries to subversion was the common practice, e.g. I think I saw commits of dojo sources in tapestry and cocoon. Do you think we should remove it? No, at least the way I see it. Legally the dependency is fine (though having license comments in each file and a standard NOTICE file would be nice), so the question is mostly about the technical mechanism used to include the Dojo library in the webapp. Since Javascript libraries are distributed in source form, there is nothing like a Maven repository for them, and pointing a client to download the library from somewhere else than the deployed webapp is out of the question, the best we can do is to include a copy. If we are not planning on maintaining the dojo files as a fork, then we include installation instructions with the webapp, or an install script that builds a webapp from our source and the latest tarball from dojo. The only time that we would distribute both is when the RM builds a release, at which time the RM would install the best available version of dojo inside the release jar. We do not need it in our subversion unless we plan on forking the dojo content. We are talking about 20MB of *source*. Roy
[jira] Commented: (JCR-592) Use only the standard Maven repository for dependencies
[ http://issues.apache.org/jira/browse/JCR-592?page=comments#action_12445587 ] Roy T. Fielding commented on JCR-592: - The Day Spec License is the broadest possible license allowed under the JSPA (use of this template is enforced by Sun legal as part of the review process prior to publication of the Specification). The JCP requires that this license be enforced through (at a minimum) a click-through licensing agreement. In other words, that license can only be used for personal experimentation and distribution of bundles that include an independent implementation that passes the TCK. Apache Maven would require a separate license in order to distribute the JCR jar file to third parties. The CCLA that Day signed for Apache does not include the Specification and its associate API. JSPA rules do not allow us to transfer such a broad license to Apache due to the API compatibility restrictions. However, Day is able to extend additional license terms on its own that would not change the specification agreement. For example, Day could upload the JCR API jar file to the Maven repository with a license addendum that states it may also be redistributed unmodified to third parties for the purpose of building/compiling Java software, provided that further redistribution of the JCR API jar file (such as when distributed with the result of that compilation) is only allowed under the terms of the Day Specification License. In any case, it is not okay for anyone other than Day to upload the jar to a repository. All of the contribution agreements that feed IP into the JSR 170/283 process are funneled through the Spec Lead, so it is safer to have the spec lead perform any actions that might lead to copyright/patent issues down the line. [Those would be issues generated by the other EG members -- Day does not have any such issues of its own]. Apache should probably ask the JCP to add Maven-style distribution as an additional (optional) term to the standard template. That would allow Day to adopt the new term when 283 is published. Use only the standard Maven repository for dependencies --- Key: JCR-592 URL: http://issues.apache.org/jira/browse/JCR-592 Project: Jackrabbit Issue Type: Improvement Components: maven Affects Versions: 0.9, 1.0, 1.0.1, 1.1 Reporter: Jukka Zitting Assigned To: Jukka Zitting Priority: Minor Fix For: 1.1.1 The JCR API jars are now available in the standard Maven repository, see http://jira.codehaus.org/browse/MAVENUPLOAD-1050. We could thus remove the dependency on the Day repository, as requested in http://jira.codehaus.org/browse/MEV-453. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: is the wiki the right place to distribute binaries?
On Sep 19, 2006, at 7:00 AM, Edgar Poce wrote: a few days ago a user uploaded to the wiki a zip file which contains a jackrabbit installer for jboss. Personally, for lots of reasons, I think it's a bad idea to distribute binaries through the wiki and I think the asf has well defined procedures for releasing. I invited the author to contribute the script to generate the installer but didn't get a response. I think it should be removed, however I don't want to remove a user contribution without knowing the wiki policy and others opinions. So, wdyt? should we remove the zip file from the wiki? You are right. We can link to someone else's website that contains a page about their own installer, but we can't distribute a binary that someone else created from our own website. It needs to be removed. BTW, I don't recall seeing any notification for that upload. Did we get one and I just missed it, or is the wiki software letting people upload files without sending a notification? Roy
Re: Improving the accessibility of the Jackrabbit core
On Sep 6, 2006, at 4:14 AM, David Nuescheler wrote: Personally, I believe that for example a restore facility has to be buried deep down in the core and therefore the code has to comply with the high quality requirements that we have for code in the core and for the seasoned Jackrabbit experience of a developer. That is why each of the core developers has veto power over the code. If we want to ensure that every line is adequately reviewed, then ask for the core code to be governed by the RTC (review-then-commit) rule. Note, however, that such a requirement will extend to all commits on that part of the code. In my mind your experience with developing very close to the heart of Jackrabbit should not lead us to opening up the core so inexperienced Jackrabbit developers can contribute, but it should help us realize that we have very high requirements for Jackrabbit developers that make modifications to the core. I don't think you understand. This is an Apache project and anyone can contribute to any part of it. The degree of review we require of those contributions is decided by the PMC (our committers). We can increase the requirements on review of the core code and we can separate compatible and incompatible changes into versioned branches, but we cannot ask of others what we do not accept of ourselves. In my opinion, the core code continues to evolve as people try to do larger and more expressive things with Jackrabbit and apply JCR to real problem sets. We need to welcome that and change things based on their technical merits, not any preconceived notions of how much a person knows about the current (highly opaque) core architecture. Most likely, this will mean simplifying the core by removing or refactoring some of the spaghetti dependencies. One of those things that will change is the degree of extensibility, since that is the heart of any successful open source project and Jackrabbit isn't even halfway there yet. I am sure that others with fresh energy will see new ways to solve the same problem that will not be burdened with the legacy decisions that we made for one reason or another. When those ideas are presented, they will be subject to intense scrutiny and adopted based only on their proven benefits. They will not be judged based on who wrote them or how much time they spent writing the initial core code. Roy
website look
As part of the website upgrade, someone decided to change the ASF logo. As you might imagine, making arbitrary changes to the Apache logos are just as forbidden here as they would be for any other company. I have reverted the change to project.xml that caused the new logo to be shown. Unfortunately, that messes up the CSS layout, which is entirely too fragile at the moment -- just try adjusting the screen width on your browser to see why. I am supposed to be on vacation right now and don't have access to the right software. Hopefully, folks can make another pass at the website look and (without changing the ASF logo) improve it. Also, the main reason we needed a new Jackrabbit logo is because the project is Apache Jackrabbit. Leaving the Apache part out of the logo is not an option. Hopefully that will be easy to adjust. Roy
[jira] Commented: (JCR-367) Remove dependency on Xerces
[ http://issues.apache.org/jira/browse/JCR-367?page=comments#action_12418726 ] Roy T. Fielding commented on JCR-367: - It is not safe to use code from a JDK, even when that code comes from Apache originally. Please replace it with the code from Xerces trunk. Remove dependency on Xerces --- Key: JCR-367 URL: http://issues.apache.org/jira/browse/JCR-367 Project: Jackrabbit Type: Improvement Components: xml Versions: 0.9, 1.0, 1.0.1 Reporter: Michael Young Assignee: Felix Meschberger Fix For: 1.1 Attachments: No_Xerces_Patch.fm.20060627.patch Classloaders in certain J2EE servers do not play well with the Xerces requirement -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (JCR-356) Replace license headers with new policy text
[ http://issues.apache.org/jira/browse/JCR-356?page=all ] Roy T. Fielding closed JCR-356: --- Resolution: Fixed No need to update the old branch. Replace license headers with new policy text Key: JCR-356 URL: http://issues.apache.org/jira/browse/JCR-356 Project: Jackrabbit Type: Task Versions: 1.1, 1.0.1 Reporter: Roy T. Fielding Assignee: Roy T. Fielding Priority: Blocker Fix For: 1.1 We need to replace all of the license headers with a new template that replaces the Copyright and license lines with ---BEGIN PROPOSED SOURCE FILE HEADER--- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. The ASF licenses this file to You under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. ---END PROPOSED SOURCE FILE HEADER--- The copyright line is being removed from files due to legal advice from ASF attorneys. It is replaced with a statement that the copyright owners have licensed it to the ASF. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Subscription: open issues
On May 28, 2006, at 4:29 AM, Tobias Bocanegra wrote: does anybody know who is responsible for this mailing? the html is broken an none of the links work. The mailing is text-only -- maybe gmail is choking on it. Roy
[jira] Reopened: (JCR-356) Replace license headers with new policy text
[ http://issues.apache.org/jira/browse/JCR-356?page=all ] Roy T. Fielding reopened JCR-356: - The ASF board just changed the license header text (added a sentence). RESOLVED, that the NOTICE file shall begin with the following text, suitably modified to reflect the product name and year(s) of distribution of the current and past releases: Apache [PRODUCT_NAME] Copyright [] The Apache Software Foundation This product includes software developed at The Apache Software Foundation (http://www.apache.org/). and be it further RESOLVED, that files licensed to The Apache Software Foundation shall be labeled with the following notice: Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. and be it further RESOLVED, that for the case of works that have not been directly submitted by the copyright owners to the Foundation for development, the associated copyright notices for the work shall not be moved, removed, or modified. I'll start working on the changes. Replace license headers with new policy text Key: JCR-356 URL: http://issues.apache.org/jira/browse/JCR-356 Project: Jackrabbit Type: Task Versions: 0.9, 1.1, 1.0.1 Reporter: Roy T. Fielding Assignee: Roy T. Fielding Priority: Blocker Fix For: 1.0 We need to replace all of the license headers with a new template that replaces the Copyright and license lines with ---BEGIN PROPOSED SOURCE FILE HEADER--- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. The ASF licenses this file to You under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. ---END PROPOSED SOURCE FILE HEADER--- The copyright line is being removed from files due to legal advice from ASF attorneys. It is replaced with a statement that the copyright owners have licensed it to the ASF. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-356) Replace license headers with new policy text
[ http://issues.apache.org/jira/browse/JCR-356?page=all ] Roy T. Fielding updated JCR-356: Fix Version: 1.1 (was: 1.0) Version: (was: 0.9) Replace license headers with new policy text Key: JCR-356 URL: http://issues.apache.org/jira/browse/JCR-356 Project: Jackrabbit Type: Task Versions: 1.1, 1.0.1 Reporter: Roy T. Fielding Assignee: Roy T. Fielding Priority: Blocker Fix For: 1.1 We need to replace all of the license headers with a new template that replaces the Copyright and license lines with ---BEGIN PROPOSED SOURCE FILE HEADER--- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. The ASF licenses this file to You under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. ---END PROPOSED SOURCE FILE HEADER--- The copyright line is being removed from files due to legal advice from ASF attorneys. It is replaced with a statement that the copyright owners have licensed it to the ASF. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Jackrabbit site updates
On Apr 24, 2006, at 4:41 PM, Jukka Zitting wrote: I just committed a few changes to the Jackrabbit web site. Brief summary: 1) I replaced the latest javadocs with the javadocs of the 1.0 release. I also disabled the javadoc report from project.xml to keep the javadocs static. See the recent site deployment discussion for the rationale of this change. Thanks Jukka! That is a huge improvement. I had no idea that the project reports were the reason that the source tree had to be rebuilt every time I wanted to tweak a simple typo. Now we just need to fix that bug in maven that changes the class names in tables even when no content is changed. Roy
[jira] Updated: (JCR-352) Upgrade to Lucene 1.9.1
[ http://issues.apache.org/jira/browse/JCR-352?page=all ] Roy T. Fielding updated JCR-352: Component: indexing (was: query) Upgrade to Lucene 1.9.1 --- Key: JCR-352 URL: http://issues.apache.org/jira/browse/JCR-352 Project: Jackrabbit Type: Improvement Components: indexing Versions: 1.0, 0.9 Environment: All Reporter: Michael Young Assignee: Jukka Zitting We would like to upgrade to Lucene 1.9.1. There are jar conflicts when integrating with other projects such as Liferay Portal -- which uses v 1.9.1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-372) Consistently refer to Apache Jackrabbit in docs and site
[ http://issues.apache.org/jira/browse/JCR-372?page=all ] Roy T. Fielding updated JCR-372: Fix Version: 1.0.1 (was: 1.0) This is an ongoing work item, but the most significant docs are fixed for 1.0. Consistently refer to Apache Jackrabbit in docs and site -- Key: JCR-372 URL: http://issues.apache.org/jira/browse/JCR-372 Project: Jackrabbit Type: Bug Components: docs, site Reporter: Roy T. Fielding Priority: Minor Fix For: 1.0.1 We need to consistently refer to our project (and product) as Apache Jackrabbit on our site and docs, except where the context is obvious. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-298) missing blob.remove in Berkeley DB persistance manager
[ http://issues.apache.org/jira/browse/JCR-298?page=all ] Roy T. Fielding updated JCR-298: Component: contrib PMs missing blob.remove in Berkeley DB persistance manager -- Key: JCR-298 URL: http://issues.apache.org/jira/browse/JCR-298 Project: Jackrabbit Type: Bug Components: contrib PMs Versions: 1.0 Reporter: scharles Priority: Minor org/apache/jackrabbit/core/state/bdb/BerkeleyDBPersistenceManager.destroy(PropertyState state) does not remove binary file from the BLOBStore (filesystem impl) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-350) WebDAV: add support for RFC 3744
[ http://issues.apache.org/jira/browse/JCR-350?page=all ] Roy T. Fielding updated JCR-350: Component: webdav WebDAV: add support for RFC 3744 Key: JCR-350 URL: http://issues.apache.org/jira/browse/JCR-350 Project: Jackrabbit Type: New Feature Components: webdav Reporter: angela Assignee: angela Priority: Minor -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-368) Add support for simple test cases
[ http://issues.apache.org/jira/browse/JCR-368?page=all ] Roy T. Fielding updated JCR-368: Component: core Add support for simple test cases - Key: JCR-368 URL: http://issues.apache.org/jira/browse/JCR-368 Project: Jackrabbit Type: New Feature Components: core Reporter: Jukka Zitting Assignee: Jukka Zitting Priority: Minor Fix For: 1.0 Attachments: TestRepository.patch As discussed on the mailing list, I'd like to add a simple org.apache.jackrabbit.core.TestRepository helper class that could be used in a simple unit test template. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-76) PersistenceManager sanity check
[ http://issues.apache.org/jira/browse/JCR-76?page=all ] Roy T. Fielding updated JCR-76: --- Component: contrib PMs Environment: PersistenceManager sanity check --- Key: JCR-76 URL: http://issues.apache.org/jira/browse/JCR-76 Project: Jackrabbit Type: New Feature Components: contrib PMs Reporter: Edgar Poce Attachments: 05-03-21-sanitycheck.zip, 05-04-18-sanitycheck.zip, 05-05-15-sanitycheck.zip Library that provides a framework for testing the repository consistency and repairing it if necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-148) ORM-PMs store data disregarding the workspace
[ http://issues.apache.org/jira/browse/JCR-148?page=all ] Roy T. Fielding updated JCR-148: Component: contrib PMs ORM-PMs store data disregarding the workspace - Key: JCR-148 URL: http://issues.apache.org/jira/browse/JCR-148 Project: Jackrabbit Type: Bug Components: contrib PMs Reporter: Edgar Poce This bug was reported in the mailing list on june 8th. See http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/2247 ORM PMs store itemstates disregarding the workspace name, which means that the data stored in one workspace is accessible from any other. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (JCR-373) all references to incubator need to be replaced with new locations
all references to incubator need to be replaced with new locations -- Key: JCR-373 URL: http://issues.apache.org/jira/browse/JCR-373 Project: Jackrabbit Type: Bug Components: docs, site Reporter: Roy T. Fielding Priority: Blocker Fix For: 1.0 The following files under 1.0 branch refer to incubator in one way or another. Some of them may be benign. ./contrib/bdb-persistence/project.properties ./contrib/bdb-persistence/project.xml ./contrib/bdb-persistence/README.txt ./contrib/classloader/project.properties ./contrib/classloader/project.xml ./contrib/examples/project.xml ./contrib/extension-framework/project.properties ./contrib/extension-framework/project.xml ./contrib/jcr-commands/jmeter-chain/project.properties ./contrib/jcr-commands/project.properties ./contrib/jcr-commands/xdocs/navigation.xml ./contrib/jcr-ext/project.xml ./contrib/jcrtaglib/project.properties ./contrib/orm-persistence/project.properties ./contrib/orm-persistence/project.xml ./jackrabbit/applications/test/cnd-reader-test-input.cnd ./jackrabbit/project.properties ./jackrabbit/project.xml ./jackrabbit/README.txt ./jackrabbit/src/site/fml/faq.fml ./jackrabbit/src/site/xdoc/doc/arch/overview/jcrlevels.xml ./jackrabbit/src/site/xdoc/doc/building.xml ./jackrabbit/src/site/xdoc/doc/config.xml ./jackrabbit/src/site/xdoc/downloads.xml ./jackrabbit/src/site/xdoc/index.xml ./jackrabbit/src/site/xdoc/tasks.xml ./jackrabbit/src/test/java/org/apache/jackrabbit/core/nodetype/compact/CompactNodeTypeDefTest.java ./jca/project.properties ./jca/project.xml ./textfilters/project.properties ./textfilters/project.xml I'd edit them myself, but I need to sleep... maybe tomorrow if nobody beats me to it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
