[jira] Commented: (JCR-674) String properties with invalid XML characters export as invalid XML
[ http://issues.apache.org/jira/browse/JCR-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461743 ] Jan Kuzniak commented on JCR-674: - I have a question about adding namespaces to repository. We have to use "xsi" and "xsd" namespaces during XML generation (see JSR170 1.0.1 -> 6.4.1.7). Currently all namespaces in the XML seem to come from repository namespaces - is that true? We are a bit confused about adding xsi and xsd to "reservedNamespaces" collection. Currently Javadoc for javax.jcr.NamespaceRegistry.registerNamespace says nothing about xsi and xsd namespaces and suggests that they are perfectly legal to be added by a user: "Attempting to re-assign a built-in prefix (jcr, nt, mix,sv, xml, or the empty prefix) to a new URI will throw a NamespaceException". Can we just and xsi and xsd namespaces to reservedNamespaces or will it raise compatibility issues? If it is not a good solution then where would you suggest to put code responsible for adding those namespaces to XML? -- Regards, Liliana and Jan > String properties with invalid XML characters export as invalid XML > --- > > Key: JCR-674 > URL: http://issues.apache.org/jira/browse/JCR-674 > Project: Jackrabbit > Issue Type: Bug > Components: JCR 1.0.1, xml >Affects Versions: 1.1.1 >Reporter: Joshua Levy >Priority: Minor > > As noted in the current JCR 1.0.1 maintenance draft, sections 6.4.1, > 6.4.2.6, XML export of string properties that contain invalid XML > characters isn't well-defined currently, since those characters are > not permissible in XML. The proposed fix is to use base64 > encoding for such values in System View. > Most characters below #x20 are examples of this. Currently, these > are escaped numerically in output (such as (amp)#0; ) but > such escape sequences can't be parsed by the XML > import methods. > The current behavior is particularly problematic, because the user > doesn't know the output is corrupt until later, when they try to import it > and get InvalidSerializedDataException. > If for some reason the base64 option is delayed, it might > make sense, as an interim solution, to fail on export > or to somehow patch import to relax its parsing and allow > these escape codes. -- 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] Commented: (JCR-690) Nodes' and properties' names with invalid XML characters export as invalid XML
[ http://issues.apache.org/jira/browse/JCR-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461727 ] Jan Kuzniak commented on JCR-690: - > Using the _x_ escapes is not a good solution [...] Agreed. > IMHO the only way to make the export/import of such names work is to add some > extra attribute that indicates the name encoding. Do you mean something like: ? There is one point worth mentioning here: for repositories containing invalid XML values documents exported from Jackrabbit 1.3+ will not be importable by previous versions of Jackrabbit and other JCR repositories. > [..] we could for now just make the name parser log warnings of invalid > characters Agreed, good idea. > Nodes' and properties' names with invalid XML characters export as invalid XML > -- > > Key: JCR-690 > URL: http://issues.apache.org/jira/browse/JCR-690 > Project: Jackrabbit > Issue Type: Bug > Components: JCR 2.0, xml >Affects Versions: 1.1, 1.1.1 >Reporter: Jan Kuzniak >Priority: Minor > > Session.exportSystemView method does check whether character should be > escaped using _X_ pattern or not. It just puts it into XML without any > validation. It causes e.g. XML attributes to contain entities like � -- 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] Commented: (JCR-690) Nodes' and properties' names with invalid XML characters export as invalid XML
[ http://issues.apache.org/jira/browse/JCR-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461702 ] Jan Kuzniak commented on JCR-690: - > I think we should adopt the same policy already now Already? And what about compatibility issues? If there are people using invalid XML characters as nodes' and properties' names, their repositories will become invalid with next release. Well, it's OK if it is introduced in jackrabbit 2.0, but as a user I would not expect such an issue while upgrading to 1.3. Probably we should write some external program checking if given repository is compatible with next release and maybe escaping invalid characters in the repository itself. Another approach is to implement escaping using _X_ pattern as a 1.x solution and restrict allowed characters set starting from jackrabbit 2.x > Nodes' and properties' names with invalid XML characters export as invalid XML > -- > > Key: JCR-690 > URL: http://issues.apache.org/jira/browse/JCR-690 > Project: Jackrabbit > Issue Type: Bug > Components: JCR 2.0, xml >Affects Versions: 1.1, 1.1.1 >Reporter: Jan Kuzniak >Priority: Minor > > Session.exportSystemView method does check whether character should be > escaped using _X_ pattern or not. It just puts it into XML without any > validation. It causes e.g. XML attributes to contain entities like � -- 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-690) Nodes' and properties' names with invalid XML characters export as invalid XML
Nodes' and properties' names with invalid XML characters export as invalid XML -- Key: JCR-690 URL: http://issues.apache.org/jira/browse/JCR-690 Project: Jackrabbit Issue Type: Bug Components: xml Affects Versions: 1.1.1, 1.1 Reporter: Jan Kuzniak Session.exportSystemView method does check whether character should be escaped using _X_ pattern or not. It just puts it into XML without any validation. It causes e.g. XML attributes to contain entities like � -- 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] Commented: (JCR-674) String properties with invalid XML characters export as invalid XML
[ http://issues.apache.org/jira/browse/JCR-674?page=comments#action_12460262 ] Jan Kuzniak commented on JCR-674: - One more thought: maybe we should split this issue into 2: - leave values encoding (to base64) here, - create new issue for names encoding in Session.exportSystemView. What do you think about it? > String properties with invalid XML characters export as invalid XML > --- > > Key: JCR-674 > URL: http://issues.apache.org/jira/browse/JCR-674 > Project: Jackrabbit > Issue Type: Bug > Components: xml >Affects Versions: 1.1.1 >Reporter: Joshua Levy > > As noted in the current JCR 1.0.1 maintenance draft, sections 6.4.1, > 6.4.2.6, XML export of string properties that contain invalid XML > characters isn't well-defined currently, since those characters are > not permissible in XML. The proposed fix is to use base64 > encoding for such values in System View. > Most characters below #x20 are examples of this. Currently, these > are escaped numerically in output (such as (amp)#0; ) but > such escape sequences can't be parsed by the XML > import methods. > The current behavior is particularly problematic, because the user > doesn't know the output is corrupt until later, when they try to import it > and get InvalidSerializedDataException. > If for some reason the base64 option is delayed, it might > make sense, as an interim solution, to fail on export > or to somehow patch import to relax its parsing and allow > these escape codes. -- 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] Commented: (JCR-674) String properties with invalid XML characters export as invalid XML
[ http://issues.apache.org/jira/browse/JCR-674?page=comments#action_12460227 ] Jan Kuzniak commented on JCR-674: - Hello there! After short investigation we at Cognifide think that we know what the problem is :-) Not only values that should be base64 are not exported, but also node and property names that have invalid characters in it (e.g. most characters below 0x0020) are exported using entities (that is still invalid). We are currently implementing patch for the first issue (base64). And a little more about invalid node/property names: it seems like the difference lies between Session.exportDocumentView and Session.exportSystemView. The first one seems to be doing it correctly. However the second does not use ISO9075 class that is responsible for encoding. Simply connecting exportSystemView to ISO9075 should make it (we are also going to implement this). Any comments on this approach? Patch is coming soon (we hope). -- Regards, Liliana and Jan > String properties with invalid XML characters export as invalid XML > --- > > Key: JCR-674 > URL: http://issues.apache.org/jira/browse/JCR-674 > Project: Jackrabbit > Issue Type: Bug > Components: xml >Affects Versions: 1.1.1 >Reporter: Joshua Levy > > As noted in the current JCR 1.0.1 maintenance draft, sections 6.4.1, > 6.4.2.6, XML export of string properties that contain invalid XML > characters isn't well-defined currently, since those characters are > not permissible in XML. The proposed fix is to use base64 > encoding for such values in System View. > Most characters below #x20 are examples of this. Currently, these > are escaped numerically in output (such as (amp)#0; ) but > such escape sequences can't be parsed by the XML > import methods. > The current behavior is particularly problematic, because the user > doesn't know the output is corrupt until later, when they try to import it > and get InvalidSerializedDataException. > If for some reason the base64 option is delayed, it might > make sense, as an interim solution, to fail on export > or to somehow patch import to relax its parsing and allow > these escape codes. -- 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-97) Improve Checkstyle conformance
[ http://issues.apache.org/jira/browse/JCR-97?page=all ] Jan Kuzniak updated JCR-97: --- Attachment: stacktraceLost.patch I noticed that some caught exceptions are rethrown without cause specified. Because of this original stack traces are lost. I attach a patch that fixes it where possible. > Improve Checkstyle conformance > -- > > Key: JCR-97 > URL: http://issues.apache.org/jira/browse/JCR-97 > Project: Jackrabbit > Issue Type: Improvement >Reporter: Jukka Zitting >Priority: Minor > Attachments: jackrabbit.core.cluster_imports.patch, > jackrabbit.core.config_imports.patch, jackrabbit.core.fs_imports.patch, > jackrabbit.core.jndi.patch, jackrabbit.core.lock.patch, > jackrabbitAPICheckstylePatch.patch, jackrabbitCoreClusterCleanup.patch, > jackrabbitCoreConfigCleanup.patch, jackrabbitCoreFsDbCleanup.patch, > jackrabbitCoreFsDbCleanup.patch, jackrabbitCoreUnnecessaryCodeCleanup.patch, > stacktraceLost.patch > > > This is an ongoing meta-issue for improving the Checkstyle conformance of the > Jackrabbit codebase. > Checkstyle (http://checkstyle.sourceforge.net/) is an automated tool for > checking conformance with coding standard and good coding style. A Checkstyle > report for Jackrabbit can be generated by running "maven checkstyle". > Currently the Jackrabbit Checkstyle report contains thousands of trivial > problems like unused imports and minor formatting issues. While it would be > possible to just remove those checks from the Jackrabbit Checkstyle > configuration, it would certainly be better to fix the real issues. After > fixing the trivial problems, the Checkstyle reports become much more valuable > tools in locating troublesome code and identifying chances for improvement. > While this issue remains open, you have an open mandate to improve the > standards conformance and coding style of the Jackrabbit sources. This > mandate applies only to changes that fix problems reported by Checkstyle > while making no changes to the external interface or behaviour of the changed > code. > The commit messages of such Checkstyle improvements should be labeled with > the Jira key of this issue (JCR-97) to mark the changes as style-only. This > way other committers will have easier time reviewing your changes for bugs or > other unexpected side-effects. > If you are not a Jackrabbit committer, but want to help improve the > Checkstyle conformance, you can make your changes using sources from > anonymous subversion and send your changes as an attachment to this issue. > Please see the Javadoc improvement issue JCR-73 for details. > PS. Blind conformance to style guides is seldom beneficial. Please remember > that the goal of this issue is to improve Jackrabbit code, not just the > Checkstyle output! -- 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] Commented: (JCR-631) Change resources sequence during transaction commit.
[ http://issues.apache.org/jira/browse/JCR-631?page=comments#action_12458790 ] Jan Kuzniak commented on JCR-631: - I am afraid that it is impossible to change this sequence easily. It seems that there are some dependencies between those managers i.e. version manager depends on state manager. Changing this is not trivial and since this part leaks some documentation probably only author can make it. -- Regards, Jan > Change resources sequence during transaction commit. > > > Key: JCR-631 > URL: http://issues.apache.org/jira/browse/JCR-631 > Project: Jackrabbit > Issue Type: Improvement >Affects Versions: 1.0, 1.0.1, 1.1, 0.9 >Reporter: Przemo Pakulski > > It seems that during commmit of transaction first changes in version storage > are committed, followed by workspace changes. > If second transaction fail it leads to situation where some nodes in > workspace could have reference (base version for example) to nonexistenst > version in version storage. In such case this node is corrupted, cannot be > checked in anymore :-(. > Long term solution is make versioning operation fully transactional (see > JCR-630). In short term I think it is worth to change sequence of commit > operations on different resources to stores changes in version storage before > workspace changes. > It would be better to have some redundant data in version storage (not > referenced version) than broken reference in workspace I think. > Any comments ? Does it make sense ? -- 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-97) Improve Checkstyle conformance
[ http://issues.apache.org/jira/browse/JCR-97?page=all ] Jan Kuzniak updated JCR-97: --- Attachment: jackrabbit.core.fs_imports.patch Imports organized in jackrabbit.core.fs package > Improve Checkstyle conformance > -- > > Key: JCR-97 > URL: http://issues.apache.org/jira/browse/JCR-97 > Project: Jackrabbit > Issue Type: Improvement >Reporter: Jukka Zitting >Priority: Minor > Attachments: jackrabbit.core.cluster_imports.patch, > jackrabbit.core.config_imports.patch, jackrabbit.core.fs_imports.patch, > jackrabbit.core.jndi.patch, jackrabbit.core.lock.patch, > jackrabbitAPICheckstylePatch.patch, jackrabbitCoreClusterCleanup.patch, > jackrabbitCoreConfigCleanup.patch, jackrabbitCoreFsDbCleanup.patch, > jackrabbitCoreFsDbCleanup.patch, jackrabbitCoreUnnecessaryCodeCleanup.patch > > > This is an ongoing meta-issue for improving the Checkstyle conformance of the > Jackrabbit codebase. > Checkstyle (http://checkstyle.sourceforge.net/) is an automated tool for > checking conformance with coding standard and good coding style. A Checkstyle > report for Jackrabbit can be generated by running "maven checkstyle". > Currently the Jackrabbit Checkstyle report contains thousands of trivial > problems like unused imports and minor formatting issues. While it would be > possible to just remove those checks from the Jackrabbit Checkstyle > configuration, it would certainly be better to fix the real issues. After > fixing the trivial problems, the Checkstyle reports become much more valuable > tools in locating troublesome code and identifying chances for improvement. > While this issue remains open, you have an open mandate to improve the > standards conformance and coding style of the Jackrabbit sources. This > mandate applies only to changes that fix problems reported by Checkstyle > while making no changes to the external interface or behaviour of the changed > code. > The commit messages of such Checkstyle improvements should be labeled with > the Jira key of this issue (JCR-97) to mark the changes as style-only. This > way other committers will have easier time reviewing your changes for bugs or > other unexpected side-effects. > If you are not a Jackrabbit committer, but want to help improve the > Checkstyle conformance, you can make your changes using sources from > anonymous subversion and send your changes as an attachment to this issue. > Please see the Javadoc improvement issue JCR-73 for details. > PS. Blind conformance to style guides is seldom beneficial. Please remember > that the goal of this issue is to improve Jackrabbit code, not just the > Checkstyle output! -- 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-97) Improve Checkstyle conformance
[ http://issues.apache.org/jira/browse/JCR-97?page=all ] Jan Kuzniak updated JCR-97: --- Attachment: jackrabbit.core.config_imports.patch Imports organized in jackrabbit.core.config package > Improve Checkstyle conformance > -- > > Key: JCR-97 > URL: http://issues.apache.org/jira/browse/JCR-97 > Project: Jackrabbit > Issue Type: Improvement >Reporter: Jukka Zitting >Priority: Minor > Attachments: jackrabbit.core.cluster_imports.patch, > jackrabbit.core.config_imports.patch, jackrabbit.core.jndi.patch, > jackrabbit.core.lock.patch, jackrabbitAPICheckstylePatch.patch, > jackrabbitCoreClusterCleanup.patch, jackrabbitCoreConfigCleanup.patch, > jackrabbitCoreFsDbCleanup.patch, jackrabbitCoreFsDbCleanup.patch, > jackrabbitCoreUnnecessaryCodeCleanup.patch > > > This is an ongoing meta-issue for improving the Checkstyle conformance of the > Jackrabbit codebase. > Checkstyle (http://checkstyle.sourceforge.net/) is an automated tool for > checking conformance with coding standard and good coding style. A Checkstyle > report for Jackrabbit can be generated by running "maven checkstyle". > Currently the Jackrabbit Checkstyle report contains thousands of trivial > problems like unused imports and minor formatting issues. While it would be > possible to just remove those checks from the Jackrabbit Checkstyle > configuration, it would certainly be better to fix the real issues. After > fixing the trivial problems, the Checkstyle reports become much more valuable > tools in locating troublesome code and identifying chances for improvement. > While this issue remains open, you have an open mandate to improve the > standards conformance and coding style of the Jackrabbit sources. This > mandate applies only to changes that fix problems reported by Checkstyle > while making no changes to the external interface or behaviour of the changed > code. > The commit messages of such Checkstyle improvements should be labeled with > the Jira key of this issue (JCR-97) to mark the changes as style-only. This > way other committers will have easier time reviewing your changes for bugs or > other unexpected side-effects. > If you are not a Jackrabbit committer, but want to help improve the > Checkstyle conformance, you can make your changes using sources from > anonymous subversion and send your changes as an attachment to this issue. > Please see the Javadoc improvement issue JCR-73 for details. > PS. Blind conformance to style guides is seldom beneficial. Please remember > that the goal of this issue is to improve Jackrabbit code, not just the > Checkstyle output! -- 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-97) Improve Checkstyle conformance
[ http://issues.apache.org/jira/browse/JCR-97?page=all ] Jan Kuzniak updated JCR-97: --- Attachment: jackrabbit.core.cluster_imports.patch Thank you, now I am starting to understand Jackrabbit desired code format guidelines better. It would be great to put them together on some page (e.g. wiki) or something, possibly along with a checkstyle and Eclipse formatter (that I am still adjusting to fit your suggestions). I see that it could be built incrementally and evolve into a code conventions specification document. I decided to start this work over again. I will submit smaller and one aspect based patches right on. First, patch that organizes imports in jackrabbit.core.cluster package. -- Regards, Jan > Improve Checkstyle conformance > -- > > Key: JCR-97 > URL: http://issues.apache.org/jira/browse/JCR-97 > Project: Jackrabbit > Issue Type: Improvement >Reporter: Jukka Zitting >Priority: Minor > Attachments: jackrabbit.core.cluster_imports.patch, > jackrabbit.core.jndi.patch, jackrabbit.core.lock.patch, > jackrabbitAPICheckstylePatch.patch, jackrabbitCoreClusterCleanup.patch, > jackrabbitCoreConfigCleanup.patch, jackrabbitCoreFsDbCleanup.patch, > jackrabbitCoreFsDbCleanup.patch, jackrabbitCoreUnnecessaryCodeCleanup.patch > > > This is an ongoing meta-issue for improving the Checkstyle conformance of the > Jackrabbit codebase. > Checkstyle (http://checkstyle.sourceforge.net/) is an automated tool for > checking conformance with coding standard and good coding style. A Checkstyle > report for Jackrabbit can be generated by running "maven checkstyle". > Currently the Jackrabbit Checkstyle report contains thousands of trivial > problems like unused imports and minor formatting issues. While it would be > possible to just remove those checks from the Jackrabbit Checkstyle > configuration, it would certainly be better to fix the real issues. After > fixing the trivial problems, the Checkstyle reports become much more valuable > tools in locating troublesome code and identifying chances for improvement. > While this issue remains open, you have an open mandate to improve the > standards conformance and coding style of the Jackrabbit sources. This > mandate applies only to changes that fix problems reported by Checkstyle > while making no changes to the external interface or behaviour of the changed > code. > The commit messages of such Checkstyle improvements should be labeled with > the Jira key of this issue (JCR-97) to mark the changes as style-only. This > way other committers will have easier time reviewing your changes for bugs or > other unexpected side-effects. > If you are not a Jackrabbit committer, but want to help improve the > Checkstyle conformance, you can make your changes using sources from > anonymous subversion and send your changes as an attachment to this issue. > Please see the Javadoc improvement issue JCR-73 for details. > PS. Blind conformance to style guides is seldom beneficial. Please remember > that the goal of this issue is to improve Jackrabbit code, not just the > Checkstyle output! -- 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-97) Improve Checkstyle conformance
[ http://issues.apache.org/jira/browse/JCR-97?page=all ] Jan Kuzniak updated JCR-97: --- Attachment: jackrabbit.core.lock.patch org.apache.jackrabbit.core.lock cleanup patch attached > Improve Checkstyle conformance > -- > > Key: JCR-97 > URL: http://issues.apache.org/jira/browse/JCR-97 > Project: Jackrabbit > Issue Type: Improvement >Reporter: Jukka Zitting >Priority: Minor > Attachments: jackrabbit.core.jndi.patch, jackrabbit.core.lock.patch, > jackrabbitAPICheckstylePatch.patch, jackrabbitCoreClusterCleanup.patch, > jackrabbitCoreConfigCleanup.patch, jackrabbitCoreFsDbCleanup.patch, > jackrabbitCoreFsDbCleanup.patch, jackrabbitCoreUnnecessaryCodeCleanup.patch > > > This is an ongoing meta-issue for improving the Checkstyle conformance of the > Jackrabbit codebase. > Checkstyle (http://checkstyle.sourceforge.net/) is an automated tool for > checking conformance with coding standard and good coding style. A Checkstyle > report for Jackrabbit can be generated by running "maven checkstyle". > Currently the Jackrabbit Checkstyle report contains thousands of trivial > problems like unused imports and minor formatting issues. While it would be > possible to just remove those checks from the Jackrabbit Checkstyle > configuration, it would certainly be better to fix the real issues. After > fixing the trivial problems, the Checkstyle reports become much more valuable > tools in locating troublesome code and identifying chances for improvement. > While this issue remains open, you have an open mandate to improve the > standards conformance and coding style of the Jackrabbit sources. This > mandate applies only to changes that fix problems reported by Checkstyle > while making no changes to the external interface or behaviour of the changed > code. > The commit messages of such Checkstyle improvements should be labeled with > the Jira key of this issue (JCR-97) to mark the changes as style-only. This > way other committers will have easier time reviewing your changes for bugs or > other unexpected side-effects. > If you are not a Jackrabbit committer, but want to help improve the > Checkstyle conformance, you can make your changes using sources from > anonymous subversion and send your changes as an attachment to this issue. > Please see the Javadoc improvement issue JCR-73 for details. > PS. Blind conformance to style guides is seldom beneficial. Please remember > that the goal of this issue is to improve Jackrabbit code, not just the > Checkstyle output! -- 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-97) Improve Checkstyle conformance
[ http://issues.apache.org/jira/browse/JCR-97?page=all ] Jan Kuzniak updated JCR-97: --- Attachment: jackrabbit.core.jndi.patch org.apache.jackrabbit.jndi cleanup patch attached > Improve Checkstyle conformance > -- > > Key: JCR-97 > URL: http://issues.apache.org/jira/browse/JCR-97 > Project: Jackrabbit > Issue Type: Improvement >Reporter: Jukka Zitting >Priority: Minor > Attachments: jackrabbit.core.jndi.patch, > jackrabbitAPICheckstylePatch.patch, jackrabbitCoreClusterCleanup.patch, > jackrabbitCoreConfigCleanup.patch, jackrabbitCoreFsDbCleanup.patch, > jackrabbitCoreFsDbCleanup.patch, jackrabbitCoreUnnecessaryCodeCleanup.patch > > > This is an ongoing meta-issue for improving the Checkstyle conformance of the > Jackrabbit codebase. > Checkstyle (http://checkstyle.sourceforge.net/) is an automated tool for > checking conformance with coding standard and good coding style. A Checkstyle > report for Jackrabbit can be generated by running "maven checkstyle". > Currently the Jackrabbit Checkstyle report contains thousands of trivial > problems like unused imports and minor formatting issues. While it would be > possible to just remove those checks from the Jackrabbit Checkstyle > configuration, it would certainly be better to fix the real issues. After > fixing the trivial problems, the Checkstyle reports become much more valuable > tools in locating troublesome code and identifying chances for improvement. > While this issue remains open, you have an open mandate to improve the > standards conformance and coding style of the Jackrabbit sources. This > mandate applies only to changes that fix problems reported by Checkstyle > while making no changes to the external interface or behaviour of the changed > code. > The commit messages of such Checkstyle improvements should be labeled with > the Jira key of this issue (JCR-97) to mark the changes as style-only. This > way other committers will have easier time reviewing your changes for bugs or > other unexpected side-effects. > If you are not a Jackrabbit committer, but want to help improve the > Checkstyle conformance, you can make your changes using sources from > anonymous subversion and send your changes as an attachment to this issue. > Please see the Javadoc improvement issue JCR-73 for details. > PS. Blind conformance to style guides is seldom beneficial. Please remember > that the goal of this issue is to improve Jackrabbit code, not just the > Checkstyle output! -- 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-97) Improve Checkstyle conformance
[ http://issues.apache.org/jira/browse/JCR-97?page=all ] Jan Kuzniak updated JCR-97: --- Attachment: jackrabbitCoreFsDbCleanup.patch org.apache.jackrabbit.core.cluster org.apache.jackrabbit.core.config org.apache.jackrabbit.core.fs cleaned up with regard to Stefans suggestions. See jackrabbitCoreFsDbCleanup.patch > Improve Checkstyle conformance > -- > > Key: JCR-97 > URL: http://issues.apache.org/jira/browse/JCR-97 > Project: Jackrabbit > Issue Type: Improvement >Reporter: Jukka Zitting >Priority: Minor > Attachments: jackrabbitAPICheckstylePatch.patch, > jackrabbitCoreClusterCleanup.patch, jackrabbitCoreConfigCleanup.patch, > jackrabbitCoreFsDbCleanup.patch, jackrabbitCoreFsDbCleanup.patch, > jackrabbitCoreUnnecessaryCodeCleanup.patch > > > This is an ongoing meta-issue for improving the Checkstyle conformance of the > Jackrabbit codebase. > Checkstyle (http://checkstyle.sourceforge.net/) is an automated tool for > checking conformance with coding standard and good coding style. A Checkstyle > report for Jackrabbit can be generated by running "maven checkstyle". > Currently the Jackrabbit Checkstyle report contains thousands of trivial > problems like unused imports and minor formatting issues. While it would be > possible to just remove those checks from the Jackrabbit Checkstyle > configuration, it would certainly be better to fix the real issues. After > fixing the trivial problems, the Checkstyle reports become much more valuable > tools in locating troublesome code and identifying chances for improvement. > While this issue remains open, you have an open mandate to improve the > standards conformance and coding style of the Jackrabbit sources. This > mandate applies only to changes that fix problems reported by Checkstyle > while making no changes to the external interface or behaviour of the changed > code. > The commit messages of such Checkstyle improvements should be labeled with > the Jira key of this issue (JCR-97) to mark the changes as style-only. This > way other committers will have easier time reviewing your changes for bugs or > other unexpected side-effects. > If you are not a Jackrabbit committer, but want to help improve the > Checkstyle conformance, you can make your changes using sources from > anonymous subversion and send your changes as an attachment to this issue. > Please see the Javadoc improvement issue JCR-73 for details. > PS. Blind conformance to style guides is seldom beneficial. Please remember > that the goal of this issue is to improve Jackrabbit code, not just the > Checkstyle output! -- 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] Commented: (JCR-97) Improve Checkstyle conformance
[ http://issues.apache.org/jira/browse/JCR-97?page=comments#action_12456799 ] Jan Kuzniak commented on JCR-97: > i also consider changes like the following as rather awkward Javadoc formatting across whole Jackrabbit is really inconsistent. I have chosen the most readable format amongst those that I have found here and I use it consistently. Also this is Sun formatting convention that I thought Jackrabbit checkstyle is based on. Please correct me if I am wrong. And one word about this format advantages: Please consider common case like "@param number number of occurences in text". When written in one line seems strange, but when broken after param name and intended seems clear (at least to me). re second example - corrected in next patch (coming soon). And about blind conformance - ok, you're right. I will watch out more and try to find better compromises. I promise :-) > Improve Checkstyle conformance > -- > > Key: JCR-97 > URL: http://issues.apache.org/jira/browse/JCR-97 > Project: Jackrabbit > Issue Type: Improvement >Reporter: Jukka Zitting >Priority: Minor > Attachments: jackrabbitAPICheckstylePatch.patch, > jackrabbitCoreClusterCleanup.patch, jackrabbitCoreConfigCleanup.patch, > jackrabbitCoreFsDbCleanup.patch, jackrabbitCoreUnnecessaryCodeCleanup.patch > > > This is an ongoing meta-issue for improving the Checkstyle conformance of the > Jackrabbit codebase. > Checkstyle (http://checkstyle.sourceforge.net/) is an automated tool for > checking conformance with coding standard and good coding style. A Checkstyle > report for Jackrabbit can be generated by running "maven checkstyle". > Currently the Jackrabbit Checkstyle report contains thousands of trivial > problems like unused imports and minor formatting issues. While it would be > possible to just remove those checks from the Jackrabbit Checkstyle > configuration, it would certainly be better to fix the real issues. After > fixing the trivial problems, the Checkstyle reports become much more valuable > tools in locating troublesome code and identifying chances for improvement. > While this issue remains open, you have an open mandate to improve the > standards conformance and coding style of the Jackrabbit sources. This > mandate applies only to changes that fix problems reported by Checkstyle > while making no changes to the external interface or behaviour of the changed > code. > The commit messages of such Checkstyle improvements should be labeled with > the Jira key of this issue (JCR-97) to mark the changes as style-only. This > way other committers will have easier time reviewing your changes for bugs or > other unexpected side-effects. > If you are not a Jackrabbit committer, but want to help improve the > Checkstyle conformance, you can make your changes using sources from > anonymous subversion and send your changes as an attachment to this issue. > Please see the Javadoc improvement issue JCR-73 for details. > PS. Blind conformance to style guides is seldom beneficial. Please remember > that the goal of this issue is to improve Jackrabbit code, not just the > Checkstyle output! -- 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] Commented: (JCR-97) Improve Checkstyle conformance
[ http://issues.apache.org/jira/browse/JCR-97?page=comments#action_12456795 ] Jan Kuzniak commented on JCR-97: > appart from religios line wrapping, this patch also changes caps of variables Please note, that this field is NOT a constant, and caps suggest it to be, that may lead to errors. > 80 chars max line length is a good rule but imo we shouldn't follow this rule > blindly. Ok, that is my mistake and will be repaired in next patch. However if there is a rule, then IMHO we should not allow breaking it. Either code or rule should be adjusted in every controversial case. And what is more, I use automatic tools (Eclipse formatter) that DOES follow this rules blindly, but makes keeping format easier and consistent. > Improve Checkstyle conformance > -- > > Key: JCR-97 > URL: http://issues.apache.org/jira/browse/JCR-97 > Project: Jackrabbit > Issue Type: Improvement >Reporter: Jukka Zitting >Priority: Minor > Attachments: jackrabbitAPICheckstylePatch.patch, > jackrabbitCoreClusterCleanup.patch, jackrabbitCoreConfigCleanup.patch, > jackrabbitCoreFsDbCleanup.patch, jackrabbitCoreUnnecessaryCodeCleanup.patch > > > This is an ongoing meta-issue for improving the Checkstyle conformance of the > Jackrabbit codebase. > Checkstyle (http://checkstyle.sourceforge.net/) is an automated tool for > checking conformance with coding standard and good coding style. A Checkstyle > report for Jackrabbit can be generated by running "maven checkstyle". > Currently the Jackrabbit Checkstyle report contains thousands of trivial > problems like unused imports and minor formatting issues. While it would be > possible to just remove those checks from the Jackrabbit Checkstyle > configuration, it would certainly be better to fix the real issues. After > fixing the trivial problems, the Checkstyle reports become much more valuable > tools in locating troublesome code and identifying chances for improvement. > While this issue remains open, you have an open mandate to improve the > standards conformance and coding style of the Jackrabbit sources. This > mandate applies only to changes that fix problems reported by Checkstyle > while making no changes to the external interface or behaviour of the changed > code. > The commit messages of such Checkstyle improvements should be labeled with > the Jira key of this issue (JCR-97) to mark the changes as style-only. This > way other committers will have easier time reviewing your changes for bugs or > other unexpected side-effects. > If you are not a Jackrabbit committer, but want to help improve the > Checkstyle conformance, you can make your changes using sources from > anonymous subversion and send your changes as an attachment to this issue. > Please see the Javadoc improvement issue JCR-73 for details. > PS. Blind conformance to style guides is seldom beneficial. Please remember > that the goal of this issue is to improve Jackrabbit code, not just the > Checkstyle output! -- 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-97) Improve Checkstyle conformance
[ http://issues.apache.org/jira/browse/JCR-97?page=all ] Jan Kuzniak updated JCR-97: --- Attachment: jackrabbitCoreFsDbCleanup.patch org.apache.jackrabbit.core.fs.db package cleared. Only javadoc errors are left. I suggest changing line length module of the checkstyle.xml that it works better with javadocs. It can be achieved with this configuration: It allows javadoc lines with one long word (e.g. XML code) to exceed 80 characters. > Improve Checkstyle conformance > -- > > Key: JCR-97 > URL: http://issues.apache.org/jira/browse/JCR-97 > Project: Jackrabbit > Issue Type: Improvement >Reporter: Jukka Zitting >Priority: Minor > Attachments: jackrabbitAPICheckstylePatch.patch, > jackrabbitCoreClusterCleanup.patch, jackrabbitCoreConfigCleanup.patch, > jackrabbitCoreFsDbCleanup.patch, jackrabbitCoreUnnecessaryCodeCleanup.patch > > > This is an ongoing meta-issue for improving the Checkstyle conformance of the > Jackrabbit codebase. > Checkstyle (http://checkstyle.sourceforge.net/) is an automated tool for > checking conformance with coding standard and good coding style. A Checkstyle > report for Jackrabbit can be generated by running "maven checkstyle". > Currently the Jackrabbit Checkstyle report contains thousands of trivial > problems like unused imports and minor formatting issues. While it would be > possible to just remove those checks from the Jackrabbit Checkstyle > configuration, it would certainly be better to fix the real issues. After > fixing the trivial problems, the Checkstyle reports become much more valuable > tools in locating troublesome code and identifying chances for improvement. > While this issue remains open, you have an open mandate to improve the > standards conformance and coding style of the Jackrabbit sources. This > mandate applies only to changes that fix problems reported by Checkstyle > while making no changes to the external interface or behaviour of the changed > code. > The commit messages of such Checkstyle improvements should be labeled with > the Jira key of this issue (JCR-97) to mark the changes as style-only. This > way other committers will have easier time reviewing your changes for bugs or > other unexpected side-effects. > If you are not a Jackrabbit committer, but want to help improve the > Checkstyle conformance, you can make your changes using sources from > anonymous subversion and send your changes as an attachment to this issue. > Please see the Javadoc improvement issue JCR-73 for details. > PS. Blind conformance to style guides is seldom beneficial. Please remember > that the goal of this issue is to improve Jackrabbit code, not just the > Checkstyle output! -- 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-97) Improve Checkstyle conformance
[ http://issues.apache.org/jira/browse/JCR-97?page=all ] Jan Kuzniak updated JCR-97: --- Attachment: jackrabbitCoreConfigCleanup.patch org.apache.jackrabbit.core.config package cleared. Again only javadoc errors and one major problem (too many parameters in RepositoryConfig constructor are left. > Improve Checkstyle conformance > -- > > Key: JCR-97 > URL: http://issues.apache.org/jira/browse/JCR-97 > Project: Jackrabbit > Issue Type: Improvement >Reporter: Jukka Zitting >Priority: Minor > Attachments: jackrabbitAPICheckstylePatch.patch, > jackrabbitCoreClusterCleanup.patch, jackrabbitCoreConfigCleanup.patch, > jackrabbitCoreUnnecessaryCodeCleanup.patch > > > This is an ongoing meta-issue for improving the Checkstyle conformance of the > Jackrabbit codebase. > Checkstyle (http://checkstyle.sourceforge.net/) is an automated tool for > checking conformance with coding standard and good coding style. A Checkstyle > report for Jackrabbit can be generated by running "maven checkstyle". > Currently the Jackrabbit Checkstyle report contains thousands of trivial > problems like unused imports and minor formatting issues. While it would be > possible to just remove those checks from the Jackrabbit Checkstyle > configuration, it would certainly be better to fix the real issues. After > fixing the trivial problems, the Checkstyle reports become much more valuable > tools in locating troublesome code and identifying chances for improvement. > While this issue remains open, you have an open mandate to improve the > standards conformance and coding style of the Jackrabbit sources. This > mandate applies only to changes that fix problems reported by Checkstyle > while making no changes to the external interface or behaviour of the changed > code. > The commit messages of such Checkstyle improvements should be labeled with > the Jira key of this issue (JCR-97) to mark the changes as style-only. This > way other committers will have easier time reviewing your changes for bugs or > other unexpected side-effects. > If you are not a Jackrabbit committer, but want to help improve the > Checkstyle conformance, you can make your changes using sources from > anonymous subversion and send your changes as an attachment to this issue. > Please see the Javadoc improvement issue JCR-73 for details. > PS. Blind conformance to style guides is seldom beneficial. Please remember > that the goal of this issue is to improve Jackrabbit code, not just the > Checkstyle output! -- 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-97) Improve Checkstyle conformance
[ http://issues.apache.org/jira/browse/JCR-97?page=all ] Jan Kuzniak updated JCR-97: --- Attachment: jackrabbitCoreClusterCleanup.patch org.apache.jackrabbit.core.cluster package cleared. There are only javadoc errors left and one major problem (too many parameters in RecordProcessor.process and its implementation. I also tuned checkstyle a bit that it is configured for UNIX style line breaks (LF only) instead of system ones. > Improve Checkstyle conformance > -- > > Key: JCR-97 > URL: http://issues.apache.org/jira/browse/JCR-97 > Project: Jackrabbit > Issue Type: Improvement >Reporter: Jukka Zitting >Priority: Minor > Attachments: jackrabbitAPICheckstylePatch.patch, > jackrabbitCoreClusterCleanup.patch, jackrabbitCoreUnnecessaryCodeCleanup.patch > > > This is an ongoing meta-issue for improving the Checkstyle conformance of the > Jackrabbit codebase. > Checkstyle (http://checkstyle.sourceforge.net/) is an automated tool for > checking conformance with coding standard and good coding style. A Checkstyle > report for Jackrabbit can be generated by running "maven checkstyle". > Currently the Jackrabbit Checkstyle report contains thousands of trivial > problems like unused imports and minor formatting issues. While it would be > possible to just remove those checks from the Jackrabbit Checkstyle > configuration, it would certainly be better to fix the real issues. After > fixing the trivial problems, the Checkstyle reports become much more valuable > tools in locating troublesome code and identifying chances for improvement. > While this issue remains open, you have an open mandate to improve the > standards conformance and coding style of the Jackrabbit sources. This > mandate applies only to changes that fix problems reported by Checkstyle > while making no changes to the external interface or behaviour of the changed > code. > The commit messages of such Checkstyle improvements should be labeled with > the Jira key of this issue (JCR-97) to mark the changes as style-only. This > way other committers will have easier time reviewing your changes for bugs or > other unexpected side-effects. > If you are not a Jackrabbit committer, but want to help improve the > Checkstyle conformance, you can make your changes using sources from > anonymous subversion and send your changes as an attachment to this issue. > Please see the Javadoc improvement issue JCR-73 for details. > PS. Blind conformance to style guides is seldom beneficial. Please remember > that the goal of this issue is to improve Jackrabbit code, not just the > Checkstyle output! -- 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-97) Improve Checkstyle conformance
[ http://issues.apache.org/jira/browse/JCR-97?page=all ] Jan Kuzniak updated JCR-97: --- Attachment: jackrabbitAPICheckstylePatch.patch Four checkstyle errors fixed in jackrabbit-api. This module is now clean. > Improve Checkstyle conformance > -- > > Key: JCR-97 > URL: http://issues.apache.org/jira/browse/JCR-97 > Project: Jackrabbit > Issue Type: Improvement >Reporter: Jukka Zitting >Priority: Minor > Attachments: jackrabbitAPICheckstylePatch.patch, > jackrabbitCoreUnnecessaryCodeCleanup.patch > > > This is an ongoing meta-issue for improving the Checkstyle conformance of the > Jackrabbit codebase. > Checkstyle (http://checkstyle.sourceforge.net/) is an automated tool for > checking conformance with coding standard and good coding style. A Checkstyle > report for Jackrabbit can be generated by running "maven checkstyle". > Currently the Jackrabbit Checkstyle report contains thousands of trivial > problems like unused imports and minor formatting issues. While it would be > possible to just remove those checks from the Jackrabbit Checkstyle > configuration, it would certainly be better to fix the real issues. After > fixing the trivial problems, the Checkstyle reports become much more valuable > tools in locating troublesome code and identifying chances for improvement. > While this issue remains open, you have an open mandate to improve the > standards conformance and coding style of the Jackrabbit sources. This > mandate applies only to changes that fix problems reported by Checkstyle > while making no changes to the external interface or behaviour of the changed > code. > The commit messages of such Checkstyle improvements should be labeled with > the Jira key of this issue (JCR-97) to mark the changes as style-only. This > way other committers will have easier time reviewing your changes for bugs or > other unexpected side-effects. > If you are not a Jackrabbit committer, but want to help improve the > Checkstyle conformance, you can make your changes using sources from > anonymous subversion and send your changes as an attachment to this issue. > Please see the Javadoc improvement issue JCR-73 for details. > PS. Blind conformance to style guides is seldom beneficial. Please remember > that the goal of this issue is to improve Jackrabbit code, not just the > Checkstyle output! -- 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-663) Maven2 site modules and checkstyle
[ http://issues.apache.org/jira/browse/JCR-663?page=all ] Jan Kuzniak updated JCR-663: Attachment: sitePatch2.zip I have found a way to preserve properties inside checkstyle.xml file while not spoiling maven2 build, I am then attaching changed version. > Maven2 site modules and checkstyle > -- > > Key: JCR-663 > URL: http://issues.apache.org/jira/browse/JCR-663 > Project: Jackrabbit > Issue Type: Improvement > Components: maven >Affects Versions: 1.2 >Reporter: Jan Kuzniak >Priority: Minor > Attachments: sitePatch.zip, sitePatch2.zip > > > Site generated by maven2 does not include sites for modules. Also checkstyle > reports are missing. -- 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-97) Improve Checkstyle conformance
[ http://issues.apache.org/jira/browse/JCR-97?page=all ] Jan Kuzniak updated JCR-97: --- Attachment: jackrabbitCoreUnnecessaryCodeCleanup.patch I attached a patch that removes unnecessary code from jackrabbit-core. It includes unused imports and variables (sometimes togeather with small changes in signatures of constructors) > Improve Checkstyle conformance > -- > > Key: JCR-97 > URL: http://issues.apache.org/jira/browse/JCR-97 > Project: Jackrabbit > Issue Type: Improvement >Reporter: Jukka Zitting >Priority: Minor > Attachments: jackrabbitCoreUnnecessaryCodeCleanup.patch > > > This is an ongoing meta-issue for improving the Checkstyle conformance of the > Jackrabbit codebase. > Checkstyle (http://checkstyle.sourceforge.net/) is an automated tool for > checking conformance with coding standard and good coding style. A Checkstyle > report for Jackrabbit can be generated by running "maven checkstyle". > Currently the Jackrabbit Checkstyle report contains thousands of trivial > problems like unused imports and minor formatting issues. While it would be > possible to just remove those checks from the Jackrabbit Checkstyle > configuration, it would certainly be better to fix the real issues. After > fixing the trivial problems, the Checkstyle reports become much more valuable > tools in locating troublesome code and identifying chances for improvement. > While this issue remains open, you have an open mandate to improve the > standards conformance and coding style of the Jackrabbit sources. This > mandate applies only to changes that fix problems reported by Checkstyle > while making no changes to the external interface or behaviour of the changed > code. > The commit messages of such Checkstyle improvements should be labeled with > the Jira key of this issue (JCR-97) to mark the changes as style-only. This > way other committers will have easier time reviewing your changes for bugs or > other unexpected side-effects. > If you are not a Jackrabbit committer, but want to help improve the > Checkstyle conformance, you can make your changes using sources from > anonymous subversion and send your changes as an attachment to this issue. > Please see the Javadoc improvement issue JCR-73 for details. > PS. Blind conformance to style guides is seldom beneficial. Please remember > that the goal of this issue is to improve Jackrabbit code, not just the > Checkstyle output! -- 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] Commented: (JCR-663) Maven2 site modules and checkstyle
[ http://issues.apache.org/jira/browse/JCR-663?page=comments#action_12455590 ] Jan Kuzniak commented on JCR-663: - you can test if this site is working by executing mvn site:stage -DstagingDirectory="c:\fullsite" to build full site (with subprojects included) in project parent directory. Simple mvn site will not generate all files in place. > Maven2 site modules and checkstyle > -- > > Key: JCR-663 > URL: http://issues.apache.org/jira/browse/JCR-663 > Project: Jackrabbit > Issue Type: Improvement > Components: maven >Affects Versions: 1.2 >Reporter: Jan Kuzniak >Priority: Minor > Attachments: sitePatch.zip > > > Site generated by maven2 does not include sites for modules. Also checkstyle > reports are missing. -- 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-663) Maven2 site modules and checkstyle
[ http://issues.apache.org/jira/browse/JCR-663?page=all ] Jan Kuzniak updated JCR-663: Attachment: sitePatch.zip I attach resolution to this problem. There are files to be copied with file structure preserved and svn .patch file to be applied. > Maven2 site modules and checkstyle > -- > > Key: JCR-663 > URL: http://issues.apache.org/jira/browse/JCR-663 > Project: Jackrabbit > Issue Type: Improvement > Components: maven >Affects Versions: 1.2 >Reporter: Jan Kuzniak >Priority: Minor > Attachments: sitePatch.zip > > > Site generated by maven2 does not include sites for modules. Also checkstyle > reports are missing. -- 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-663) Maven2 site modules and checkstyle
Maven2 site modules and checkstyle --- Key: JCR-663 URL: http://issues.apache.org/jira/browse/JCR-663 Project: Jackrabbit Issue Type: Improvement Components: maven Affects Versions: 1.2 Reporter: Jan Kuzniak Priority: Minor Site generated by maven2 does not include sites for modules. Also checkstyle reports are missing. -- 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-661) RMIC not working in subprojects when compiling parent using maven2
[ http://issues.apache.org/jira/browse/JCR-661?page=all ] Jan Kuzniak updated JCR-661: Attachment: pom-rmi-patch.patch Patch attached, works fine for me. Please give any comments if it works for you. > RMIC not working in subprojects when compiling parent using maven2 > -- > > Key: JCR-661 > URL: http://issues.apache.org/jira/browse/JCR-661 > Project: Jackrabbit > Issue Type: Bug > Components: config >Affects Versions: 1.2 >Reporter: Jan Kuzniak > Attachments: pom-rmi-patch.patch > > > This is because there is a bug such that if you have a child build which uses > the ant plugin it inherits the plugin dependencies of the first time the > plugin is declared. > The workaround is to put the antrun plugin in the toplevel, and add the java > jar to its plugin dependencies. > (reference: > http://mail-archives.apache.org/mod_mbox/maven-users/200602.mbox/[EMAIL > PROTECTED]) -- 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-661) RMIC not working in subprojects when compiling parent using maven2
RMIC not working in subprojects when compiling parent using maven2 -- Key: JCR-661 URL: http://issues.apache.org/jira/browse/JCR-661 Project: Jackrabbit Issue Type: Bug Components: config Affects Versions: 1.2 Reporter: Jan Kuzniak This is because there is a bug such that if you have a child build which uses the ant plugin it inherits the plugin dependencies of the first time the plugin is declared. The workaround is to put the antrun plugin in the toplevel, and add the java jar to its plugin dependencies. (reference: http://mail-archives.apache.org/mod_mbox/maven-users/200602.mbox/[EMAIL PROTECTED]) -- 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-612) Restructure the Jackrabbit source tree
[ http://issues.apache.org/jira/browse/JCR-612?page=all ] Jan Kuzniak updated JCR-612: Attachment: _restructurisationPath.zip As you wish: there you have a patch with all restructurisation and maven2 poms in one unix script. Just put directory _restructurisationPath inside trunk and run patch.sh inside this dir and in a short while you have everything done. I hope that I didn't miss anything. Regards, Jan > Restructure the Jackrabbit source tree > -- > > Key: JCR-612 > URL: http://issues.apache.org/jira/browse/JCR-612 > Project: Jackrabbit > Issue Type: Improvement >Reporter: Jukka Zitting > Assigned To: Jukka Zitting > Fix For: 1.2 > > Attachments: _restructurisationPath.zip, pomParent.zip > > > Reintroduce some of the changes in JCR-157 as a more general restructuring to > simplify the Jackrabbit project structure. See > http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/9170/ for the > rationale and discussion. The main parts of this restructuring would be: > 1. Create a Jackrabbit "super-project" (artifactId: jackrabbit) in trunk/ > 2. Use the super-project POM as the parent of all Jackrabbit component POMs > 3. Move the contents of trunk/jackrabbit/src/site directly to trunk/src/site, > and use the super-project to generate the web site > 4. Create independent subprojects for the the jackrabbit-api and > jackrabbit-commons components, moving the the corresponding parts of the > source tree > 5. Move the jcr-server subprojects on level up > 6. Rename the subproject directories to match their artifactIds > Note that this restructuring depends on JCR-611 and JCR-332, since the best > way to implement this by utilizing a snapshot repository for the component > dependencies. -- 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] Commented: (JCR-612) Restructure the Jackrabbit source tree
[ http://issues.apache.org/jira/browse/JCR-612?page=comments#action_12453987 ] Jan Kuzniak commented on JCR-612: - I have just ripped out jackrabbit-api and jackrabbit-commons and jackrabbit-core out of jackrabbit artifact (that is now empty). It is quite a big change and providing .patch file or everything zipped in here is hard to imagine. What are your preferences on how should I bring it here? I am thinking of one batch file or one ant file that when executed will copy files here and there. I am awaiting your comments. In the meantime I'll pom jcr-server, webdav and webapp. Regards, Jan > Restructure the Jackrabbit source tree > -- > > Key: JCR-612 > URL: http://issues.apache.org/jira/browse/JCR-612 > Project: Jackrabbit > Issue Type: Improvement >Reporter: Jukka Zitting > Assigned To: Jukka Zitting > Fix For: 1.2 > > Attachments: pomParent.zip > > > Reintroduce some of the changes in JCR-157 as a more general restructuring to > simplify the Jackrabbit project structure. See > http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/9170/ for the > rationale and discussion. The main parts of this restructuring would be: > 1. Create a Jackrabbit "super-project" (artifactId: jackrabbit) in trunk/ > 2. Use the super-project POM as the parent of all Jackrabbit component POMs > 3. Move the contents of trunk/jackrabbit/src/site directly to trunk/src/site, > and use the super-project to generate the web site > 4. Create independent subprojects for the the jackrabbit-api and > jackrabbit-commons components, moving the the corresponding parts of the > source tree > 5. Move the jcr-server subprojects on level up > 6. Rename the subproject directories to match their artifactIds > Note that this restructuring depends on JCR-611 and JCR-332, since the best > way to implement this by utilizing a snapshot repository for the component > dependencies. -- 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-202) Add configuration options for search manager
[ http://issues.apache.org/jira/browse/JCR-202?page=all ] Jan Kuzniak updated JCR-202: Attachment: indexConfigurationPatch.zip Ok, after quite a while of work here it comes. I was not as easy as I thought and I had to change few parts of the code. If you have any questions about this changes, please ask without hesistation. Patch consists of 16 new files (in folder structure of course) and 11 changed files (in standard svn .patch file). Regards, Jan > Add configuration options for search manager > > > Key: JCR-202 > URL: http://issues.apache.org/jira/browse/JCR-202 > Project: Jackrabbit > Issue Type: New Feature > Components: config >Affects Versions: 0.9, 1.0, 1.0.1 > Environment: all >Reporter: Michael Aemisegger > Attachments: indexConfigurationPatch.zip > > > Right now, if the search manager is active, everything is indexed, even the > system branch of a workspace with the versions. > take parameters / conditions into account whether a node should be indexed: > - path > - node type > - property type > - property name > see also http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/3343 -- 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] Commented: (JCR-626) Move document type definition out of repository.xml
[ http://issues.apache.org/jira/browse/JCR-626?page=comments#action_12452426 ] Jan Kuzniak commented on JCR-626: - Hello, I am currently finishing implementation of JCR-202 and I created new repository.xml files here and there for tests. Should I keep DTD inside each, or replace it with URL mentioned above? > Move document type definition out of repository.xml > --- > > Key: JCR-626 > URL: http://issues.apache.org/jira/browse/JCR-626 > Project: Jackrabbit > Issue Type: Improvement > Components: config >Affects Versions: 1.1 >Reporter: Jan Kuzniak > Assigned To: Jukka Zitting >Priority: Minor > Fix For: 1.2 > > Attachments: reposiory.dtd.patch > > > Hello! > Here at Cognifide, Przemo and I we got a bit confused while trying to solve > JCR-202. There was a need to modify repository.xml configuration file and > it's DTD, and we have found that there are different repository.xml files > within trunk that differs this definition. I think that it is a good idea to > extract this definition to a one separate file (and maybe .xsd instead of > .dtd) and then link it in other files. It would be also nice to put this file > somewhere on the Web and reference it via URL. > I am waiting for your comments. > Regards, Jan -- 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] Commented: (JCR-612) Restructure the Jackrabbit source tree
[ http://issues.apache.org/jira/browse/JCR-612?page=comments#action_12450709 ] Jan Kuzniak commented on JCR-612: - Jukka: > You mean textfilters/changes/changes.xml? I don't see why we should need a > file like that. I just moved everything that I could from maven1 to maven2. There was changelog turned on in maven1 so I made it avaiable for maven2 as well. It seems to be quite informative report so I would think about turning it on in core or super project as well. Angela: > uuuh... and i was waiting for an ok... [...] Heh, classic dead lock. I have to admit that I have the foggiest idea what sits inside jcr-server so I am was waiting for any decision. What do you think Jukka, should Angela make it real, or should I maven2 jcr-server as it is at the moment? Regards! > Restructure the Jackrabbit source tree > -- > > Key: JCR-612 > URL: http://issues.apache.org/jira/browse/JCR-612 > Project: Jackrabbit > Issue Type: Improvement >Reporter: Jukka Zitting > Assigned To: Jukka Zitting > Fix For: 1.2 > > Attachments: pomParent.zip > > > Reintroduce some of the changes in JCR-157 as a more general restructuring to > simplify the Jackrabbit project structure. See > http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/9170/ for the > rationale and discussion. The main parts of this restructuring would be: > 1. Create a Jackrabbit "super-project" (artifactId: jackrabbit) in trunk/ > 2. Use the super-project POM as the parent of all Jackrabbit component POMs > 3. Move the contents of trunk/jackrabbit/src/site directly to trunk/src/site, > and use the super-project to generate the web site > 4. Create independent subprojects for the the jackrabbit-api and > jackrabbit-commons components, moving the the corresponding parts of the > source tree > 5. Move the jcr-server subprojects on level up > 6. Rename the subproject directories to match their artifactIds > Note that this restructuring depends on JCR-611 and JCR-332, since the best > way to implement this by utilizing a snapshot repository for the component > dependencies. -- 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-599) Allow to inherit workspace configuration from repository level template
[ http://issues.apache.org/jira/browse/JCR-599?page=all ] Jan Kuzniak updated JCR-599: Attachment: repositoryConfigInheritance.patch Patch attached. Solution allows to enable this feature and keeps it disabled by default so I see no conflict here. I'm waiting for comments. > Allow to inherit workspace configuration from repository level template > --- > > Key: JCR-599 > URL: http://issues.apache.org/jira/browse/JCR-599 > Project: Jackrabbit > Issue Type: New Feature > Components: config >Affects Versions: 0.9, 1.0, 1.0.1, 1.1 >Reporter: Przemo Pakulski >Priority: Minor > Attachments: repositoryConfigInheritance.patch > > > RepositoryConfig file contains section with template for Workspace config. > This template is used to create new workspace using jackrabbit internal api, > and new workspace configuration file is created based on this template. > Probably in most scenarios common configuration for all workspaces is used. > If you need to make some configuration changes then you have to iterate > through each workspace and edit each config file separately. > It is quit easy task if you are using local file system, but can be hard if > other file systems are used (for example using DbFileSystem editing blobs in > database is required). > Our proposal to make some improvement here and allow to inherit workspace > configuration by reading it from repository level template. Change made in > repository config file will be reflected auomaticallly in all worskpaces then. > Feature details : > - if workspace.xml file doesn't exists it can be inherited (read and created > in memory from template), no workspace.xml file must be generated, > - you can still override workspace config by creating workspace.xml file by > hand, then this file will be used instead of template, > - if required additional parameter 'inheritConfig' can be added with default > value 'false' to keep current behaviour > and workspace config inheritance will work only if this parameter is set to > 'true'. > We are working on this feature, and we will contribute patch. -- 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] Commented: (JCR-332) Upgrade to Maven 2
[ http://issues.apache.org/jira/browse/JCR-332?page=comments#action_12450691 ] Jan Kuzniak commented on JCR-332: - see JCR-612 - there is more maven2 stuff attached. I decided to put it there because it's closer to restructurisation than migration itself. > Upgrade to Maven 2 > -- > > Key: JCR-332 > URL: http://issues.apache.org/jira/browse/JCR-332 > Project: Jackrabbit > Issue Type: New Feature > Components: maven >Affects Versions: 0.9, 1.0, 1.0.1, 1.1 >Reporter: fabrizio giustina > Assigned To: Jukka Zitting > Fix For: 1.2 > > Attachments: jackrabbit-core_single-line-description_pom.xml.patch, > jackrabbit-jcr-rmi_scm.patch, > jackrabbit-jcr-rmi_single-line-description-and-rmic_pom.xml.patch, > jcr-rmi-pom.xml, maven2-test.patch, pom.xml, pom.xml, pom.xml.patch > > > If you are interested in migrating to maven2 (or adding optional maven 2 > build scripts) this is a full maven 2 pom.xml for the main jackrabbit jar. > All the xpath/javacc stuff, previously done in maven.xml, was pretty painfull > to reproduce in maven2... the attached pom exactly reproduces the m1 build by > using the maven2 javacc plugin + a couple of antrun executions. > Test configuration is not yet complete, I think it will be a lot better to > reproduce the previous behaviour (init tests run first) without any > customization (maybe using a single junit test suite with setUp tasks). Also > custom packaging goals added to maven.xml (that can be esily done in m2 by > using the assembly plugin) are not yet reproduced too. > If there is interest, I can also provide poms for the contribution projects > (that will be easy, the only complex pom is the main one). -- 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
