Re: jackrabbit
Hi, please use the user list for questions on how to use jackrabbit. regards marcel On Wed, Apr 8, 2009 at 17:25, Utpal Bhattacharya wrote: > Hello, > > I plan to use Jackrabbit as DMS tool in my project. If any of you can guide > me how to save and browse files of different types from a java program, that > would be great. > > > > > > > > Thanks & Regards > > Utpal Bhattacharya > > > This e-mail and its attachments are confidential. If you are not the > intended recipient of this e-mail message, please telephone or e-mail us > immediately, delete this message from your system and do not read, copy, > distribute, disclose or otherwise use this e-mail message and any > attachments. > > Although RI3K believes this e-mail and any attachments to be free of any > virus or other defect which may affect your computer, it is the > responsibility of the recipient to ensure that it is virus free and RI3K > does not accept any responsibility for any loss or damage in any way from > its use. > > RI3K Limited is a company registered in England no: 3909745. Registered > office 10, Ely Place, London, EC1N 6RY. VAT registration no: 769 0192 07 >
jackrabbit
Hello, I plan to use Jackrabbit as DMS tool in my project. If any of you can guide me how to save and browse files of different types from a java program, that would be great. Thanks & Regards Utpal Bhattacharya This e-mail and its attachments are confidential. If you are not the intended recipient of this e-mail message, please telephone or e-mail us immediately, delete this message from your system and do not read, copy, distribute, disclose or otherwise use this e-mail message and any attachments. Although RI3K believes this e-mail and any attachments to be free of any virus or other defect which may affect your computer, it is the responsibility of the recipient to ensure that it is virus free and RI3K does not accept any responsibility for any loss or damage in any way from its use. RI3K Limited is a company registered in England no: 3909745. Registered office 10, Ely Place, London, EC1N 6RY. VAT registration no: 769 0192 07<>
Hudson build is back to normal: Jackrabbit-trunk-java14 #163
See http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/163/changes
[jira] Updated: (JCRRMI-10) Implement RepositoryFactory
[ https://issues.apache.org/jira/browse/JCRRMI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCRRMI-10: Fix Version/s: 2.0.0 > Implement RepositoryFactory > --- > > Key: JCRRMI-10 > URL: https://issues.apache.org/jira/browse/JCRRMI-10 > Project: Jackrabbit JCR-RMI > Issue Type: New Feature >Reporter: Jukka Zitting > Fix For: 2.0.0 > > > Once JCR 2.0 is out and we want to upgrade JCR-RMI to use it, we can restore > the RepositoryFactory implementation removed in JCRRMI-8 simply by reverting > revision 760904. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Hudson build is back to stable: Jac krabbit-trunk » Jackrabbit Core #448
See http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk/org.apache.jackrabbit$jackrabbit-core/448/
[jira] Created: (JCR-2066) NodeTypeRegistry could auto-subtype from nt:base
NodeTypeRegistry could auto-subtype from nt:base Key: JCR-2066 URL: https://issues.apache.org/jira/browse/JCR-2066 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Tobias Bocanegra Priority: Minor this is basically a copy of JCR-433, which was fixed but somehow sneaked in again: when tying to register a (primary) nodetype that does not extend from nt:base the following error is thrown: "all primary node types except nt:base itself must be (directly or indirectly) derived from nt:base" since the registry is able to detect this error, it would be easy to auto-subtype all nodetypes from nt:base. imo it's pointless to explicitly add the nt:base to every superclass set. as an analogy, you don't need to 'extend from java.lang.Object' explicitly - the compiler does that automatically for your. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: auto subtype from nt:base
Hi, On Wed, Apr 8, 2009 at 4:08 PM, Tobias Bocanegra wrote: > i would like to get rid of this. Agreed. > should i reopen JCR-433 or create a new one? It's better not to reopen closed issues. A new minor (or trivial) improvement issue is probably best. BR, Jukka Zitting
auto subtype from nt:base
hi
the issue JCR-433 was fixed a long time ago, but there is still a
check in the nodetype registry:
// make sure that all primary types except nt:base
extend from nt:base
if (!ntd.isMixin() &&
!NameConstants.NT_BASE.equals(ntd.getName())
&& !est.includesNodeType(NameConstants.NT_BASE)) {
String msg = "[" + name + "] all primary node types except"
+ " nt:base itself must be (directly or
indirectly) derived from nt:base";
log.debug(msg);
throw new InvalidNodeTypeDefException(msg);
}
i would like to get rid of this. should i reopen JCR-433 or create a new one?
regards, toby
[0] https://issues.apache.org/jira/browse/JCR-433
[jira] Resolved: (JCR-2065) use the internal CND file for builtin nodetypes
[ https://issues.apache.org/jira/browse/JCR-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra resolved JCR-2065. --- Resolution: Fixed Fix Version/s: 1.6.0 added missing node types to the CND file and removed the builtin xml one. note that the custom node types are still stored in the custom_nodetypes.xml > use the internal CND file for builtin nodetypes > --- > > Key: JCR-2065 > URL: https://issues.apache.org/jira/browse/JCR-2065 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: nodetype >Affects Versions: 2.0.0 >Reporter: Tobias Bocanegra >Assignee: Tobias Bocanegra > Fix For: 1.6.0 > > > the jackrabbit node type registry is reading the built in node types from a > XML file. > since the CND (compact node type definition notation) is now specified by > jsr283, > i would like to drop the builtin .xml file and read the builtin node > typesonly from the .cnd file. > this certainly helps the developers. furthermore, all the node types in > jsr283 are now speced > in CND, and converting them to XML is a pain and error prone. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Hudson build became unstable: Jackrabbit-trunk » Jackrabbit Core #447
Hi, On Wed, Apr 8, 2009 at 3:58 PM, Apache Hudson Server wrote: > See > http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk/org.apache.jackrabbit$jackrabbit-core/447/ Doh, looks like a yet another regression caused by the Tika integration. I'm working on it. BR, Jukka Zitting
Hudson build became unstable: Jack rabbit-trunk » Jackrabbit Core #447
See http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk/org.apache.jackrabbit$jackrabbit-core/447/
[jira] Created: (JCR-2065) use the internal CND file for builtin nodetypes
use the internal CND file for builtin nodetypes --- Key: JCR-2065 URL: https://issues.apache.org/jira/browse/JCR-2065 Project: Jackrabbit Content Repository Issue Type: Improvement Components: nodetype Affects Versions: 2.0.0 Reporter: Tobias Bocanegra Assignee: Tobias Bocanegra the jackrabbit node type registry is reading the built in node types from a XML file. since the CND (compact node type definition notation) is now specified by jsr283, i would like to drop the builtin .xml file and read the builtin node typesonly from the .cnd file. this certainly helps the developers. furthermore, all the node types in jsr283 are now speced in CND, and converting them to XML is a pain and error prone. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-2064) Add new JSR283 features to CND reader/writer
[ https://issues.apache.org/jira/browse/JCR-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra reassigned JCR-2064: - Assignee: Tobias Bocanegra > Add new JSR283 features to CND reader/writer > > > Key: JCR-2064 > URL: https://issues.apache.org/jira/browse/JCR-2064 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core, jackrabbit-spi, nodetype >Affects Versions: 2.0.0 >Reporter: Tobias Bocanegra >Assignee: Tobias Bocanegra > > the current CND parser(s) and writers do not support the new options > specified by JSR283 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-2064) Add new JSR283 features to CND reader/writer
Add new JSR283 features to CND reader/writer Key: JCR-2064 URL: https://issues.apache.org/jira/browse/JCR-2064 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core, jackrabbit-spi, nodetype Affects Versions: 2.0.0 Reporter: Tobias Bocanegra the current CND parser(s) and writers do not support the new options specified by JSR283 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Getting rid of jackrabbit-text-extractors
On Wed, Apr 8, 2009 at 14:13, Jukka Zitting wrote: > (I assume you mean jackrabbit-text-extractors) ah, right. sorry. > The SearchIndex class currently has a hard dependency to TextExtractor > that needs to be there also on runtime, so we can't make the > text-extractors dependency optional without changing things. I'd > prefer to replace that dependency with one to the Tika Parser > interface, but then we need a hard Maven dependency on Tika. ideally I'd like to have the parser/text-extractor dependencies optional and whoever uses jackrabbit-core needs to decide which parsers/text-extractors he wants to use (the same actually also applies to persistence managers). however, that requires that we get rid of the runtime dependencies to either Tika and/or jackrabbit-text-extractors, but I don't know how this can be done easily (without reflection hacks). > In either case I think it's best for everyone if the current > TextExtractor classes will remain in the runtime classpath (in either > the text-extractors or the core jar) so that there's no need to modify > existing configurations. OK, I agree. backward compatibility should be guaranteed for 1.6 and there shouldn't be deployment surprises with an upgrade. regards marcel
[jira] Commented: (JCR-2054) Provide base classes to simplify read only RepositoryService implementations
[ https://issues.apache.org/jira/browse/JCR-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696999#action_12696999 ] Marcel Reutegger commented on JCR-2054: --- Missing lock method on AbstractReadableRepositoryService added in revision: 763215 > Provide base classes to simplify read only RepositoryService implementations > > > Key: JCR-2054 > URL: https://issues.apache.org/jira/browse/JCR-2054 > Project: Jackrabbit Content Repository > Issue Type: New Feature > Components: jackrabbit-spi-commons >Reporter: Marcel Reutegger >Priority: Minor > Fix For: 1.6.0 > > Attachments: JCR-2054.patch > > > There should be base classes that simplify the implementation of a > RepositoryService for read only access. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-2054) Provide base classes to simplify read only RepositoryService implementations
[ https://issues.apache.org/jira/browse/JCR-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved JCR-2054. --- Resolution: Fixed Fix Version/s: 1.6.0 Applied patch in revision: 763205 > Provide base classes to simplify read only RepositoryService implementations > > > Key: JCR-2054 > URL: https://issues.apache.org/jira/browse/JCR-2054 > Project: Jackrabbit Content Repository > Issue Type: New Feature > Components: jackrabbit-spi-commons >Reporter: Marcel Reutegger >Priority: Minor > Fix For: 1.6.0 > > Attachments: JCR-2054.patch > > > There should be base classes that simplify the implementation of a > RepositoryService for read only access. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Getting rid of jackrabbit-text-extractors
Hi, On Wed, Apr 8, 2009 at 1:43 PM, Marcel Reutegger wrote: > On Tue, Apr 7, 2009 at 23:29, Jukka Zitting wrote: >> Thus Jackrabbit 1.6 would no longer contain a separate text-extractors >> jar, but all the existing TextExtractor classes would still be >> incluced. In Jackrabbit 2.0 we'd drop all the TextExtractors and only >> use Tika Parsers. > > hmm, this adds quite some dependencies to jackrabbit-core. Currently we already have quite a few parsing dependencies through jackrabbit-text-extractors. Tika has even more, but with TIKA-1878 we're already including them. There's been some discussion in Tika about splitting Tika into a core jar with no dependencies (or just a few like commons-io), and a separate parser jar (or more) that contain the Parser implementations that depend on the various parser libraries like POI. I could push that idea forward in Tika if it would be useful in Jackrabbit. > What if we kept the dependency from jackrabbit-core to > jackrabbit-jcr-tests at version 1.5 but at the same time flag it > optional? That would remove it from the dependency tree but you'd > still have it in the pom (until we remove it in 2.0). (I assume you mean jackrabbit-text-extractors) The SearchIndex class currently has a hard dependency to TextExtractor that needs to be there also on runtime, so we can't make the text-extractors dependency optional without changing things. I'd prefer to replace that dependency with one to the Tika Parser interface, but then we need a hard Maven dependency on Tika. In either case I think it's best for everyone if the current TextExtractor classes will remain in the runtime classpath (in either the text-extractors or the core jar) so that there's no need to modify existing configurations. BR, Jukka Zitting
Re: Getting rid of jackrabbit-text-extractors
Hi, On Tue, Apr 7, 2009 at 23:29, Jukka Zitting wrote: > JCR-1878 is now resolved and Jackrabbit trunk is depending on Apache > Tika for text extraction functionality. Thus there is little more need > for jackrabbit-text-extractors as a standalone component. Anyone who > needs that functionality separately from jackrabbit-core should just > go for Tika directly. +1 > For backwards compatibility with existing configurations (and > potential extensions) we still need the current > org.apache.jackrabbit.extractor classes, but I'm thinking of simply > moving the entire package to jackrabbit-core and deprecating > everything except the new Tika-based extractor. In fact I'd even go as > far as changing the indexing code in jackrabbit-core to use the Tika > Parser interface directly and only provide a backwards-compatibility > layer for the TextExtractor classes we have. > > Thus Jackrabbit 1.6 would no longer contain a separate text-extractors > jar, but all the existing TextExtractor classes would still be > incluced. In Jackrabbit 2.0 we'd drop all the TextExtractors and only > use Tika Parsers. hmm, this adds quite some dependencies to jackrabbit-core. What if we kept the dependency from jackrabbit-core to jackrabbit-jcr-tests at version 1.5 but at the same time flag it optional? That would remove it from the dependency tree but you'd still have it in the pom (until we remove it in 2.0). regards marcel
[jira] Resolved: (JCR-2053) JSR 283: Shareable nodes support in query
[ https://issues.apache.org/jira/browse/JCR-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved JCR-2053. --- Resolution: Fixed Fix Version/s: 1.6.0 Applied patch in revision: 763188 > JSR 283: Shareable nodes support in query > - > > Key: JCR-2053 > URL: https://issues.apache.org/jira/browse/JCR-2053 > Project: Jackrabbit Content Repository > Issue Type: Sub-task > Components: jackrabbit-core >Reporter: Marcel Reutegger > Fix For: 1.6.0 > > Attachments: JCR-2053.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Build failed in Hudson: Jackrabbit-trunk-java14 #162
See
http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/162/changes
Changes:
[jukka] JCR-1878: Use Apache Tika for text extraction
Xerces needs extra XML APIs on Java 1.4. These will be ignored on Java 5 and
higher.
--
[...truncated 397 lines...]
File "TokenMgrError.java" does not exist. Will create one.
File "ParseException.java" does not exist. Will create one.
File "Token.java" does not exist. Will create one.
File "SimpleCharStream.java" does not exist. Will create one.
Parser generated successfully.
[INFO] Processed 1 grammar
[INFO] [javacc:jjtree-javacc {execution: xpath}]
Java Compiler Compiler Version 4.0 (Tree Builder)
(type "jjtree" with no arguments for help)
Reading from file
http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/ws/trunk/jackrabbit-spi-commons/src/main/javacc/xpath/XPath.jjt
. . .
File
"http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/ws/trunk/jackrabbit-spi-commons/target/generated-sources/jjtree/org/apache/jackrabbit/spi/commons/query/xpath/Node.java";
does not exist. Will create one.
File
"http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/ws/trunk/jackrabbit-spi-commons/target/generated-sources/jjtree/org/apache/jackrabbit/spi/commons/query/xpath/SimpleNode.java";
does not exist. Will create one.
Annotated grammar generated successfully in
http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/ws/trunk/jackrabbit-spi-commons/target/generated-sources/jjtree/org/apache/jackrabbit/spi/commons/query/xpath/XPath.jj
Java Compiler Compiler Version 4.0 (Parser Generator)
(type "javacc" with no arguments for help)
Reading from file
http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/ws/trunk/jackrabbit-spi-commons/target/generated-sources/jjtree/org/apache/jackrabbit/spi/commons/query/xpath/XPath.jj
. . .
Warning: Line 535, Column 2: Non-ASCII characters used in regular expression.
Please make sure you use the correct Reader when you create the parser that can
handle your character set.
Warning: "\'" cannot be matched as a string literal token at line 1566, column
2. It will be matched as .
File "TokenMgrError.java" does not exist. Will create one.
File "ParseException.java" does not exist. Will create one.
File "Token.java" does not exist. Will create one.
File "SimpleCharStream.java" does not exist. Will create one.
Parser generated with 0 errors and 2 warnings.
[INFO] Processed 1 grammar
[INFO] [antrun:run {execution: delete-sources}]
[INFO] Executing tasks
[echo] Remove files that have been customized in Jackrabbit
[INFO] Executed tasks
[INFO] [resources:resources]
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources,
i.e. build is platform dependent!
[INFO] Copying 3 resources
[INFO] [compiler:compile]
[INFO] Compiling 230 source files to
http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/ws/trunk/jackrabbit-spi-commons/target/classes
[INFO] [resources:testResources]
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources,
i.e. build is platform dependent!
[INFO] Copying 2 resources
[INFO] [compiler:testCompile]
[INFO] Compiling 27 source files to
http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/ws/trunk/jackrabbit-spi-commons/target/test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory:
http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/ws/trunk/jackrabbit-spi-commons/target/surefire-reports
---
T E S T S
---
Running org.apache.jackrabbit.spi.commons.nodetype.BooleanConstraintTest
Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.128 sec
Running org.apache.jackrabbit.spi.commons.batch.ConsolidatedBatchTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.034 sec
Running org.apache.jackrabbit.spi.commons.name.MatcherTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec
Running org.apache.jackrabbit.spi.commons.nodetype.StringConstraintTest
Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec
Running org.apache.jackrabbit.spi.commons.nodetype.NumericConstraintTest
Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.022 sec
Running org.apache.jackrabbit.spi.commons.conversion.ParsingPathResolverTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec
Running
org.apache.jackrabbit.spi.commons.nodetype.compact.CompactNodeTypeDefTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.071 sec
Running org.apache.jackrabbit.spi.commons.value.QValueTest
Tests run: 44, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 104.237 sec
Running org.apache.jackrabbit.spi.commons.identifier.SerializationTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec
Ru
Re: Use CND for builtin nodetypes
On Wed, Apr 8, 2009 at 11:48 AM, Stefan Guggisberg wrote: > On Wed, Apr 8, 2009 at 11:24 AM, Tobias Bocanegra wrote: >> On Wed, Apr 8, 2009 at 11:05 AM, Jukka Zitting >> wrote: >>> Hi, >>> >>> On Wed, Apr 8, 2009 at 10:53 AM, Tobias Bocanegra >>> wrote: i would like to drop the builtin .xml file and read the builtin node types only from the .cnd file and additionally add support for a "custom_nodetypes.cnd". this will make the node types file much more readable and offers users a simpler way of providing their node types. >>> >>> I'm a bit afraid that making the file more readable will just >>> encourage more people to modify it directly. :-( >> well, but that's security by obscurity :-) but it certainly helps the >> developers. furthermore, all the node types in jsr283 are now speced >> in CND, and converting them to XML is a pain and error prone. >> >>> Instead, couldn't we store the node type information as actual nodes >>> in the same persistence manager we currently use for versioning >>> information? This way we could get rid of the current virtual item >>> states we use for exposing the node types under /jcr:system. Storing >>> the type information as content would also simplify clustering, >>> backups, etc. >> hmm, i think you're talking about something else :-). storing the >> registered (builtin and custom) nodetypes in the persistence manager >> (instead of the custom.xml) would certainly be a big advantage. the >> 'versioning' workspace should then be the general "rep:system" shared >> tree. >> >> i was talking about installing the initial set of nodetypes, like: >> nt:base :-) those are currently stored as resource in >> builtin_nodetypes.xml, and i would like to replace it with the >> (already present) .cnd aequivalent. > > +1 ok, i will create a jira issue + patch. > WRT custom_nodetypes.cnd: > -0, i do share jukka's concerns. with hindsight i consider it a > mistake storing the registered custom node type definitions > in a human readable format ;) you're right - but it was a long time the only way for adding node types to the system. maybe we can drop the support that file for jr 2.0 and use the jcr:system/jcr:nodetypes as a store for them. currently i don't see any chicken-egg problems for the jcr:system workspace, since it contains only nodes with builtin node types. regards, toby
Re: Use CND for builtin nodetypes
On Wed, Apr 8, 2009 at 11:24 AM, Tobias Bocanegra wrote: > On Wed, Apr 8, 2009 at 11:05 AM, Jukka Zitting > wrote: >> Hi, >> >> On Wed, Apr 8, 2009 at 10:53 AM, Tobias Bocanegra >> wrote: >>> i would like to drop the builtin .xml file and read the builtin node types >>> only from the .cnd file and additionally add support for a >>> "custom_nodetypes.cnd". >>> this will make the node types file much more readable and offers users a >>> simpler >>> way of providing their node types. >> >> I'm a bit afraid that making the file more readable will just >> encourage more people to modify it directly. :-( > well, but that's security by obscurity :-) but it certainly helps the > developers. furthermore, all the node types in jsr283 are now speced > in CND, and converting them to XML is a pain and error prone. > >> Instead, couldn't we store the node type information as actual nodes >> in the same persistence manager we currently use for versioning >> information? This way we could get rid of the current virtual item >> states we use for exposing the node types under /jcr:system. Storing >> the type information as content would also simplify clustering, >> backups, etc. > hmm, i think you're talking about something else :-). storing the > registered (builtin and custom) nodetypes in the persistence manager > (instead of the custom.xml) would certainly be a big advantage. the > 'versioning' workspace should then be the general "rep:system" shared > tree. > > i was talking about installing the initial set of nodetypes, like: > nt:base :-) those are currently stored as resource in > builtin_nodetypes.xml, and i would like to replace it with the > (already present) .cnd aequivalent. +1 WRT custom_nodetypes.cnd: -0, i do share jukka's concerns. with hindsight i consider it a mistake storing the registered custom node type definitions in a human readable format ;) cheers stefan > > regards, toby >
Build failed in Hudson: Jackrabbit-trunk-java14 #161
See
http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/161/changes
Changes:
[tripod] fixing typo
--
[...truncated 321 lines...]
[INFO] Installing
http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/ws/trunk/jackrabbit-jcr-benchmark/target/jackrabbit-jcr-benchmark-1.6-SNAPSHOT-sources.jar
to
/home/hudson/.m2/repository/org/apache/jackrabbit/jackrabbit-jcr-benchmark/1.6-SNAPSHOT/jackrabbit-jcr-benchmark-1.6-SNAPSHOT-sources.jar
[INFO] [maven-one-plugin:install-maven-one-repository {execution: default}]
[INFO] Installing
http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/ws/trunk/jackrabbit-jcr-benchmark/target/jackrabbit-jcr-benchmark-1.6-SNAPSHOT.jar
to
/home/hudson/.maven/repository/org.apache.jackrabbit/jars/jackrabbit-jcr-benchmark-1.6-SNAPSHOT.jar
[INFO] Installing
http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/ws/trunk/jackrabbit-jcr-benchmark/target/jackrabbit-jcr-benchmark-1.6-SNAPSHOT-sources.jar
to
/home/hudson/.maven/repository/org.apache.jackrabbit/java-sources/jackrabbit-jcr-benchmark-1.6-SNAPSHOT-sources.jar
[INFO]
[INFO] Building Jackrabbit SPI
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting file set:
http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/ws/trunk/jackrabbit-spi/target
(included: [**], excluded: [])
[INFO] [resources:resources]
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources,
i.e. build is platform dependent!
[INFO] Copying 2 resources
[INFO] [compiler:compile]
[INFO] Compiling 29 source files to
http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/ws/trunk/jackrabbit-spi/target/classes
[INFO] [resources:testResources]
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources,
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/ws/trunk/jackrabbit-spi/src/test/resources
[INFO] [compiler:testCompile]
[INFO] Compiling 7 source files to
http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/ws/trunk/jackrabbit-spi/target/test-classes
[INFO] [surefire:test]
[INFO] Tests are skipped.
[INFO] [jar:jar]
[INFO] Building jar:
http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/ws/trunk/jackrabbit-spi/target/jackrabbit-spi-1.6-SNAPSHOT.jar
[INFO] Preparing source:jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation.
[INFO] No goals needed for project - skipping
[INFO] [source:jar {execution: attach-sources}]
[INFO] Building jar:
http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/ws/trunk/jackrabbit-spi/target/jackrabbit-spi-1.6-SNAPSHOT-sources.jar
[INFO] [jar:jar {execution: default}]
[INFO] [jar:test-jar {execution: default}]
[INFO] Building jar:
http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/ws/trunk/jackrabbit-spi/target/jackrabbit-spi-1.6-SNAPSHOT-tests.jar
[INFO] [install:install]
[INFO] Installing
http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/ws/trunk/jackrabbit-spi/target/jackrabbit-spi-1.6-SNAPSHOT.jar
to
/home/hudson/.m2/repository/org/apache/jackrabbit/jackrabbit-spi/1.6-SNAPSHOT/jackrabbit-spi-1.6-SNAPSHOT.jar
[INFO] Installing
http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/ws/trunk/jackrabbit-spi/target/jackrabbit-spi-1.6-SNAPSHOT-sources.jar
to
/home/hudson/.m2/repository/org/apache/jackrabbit/jackrabbit-spi/1.6-SNAPSHOT/jackrabbit-spi-1.6-SNAPSHOT-sources.jar
[INFO] Installing
http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/ws/trunk/jackrabbit-spi/target/jackrabbit-spi-1.6-SNAPSHOT-tests.jar
to
/home/hudson/.m2/repository/org/apache/jackrabbit/jackrabbit-spi/1.6-SNAPSHOT/jackrabbit-spi-1.6-SNAPSHOT-tests.jar
[INFO] [maven-one-plugin:install-maven-one-repository {execution: default}]
[INFO] Installing
http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/ws/trunk/jackrabbit-spi/target/jackrabbit-spi-1.6-SNAPSHOT.jar
to
/home/hudson/.maven/repository/org.apache.jackrabbit/jars/jackrabbit-spi-1.6-SNAPSHOT.jar
[INFO] Installing
http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/ws/trunk/jackrabbit-spi/target/jackrabbit-spi-1.6-SNAPSHOT-sources.jar
to
/home/hudson/.maven/repository/org.apache.jackrabbit/java-sources/jackrabbit-spi-1.6-SNAPSHOT-sources.jar
[INFO] Installing
http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk-java14/ws/trunk/jackrabbit-spi/target/jackrabbit-spi-1.6-SNAPSHOT-tests.jar
to
/home/hudson/.maven/repository/org.apache.jackrabbit/jars/jackrabbit-spi-1.6-SNAPSHOT-tests.jar
[INFO]
[INFO] Building Jackrab
Re: Use CND for builtin nodetypes
Hi, On Wed, Apr 8, 2009 at 11:24 AM, Tobias Bocanegra wrote: > i was talking about installing the initial set of nodetypes, like: > nt:base :-) those are currently stored as resource in > builtin_nodetypes.xml, and i would like to replace it with the > (already present) .cnd aequivalent. Oh, sure. +1 to that! BR, Jukka Zitting
Re: Use CND for builtin nodetypes
On Wed, Apr 8, 2009 at 11:05 AM, Jukka Zitting wrote: > Hi, > > On Wed, Apr 8, 2009 at 10:53 AM, Tobias Bocanegra > wrote: >> i would like to drop the builtin .xml file and read the builtin node types >> only from the .cnd file and additionally add support for a >> "custom_nodetypes.cnd". >> this will make the node types file much more readable and offers users a >> simpler >> way of providing their node types. > > I'm a bit afraid that making the file more readable will just > encourage more people to modify it directly. :-( well, but that's security by obscurity :-) but it certainly helps the developers. furthermore, all the node types in jsr283 are now speced in CND, and converting them to XML is a pain and error prone. > Instead, couldn't we store the node type information as actual nodes > in the same persistence manager we currently use for versioning > information? This way we could get rid of the current virtual item > states we use for exposing the node types under /jcr:system. Storing > the type information as content would also simplify clustering, > backups, etc. hmm, i think you're talking about something else :-). storing the registered (builtin and custom) nodetypes in the persistence manager (instead of the custom.xml) would certainly be a big advantage. the 'versioning' workspace should then be the general "rep:system" shared tree. i was talking about installing the initial set of nodetypes, like: nt:base :-) those are currently stored as resource in builtin_nodetypes.xml, and i would like to replace it with the (already present) .cnd aequivalent. regards, toby
Re: Use CND for builtin nodetypes
Hi, On Wed, Apr 8, 2009 at 10:53 AM, Tobias Bocanegra wrote: > i would like to drop the builtin .xml file and read the builtin node types > only from the .cnd file and additionally add support for a > "custom_nodetypes.cnd". > this will make the node types file much more readable and offers users a > simpler > way of providing their node types. I'm a bit afraid that making the file more readable will just encourage more people to modify it directly. :-( Instead, couldn't we store the node type information as actual nodes in the same persistence manager we currently use for versioning information? This way we could get rid of the current virtual item states we use for exposing the node types under /jcr:system. Storing the type information as content would also simplify clustering, backups, etc. BR, Jukka Zitting
Use CND for builtin nodetypes
hi, the jackrabbit node type registry is reading the built in node types from a XML file. since the CND (compact node type definition notation) is now specified by jsr283, i would like to drop the builtin .xml file and read the builtin node types only from the .cnd file and additionally add support for a "custom_nodetypes.cnd". this will make the node types file much more readable and offers users a simpler way of providing their node types. WDYT ? regards, toby
