[JBoss JIRA] Created: (DNA-621) Document search/query languages in the Reference Guide
by Randall Hauch (JIRA)
Document search/query languages in the Reference Guide
------------------------------------------------------
Key: DNA-621
URL: https://jira.jboss.org/jira/browse/DNA-621
Project: DNA
Issue Type: Task
Components: Documentation, Query, Search
Affects Versions: 0.7
Reporter: Randall Hauch
Fix For: 0.7
We probably want to have a section/chapter in the Reference Guide that presents the different languages. We probably just need to have a bit of intro (list the different languages, maybe show how to use them via JCR API), and then describe the different languages in detail. The SQL language and full-text search parsers have pretty good JavaDoc, and we can probably just lift it and reformat it for DocBook. And for XPath, we should be able to just reference the appropriate sections in the JCR 1.0 specification (perhaps linking to the online versions hosted by Day).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 12 months
[JBoss JIRA] Created: (DNA-643) Provide a JAR (or OSGi bundle) that contains all of the JCR implementation, all extensions, and all dependencies
by Randall Hauch (JIRA)
Provide a JAR (or OSGi bundle) that contains all of the JCR implementation, all extensions, and all dependencies
----------------------------------------------------------------------------------------------------------------
Key: DNA-643
URL: https://jira.jboss.org/jira/browse/DNA-643
Project: DNA
Issue Type: Feature Request
Components: Development Environment, JCR, Web Application
Affects Versions: 0.7
Reporter: Randall Hauch
Fix For: 1.0
Web applications and other non-Maven applications often require manual deployment of JARs. This can be very difficult with JBoss DNA, considering the number of artifacts and the number of dependencies. We should include as part of our release one (or several) "convenience" JARs that can be used in different situations.
One might be a JAR that contains the JCR implementation, all extensions, and all third-party dependencies (without the logging JARs?). This would be useful when deploying our JCR implementation to a web server via JNDI.
Another might contain our JCR implementation and all extensions, but no third-party dependencies.
Ideally we can identify the real-world scenarios so that produce only those artifacts that are useful.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 12 months