from:"Robert Munteanu \(JIRA\)"

[jira] [Commented] (JCRVLT-623) Validate that DocView values for a specific type are correct serializations (i.e. are a string which can be converted back to the given type)

2022-04-01 Thread Robert Munteanu (Jira)



[ 
https://issues.apache.org/jira/browse/JCRVLT-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515942#comment-17515942
 ] 

Robert Munteanu commented on JCRVLT-623:


FWIW, I would prefer that these values are passed, in one form or another, to 
the users of the parser. That is, the SLING-11240 scenario should still work.

> Validate that DocView values for a specific type are correct serializations 
> (i.e. are a string which can be converted back to the given type)
> -
>
> Key: JCRVLT-623
> URL: https://issues.apache.org/jira/browse/JCRVLT-623
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>Affects Versions: 3.6.0
>Reporter: Konrad Windszus
>Priority: Major
>
> This came up in the context of SLING-11240. Sometimes DocView XML files 
> contain invalid property values, like 
> {code:xml}
> test="{Long}1.0"
> {code}
> Those should be detected by the {{jackrabbit-docviewparser}} validator as 
> they can never be applied to a JCR node. Currently the exception is only 
> thrown during the actual import of those files, but not during parsing.
> Either the exception could be generated from the validator implementation or 
> whenever such an invalid string value is being detected in the 
> {{DocViewProperty2.parse(...)}} method, but I am not sure how big the 
> overhead is of always calling 
> https://github.com/apache/jackrabbit/blob/ed3124e5fe223dada33ce6ddf53bc666063c3f2f/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/value/ValueHelper.java#L779.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (JCRVLT-488) PlatformNameFormat incorrectly sets repository names for nodes with double colons

2021-01-07 Thread Robert Munteanu (Jira)



[ 
https://issues.apache.org/jira/browse/JCRVLT-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17260546#comment-17260546
 ] 

Robert Munteanu commented on JCRVLT-488:


[~kwin] - added and marked ready for review

> PlatformNameFormat incorrectly sets repository names for nodes with double 
> colons
> -
>
> Key: JCRVLT-488
> URL: https://issues.apache.org/jira/browse/JCRVLT-488
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Affects Versions: 3.4.6
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: 3.4.8
>
> Attachments: support-hidden-node-names.patch
>
>
> With a node name such as ":oak:mount-libs-nodetype" the 
> {{PlatformNameFormat}} class generates a platform name of 
> {{_%3aoak_mount-libs-nodetype}}, which looks incorrect : 
> - leading underscore should not be there
> - second underscore should not be there, as it's not part of a namespace 
> declaration



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JCRVLT-488) PlatformNameFormat incorrectly sets repository names for nodes with double colons

2021-01-07 Thread Robert Munteanu (Jira)



[ 
https://issues.apache.org/jira/browse/JCRVLT-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17260535#comment-17260535
 ] 

Robert Munteanu commented on JCRVLT-488:


[~kwin] - that works very well! Do you want to add it to 
https://github.com/apache/jackrabbit-filevault/pull/112 ? Alternatively I can 
do it and move it before the commit that adds the new test.

> PlatformNameFormat incorrectly sets repository names for nodes with double 
> colons
> -
>
> Key: JCRVLT-488
> URL: https://issues.apache.org/jira/browse/JCRVLT-488
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Affects Versions: 3.4.6
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: 3.4.8
>
> Attachments: support-hidden-node-names.patch
>
>
> With a node name such as ":oak:mount-libs-nodetype" the 
> {{PlatformNameFormat}} class generates a platform name of 
> {{_%3aoak_mount-libs-nodetype}}, which looks incorrect : 
> - leading underscore should not be there
> - second underscore should not be there, as it's not part of a namespace 
> declaration



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JCRVLT-488) PlatformNameFormat incorrectly sets repository names for nodes with double colons

2021-01-07 Thread Robert Munteanu (Jira)



[ 
https://issues.apache.org/jira/browse/JCRVLT-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17260522#comment-17260522
 ] 

Robert Munteanu commented on JCRVLT-488:


[~kwin] - I'll give it another shot. Do you think replacing leading colon 
characters with the char sequence is ok, given the special use case? 
{{:oak:mount-libs-nodetype}} would be mapped to 
{{%3aoak%3amount-libs-nodetype}}, just like in my failing test.

> PlatformNameFormat incorrectly sets repository names for nodes with double 
> colons
> -
>
> Key: JCRVLT-488
> URL: https://issues.apache.org/jira/browse/JCRVLT-488
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Affects Versions: 3.4.6
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: 3.4.8
>
>
> With a node name such as ":oak:mount-libs-nodetype" the 
> {{PlatformNameFormat}} class generates a platform name of 
> {{_%3aoak_mount-libs-nodetype}}, which looks incorrect : 
> - leading underscore should not be there
> - second underscore should not be there, as it's not part of a namespace 
> declaration



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JCRVLT-488) PlatformNameFormat incorrectly sets repository names for nodes with double colons

2021-01-06 Thread Robert Munteanu (Jira)



[ 
https://issues.apache.org/jira/browse/JCRVLT-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17259662#comment-17259662
 ] 

Robert Munteanu commented on JCRVLT-488:


[~kwin] - I'm sort of abusing the {{PlatformNameFormat}} to read-write an 
on-disk structure that is based on FileVault but is not a content package. So 
it's not surprising that this edge case was not considered.

I would be fine with either:
- properly supporting hidden nodes as well
- failing fast if the node name is illegal

but I would obviously prefer the first option, as it would make my life simpler.

> PlatformNameFormat incorrectly sets repository names for nodes with double 
> colons
> -
>
> Key: JCRVLT-488
> URL: https://issues.apache.org/jira/browse/JCRVLT-488
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Affects Versions: 3.4.6
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: 3.4.8
>
>
> With a node name such as ":oak:mount-libs-nodetype" the 
> {{PlatformNameFormat}} class generates a platform name of 
> {{_%3aoak_mount-libs-nodetype}}, which looks incorrect : 
> - leading underscore should not be there
> - second underscore should not be there, as it's not part of a namespace 
> declaration



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JCRVLT-488) PlatformNameFormat incorrectly sets repository names for nodes with double colons

2020-12-23 Thread Robert Munteanu (Jira)



[ 
https://issues.apache.org/jira/browse/JCRVLT-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254320#comment-17254320
 ] 

Robert Munteanu commented on JCRVLT-488:


[~kwin] - the mapping and reversal are not symmetric and don't work as expected 
- see https://github.com/apache/jackrabbit-filevault/pull/112 for a failing 
test .

> PlatformNameFormat incorrectly sets repository names for nodes with double 
> colons
> -
>
> Key: JCRVLT-488
> URL: https://issues.apache.org/jira/browse/JCRVLT-488
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Affects Versions: 3.4.6
>Reporter: Robert Munteanu
>Priority: Major
>
> With a node name such as ":oak:mount-libs-nodetype" the 
> {{PlatformNameFormat}} class generates a platform name of 
> {{_%3aoak_mount-libs-nodetype}}, which looks incorrect : 
> - leading underscore should not be there
> - second underscore should not be there, as it's not part of a namespace 
> declaration



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JCRVLT-488) PlatformNameFormat incorrectly sets repository names for nodes with double colons

2020-12-17 Thread Robert Munteanu (Jira)



[ 
https://issues.apache.org/jira/browse/JCRVLT-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17251381#comment-17251381
 ] 

Robert Munteanu commented on JCRVLT-488:


I've added some minor cleanups + a failing test at 
https://github.com/apache/jackrabbit-filevault/pull/112 . Unfortunately I could 
not create a fix.

> PlatformNameFormat incorrectly sets repository names for nodes with double 
> colons
> -
>
> Key: JCRVLT-488
> URL: https://issues.apache.org/jira/browse/JCRVLT-488
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Affects Versions: 3.4.6
>Reporter: Robert Munteanu
>Priority: Major
>
> With a node name such as ":oak:mount-libs-nodetype" the 
> {{PlatformNameFormat}} class generates a platform name of 
> {{_%3aoak_mount-libs-nodetype}}, which looks incorrect : 
> - leading underscore should not be there
> - second underscore should not be there, as it's not part of a namespace 
> declaration



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (JCRVLT-488) PlatformNameFormat incorrectly sets repository names for nodes with double colons

2020-12-17 Thread Robert Munteanu (Jira)

Robert Munteanu created JCRVLT-488:
--

 Summary: PlatformNameFormat incorrectly sets repository names for 
nodes with double colons
 Key: JCRVLT-488
 URL: https://issues.apache.org/jira/browse/JCRVLT-488
 Project: Jackrabbit FileVault
  Issue Type: Bug
  Components: vlt
Affects Versions: 3.4.6
Reporter: Robert Munteanu


With a node name such as ":oak:mount-libs-nodetype" the {{PlatformNameFormat}} 
class generates a platform name of {{_%3aoak_mount-libs-nodetype}}, which looks 
incorrect : 

- leading underscore should not be there
- second underscore should not be there, as it's not part of a namespace 
declaration



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JCRVLT-472) Content package with principal policy fails to install when the user is in the same package

2020-09-24 Thread Robert Munteanu (Jira)



[ 
https://issues.apache.org/jira/browse/JCRVLT-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201602#comment-17201602
 ] 

Robert Munteanu commented on JCRVLT-472:


[~kwin] - I've put it on my to-do list, but I don't see this happening too soon 
unfortunately.

> Content package with principal policy fails to install when the user is in 
> the same package
> ---
>
> Key: JCRVLT-472
> URL: https://issues.apache.org/jira/browse/JCRVLT-472
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Reporter: Robert Munteanu
>Priority: Major
> Attachments: sling-slingshot-apps-pkg-1.0-SNAPSHOT.zip
>
>
> I have attached a content package that includes a system user, a principal 
> policy and a principal entry. The content package, when installed in the 
> Sling Starter 12-SNAPSHOT, fails the first time and then the second time 
> works. The full error is 
> {noformat}24.08.2020 17:24:08.669 *WARN* [pool-10-thread-1] 
> com.composum.sling.core.pckgmgr.util.PackageUtil Received error for mode 
> PATHS path /home/users/system/sling/slingshot/rep:principalPolicy
> org.xml.sax.SAXException: javax.jcr.security.AccessControlException: 
> Unsupported principal slingshot-service
> at 
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter.endElement(DocViewSAXImporter.java:1246)
>  [org.apache.jackrabbit.vault:3.4.6]
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:610)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1718)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2883)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:534)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:888)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:824)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1216)
> at 
> java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:635)
> at 
> java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:324)
> at 
> org.apache.jackrabbit.vault.fs.impl.io.GenericArtifactHandler.accept(GenericArtifactHandler.java:100)
>  [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:896) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:799) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
> [org.apache.jackrabbit.vault:3.4.6]
> at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:440) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:255)
>  [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:400)
>  [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:359)
>  [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.install(JcrPackageImpl.java:353)
>

[jira] [Commented] (JCRVLT-472) Content package with principal policy fails to install when the user is in the same package

2020-08-27 Thread Robert Munteanu (Jira)



[ 
https://issues.apache.org/jira/browse/JCRVLT-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17185821#comment-17185821
 ] 

Robert Munteanu commented on JCRVLT-472:


The consensus seems to be that this is a known issue with low impact and  a 
workaround, so no action is needed. I'm OK with that, as I have an immediate 
fix for my problem (and a better understanding of how FileVault works in 
respect to ACEs and principals).

> Content package with principal policy fails to install when the user is in 
> the same package
> ---
>
> Key: JCRVLT-472
> URL: https://issues.apache.org/jira/browse/JCRVLT-472
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Reporter: Robert Munteanu
>Priority: Major
> Attachments: sling-slingshot-apps-pkg-1.0-SNAPSHOT.zip
>
>
> I have attached a content package that includes a system user, a principal 
> policy and a principal entry. The content package, when installed in the 
> Sling Starter 12-SNAPSHOT, fails the first time and then the second time 
> works. The full error is 
> {noformat}24.08.2020 17:24:08.669 *WARN* [pool-10-thread-1] 
> com.composum.sling.core.pckgmgr.util.PackageUtil Received error for mode 
> PATHS path /home/users/system/sling/slingshot/rep:principalPolicy
> org.xml.sax.SAXException: javax.jcr.security.AccessControlException: 
> Unsupported principal slingshot-service
> at 
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter.endElement(DocViewSAXImporter.java:1246)
>  [org.apache.jackrabbit.vault:3.4.6]
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:610)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1718)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2883)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:534)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:888)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:824)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1216)
> at 
> java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:635)
> at 
> java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:324)
> at 
> org.apache.jackrabbit.vault.fs.impl.io.GenericArtifactHandler.accept(GenericArtifactHandler.java:100)
>  [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:896) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:799) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
> [org.apache.jackrabbit.vault:3.4.6]
> at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:440) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:255)
>  [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:400)
>  [org.apache.jackrabbit.vault:3.4.6]
> at 
>

[jira] [Commented] (JCRVLT-472) Content package with principal policy fails to install when the user is in the same package

2020-08-25 Thread Robert Munteanu (Jira)



[ 
https://issues.apache.org/jira/browse/JCRVLT-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17183936#comment-17183936
 ] 

Robert Munteanu commented on JCRVLT-472:


I confirm that configuring 
{{org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl}}
 with "besteffort" import behaviour does fix the package install. It would be 
good IMO to not require this setting for this particular scenario ( principal 
policy nested under principal ).

Note that this is different scenario that the one on the oak-dev list I asked 
about in 
https://lists.apache.org/thread.html/r94b8b31d3da59d18e3eaced1594c453fc7759b62d26474a42c3dbbe3%40%3Coak-dev.jackrabbit.apache.org%3E
 .

> Content package with principal policy fails to install when the user is in 
> the same package
> ---
>
> Key: JCRVLT-472
> URL: https://issues.apache.org/jira/browse/JCRVLT-472
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Reporter: Robert Munteanu
>Priority: Major
> Attachments: sling-slingshot-apps-pkg-1.0-SNAPSHOT.zip
>
>
> I have attached a content package that includes a system user, a principal 
> policy and a principal entry. The content package, when installed in the 
> Sling Starter 12-SNAPSHOT, fails the first time and then the second time 
> works. The full error is 
> {noformat}24.08.2020 17:24:08.669 *WARN* [pool-10-thread-1] 
> com.composum.sling.core.pckgmgr.util.PackageUtil Received error for mode 
> PATHS path /home/users/system/sling/slingshot/rep:principalPolicy
> org.xml.sax.SAXException: javax.jcr.security.AccessControlException: 
> Unsupported principal slingshot-service
> at 
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter.endElement(DocViewSAXImporter.java:1246)
>  [org.apache.jackrabbit.vault:3.4.6]
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:610)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1718)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2883)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:534)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:888)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:824)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1216)
> at 
> java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:635)
> at 
> java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:324)
> at 
> org.apache.jackrabbit.vault.fs.impl.io.GenericArtifactHandler.accept(GenericArtifactHandler.java:100)
>  [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:896) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:799) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
> [org.apache.jackrabbit.vault:3.4.6]
> at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:440) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:255)
>

[jira] [Commented] (JCRVLT-472) Content package with principal policy fails to install when the user is in the same package

2020-08-25 Thread Robert Munteanu (Jira)



[ 
https://issues.apache.org/jira/browse/JCRVLT-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17183908#comment-17183908
 ] 

Robert Munteanu commented on JCRVLT-472:


Thank you for your comments. For extended context, the principal is part of the 
content package and included in the operation, judging by the log

{noformat}Creating snapshot for package 
org.apache.sling:sling-slingshot-apps-pkg:1.0-SNAPSHOT 
  A  META-INF
  A  META-INF/MANIFEST.MF
  A  META-INF/vault
  A  META-INF/vault/config.xml
  A  META-INF/vault/filter.xml
  A  META-INF/vault/nodetypes.cnd
  A  META-INF/vault/properties.xml
  A  /.content.xml
  A  /home
  A  /home/.content.xml
  A  /home/users
  A  /home/users/.content.xml
  A  /home/users/system
  A  /home/users/system/.content.xml
  -  Aggregation status: 3 of 1 prepared, 2 collected
  A  META-INF/vault/definition/.content.xml
Collecting import information... 
Installing node types... 
Installing privileges... 
Importing content... 
  -  /
  -  /home
  -  /home/users
  -  /home/users/system
  A  /home/users/system/sling
  A  /home/users/system/sling/slingshot
  E  /home/users/system/sling/slingshot/rep:principalPolicy
  ! org.xml.sax.SAXException: javax.jcr.security.AccessControlException: 
Unsupported principal slingshot-service
javax.jcr.security.AccessControlException: Unsupported principal 
slingshot-service
saving approx 4 nodes... 
Package imported (with errors, check logs!) 
{noformat}

When reinstalling the package, this works as expected

{noformat}Collecting import information... 
Installing node types... 
Installing privileges... 
Importing content... 
  -  /
  -  /home
  -  /home/users
  -  /home/users/system
  -  /home/users/system/sling
  A  /home/users/system/sling/slingshot
saving approx 2 nodes... 
Package imported. 
{noformat}

So IMHO the principal is there, but not noticed when importing for some reason. 
I will try the {{besteffort}} workaround, for the sake of completeness.

> Content package with principal policy fails to install when the user is in 
> the same package
> ---
>
> Key: JCRVLT-472
> URL: https://issues.apache.org/jira/browse/JCRVLT-472
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Reporter: Robert Munteanu
>Priority: Major
> Attachments: sling-slingshot-apps-pkg-1.0-SNAPSHOT.zip
>
>
> I have attached a content package that includes a system user, a principal 
> policy and a principal entry. The content package, when installed in the 
> Sling Starter 12-SNAPSHOT, fails the first time and then the second time 
> works. The full error is 
> {noformat}24.08.2020 17:24:08.669 *WARN* [pool-10-thread-1] 
> com.composum.sling.core.pckgmgr.util.PackageUtil Received error for mode 
> PATHS path /home/users/system/sling/slingshot/rep:principalPolicy
> org.xml.sax.SAXException: javax.jcr.security.AccessControlException: 
> Unsupported principal slingshot-service
> at 
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter.endElement(DocViewSAXImporter.java:1246)
>  [org.apache.jackrabbit.vault:3.4.6]
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:610)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1718)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2883)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:534)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:888)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:824)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1216)
> at 
> java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:635)
> at 
> java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:324)
> at 
> org.apache.jackrabbit.vault.fs.impl.io.GenericArtifactHandler.accept(GenericArtifactHandler.java:100)
>

[jira] [Commented] (JCRVLT-472) Content package with principal policy fails to install when the user is in the same package

2020-08-24 Thread Robert Munteanu (Jira)



[ 
https://issues.apache.org/jira/browse/JCRVLT-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17183383#comment-17183383
 ] 

Robert Munteanu commented on JCRVLT-472:


[~angela], [~kwin] - this may be of interest to you.

> Content package with principal policy fails to install when the user is in 
> the same package
> ---
>
> Key: JCRVLT-472
> URL: https://issues.apache.org/jira/browse/JCRVLT-472
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Reporter: Robert Munteanu
>Priority: Major
> Attachments: sling-slingshot-apps-pkg-1.0-SNAPSHOT.zip
>
>
> I have attached a content package that includes a system user, a principal 
> policy and a principal entry. The content package, when installed in the 
> Sling Starter 12-SNAPSHOT, fails the first time and then the second time 
> works. The full error is 
> {noformat}24.08.2020 17:24:08.669 *WARN* [pool-10-thread-1] 
> com.composum.sling.core.pckgmgr.util.PackageUtil Received error for mode 
> PATHS path /home/users/system/sling/slingshot/rep:principalPolicy
> org.xml.sax.SAXException: javax.jcr.security.AccessControlException: 
> Unsupported principal slingshot-service
> at 
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter.endElement(DocViewSAXImporter.java:1246)
>  [org.apache.jackrabbit.vault:3.4.6]
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:610)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1718)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2883)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
> at 
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:534)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:888)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:824)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
> at 
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1216)
> at 
> java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:635)
> at 
> java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:324)
> at 
> org.apache.jackrabbit.vault.fs.impl.io.GenericArtifactHandler.accept(GenericArtifactHandler.java:100)
>  [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:896) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:799) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
> [org.apache.jackrabbit.vault:3.4.6]
> at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:440) 
> [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:255)
>  [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:400)
>  [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:359)
>  [org.apache.jackrabbit.vault:3.4.6]
> at 
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.install(JcrPackageImpl.java:353)
>  [org.apache.jackrabbit.vault:3.4.6]
> at 
>

[jira] [Created] (JCRVLT-472) Content package with principal policy fails to install when the user is in the same package

2020-08-24 Thread Robert Munteanu (Jira)

Robert Munteanu created JCRVLT-472:
--

 Summary: Content package with principal policy fails to install 
when the user is in the same package
 Key: JCRVLT-472
 URL: https://issues.apache.org/jira/browse/JCRVLT-472
 Project: Jackrabbit FileVault
  Issue Type: Improvement
  Components: Packaging
Reporter: Robert Munteanu
 Attachments: sling-slingshot-apps-pkg-1.0-SNAPSHOT.zip

I have attached a content package that includes a system user, a principal 
policy and a principal entry. The content package, when installed in the Sling 
Starter 12-SNAPSHOT, fails the first time and then the second time works. The 
full error is 

{noformat}24.08.2020 17:24:08.669 *WARN* [pool-10-thread-1] 
com.composum.sling.core.pckgmgr.util.PackageUtil Received error for mode PATHS 
path /home/users/system/sling/slingshot/rep:principalPolicy
org.xml.sax.SAXException: javax.jcr.security.AccessControlException: 
Unsupported principal slingshot-service
at 
org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter.endElement(DocViewSAXImporter.java:1246)
 [org.apache.jackrabbit.vault:3.4.6]
at 
java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:610)
at 
java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1718)
at 
java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2883)
at 
java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
at 
java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
at 
java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:534)
at 
java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:888)
at 
java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:824)
at 
java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
at 
java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1216)
at 
java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:635)
at 
java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:324)
at 
org.apache.jackrabbit.vault.fs.impl.io.GenericArtifactHandler.accept(GenericArtifactHandler.java:100)
 [org.apache.jackrabbit.vault:3.4.6]
at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:896) 
[org.apache.jackrabbit.vault:3.4.6]
at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:799) 
[org.apache.jackrabbit.vault:3.4.6]
at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
[org.apache.jackrabbit.vault:3.4.6]
at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
[org.apache.jackrabbit.vault:3.4.6]
at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
[org.apache.jackrabbit.vault:3.4.6]
at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
[org.apache.jackrabbit.vault:3.4.6]
at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
[org.apache.jackrabbit.vault:3.4.6]
at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839) 
[org.apache.jackrabbit.vault:3.4.6]
at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:440) 
[org.apache.jackrabbit.vault:3.4.6]
at 
org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:255)
 [org.apache.jackrabbit.vault:3.4.6]
at 
org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:400)
 [org.apache.jackrabbit.vault:3.4.6]
at 
org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:359)
 [org.apache.jackrabbit.vault:3.4.6]
at 
org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.install(JcrPackageImpl.java:353)
 [org.apache.jackrabbit.vault:3.4.6]
at 
com.composum.sling.core.pckgmgr.PackageJobExecutor$PackageManagerCallable$InstallOperation.doIt(PackageJobExecutor.java:173)
 [com.composum.core.pckgmgr:1.12.0]
at 
com.composum.sling.core.pckgmgr.PackageJobExecutor$PackageManagerCallable$Operation.call(PackageJobExecutor.java:276)
 [com.composum.core.pckgmgr:1.12.0]
at 
com.composum.sling.core.pckgmgr.PackageJobExecutor$PackageManagerCallable.call(PackageJobExecutor.java:145)
 [com.composum.core.pckgmgr:1.12.0]
at

[jira] [Created] (JCRVLT-471) Allow configuring a files that will pe packaged under META-INF

2020-08-21 Thread Robert Munteanu (Jira)

Robert Munteanu created JCRVLT-471:
--

 Summary: Allow configuring a files that will pe packaged under 
META-INF
 Key: JCRVLT-471
 URL: https://issues.apache.org/jira/browse/JCRVLT-471
 Project: Jackrabbit FileVault
  Issue Type: Improvement
Affects Versions: package-maven-plugin-1.1.4
Reporter: Robert Munteanu


It is useful to configure files that will be packaged under META-INF (not 
META-INF/vault ). For instance, in the Sling project we require that legal 
artifacts ( META-INF/LICENSE and META-INF/NOTICE ) are present in the main 
artifacts.

There are possible workarounds involving the maven-resources-plugin, but a 
simple solution from this plugin would be better.

Initially discussed at 
https://lists.apache.org/thread.html/raacee511c1e6dbf79ffeb2021736d27b76ce6a8a5f25a528df4492b7%40%3Coak-dev.jackrabbit.apache.org%3E



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (JCRVLT-369) Include package name in error message when dependencies are not satisfied

2019-09-16 Thread Robert Munteanu (Jira)



 [ 
https://issues.apache.org/jira/browse/JCRVLT-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated JCRVLT-369:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Fixed with https://svn.apache.org/r1867026 .

> Include package name in error message when dependencies are not satisfied
> -
>
> Key: JCRVLT-369
> URL: https://issues.apache.org/jira/browse/JCRVLT-369
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Affects Versions: 3.4.0
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: 3.4.2
>
>
> The Sling Feature Launcher installs packages in batches. When a missing 
> dependency is encountered, the error message does not specify which package 
> failed to install, which makes it quite hard to debug the problem.
> {noformat}[ERROR] Error while assembling launcher: Package has unresolved 
> dependencies: day/cq610/social/enablement:cq-social-enablement-pkg:1.1.0
> shaded.org.apache.jackrabbit.vault.packaging.DependencyException: Package has 
> unresolved dependencies: 
> day/cq610/social/enablement:cq-social-enablement-pkg:1.1.0
>   at 
> shaded.org.apache.jackrabbit.vault.packaging.registry.impl.ExecutionPlanBuilderImpl.resolveInstall(ExecutionPlanBuilderImpl.java:257)
>   at 
> shaded.org.apache.jackrabbit.vault.packaging.registry.impl.ExecutionPlanBuilderImpl.validate(ExecutionPlanBuilderImpl.java:239)
>   at 
> org.apache.sling.feature.extension.content.ContentHandler.buildExecutionPlan(ContentHandler.java:79)
>   at 
> org.apache.sling.feature.extension.content.ContentHandler.handle(ContentHandler.java:121)
>   at 
> org.apache.sling.feature.launcher.impl.FeatureProcessor.prepareLauncher(FeatureProcessor.java:159)
>   at 
> org.apache.sling.feature.launcher.impl.Main.main(Main.java:250){noformat}
> It would be very useful to include the information in the error message.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Commented] (JCRVLT-369) Include package name in error message when dependencies are not satisfied

2019-09-13 Thread Robert Munteanu (Jira)



[ 
https://issues.apache.org/jira/browse/JCRVLT-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929308#comment-16929308
 ] 

Robert Munteanu commented on JCRVLT-369:


Here's a trivial patch which fixes the problem:

{noformat}
Index: 
vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/ExecutionPlanBuilderImpl.java
===
--- 
vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/ExecutionPlanBuilderImpl.java
  (revision 1866899)
+++ 
vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/ExecutionPlanBuilderImpl.java
  (working copy)
@@ -254,7 +254,7 @@
 resolved.add(id);
 DependencyReport report = registry.analyzeDependencies(id, false);
 if (report.getUnresolvedDependencies().length > 0) {
-throw new DependencyException("Package has unresolved 
dependencies: " + Dependency.toString(report.getUnresolvedDependencies()));
+throw new DependencyException("Package " + id + " has unresolved 
dependencies: " + Dependency.toString(report.getUnresolvedDependencies()));
 }
 for (PackageId depId: report.getResolvedDependencies()) {
 // if the package task is already present, continue resolution
@@ -371,4 +371,4 @@
 return packages;
 }
 }
-}
\ No newline at end of file
+}
{noformat}

[~tripod], [~kwin] - WDYT?

> Include package name in error message when dependencies are not satisfied
> -
>
> Key: JCRVLT-369
> URL: https://issues.apache.org/jira/browse/JCRVLT-369
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Affects Versions: 3.4.0
>Reporter: Robert Munteanu
>Priority: Major
>
> The Sling Feature Launcher installs packages in batches. When a missing 
> dependency is encountered, the error message does not specify which package 
> failed to install, which makes it quite hard to debug the problem.
> {noformat}[ERROR] Error while assembling launcher: Package has unresolved 
> dependencies: day/cq610/social/enablement:cq-social-enablement-pkg:1.1.0
> shaded.org.apache.jackrabbit.vault.packaging.DependencyException: Package has 
> unresolved dependencies: 
> day/cq610/social/enablement:cq-social-enablement-pkg:1.1.0
>   at 
> shaded.org.apache.jackrabbit.vault.packaging.registry.impl.ExecutionPlanBuilderImpl.resolveInstall(ExecutionPlanBuilderImpl.java:257)
>   at 
> shaded.org.apache.jackrabbit.vault.packaging.registry.impl.ExecutionPlanBuilderImpl.validate(ExecutionPlanBuilderImpl.java:239)
>   at 
> org.apache.sling.feature.extension.content.ContentHandler.buildExecutionPlan(ContentHandler.java:79)
>   at 
> org.apache.sling.feature.extension.content.ContentHandler.handle(ContentHandler.java:121)
>   at 
> org.apache.sling.feature.launcher.impl.FeatureProcessor.prepareLauncher(FeatureProcessor.java:159)
>   at 
> org.apache.sling.feature.launcher.impl.Main.main(Main.java:250){noformat}
> It would be very useful to include the information in the error message.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Updated] (JCRVLT-369) Include package name in error message when dependencies are not satisfied

2019-09-13 Thread Robert Munteanu (Jira)



 [ 
https://issues.apache.org/jira/browse/JCRVLT-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated JCRVLT-369:
---
Status: Patch Available  (was: Open)

> Include package name in error message when dependencies are not satisfied
> -
>
> Key: JCRVLT-369
> URL: https://issues.apache.org/jira/browse/JCRVLT-369
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Affects Versions: 3.4.0
>Reporter: Robert Munteanu
>Priority: Major
>
> The Sling Feature Launcher installs packages in batches. When a missing 
> dependency is encountered, the error message does not specify which package 
> failed to install, which makes it quite hard to debug the problem.
> {noformat}[ERROR] Error while assembling launcher: Package has unresolved 
> dependencies: day/cq610/social/enablement:cq-social-enablement-pkg:1.1.0
> shaded.org.apache.jackrabbit.vault.packaging.DependencyException: Package has 
> unresolved dependencies: 
> day/cq610/social/enablement:cq-social-enablement-pkg:1.1.0
>   at 
> shaded.org.apache.jackrabbit.vault.packaging.registry.impl.ExecutionPlanBuilderImpl.resolveInstall(ExecutionPlanBuilderImpl.java:257)
>   at 
> shaded.org.apache.jackrabbit.vault.packaging.registry.impl.ExecutionPlanBuilderImpl.validate(ExecutionPlanBuilderImpl.java:239)
>   at 
> org.apache.sling.feature.extension.content.ContentHandler.buildExecutionPlan(ContentHandler.java:79)
>   at 
> org.apache.sling.feature.extension.content.ContentHandler.handle(ContentHandler.java:121)
>   at 
> org.apache.sling.feature.launcher.impl.FeatureProcessor.prepareLauncher(FeatureProcessor.java:159)
>   at 
> org.apache.sling.feature.launcher.impl.Main.main(Main.java:250){noformat}
> It would be very useful to include the information in the error message.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Created] (JCRVLT-369) Include package name in error message when dependencies are not satisfied

2019-09-13 Thread Robert Munteanu (Jira)

Robert Munteanu created JCRVLT-369:
--

 Summary: Include package name in error message when dependencies 
are not satisfied
 Key: JCRVLT-369
 URL: https://issues.apache.org/jira/browse/JCRVLT-369
 Project: Jackrabbit FileVault
  Issue Type: Improvement
  Components: Packaging
Affects Versions: 3.4.0
Reporter: Robert Munteanu


The Sling Feature Launcher installs packages in batches. When a missing 
dependency is encountered, the error message does not specify which package 
failed to install, which makes it quite hard to debug the problem.

{noformat}[ERROR] Error while assembling launcher: Package has unresolved 
dependencies: day/cq610/social/enablement:cq-social-enablement-pkg:1.1.0
shaded.org.apache.jackrabbit.vault.packaging.DependencyException: Package has 
unresolved dependencies: 
day/cq610/social/enablement:cq-social-enablement-pkg:1.1.0
at 
shaded.org.apache.jackrabbit.vault.packaging.registry.impl.ExecutionPlanBuilderImpl.resolveInstall(ExecutionPlanBuilderImpl.java:257)
at 
shaded.org.apache.jackrabbit.vault.packaging.registry.impl.ExecutionPlanBuilderImpl.validate(ExecutionPlanBuilderImpl.java:239)
at 
org.apache.sling.feature.extension.content.ContentHandler.buildExecutionPlan(ContentHandler.java:79)
at 
org.apache.sling.feature.extension.content.ContentHandler.handle(ContentHandler.java:121)
at 
org.apache.sling.feature.launcher.impl.FeatureProcessor.prepareLauncher(FeatureProcessor.java:159)
at 
org.apache.sling.feature.launcher.impl.Main.main(Main.java:250){noformat}

It would be very useful to include the information in the error message.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Commented] (JCRVLT-367) CLONE - vlt shell script prints out error when using openjdk

2019-09-09 Thread Robert Munteanu (Jira)



[ 
https://issues.apache.org/jira/browse/JCRVLT-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925992#comment-16925992
 ] 

Robert Munteanu commented on JCRVLT-367:


[~kwin] - the script from the article you mentioned correctly outputs '11' for 
the {{java -version}} I added in the description.

> CLONE - vlt shell script prints out error when using openjdk
> 
>
> Key: JCRVLT-367
> URL: https://issues.apache.org/jira/browse/JCRVLT-367
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: Packaging
>Affects Versions: 3.2.8
>Reporter: Robert Munteanu
>Priority: Minor
> Fix For: 3.4.0
>
>
> {noformat}$ vlt --version
> /usr/bin/vlt: line 146: [: 110 2019-07-16: integer expression expected
> Jackrabbit FileVault [version 3.2.8] Copyright 2018 by Apache Software 
> Foundation. See LICENSE.txt for more information.{noformat}
> {noformat}$ java -version
> openjdk version "11.0.4" 2019-07-16
> OpenJDK Runtime Environment (build 11.0.4+11-suse-1.1-x8664)
> OpenJDK 64-Bit Server VM (build 11.0.4+11-suse-1.1-x8664, mixed 
> mode){noformat}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Updated] (JCRVLT-367) CLONE - vlt shell script prints out error when using openjdk

2019-09-09 Thread Robert Munteanu (Jira)



 [ 
https://issues.apache.org/jira/browse/JCRVLT-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated JCRVLT-367:
---
Description: 
{noformat}$ vlt --version
/usr/bin/vlt: line 146: [: 110 2019-07-16: integer expression expected
Jackrabbit FileVault [version 3.2.8] Copyright 2018 by Apache Software 
Foundation. See LICENSE.txt for more information.{noformat}

{noformat}$ java -version
openjdk version "11.0.4" 2019-07-16
OpenJDK Runtime Environment (build 11.0.4+11-suse-1.1-x8664)
OpenJDK 64-Bit Server VM (build 11.0.4+11-suse-1.1-x8664, mixed mode){noformat}

  was:
{noformat}$ vlt --version
/usr/bin/vlt: line 141: [: openjdk version "1.8.0_131": integer expression 
expected
Jackrabbit FileVault [version 3.1.40] Copyright 2013 by Apache Software 
Foundation. See LICENSE.txt for more information.{noformat}

{noformat}$ java -version
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (IcedTea 3.4.0) (suse-1.1-x86_64)
OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode){noformat}


> CLONE - vlt shell script prints out error when using openjdk
> 
>
> Key: JCRVLT-367
> URL: https://issues.apache.org/jira/browse/JCRVLT-367
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: Packaging
>Affects Versions: 3.2.8
>Reporter: Robert Munteanu
>Priority: Minor
>
> {noformat}$ vlt --version
> /usr/bin/vlt: line 146: [: 110 2019-07-16: integer expression expected
> Jackrabbit FileVault [version 3.2.8] Copyright 2018 by Apache Software 
> Foundation. See LICENSE.txt for more information.{noformat}
> {noformat}$ java -version
> openjdk version "11.0.4" 2019-07-16
> OpenJDK Runtime Environment (build 11.0.4+11-suse-1.1-x8664)
> OpenJDK 64-Bit Server VM (build 11.0.4+11-suse-1.1-x8664, mixed 
> mode){noformat}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Updated] (JCRVLT-367) CLONE - vlt shell script prints out error when using openjdk

2019-09-09 Thread Robert Munteanu (Jira)



 [ 
https://issues.apache.org/jira/browse/JCRVLT-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated JCRVLT-367:
---
Fix Version/s: (was: 3.1.44)

> CLONE - vlt shell script prints out error when using openjdk
> 
>
> Key: JCRVLT-367
> URL: https://issues.apache.org/jira/browse/JCRVLT-367
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: Packaging
>Affects Versions: 3.2.8
>Reporter: Robert Munteanu
>Priority: Minor
>
> {noformat}$ vlt --version
> /usr/bin/vlt: line 141: [: openjdk version "1.8.0_131": integer expression 
> expected
> Jackrabbit FileVault [version 3.1.40] Copyright 2013 by Apache Software 
> Foundation. See LICENSE.txt for more information.{noformat}
> {noformat}$ java -version
> openjdk version "1.8.0_131"
> OpenJDK Runtime Environment (IcedTea 3.4.0) (suse-1.1-x86_64)
> OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode){noformat}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Updated] (JCRVLT-367) CLONE - vlt shell script prints out error when using openjdk

2019-09-09 Thread Robert Munteanu (Jira)



 [ 
https://issues.apache.org/jira/browse/JCRVLT-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated JCRVLT-367:
---
Affects Version/s: (was: 3.1.40)
   3.2.8

> CLONE - vlt shell script prints out error when using openjdk
> 
>
> Key: JCRVLT-367
> URL: https://issues.apache.org/jira/browse/JCRVLT-367
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: Packaging
>Affects Versions: 3.2.8
>Reporter: Robert Munteanu
>Priority: Minor
> Fix For: 3.1.44
>
>
> {noformat}$ vlt --version
> /usr/bin/vlt: line 141: [: openjdk version "1.8.0_131": integer expression 
> expected
> Jackrabbit FileVault [version 3.1.40] Copyright 2013 by Apache Software 
> Foundation. See LICENSE.txt for more information.{noformat}
> {noformat}$ java -version
> openjdk version "1.8.0_131"
> OpenJDK Runtime Environment (IcedTea 3.4.0) (suse-1.1-x86_64)
> OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode){noformat}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Created] (JCRVLT-367) CLONE - vlt shell script prints out error when using openjdk

2019-09-09 Thread Robert Munteanu (Jira)

Robert Munteanu created JCRVLT-367:
--

 Summary: CLONE - vlt shell script prints out error when using 
openjdk
 Key: JCRVLT-367
 URL: https://issues.apache.org/jira/browse/JCRVLT-367
 Project: Jackrabbit FileVault
  Issue Type: Bug
  Components: Packaging
Affects Versions: 3.1.40
Reporter: Robert Munteanu
 Fix For: 3.1.44


{noformat}$ vlt --version
/usr/bin/vlt: line 141: [: openjdk version "1.8.0_131": integer expression 
expected
Jackrabbit FileVault [version 3.1.40] Copyright 2013 by Apache Software 
Foundation. See LICENSE.txt for more information.{noformat}

{noformat}$ java -version
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (IcedTea 3.4.0) (suse-1.1-x86_64)
OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode){noformat}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Commented] (JCR-4467) Remove all usage of java.security.acl.Group for Java 14

2019-08-28 Thread Robert Munteanu (Jira)



[ 
https://issues.apache.org/jira/browse/JCR-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917527#comment-16917527
 ] 

Robert Munteanu commented on JCR-4467:
--

Yes, that is definitely an option. My preference would be to fix, if easy, 
otherwise to drop support.

> Remove all usage of java.security.acl.Group for Java 14
> ---
>
> Key: JCR-4467
> URL: https://issues.apache.org/jira/browse/JCR-4467
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 2.20
>
> Attachments: JCR-4467.diff
>
>
> Followup of OAK-7024 for the actual removal of the Group class from the 
> codebase to be java 14 compliant.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Commented] (JCR-4467) Remove all usage of java.security.acl.Group for Java 14

2019-08-28 Thread Robert Munteanu (Jira)



[ 
https://issues.apache.org/jira/browse/JCR-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917504#comment-16917504
 ] 

Robert Munteanu commented on JCR-4467:
--

[~reschke] - I took a quick look at the patch. The bump by itself can be 
problematic. It seems however that there is no usage of 
{{java.security.acl.Group}} in all of Sling, so we might be able to just widen 
the import ranges on the {{org.apache.sling.jcr.registration}} bundle and call 
it a day. I haven't done a test build though.

> Remove all usage of java.security.acl.Group for Java 14
> ---
>
> Key: JCR-4467
> URL: https://issues.apache.org/jira/browse/JCR-4467
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 2.20
>
> Attachments: JCR-4467.diff
>
>
> Followup of OAK-7024 for the actual removal of the Group class from the 
> codebase to be java 14 compliant.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Commented] (JCRVLT-330) NoClassFoundError(org/apache/commons/io/FileUtils) in analyse-classes goal

2019-02-06 Thread Robert Munteanu (JIRA)



[ 
https://issues.apache.org/jira/browse/JCRVLT-330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761631#comment-16761631
 ] 

Robert Munteanu commented on JCRVLT-330:


I'm not familiar with the FileVault tooling, but I guess a first step would be 
for you to attach a simple project which reproduces the failure.

> NoClassFoundError(org/apache/commons/io/FileUtils) in analyse-classes goal
> --
>
> Key: JCRVLT-330
> URL: https://issues.apache.org/jira/browse/JCRVLT-330
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1, package-maven-plugin-1.0.3
>Reporter: Rakesh Kumar
>Priority: Critical
>
> Hi,
> When trying to create a package using 
> *org.apache.jackrabbit:filevault-package-maven-plugin:1.0.1* 
> *or*
> *org.apache.jackrabbit:filevault-package-maven-plugin:1.0.3***
>  
> we get a NoClassDefFoundError - *org/apache/commons/io/FileUtils*
>  
> Here is the trace.
>  
> [*INFO*] *BUILD FAILURE*
> [*INFO*] 
> **
> [*INFO*] Total time:  20.156 s
> [*INFO*] Finished at: 2019-01-25T11:14:17-05:00
> [*INFO*] 
> **
> [*ERROR*] Failed to execute goal 
> org.apache.jackrabbit:filevault-package-maven-plugin:1.0.1:analyze-classes 
> *(default-analyze-classes)* on project joule-mvp-ui-joule:*Execution 
> default-analyze-classes of goal 
> org.apache.jackrabbit:filevault-package-maven-plugin:1.0.1:analyze-classes 
> failed: A required class was missing while executing 
> org.apache.jackrabbit:filevault-package-maven-plugin:1.0.1:analyze-classes: 
> org/apache/commons/io/FileUtils*
> [*ERROR*] *-*
> [*ERROR*] *realm =    
> extension>org.apache.jackrabbit:filevault-package-maven-plugin:1.0.1*
> [*ERROR*] *strategy = 
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy*
> [*ERROR*] *urls[0] = 
> file:/Users/mhenry/.m2/repository/org/apache/jackrabbit/filevault-package-maven-plugin/1.0.1/filevault-package-maven-plugin-1.0.1.jar*
> [*ERROR*] *urls[1] = 
> file:/Users/mhenry/.m2/repository/org/apache/jackrabbit/vault/org.apache.jackrabbit.vault/3.1.42/org.apache.jackrabbit.vault-3.1.42.jar*
> [*ERROR*] *urls[2] = 
> file:/Users/mhenry/.m2/repository/javax/jcr/jcr/2.0/jcr-2.0.jar*
> [*ERROR*] *urls[3] = 
> file:/Users/mhenry/.m2/repository/org/apache/maven/maven-builder-support/3.3.9/maven-builder-support-3.3.9.jar*
> [*ERROR*] *urls[4] = 
> file:/Users/mhenry/.m2/repository/com/google/guava/guava/18.0/guava-18.0.jar*
> [*ERROR*] *urls[5] = 
> file:/Users/mhenry/.m2/repository/org/eclipse/aether/aether-util/1.0.2.v20150114/aether-util-1.0.2.v20150114.jar*
> [*ERROR*] *urls[6] = 
> file:/Users/mhenry/.m2/repository/com/google/inject/guice/4.0/guice-4.0-no_aop.jar*
> [*ERROR*] *urls[7] = 
> file:/Users/mhenry/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar*
> [*ERROR*] *urls[8] = 
> file:/Users/mhenry/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.21/plexus-interpolation-1.21.jar*
> [*ERROR*] *urls[9] = 
> file:/Users/mhenry/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.6/plexus-component-annotations-1.6.jar*
> [*ERROR*] *urls[10] = 
> file:/Users/mhenry/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar*
> [*ERROR*] *urls[11] = 
> file:/Users/mhenry/.m2/repository/org/apache/commons/commons-lang3/3.4/commons-lang3-3.4.jar*
> [*ERROR*] *urls[12] = 
> file:/Users/mhenry/.m2/repository/org/apache/maven/plugin-tools/maven-plugin-annotations/3.5/maven-plugin-annotations-3.5.jar*
> [*ERROR*] *urls[13] = 
> file:/Users/mhenry/.m2/repository/org/apache/maven/maven-archiver/3.0.0/maven-archiver-3.0.0.jar*
> [*ERROR*] *urls[14] = 
> file:/Users/mhenry/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.22/plexus-utils-3.0.22.jar*
> [*ERROR*] *urls[15] = 
> file:/Users/mhenry/.m2/repository/org/codehaus/mojo/animal-sniffer-maven-plugin/1.14/animal-sniffer-maven-plugin-1.14.jar*
> [*ERROR*] *urls[16] = 
> file:/Users/mhenry/.m2/repository/org/codehaus/mojo/animal-sniffer/1.14/animal-sniffer-1.14.jar*
> [*ERROR*] *urls[17] = 
> file:/Users/mhenry/.m2/repository/org/ow2/asm/asm-all/5.0.3/asm-all-5.0.3.jar*
> [*ERROR*] *urls[18] = 
> file:/Users/mhenry/.m2/repository/org/codehaus/mojo/java-boot-classpath-detector/1.14/java-boot-classpath-detector-1.14.jar*
> [*ERROR*] *urls[19] = 
> file:/Users/mhenry/.m2/repository/org/apache/maven/shared/maven-common-artifact-filters/1.4/maven-common-artifact-filters-1.4.jar*
> [*ERROR*] *urls[20] = 
> file:/Users/mhenry/.m2/repository/org/apache/xbean/xbean-reflect/3.4/xbean-reflect-3.4.jar*
> [*ERROR*]

[jira] [Assigned] (JCR-4317) davex remoting fails for non-ASCII characters in node names

2018-07-26 Thread Robert Munteanu (JIRA)



 [ 
https://issues.apache.org/jira/browse/JCR-4317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu reassigned JCR-4317:


Assignee: Julian Reschke

> davex remoting fails for non-ASCII characters in node names
> ---
>
> Key: JCR-4317
> URL: https://issues.apache.org/jira/browse/JCR-4317
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-spi2dav
>Affects Versions: 2.14.5, 2.16.2, 2.17.3
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>  Labels: candidate_jcr_2_14
> Fix For: 2.18, 2.17.4, 2.16.3
>
> Attachments: namefail.diff
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JCR-4301) get rid of JSR 305 dependency

2018-05-23 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-4301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16487376#comment-16487376
 ] 

Robert Munteanu commented on JCR-4301:
--

[~kwin] - would the Jetbrains annotations work for us in Sling?

> get rid of JSR 305 dependency
> -
>
> Key: JCR-4301
> URL: https://issues.apache.org/jira/browse/JCR-4301
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-api
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Attachments: JCR-4301-2.diff, JCR-4301.diff
>
>
> We should consider getting rid of the JSR 305 dependency (see 
> ). Note that we only used the 
> annotations in a few recently changed APIs.
> Further note that we could use spotbugs as replacement for findbugs to detect 
> problems.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JCR-4301) get rid of JSR 305 dependency

2018-05-23 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-4301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16487326#comment-16487326
 ] 

Robert Munteanu commented on JCR-4301:
--

These two should be safe I guess, given that we are OK with loosing 
{{Nonnegative}}, which is only used once with 
https://github.com/apache/jackrabbit-oak/blob/4137effe382f7c1456e0ee35eb175235c5952f0b/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/cache/NodeDocumentCache.java#L128
 . 

> get rid of JSR 305 dependency
> -
>
> Key: JCR-4301
> URL: https://issues.apache.org/jira/browse/JCR-4301
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-api
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Attachments: JCR-4301-2.diff, JCR-4301.diff
>
>
> We should consider getting rid of the JSR 305 dependency (see 
> ). Note that we only used the 
> annotations in a few recently changed APIs.
> Further note that we could use spotbugs as replacement for findbugs to detect 
> problems.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JCRVLT-275) Docker build and docker image for filevault

2018-02-21 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCRVLT-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16371507#comment-16371507
 ] 

Robert Munteanu commented on JCRVLT-275:


_If_ we decide to do this, we need to maintain it, obviously. So it's an 
additional burden on the release manager, which so far for FileVault is 
[~tripod] .

> Docker build and docker image for filevault
> ---
>
> Key: JCRVLT-275
> URL: https://issues.apache.org/jira/browse/JCRVLT-275
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging, vlt
>Affects Versions: 3.1.42
>Reporter: Ioan Eugen Stan
>Priority: Major
>
> I believe it will improve FileVault usage if we make it easier for users to 
> consume the software.
> One way to achieve this is to publlish binary artifacts.
> Docker makes this easy to.
> I've published patches in a PR on Github 
> [https://github.com/apache/jackrabbit-filevault/pull/25] .
> Docker file contains a multi-stage docker build:
> Stage 1: builds FileVault binary using official maven openjdk image
> Stage 2: Creates a FileVault image that can be published via automated builds 
> on docker hub.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JCRVLT-275) Docker build and docker image for filevault

2018-02-20 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCRVLT-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369864#comment-16369864
 ] 

Robert Munteanu commented on JCRVLT-275:


If we decide to do this we should publish it under the official 'Apache' 
account - https://hub.docker.com/u/apache/ . For that you need to add the 
Dockerfile to a github repo and then contact INFRA and tell them to add a new 
automated build with the following data:

- github repo
- docker image name ( if different from github repo )
- which tags/branches to build on

> Docker build and docker image for filevault
> ---
>
> Key: JCRVLT-275
> URL: https://issues.apache.org/jira/browse/JCRVLT-275
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging, vlt
>Affects Versions: 3.1.42
>Reporter: Ioan Eugen Stan
>Priority: Major
>
> I believe it will improve FileVault usage if we make it easier for users to 
> consume the software.
> One way to achieve this is to publlish binary artifacts.
> Docker makes this easy to.
> I've published patches in a PR on Github 
> [https://github.com/apache/jackrabbit-filevault/pull/25] .
> Docker file contains a multi-stage docker build:
> Stage 1: builds FileVault binary using official maven openjdk image
> Stage 2: Creates a FileVault image that can be published via automated builds 
> on docker hub.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JCR-4215) Use Tika version 1.17

2017-12-19 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-4215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16296513#comment-16296513
 ] 

Robert Munteanu commented on JCR-4215:
--

Fails for me as well, but I don't get any error messages, except Tika 
complaining about missing optional dependencies.

> Use Tika version 1.17
> -
>
> Key: JCR-4215
> URL: https://issues.apache.org/jira/browse/JCR-4215
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 2.18
>
> Attachments: 
> TEST-org.apache.jackrabbit.core.query.lucene.IndexingQueueTest.xml, 
> org.apache.jackrabbit.core.query.lucene.IndexingQueueTest.log, 
> org.apache.jackrabbit.core.query.lucene.IndexingQueueTest.txt
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCR-4195) jcr-rmi on java 9: Cannot use SUN rmic, as it is not available

2017-11-28 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16268422#comment-16268422
 ] 

Robert Munteanu commented on JCR-4195:
--

[~c_koell] - can you share your local test project?

> jcr-rmi on java 9: Cannot use SUN rmic, as it is not available
> --
>
> Key: JCR-4195
> URL: https://issues.apache.org/jira/browse/JCR-4195
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 2.16, 2.15.7
>
>
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-antrun-plugin:1.8:run (rmic) on project 
> jackrabbit-jcr-rmi: An Ant BuildException has occured: Cannot use SUN rmic, 
> as it is not available.  A common solution is to set the environment variable 
> JAVA_HOME
> [ERROR] around Ant part ... classpathref="maven.compile.classpath" 
> base="C:\projects\apache\jackrabbit\trunk\jackrabbit-jcr-rmi\target\classes"/>...
>  @ 4:140 in 
> C:\projects\apache\jackrabbit\trunk\jackrabbit-jcr-rmi\target\antrun\build-main.xml
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCRVLT-184) vlt shell script prints out error when using openjdk

2017-11-13 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCRVLT-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251018#comment-16251018
 ] 

Robert Munteanu commented on JCRVLT-184:


This one works just file as well, thank you.

> vlt shell script prints out error when using openjdk
> 
>
> Key: JCRVLT-184
> URL: https://issues.apache.org/jira/browse/JCRVLT-184
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>Affects Versions: 3.1.40
>Reporter: Robert Munteanu
>Priority: Minor
> Fix For: 3.1.44
>
>
> {noformat}$ vlt --version
> /usr/bin/vlt: line 141: [: openjdk version "1.8.0_131": integer expression 
> expected
> Jackrabbit FileVault [version 3.1.40] Copyright 2013 by Apache Software 
> Foundation. See LICENSE.txt for more information.{noformat}
> {noformat}$ java -version
> openjdk version "1.8.0_131"
> OpenJDK Runtime Environment (IcedTea 3.4.0) (suse-1.1-x86_64)
> OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode){noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (JCRVLT-184) vlt shell script prints out error when using openjdk

2017-11-13 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCRVLT-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251018#comment-16251018
 ] 

Robert Munteanu edited comment on JCRVLT-184 at 11/14/17 7:17 AM:
--

This one works just fine as well, thank you.


was (Author: rombert):
This one works just file as well, thank you.

> vlt shell script prints out error when using openjdk
> 
>
> Key: JCRVLT-184
> URL: https://issues.apache.org/jira/browse/JCRVLT-184
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>Affects Versions: 3.1.40
>Reporter: Robert Munteanu
>Priority: Minor
> Fix For: 3.1.44
>
>
> {noformat}$ vlt --version
> /usr/bin/vlt: line 141: [: openjdk version "1.8.0_131": integer expression 
> expected
> Jackrabbit FileVault [version 3.1.40] Copyright 2013 by Apache Software 
> Foundation. See LICENSE.txt for more information.{noformat}
> {noformat}$ java -version
> openjdk version "1.8.0_131"
> OpenJDK Runtime Environment (IcedTea 3.4.0) (suse-1.1-x86_64)
> OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode){noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JCRVLT-184) vlt shell script prints out error when using openjdk

2017-11-13 Thread Robert Munteanu (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCRVLT-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated JCRVLT-184:
---
Status: Patch Available  (was: Open)

> vlt shell script prints out error when using openjdk
> 
>
> Key: JCRVLT-184
> URL: https://issues.apache.org/jira/browse/JCRVLT-184
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>Affects Versions: 3.1.40
>Reporter: Robert Munteanu
>Priority: Minor
>
> {noformat}$ vlt --version
> /usr/bin/vlt: line 141: [: openjdk version "1.8.0_131": integer expression 
> expected
> Jackrabbit FileVault [version 3.1.40] Copyright 2013 by Apache Software 
> Foundation. See LICENSE.txt for more information.{noformat}
> {noformat}$ java -version
> openjdk version "1.8.0_131"
> OpenJDK Runtime Environment (IcedTea 3.4.0) (suse-1.1-x86_64)
> OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode){noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (JCRVLT-184) vlt shell script prints out error when using openjdk

2017-11-13 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCRVLT-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16249252#comment-16249252
 ] 

Robert Munteanu edited comment on JCRVLT-184 at 11/13/17 8:49 AM:
--

{noformat}diff --git a/vault-cli/src/main/appassembler/unix-template.sh 
b/vault-cli/src/main/appassembler/unix-template.sh
index d0a0634..7bbf6ba 100644
--- a/vault-cli/src/main/appassembler/unix-template.sh
+++ b/vault-cli/src/main/appassembler/unix-template.sh
@@ -121,7 +121,7 @@ if [ -n "$COLS" ]; then
 EXTRA_JVM_ARGUMENTS="$EXTRA_JVM_ARGUMENTS -Denv.term.width=${COLS}"
 fi
 
-JAVA_VER=$($JAVACMD -version 2>&1 | sed 's/java version 
"\(.*\)\.\(.*\)\..*"/\1\2/; 1q')
+JAVA_VER=$($JAVACMD -version 2>&1 | sed 's/\(java\|openjdk\) version 
"\(.*\)\.\(.*\)\..*"/\2\3/; 1q')
 
 if [ "$JAVA_VER" -lt 18 ]; then
 EXTRA_JVM_ARGUMENTS="$EXTRA_JVM_ARGUMENTS -XX:PermSize=128m 
-XX:-UseGCOverheadLimit"
{noformat}

[~tripod] - the above trivial patch works for me with both OpenJDK and Oracle's 
Java distribution.


was (Author: rombert):
{noformat}diff --git a/vault-cli/src/main/appassembler/unix-template.sh 
b/vault-cli/src/main/appassembler/unix-template.sh
index d0a0634..7bbf6ba 100644
--- a/vault-cli/src/main/appassembler/unix-template.sh
+++ b/vault-cli/src/main/appassembler/unix-template.sh
@@ -121,7 +121,7 @@ if [ -n "$COLS" ]; then
 EXTRA_JVM_ARGUMENTS="$EXTRA_JVM_ARGUMENTS -Denv.term.width=${COLS}"
 fi
 
-JAVA_VER=$($JAVACMD -version 2>&1 | sed 's/java version 
"\(.*\)\.\(.*\)\..*"/\1\2/; 1q')
+JAVA_VER=$($JAVACMD -version 2>&1 | sed 's/\(java\|openjdk\) version 
"\(.*\)\.\(.*\)\..*"/\2\3/; 1q')
 
 if [ "$JAVA_VER" -lt 18 ]; then
 EXTRA_JVM_ARGUMENTS="$EXTRA_JVM_ARGUMENTS -XX:PermSize=128m 
-XX:-UseGCOverheadLimit"
{noformat}

[~tripod] - the following trivial patch works for me with both OpenJDK and 
Oracle's Java distribution.

> vlt shell script prints out error when using openjdk
> 
>
> Key: JCRVLT-184
> URL: https://issues.apache.org/jira/browse/JCRVLT-184
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>Affects Versions: 3.1.40
>Reporter: Robert Munteanu
>Priority: Minor
>
> {noformat}$ vlt --version
> /usr/bin/vlt: line 141: [: openjdk version "1.8.0_131": integer expression 
> expected
> Jackrabbit FileVault [version 3.1.40] Copyright 2013 by Apache Software 
> Foundation. See LICENSE.txt for more information.{noformat}
> {noformat}$ java -version
> openjdk version "1.8.0_131"
> OpenJDK Runtime Environment (IcedTea 3.4.0) (suse-1.1-x86_64)
> OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode){noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCRVLT-184) vlt shell script prints out error when using openjdk

2017-11-13 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCRVLT-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16249252#comment-16249252
 ] 

Robert Munteanu commented on JCRVLT-184:


{noformat}diff --git a/vault-cli/src/main/appassembler/unix-template.sh 
b/vault-cli/src/main/appassembler/unix-template.sh
index d0a0634..7bbf6ba 100644
--- a/vault-cli/src/main/appassembler/unix-template.sh
+++ b/vault-cli/src/main/appassembler/unix-template.sh
@@ -121,7 +121,7 @@ if [ -n "$COLS" ]; then
 EXTRA_JVM_ARGUMENTS="$EXTRA_JVM_ARGUMENTS -Denv.term.width=${COLS}"
 fi
 
-JAVA_VER=$($JAVACMD -version 2>&1 | sed 's/java version 
"\(.*\)\.\(.*\)\..*"/\1\2/; 1q')
+JAVA_VER=$($JAVACMD -version 2>&1 | sed 's/\(java\|openjdk\) version 
"\(.*\)\.\(.*\)\..*"/\2\3/; 1q')
 
 if [ "$JAVA_VER" -lt 18 ]; then
 EXTRA_JVM_ARGUMENTS="$EXTRA_JVM_ARGUMENTS -XX:PermSize=128m 
-XX:-UseGCOverheadLimit"
{noformat}

[~tripod] - the following trivial patch works for me with both OpenJDK and 
Oracle's Java distribution.

> vlt shell script prints out error when using openjdk
> 
>
> Key: JCRVLT-184
> URL: https://issues.apache.org/jira/browse/JCRVLT-184
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>Affects Versions: 3.1.40
>Reporter: Robert Munteanu
>Priority: Minor
>
> {noformat}$ vlt --version
> /usr/bin/vlt: line 141: [: openjdk version "1.8.0_131": integer expression 
> expected
> Jackrabbit FileVault [version 3.1.40] Copyright 2013 by Apache Software 
> Foundation. See LICENSE.txt for more information.{noformat}
> {noformat}$ java -version
> openjdk version "1.8.0_131"
> OpenJDK Runtime Environment (IcedTea 3.4.0) (suse-1.1-x86_64)
> OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode){noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JCRVLT-222) analyze-classes goal should be marked as ignored for m2e

2017-11-07 Thread Robert Munteanu (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCRVLT-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated JCRVLT-222:
---
Attachment: 0001-JCRVLT-222-analyze-classes-goal-should-be-marked-as-.patch

[~tripod] - here's a trivial patch which fixes this issue

> analyze-classes goal should be marked as ignored for m2e
> 
>
> Key: JCRVLT-222
> URL: https://issues.apache.org/jira/browse/JCRVLT-222
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.0
>Reporter: Robert Munteanu
>Priority: Minor
> Fix For: package-maven-plugin-1.0.1
>
> Attachments: 
> 0001-JCRVLT-222-analyze-classes-goal-should-be-marked-as-.patch
>
>
> The analyze-classes goal is currently bound to the 'process-classes' 
> lifecycle phase and causes m2e to raise an error since it's not mapped.
> It should be mapped to ignore, same as 'check-signature', as it does not make 
> sense in an IDE context.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JCRVLT-222) analyze-classes goal should be marked as ignored for m2e

2017-11-07 Thread Robert Munteanu (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCRVLT-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated JCRVLT-222:
---
Status: Patch Available  (was: Open)

> analyze-classes goal should be marked as ignored for m2e
> 
>
> Key: JCRVLT-222
> URL: https://issues.apache.org/jira/browse/JCRVLT-222
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.0
>Reporter: Robert Munteanu
>Priority: Minor
> Fix For: package-maven-plugin-1.0.1
>
>
> The analyze-classes goal is currently bound to the 'process-classes' 
> lifecycle phase and causes m2e to raise an error since it's not mapped.
> It should be mapped to ignore, same as 'check-signature', as it does not make 
> sense in an IDE context.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JCRVLT-222) analyze-classes goal should be marked as ignored for m2e

2017-11-07 Thread Robert Munteanu (JIRA)

Robert Munteanu created JCRVLT-222:
--

 Summary: analyze-classes goal should be marked as ignored for m2e
 Key: JCRVLT-222
 URL: https://issues.apache.org/jira/browse/JCRVLT-222
 Project: Jackrabbit FileVault
  Issue Type: Bug
  Components: package maven plugin
Affects Versions: package-maven-plugin-1.0.0
Reporter: Robert Munteanu
Priority: Minor
 Fix For: package-maven-plugin-1.0.1


The analyze-classes goal is currently bound to the 'process-classes' lifecycle 
phase and causes m2e to raise an error since it's not mapped.

It should be mapped to ignore, same as 'check-signature', as it does not make 
sense in an IDE context.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCR-4195) jcr-rmi on java 9: Cannot use SUN rmic, as it is not available

2017-10-05 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16192771#comment-16192771
 ] 

Robert Munteanu commented on JCR-4195:
--

According to 
https://docs.oracle.com/javase/8/docs/technotes/tools/unix/rmic.html, yes:

{quote}
Deprecation Note: Support for static generation of Java Remote Method Protocol 
(JRMP) stubs and skeletons has been deprecated. Oracle recommends that you use 
dynamically generated JRMP stubs instead, eliminating the need to use this tool 
for JRMP-based applications. See the java.rmi.server.UnicastRemoteObject 
specification at 
http://docs.oracle.com/javase/8/docs/api/java/rmi/server/UnicastRemoteObject.html
 for further information.
{quote}

> jcr-rmi on java 9: Cannot use SUN rmic, as it is not available
> --
>
> Key: JCR-4195
> URL: https://issues.apache.org/jira/browse/JCR-4195
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>Reporter: Julian Reschke
> Fix For: 2.16
>
>
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-antrun-plugin:1.8:run (rmic) on project 
> jackrabbit-jcr-rmi: An Ant BuildException has occured: Cannot use SUN rmic, 
> as it is not available.  A common solution is to set the environment variable 
> JAVA_HOME
> [ERROR] around Ant part ... classpathref="maven.compile.classpath" 
> base="C:\projects\apache\jackrabbit\trunk\jackrabbit-jcr-rmi\target\classes"/>...
>  @ 4:140 in 
> C:\projects\apache\jackrabbit\trunk\jackrabbit-jcr-rmi\target\antrun\build-main.xml
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCR-4195) jcr-rmi on java 9: Cannot use SUN rmic, as it is not available

2017-10-05 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16192761#comment-16192761
 ] 

Robert Munteanu commented on JCR-4195:
--

I don't think explicit stub generation is required anymore - it should work 
without since Java 5 IIRC.

> jcr-rmi on java 9: Cannot use SUN rmic, as it is not available
> --
>
> Key: JCR-4195
> URL: https://issues.apache.org/jira/browse/JCR-4195
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>Reporter: Julian Reschke
> Fix For: 2.16
>
>
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-antrun-plugin:1.8:run (rmic) on project 
> jackrabbit-jcr-rmi: An Ant BuildException has occured: Cannot use SUN rmic, 
> as it is not available.  A common solution is to set the environment variable 
> JAVA_HOME
> [ERROR] around Ant part ... classpathref="maven.compile.classpath" 
> base="C:\projects\apache\jackrabbit\trunk\jackrabbit-jcr-rmi\target\classes"/>...
>  @ 4:140 in 
> C:\projects\apache\jackrabbit\trunk\jackrabbit-jcr-rmi\target\antrun\build-main.xml
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCRVLT-207) make auto-import package a analyzer work with htl scripts

2017-09-27 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCRVLT-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16182283#comment-16182283
 ] 

Robert Munteanu commented on JCRVLT-207:


The htl-maven-plugin

> make auto-import package a analyzer  work with htl scripts
> --
>
> Key: JCRVLT-207
> URL: https://issues.apache.org/jira/browse/JCRVLT-207
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>
> if a htl script references a use class, it should be included as import 
> package dependency. eg:
> {code}
> 
> 
> 
>   
>   Default Page Title
> 
> 
>   ${jokeModel.caption}
>   ${jokeModel.joke}
> 
> 
> 
> {code}
> using the HTL plugin to validate:
> {noformat}
> 
> org.apache.sling
> htl-maven-plugin
> 1.0.9-SNAPSHOT
> 
> 
> 
> validate
> 
> 
> 
> 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCRVLT-207) make auto-import package a analyzer work with htl scripts

2017-09-27 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCRVLT-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16182136#comment-16182136
 ] 

Robert Munteanu commented on JCRVLT-207:


I am not familiar with the code bases, but I think this belongs in the HTL 
plugin rather than the vault plugin.

> make auto-import package a analyzer  work with htl scripts
> --
>
> Key: JCRVLT-207
> URL: https://issues.apache.org/jira/browse/JCRVLT-207
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>
> if a htl script references a use class, it should be included as import 
> package dependency. eg:
> {code}
> 
> 
> 
>   
>   Default Page Title
> 
> 
>   ${jokeModel.caption}
>   ${jokeModel.joke}
> 
> 
> 
> {code}
> using the HTL plugin to validate:
> {noformat}
> 
> org.apache.sling
> htl-maven-plugin
> 1.0.9-SNAPSHOT
> 
> 
> 
> validate
> 
> 
> 
> 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCRVLT-202) Import Adobe's content package maven plugin

2017-09-21 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCRVLT-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16174349#comment-16174349
 ] 

Robert Munteanu commented on JCRVLT-202:


{quote}I really would not mix remote package manager control with the archiving 
in the same plugin. {quote}

Ok

{quote}I don't understand what the scr plugin has to do with this?{quote}

Nothing in terms of code, just pointing out that this pattern was used 
somewhere else and is viable.


> Import Adobe's content package maven plugin
> ---
>
> Key: JCRVLT-202
> URL: https://issues.apache.org/jira/browse/JCRVLT-202
> Project: Jackrabbit FileVault
>  Issue Type: Task
>  Components: package maven plugin
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
> Fix For: package-maven-plugin-1.0.0
>
>
> The content-package maven plugin is a maven plugin that simplifies the 
> creation of content package maven artifacts. The content packages can later 
> be used to install content into a JCR repository using the Apache Jackrabbit 
> FileVault packaging runtime.
> Filevault was contributed 4 years ago, but we never had a tool to create the 
> packaged during runtime. Adobe's plugin is publicly available, but only in 
> binary form. With this contribution, we want to bring the source and 
> development closer to the filevault core and to leverage the community better 
> in driving this plugin further.
> *details*
> java package space: 
> {code}
> org.apache.jackrabbit.filevault.maven.packaging
> {code}
> plugin name:
> {code}
> org.apache.jackrabbit.filevault
> package-maven-plugin
> {code}
> scm location: 
> - a) SVN: 
> https://svn.apache.org/repos/asf/jackrabbit/commons/package-maven-plugin
> - b) GIT: 
> https://git-wip-us.apache.org/repos/asf?p=jackrabbit-filevault-package-plugin.git;a=tree



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCRVLT-202) Import Adobe's content package maven plugin

2017-09-18 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCRVLT-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16169901#comment-16169901
 ] 

Robert Munteanu commented on JCRVLT-202:


There is already one other package manager, provided by Composum - 
https://ist-software.atlassian.net/wiki/spaces/CMP/pages/46140125/Package+Manager
 . Given that, maybe it would be a good idea to provide some abstract 
install/uninstall/etc goals which require an additional dependency to work 
properly, maven-scr-plugin requires an annotations dependency.

Then this is a good entry point for the future Adobe maven plugin and can be 
reused to work with Composum as well, if the desire comes up.

> Import Adobe's content package maven plugin
> ---
>
> Key: JCRVLT-202
> URL: https://issues.apache.org/jira/browse/JCRVLT-202
> Project: Jackrabbit FileVault
>  Issue Type: Task
>  Components: package maven plugin
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
> Fix For: package-maven-plugin-1.0.0
>
>
> The content-package maven plugin is a maven plugin that simplifies the 
> creation of content package maven artifacts. The content packages can later 
> be used to install content into a JCR repository using the Apache Jackrabbit 
> FileVault packaging runtime.
> Filevault was contributed 4 years ago, but we never had a tool to create the 
> packaged during runtime. Adobe's plugin is publicly available, but only in 
> binary form. With this contribution, we want to bring the source and 
> development closer to the filevault core and to leverage the community better 
> in driving this plugin further.
> *details*
> java package space: 
> {code}
> org.apache.jackrabbit.filevault.maven.packaging
> {code}
> plugin name:
> {code}
> org.apache.jackrabbit.filevault
> package-maven-plugin
> {code}
> scm location: 
> - a) SVN: 
> https://svn.apache.org/repos/asf/jackrabbit/commons/package-maven-plugin
> - b) GIT: 
> https://git-wip-us.apache.org/repos/asf?p=jackrabbit-filevault-package-plugin.git;a=tree



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JCRVLT-203) Invalid links in the package-maven-plugin readme

2017-09-18 Thread Robert Munteanu (JIRA)

Robert Munteanu created JCRVLT-203:
--

 Summary: Invalid links in the package-maven-plugin readme
 Key: JCRVLT-203
 URL: https://issues.apache.org/jira/browse/JCRVLT-203
 Project: Jackrabbit FileVault
  Issue Type: Bug
  Components: package maven plugin
Reporter: Robert Munteanu


* https://svn.apache.org/repos/asf/commons/filevault/trunk
* https://svn.apache.org/viewvc/commons/filevault/trunk
* https://svn.apache.org/repos/asf/commons/filevault/trunk filevault




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCRVLT-202) Import Adobe's content package maven plugin

2017-09-11 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCRVLT-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160884#comment-16160884
 ] 

Robert Munteanu commented on JCRVLT-202:


A solution that would remove duplication is using 
{{org.apache.jackrabbit:filevault-package-maven-plugin}}.

> Import Adobe's content package maven plugin
> ---
>
> Key: JCRVLT-202
> URL: https://issues.apache.org/jira/browse/JCRVLT-202
> Project: Jackrabbit FileVault
>  Issue Type: Task
>  Components: package maven plugin
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
> Fix For: package-maven-plugin-1.0.0
>
>
> The content-package maven plugin is a maven plugin that simplifies the 
> creation of content package maven artifacts. The content packages can later 
> be used to install content into a JCR repository using the Apache Jackrabbit 
> FileVault packaging runtime.
> Filevault was contributed 4 years ago, but we never had a tool to create the 
> packaged during runtime. Adobe's plugin is publicly available, but only in 
> binary form. With this contribution, we want to bring the source and 
> development closer to the filevault core and to leverage the community better 
> in driving this plugin further.
> *details*
> java package space: 
> {code}
> org.apache.jackrabbit.filevault.maven.packaging
> {code}
> plugin name:
> {code}
> org.apache.jackrabbit.filevault
> package-maven-plugin
> {code}
> scm location: 
> - a) SVN: 
> https://svn.apache.org/repos/asf/jackrabbit/commons/package-maven-plugin
> - b) GIT: 
> https://git-wip-us.apache.org/repos/asf?p=jackrabbit-filevault-package-plugin.git;a=tree



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCRVLT-199) Allow mapping some nt:resource nodes to oak:Resource

2017-09-08 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCRVLT-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158272#comment-16158272
 ] 

Robert Munteanu commented on JCRVLT-199:


Yes, I think we can add a new oak-run command that performs the mapping for the 
composite setup. We can simply apply this mapping to the configured paths.

> Allow mapping some nt:resource nodes to oak:Resource
> 
>
> Key: JCRVLT-199
> URL: https://issues.apache.org/jira/browse/JCRVLT-199
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Reporter: Robert Munteanu
>
> In a composite setup we don't support referenceable nodes in mounts. Reality 
> is though that for a typical Sling-based setup there will be lots of 
> nt:resource nodes in /libs and /apps, and that's were we expect to see 
> mounts. Since nt:resource is referenceable any mount-time sanity check will 
> fail ( see OAK-6505 ) .
> Rather than force adaption of all content packages that write in /libs and 
> /apps to use oak:Resource, I would rather suggest a configuration to 
> transparently map nt:resource nodes to oak:Resource ones.
> I did not dig into the code yet but I would like to hear what others think 
> about this idea before going further. [~tripod] ?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCRVLT-199) Allow mapping some nt:resource nodes to oak:Resource

2017-09-07 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCRVLT-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16157026#comment-16157026
 ] 

Robert Munteanu commented on JCRVLT-199:


[~tripod] and myself cleared out the AEM-specific concerns related to workflows 
in an separate conversation. Howeever, Toby mentioned that it might be simpler 
to handle this in Oak altogether, maybe in a configurable way.

[~tomek.rekawek] - would it be possible to isolate this mapping in the 
oak-upgrade module and use it when we prepare the repository for a composite 
setup? This way we keep the change isolated where we need it.

> Allow mapping some nt:resource nodes to oak:Resource
> 
>
> Key: JCRVLT-199
> URL: https://issues.apache.org/jira/browse/JCRVLT-199
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Reporter: Robert Munteanu
>
> In a composite setup we don't support referenceable nodes in mounts. Reality 
> is though that for a typical Sling-based setup there will be lots of 
> nt:resource nodes in /libs and /apps, and that's were we expect to see 
> mounts. Since nt:resource is referenceable any mount-time sanity check will 
> fail ( see OAK-6505 ) .
> Rather than force adaption of all content packages that write in /libs and 
> /apps to use oak:Resource, I would rather suggest a configuration to 
> transparently map nt:resource nodes to oak:Resource ones.
> I did not dig into the code yet but I would like to hear what others think 
> about this idea before going further. [~tripod] ?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCR-4173) Unable to receive observation events when connecting via DavEx

2017-09-05 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-4173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16153525#comment-16153525
 ] 

Robert Munteanu commented on JCR-4173:
--

I can confirm that the observation events are now sent again in the Sling 
scenario. Thanks for the fix

> Unable to receive observation events when connecting via DavEx
> --
>
> Key: JCR-4173
> URL: https://issues.apache.org/jira/browse/JCR-4173
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jcr-server
>Affects Versions: 2.12.7, 2.10.6, 2.8.5, 2.6.9, 2.14.2, 2.15.5
>Reporter: Robert Munteanu
>Assignee: Julian Reschke
>  Labels: candidate_jcr_2_10, candidate_jcr_2_12, 
> candidate_jcr_2_14, candidate_jcr_2_6, candidate_jcr_2_8
> Fix For: 2.16, 2.15.6
>
> Attachments: JCR-4173.diff, OAK-6583.zip, test-jcr-4173.zip
>
>
> When connecting to an Oak repository by DavEx remoting ( via Sling ) event 
> listeners are not notified of events they are registered for.
> Tracing down the problem I saw that the returned XML for {{POLL}} calls is 
> invalid: {{1:529:-1:The prefix "jcr" for element "jcr:primaryType" is not 
> bound.}}
> The raw XML returned is 
> {noformat}
>  xmlns:dcr="http://www.day.com/jcr/webdav/1.0;>  
> xmlns:D="DAV:">http://localhost:/server/default/jcr%3aroot/123d9c7a-9b14-4cc2-8436-3c2ca04e64ac/admin1503526390002/123d9c7a-9b14-4cc2-8436-3c2ca04e64acnt:unstructured  
> xmlns:D="DAV:">http://localhost:/server/default/jcr%3aroot/123d9c7a-9b14-4cc2-8436-3c2ca04e64ac/jcr%3aprimaryTypeadmin1503526390002/123d9c7a-9b14-4cc2-8436-3c2ca04e64acnt:unstructurednt:unstructured
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JCR-4179) Test failures with Java 9 when using javax.imageio.spi.ServiceRegistry

2017-09-05 Thread Robert Munteanu (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCR-4179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated JCR-4179:
-
Fix Version/s: 2.16

> Test failures with Java 9 when using javax.imageio.spi.ServiceRegistry
> --
>
> Key: JCR-4179
> URL: https://issues.apache.org/jira/browse/JCR-4179
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jcr-client, jackrabbit-jcr-commons, 
> jackrabbit-spi-commons
>Affects Versions: 2.14.2, 2.15.5
> Environment: Java 9 b181
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: 2.16, 2.14.3, 2.15.6
>
>
> When building with Java 9 there is at least one test failure due to using 
> javax.imageio.spi.ServiceRegistry as a general-purpose service loader, which 
> is not possible anymore with Java 9:
> {noformat}
> [ERROR] Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.13 
> s <<< FAILURE! - in org.apache.jackrabbit.commons.JcrUtilsTest
> [ERROR] testGetRepository(org.apache.jackrabbit.commons.JcrUtilsTest)  Time 
> elapsed: 0.128 s  <<< ERROR!
> java.lang.IllegalArgumentException: javax.jcr.RepositoryFactory is not an 
> ImageIO SPI class
>   at 
> org.apache.jackrabbit.commons.JcrUtilsTest.testGetRepository(JcrUtilsTest.java:50){noformat}
> We should move away from this ServiceRegistry and use 
> {{java.util.ServiceLoader}} instead.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (JCR-4179) Test failures with Java 9 when using javax.imageio.spi.ServiceRegistry

2017-09-05 Thread Robert Munteanu (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCR-4179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu resolved JCR-4179.
--
Resolution: Fixed

Fixed in [r1807321|https://svn.apache.org/r1807321] for trunk, 
[r1807322|https://svn.apache.org/r1807322] for 2.14 .

> Test failures with Java 9 when using javax.imageio.spi.ServiceRegistry
> --
>
> Key: JCR-4179
> URL: https://issues.apache.org/jira/browse/JCR-4179
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jcr-client, jackrabbit-jcr-commons, 
> jackrabbit-spi-commons
>Affects Versions: 2.14.2, 2.15.5
> Environment: Java 9 b181
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>  Labels: candidate_jcr_2_14
> Fix For: 2.14.3, 2.15.6
>
>
> When building with Java 9 there is at least one test failure due to using 
> javax.imageio.spi.ServiceRegistry as a general-purpose service loader, which 
> is not possible anymore with Java 9:
> {noformat}
> [ERROR] Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.13 
> s <<< FAILURE! - in org.apache.jackrabbit.commons.JcrUtilsTest
> [ERROR] testGetRepository(org.apache.jackrabbit.commons.JcrUtilsTest)  Time 
> elapsed: 0.128 s  <<< ERROR!
> java.lang.IllegalArgumentException: javax.jcr.RepositoryFactory is not an 
> ImageIO SPI class
>   at 
> org.apache.jackrabbit.commons.JcrUtilsTest.testGetRepository(JcrUtilsTest.java:50){noformat}
> We should move away from this ServiceRegistry and use 
> {{java.util.ServiceLoader}} instead.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCR-4179) Test failures with Java 9 when using javax.imageio.spi.ServiceRegistry

2017-09-05 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-4179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16153268#comment-16153268
 ] 

Robert Munteanu commented on JCR-4179:
--

As I think it's unlikely that running on Java 9 will happen for older branches, 
I propose fixing this issue on trunk and 2.14 . If the need arises, we can 
backport to older versions as well.

> Test failures with Java 9 when using javax.imageio.spi.ServiceRegistry
> --
>
> Key: JCR-4179
> URL: https://issues.apache.org/jira/browse/JCR-4179
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jcr-client, jackrabbit-jcr-commons, 
> jackrabbit-spi-commons
>Affects Versions: 2.14.2, 2.15.5
> Environment: Java 9 b181
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>  Labels: candidate_jcr_2_14
> Fix For: 2.14.3, 2.15.6
>
>
> When building with Java 9 there is at least one test failure due to using 
> javax.imageio.spi.ServiceRegistry as a general-purpose service loader, which 
> is not possible anymore with Java 9:
> {noformat}
> [ERROR] Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.13 
> s <<< FAILURE! - in org.apache.jackrabbit.commons.JcrUtilsTest
> [ERROR] testGetRepository(org.apache.jackrabbit.commons.JcrUtilsTest)  Time 
> elapsed: 0.128 s  <<< ERROR!
> java.lang.IllegalArgumentException: javax.jcr.RepositoryFactory is not an 
> ImageIO SPI class
>   at 
> org.apache.jackrabbit.commons.JcrUtilsTest.testGetRepository(JcrUtilsTest.java:50){noformat}
> We should move away from this ServiceRegistry and use 
> {{java.util.ServiceLoader}} instead.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JCR-4179) Test failures with Java 9 when using javax.imageio.spi.ServiceRegistry

2017-09-05 Thread Robert Munteanu (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCR-4179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated JCR-4179:
-
Affects Version/s: 2.14.2

> Test failures with Java 9 when using javax.imageio.spi.ServiceRegistry
> --
>
> Key: JCR-4179
> URL: https://issues.apache.org/jira/browse/JCR-4179
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jcr-client, jackrabbit-jcr-commons, 
> jackrabbit-spi-commons
>Affects Versions: 2.14.2, 2.15.5
> Environment: Java 9 b181
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>  Labels: candidate_jcr_2_14
> Fix For: 2.14.3, 2.15.6
>
>
> When building with Java 9 there is at least one test failure due to using 
> javax.imageio.spi.ServiceRegistry as a general-purpose service loader, which 
> is not possible anymore with Java 9:
> {noformat}
> [ERROR] Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.13 
> s <<< FAILURE! - in org.apache.jackrabbit.commons.JcrUtilsTest
> [ERROR] testGetRepository(org.apache.jackrabbit.commons.JcrUtilsTest)  Time 
> elapsed: 0.128 s  <<< ERROR!
> java.lang.IllegalArgumentException: javax.jcr.RepositoryFactory is not an 
> ImageIO SPI class
>   at 
> org.apache.jackrabbit.commons.JcrUtilsTest.testGetRepository(JcrUtilsTest.java:50){noformat}
> We should move away from this ServiceRegistry and use 
> {{java.util.ServiceLoader}} instead.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JCR-4179) Test failures with Java 9 when using javax.imageio.spi.ServiceRegistry

2017-09-05 Thread Robert Munteanu (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCR-4179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated JCR-4179:
-
Fix Version/s: 2.14.3

> Test failures with Java 9 when using javax.imageio.spi.ServiceRegistry
> --
>
> Key: JCR-4179
> URL: https://issues.apache.org/jira/browse/JCR-4179
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jcr-client, jackrabbit-jcr-commons, 
> jackrabbit-spi-commons
>Affects Versions: 2.14.2, 2.15.5
> Environment: Java 9 b181
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>  Labels: candidate_jcr_2_14
> Fix For: 2.14.3, 2.15.6
>
>
> When building with Java 9 there is at least one test failure due to using 
> javax.imageio.spi.ServiceRegistry as a general-purpose service loader, which 
> is not possible anymore with Java 9:
> {noformat}
> [ERROR] Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.13 
> s <<< FAILURE! - in org.apache.jackrabbit.commons.JcrUtilsTest
> [ERROR] testGetRepository(org.apache.jackrabbit.commons.JcrUtilsTest)  Time 
> elapsed: 0.128 s  <<< ERROR!
> java.lang.IllegalArgumentException: javax.jcr.RepositoryFactory is not an 
> ImageIO SPI class
>   at 
> org.apache.jackrabbit.commons.JcrUtilsTest.testGetRepository(JcrUtilsTest.java:50){noformat}
> We should move away from this ServiceRegistry and use 
> {{java.util.ServiceLoader}} instead.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JCR-4179) Test failures with Java 9 when using javax.imageio.spi.ServiceRegistry

2017-09-05 Thread Robert Munteanu (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCR-4179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated JCR-4179:
-
Labels: candidate_jcr_2_14  (was: )

> Test failures with Java 9 when using javax.imageio.spi.ServiceRegistry
> --
>
> Key: JCR-4179
> URL: https://issues.apache.org/jira/browse/JCR-4179
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jcr-client, jackrabbit-jcr-commons, 
> jackrabbit-spi-commons
>Affects Versions: 2.15.5
> Environment: Java 9 b181
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>  Labels: candidate_jcr_2_14
> Fix For: 2.15.6
>
>
> When building with Java 9 there is at least one test failure due to using 
> javax.imageio.spi.ServiceRegistry as a general-purpose service loader, which 
> is not possible anymore with Java 9:
> {noformat}
> [ERROR] Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.13 
> s <<< FAILURE! - in org.apache.jackrabbit.commons.JcrUtilsTest
> [ERROR] testGetRepository(org.apache.jackrabbit.commons.JcrUtilsTest)  Time 
> elapsed: 0.128 s  <<< ERROR!
> java.lang.IllegalArgumentException: javax.jcr.RepositoryFactory is not an 
> ImageIO SPI class
>   at 
> org.apache.jackrabbit.commons.JcrUtilsTest.testGetRepository(JcrUtilsTest.java:50){noformat}
> We should move away from this ServiceRegistry and use 
> {{java.util.ServiceLoader}} instead.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JCR-4179) Test failures with Java 9 when using javax.imageio.spi.ServiceRegistry

2017-09-05 Thread Robert Munteanu (JIRA)

Robert Munteanu created JCR-4179:


 Summary: Test failures with Java 9 when using 
javax.imageio.spi.ServiceRegistry
 Key: JCR-4179
 URL: https://issues.apache.org/jira/browse/JCR-4179
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-jcr-client, jackrabbit-jcr-commons, 
jackrabbit-spi-commons
Affects Versions: 2.15.5
 Environment: Java 9 b181
Reporter: Robert Munteanu
Assignee: Robert Munteanu
 Fix For: 2.15.6


When building with Java 9 there is at least one test failure due to using 
javax.imageio.spi.ServiceRegistry as a general-purpose service loader, which is 
not possible anymore with Java 9:

{noformat}
[ERROR] Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.13 s 
<<< FAILURE! - in org.apache.jackrabbit.commons.JcrUtilsTest
[ERROR] testGetRepository(org.apache.jackrabbit.commons.JcrUtilsTest)  Time 
elapsed: 0.128 s  <<< ERROR!
java.lang.IllegalArgumentException: javax.jcr.RepositoryFactory is not an 
ImageIO SPI class
at 
org.apache.jackrabbit.commons.JcrUtilsTest.testGetRepository(JcrUtilsTest.java:50){noformat}

We should move away from this ServiceRegistry and use 
{{java.util.ServiceLoader}} instead.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCR-4173) Unable to receive observation events when connecting via DavEx

2017-08-24 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-4173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16139677#comment-16139677
 ] 

Robert Munteanu commented on JCR-4173:
--

Next week is absolutely fine.

> Unable to receive observation events when connecting via DavEx
> --
>
> Key: JCR-4173
> URL: https://issues.apache.org/jira/browse/JCR-4173
> Project: Jackrabbit Content Repository
>  Issue Type: Test
>Reporter: Robert Munteanu
>Assignee: Julian Reschke
> Attachments: OAK-6583.zip
>
>
> When connecting to an Oak repository by DavEx remoting ( via Sling ) event 
> listeners are not notified of events they are registered for.
> Tracing down the problem I saw that the returned XML for {{POLL}} calls is 
> invalid: {{1:529:-1:The prefix "jcr" for element "jcr:primaryType" is not 
> bound.}}
> The raw XML returned is 
> {noformat}
>  xmlns:dcr="http://www.day.com/jcr/webdav/1.0;>  
> xmlns:D="DAV:">http://localhost:/server/default/jcr%3aroot/123d9c7a-9b14-4cc2-8436-3c2ca04e64ac/admin1503526390002/123d9c7a-9b14-4cc2-8436-3c2ca04e64acnt:unstructured  
> xmlns:D="DAV:">http://localhost:/server/default/jcr%3aroot/123d9c7a-9b14-4cc2-8436-3c2ca04e64ac/jcr%3aprimaryTypeadmin1503526390002/123d9c7a-9b14-4cc2-8436-3c2ca04e64acnt:unstructurednt:unstructured
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCRVLT-199) Allow mapping some nt:resource nodes to oak:Resource

2017-08-01 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCRVLT-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16109041#comment-16109041
 ] 

Robert Munteanu commented on JCRVLT-199:


{quote}i think the mount could be used for other things, like storing the 
versions in a different persistence layer. then you also will have to deal with 
similar problems. {quote}

Maybe, but not for the foreseeable future ... we want /libs and /apps to be 
static and locked down.

{quote}in any case, i'm more worried about the consumers of a mounted space, 
when the nodes are no longer nt:resource. or the workflows no longer version 
able. {quote}

oak:Resource was designed for such a scenario and should be a drop-in 
replacement - see OAK-4567 . As for workflows and other resources, we will use 
the following model:

* /libs for application - e.g. AEM
* /apps for integrations
* /conf for runtime changes/modifications

So any change to an OOTB workflow which is found in /libs will be reflected in 
/conf.

> Allow mapping some nt:resource nodes to oak:Resource
> 
>
> Key: JCRVLT-199
> URL: https://issues.apache.org/jira/browse/JCRVLT-199
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Reporter: Robert Munteanu
>
> In a composite setup we don't support referenceable nodes in mounts. Reality 
> is though that for a typical Sling-based setup there will be lots of 
> nt:resource nodes in /libs and /apps, and that's were we expect to see 
> mounts. Since nt:resource is referenceable any mount-time sanity check will 
> fail ( see OAK-6505 ) .
> Rather than force adaption of all content packages that write in /libs and 
> /apps to use oak:Resource, I would rather suggest a configuration to 
> transparently map nt:resource nodes to oak:Resource ones.
> I did not dig into the code yet but I would like to hear what others think 
> about this idea before going further. [~tripod] ?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCRVLT-199) Allow mapping some nt:resource nodes to oak:Resource

2017-08-01 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCRVLT-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16109036#comment-16109036
 ] 

Robert Munteanu commented on JCRVLT-199:


Yes, we can ignore it. The reason we decide against is is that we have a node 
that is referenceable, has a jcr:uuid property, but it will not be found by 
using {{Session#getNodeByIdentifier}} . I am not sure about queries, but if 
they delegate to the unique uuid index that won't work either. 

So ignoring is also accepting some broken behaviour, which is why I'm looking 
for a way to remove referenceable nodes with as little change to the consumers 
as possible.

> Allow mapping some nt:resource nodes to oak:Resource
> 
>
> Key: JCRVLT-199
> URL: https://issues.apache.org/jira/browse/JCRVLT-199
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Reporter: Robert Munteanu
>
> In a composite setup we don't support referenceable nodes in mounts. Reality 
> is though that for a typical Sling-based setup there will be lots of 
> nt:resource nodes in /libs and /apps, and that's were we expect to see 
> mounts. Since nt:resource is referenceable any mount-time sanity check will 
> fail ( see OAK-6505 ) .
> Rather than force adaption of all content packages that write in /libs and 
> /apps to use oak:Resource, I would rather suggest a configuration to 
> transparently map nt:resource nodes to oak:Resource ones.
> I did not dig into the code yet but I would like to hear what others think 
> about this idea before going further. [~tripod] ?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCRVLT-199) Allow mapping some nt:resource nodes to oak:Resource

2017-08-01 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCRVLT-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16109003#comment-16109003
 ] 

Robert Munteanu commented on JCRVLT-199:


We don't allow writing under a mount right now so there will be no way to 
create references at runtime. However, we can't control what happens at mount 
time, when the composite node store is assembled. Thus the idea of validating 
references at mount time. We do the same for versionable nodes, only the 
problem there is less tricky, as we don't usually find versionable nodes there.

How do you see other consumers of the JCR API being impacted by this change?

> Allow mapping some nt:resource nodes to oak:Resource
> 
>
> Key: JCRVLT-199
> URL: https://issues.apache.org/jira/browse/JCRVLT-199
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Reporter: Robert Munteanu
>
> In a composite setup we don't support referenceable nodes in mounts. Reality 
> is though that for a typical Sling-based setup there will be lots of 
> nt:resource nodes in /libs and /apps, and that's were we expect to see 
> mounts. Since nt:resource is referenceable any mount-time sanity check will 
> fail ( see OAK-6505 ) .
> Rather than force adaption of all content packages that write in /libs and 
> /apps to use oak:Resource, I would rather suggest a configuration to 
> transparently map nt:resource nodes to oak:Resource ones.
> I did not dig into the code yet but I would like to hear what others think 
> about this idea before going further. [~tripod] ?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JCRVLT-199) Allow mapping some nt:resource nodes to oak:Resource

2017-08-01 Thread Robert Munteanu (JIRA)

Robert Munteanu created JCRVLT-199:
--

 Summary: Allow mapping some nt:resource nodes to oak:Resource
 Key: JCRVLT-199
 URL: https://issues.apache.org/jira/browse/JCRVLT-199
 Project: Jackrabbit FileVault
  Issue Type: Improvement
  Components: Packaging
Reporter: Robert Munteanu


In a composite setup we don't support referenceable nodes in mounts. Reality is 
though that for a typical Sling-based setup there will be lots of nt:resource 
nodes in /libs and /apps, and that's were we expect to see mounts. Since 
nt:resource is referenceable any mount-time sanity check will fail ( see 
OAK-6505 ) .

Rather than force adaption of all content packages that write in /libs and 
/apps to use oak:Resource, I would rather suggest a configuration to 
transparently map nt:resource nodes to oak:Resource ones.

I did not dig into the code yet but I would like to hear what others think 
about this idea before going further. [~tripod] ?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JCRVLT-184) vlt shell script prints out error when using openjdk

2017-06-26 Thread Robert Munteanu (JIRA)

Robert Munteanu created JCRVLT-184:
--

 Summary: vlt shell script prints out error when using openjdk
 Key: JCRVLT-184
 URL: https://issues.apache.org/jira/browse/JCRVLT-184
 Project: Jackrabbit FileVault
  Issue Type: Bug
Affects Versions: 3.1.40
Reporter: Robert Munteanu
Priority: Minor


{noformat}$ vlt --version
/usr/bin/vlt: line 141: [: openjdk version "1.8.0_131": integer expression 
expected
Jackrabbit FileVault [version 3.1.40] Copyright 2013 by Apache Software 
Foundation. See LICENSE.txt for more information.{noformat}

{noformat}$ java -version
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (IcedTea 3.4.0) (suse-1.1-x86_64)
OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode){noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCRVLT-61) Allow AccessControllHandling be defined per filter root

2015-11-13 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCRVLT-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15003837#comment-15003837
 ] 

Robert Munteanu commented on JCRVLT-61:
---

A solution that comes into mind is to establish an absolute ordering for the 
packages. This can for instance be a numeric value - ranking - attached to a 
package, and the packages are processed in natural order of their rankings - 
smaller values first. This will at least make the processing consistent.

Absolute ordering is not without pitfalls - e.g. what happens when two packages 
have the same ranking? Or what happens when you want to process your entries 
between package A ( ranking = 1 ) and package B (ranking = 2 )? So this needs 
more thought.

I have considered relative ordering ( package A installed after package B ) but 
I think this is not going to be maintainable in the long run - packages come 
and go, are refactored, etc. Also, ordering at the ACE level will not be 
maintainable either as there are simply too many entries to consider.

Another thought is to separate ACE setup into phases:

- system
- application
- demo

etc

Each package could declare ACEs as belonging to a phase, which allows more 
fine-grained control over what gets setup when. It's basically a rehash of the 
absolute ordering idea, with predefined phases and allowing a package to 
contribute to more phases. It has the advantage of being more intuitive, but 
less flexible if you need more phases than what we allow.

> Allow AccessControllHandling be defined per filter root
> ---
>
> Key: JCRVLT-61
> URL: https://issues.apache.org/jira/browse/JCRVLT-61
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Reporter: Tobias Bocanegra
>
> the current packaging only allows to specify the AccessControllHandling per 
> package. if one requires different behaviors for different content trees, the 
> only workaround today is to create sub-packages.
> it would be nice if the ac-control handling can be defined by workspace 
> filter root, similar to the iImportMode - or even tie the 
> AccessControllHandling to the ImportMode. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCRVLT-61) Allow AccessControllHandling be defined per filter root

2015-11-12 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCRVLT-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15003355#comment-15003355
 ] 

Robert Munteanu commented on JCRVLT-61:
---

As far as declarative syntax goes, I prefer what puppet does with ensure. 
Instead of telling vlt what to do, we tell it the expected state. For instance, 
in your example of

{noformat}
# ensure that user1 has only read access. remove existing ACL
begin ACL on /content/update
  remove jcr:all for user1
  add allow jcr:read for user1
end
{noformat}

What happens if user1 already has {{jcr:read}} and {{rep:write}} on 
/content/update? Asking to remove {{jcr:all}} may be interpreted as either

- remove {{jcr:all}}, if present
- remove any privilege, if present

One possibility to clarify is to use '*' instead of {{jcr:all}

{noformat}
# ensure that user1 has only read access. remove existing ACL
begin ACL on /content/update
  remove * for user1
  add allow jcr:read for user1
end
{noformat}

Another is to use an ensure-style syntax

{noformat}
# ensure that user1 has only read access. remove existing ACL
begin ACL on /content/update
  ensure user1 has only jcr:read
end
{noformat}

With the variations

* {{ensure has}} - equivalent to add
* {{ensure does not have}} - equivalent to remove

Of course, we can have a less verbose syntax, just trying to make a point about 
the language being more declarative

> Allow AccessControllHandling be defined per filter root
> ---
>
> Key: JCRVLT-61
> URL: https://issues.apache.org/jira/browse/JCRVLT-61
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Reporter: Tobias Bocanegra
>
> the current packaging only allows to specify the AccessControllHandling per 
> package. if one requires different behaviors for different content trees, the 
> only workaround today is to create sub-packages.
> it would be nice if the ac-control handling can be defined by workspace 
> filter root, similar to the iImportMode - or even tie the 
> AccessControllHandling to the ImportMode. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCR-3904) Retrieving the data without using jackrabbit from database

2015-08-31 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-3904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14723057#comment-14723057
 ] 

Robert Munteanu commented on JCR-3904:
--

This looks a lot like a support request, and not an actual bug. Please write an 
email to us...@jackrabbit.apache.org

> Retrieving the data without using jackrabbit from database
> --
>
> Key: JCR-3904
> URL: https://issues.apache.org/jira/browse/JCR-3904
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-webapp
>Affects Versions: 2.6.4
> Environment: oracle, linux, glassfish-3.1.2, 
> jackrabbbit-webapp-2.6.4, CXF webservice.
>Reporter: murali
>Priority: Blocker
>  Labels: apache, conte, jackrabbit, jackrabbit-core,
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Hi,
> I have integrated the jackarabbbit webapp 2.6.4 with oracle database.
> whenever we upload any document storing BLOB format in database. 
> I need to retrieve the data from database with out using jack rabbit web app.
> Can anyone provide the solution for that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCR-3872) Config DTD does not declare ProtectedItemImporter elements

2015-04-21 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-3872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14504926#comment-14504926
 ] 

Robert Munteanu commented on JCR-3872:
--

Thanks for the quick turnaround. Would it be possible to also update 
http://jackrabbit.apache.org/dtd/ ?

 Config DTD does not declare ProtectedItemImporter elements
 --

 Key: JCR-3872
 URL: https://issues.apache.org/jira/browse/JCR-3872
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Affects Versions: 2.4.5, 2.6.4, 2.8, 2.10
Reporter: Robert Munteanu
Assignee: Marcel Reutegger
Priority: Minor
 Fix For: 2.10.1

 Attachments: JCR-3872-1.patch


 JCR-3671 updated the DTD to allow Import/ProtectedItemImporter children , but 
 missed to declare the ProtectedItemImporter children as valid. This causes 
 validation errors when using the DTD.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCR-3872) Config DTD does not declare ProtectedItemImporter elements

2015-04-21 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-3872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14505040#comment-14505040
 ] 

Robert Munteanu commented on JCR-3872:
--

Thanks!

 Config DTD does not declare ProtectedItemImporter elements
 --

 Key: JCR-3872
 URL: https://issues.apache.org/jira/browse/JCR-3872
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Affects Versions: 2.4.5, 2.6.4, 2.8, 2.10
Reporter: Robert Munteanu
Assignee: Marcel Reutegger
Priority: Minor
 Fix For: 2.10.1

 Attachments: JCR-3872-1.patch


 JCR-3671 updated the DTD to allow Import/ProtectedItemImporter children , but 
 missed to declare the ProtectedItemImporter children as valid. This causes 
 validation errors when using the DTD.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JCR-3872) Config DTD does not declare ProtectedItemImporter elements

2015-04-21 Thread Robert Munteanu (JIRA)

Robert Munteanu created JCR-3872:


 Summary: Config DTD does not declare ProtectedItemImporter elements
 Key: JCR-3872
 URL: https://issues.apache.org/jira/browse/JCR-3872
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Affects Versions: 2.10.1
Reporter: Robert Munteanu
Priority: Minor


JCR-3671 updated the DTD to allow Import/ProtectedItemImporter children , but 
missed to declare the ProtectedItemImporter children as valid. This causes 
validation errors when using the DTD.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JCR-3872) Config DTD does not declare ProtectedItemImporter elements

2015-04-21 Thread Robert Munteanu (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCR-3872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated JCR-3872:
-
Attachment: JCR-3872-1.patch

 Config DTD does not declare ProtectedItemImporter elements
 --

 Key: JCR-3872
 URL: https://issues.apache.org/jira/browse/JCR-3872
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Affects Versions: 2.10.1
Reporter: Robert Munteanu
Priority: Minor
 Attachments: JCR-3872-1.patch


 JCR-3671 updated the DTD to allow Import/ProtectedItemImporter children , but 
 missed to declare the ProtectedItemImporter children as valid. This causes 
 validation errors when using the DTD.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JCR-3872) Config DTD does not declare ProtectedItemImporter elements

2015-04-21 Thread Robert Munteanu (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCR-3872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated JCR-3872:
-
Status: Patch Available  (was: Open)

 Config DTD does not declare ProtectedItemImporter elements
 --

 Key: JCR-3872
 URL: https://issues.apache.org/jira/browse/JCR-3872
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Affects Versions: 2.10.1
Reporter: Robert Munteanu
Priority: Minor
 Attachments: JCR-3872-1.patch


 JCR-3671 updated the DTD to allow Import/ProtectedItemImporter children , but 
 missed to declare the ProtectedItemImporter children as valid. This causes 
 validation errors when using the DTD.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCRSITE-47) Site is completely broken

2014-11-07 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCRSITE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14201841#comment-14201841
 ] 

Robert Munteanu commented on JCRSITE-47:


FWIW the problem persists over https - https://jackrabbit.apache.org/ is broken 
in the same way

 Site is completely broken
 -

 Key: JCRSITE-47
 URL: https://issues.apache.org/jira/browse/JCRSITE-47
 Project: Jackrabbit Site
  Issue Type: Bug
  Components: site
Reporter: Rick Herrick
Priority: Blocker
 Attachments: Screen Shot 2014-11-05 at 7.27.14 AM.png


 The [Jackrabbit site|http://jackrabbit.apache.org] is completely broken and 
 unusable. It has been for at least a couple of days. We're trying to decide 
 if we should be using Jackrabbit as a back-end storage system. Does this 
 indicate we shouldn't be using Jackrabbit as it's not being maintained? 
 Should we be looking to Oak instead?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCRSITE-47) Site is completely broken

2014-11-07 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCRSITE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14201889#comment-14201889
 ] 

Robert Munteanu commented on JCRSITE-47:


You're right, works for me as well now.

 Site is completely broken
 -

 Key: JCRSITE-47
 URL: https://issues.apache.org/jira/browse/JCRSITE-47
 Project: Jackrabbit Site
  Issue Type: Bug
  Components: site
Reporter: Rick Herrick
Priority: Blocker
 Attachments: Screen Shot 2014-11-05 at 7.27.14 AM.png


 The [Jackrabbit site|http://jackrabbit.apache.org] is completely broken and 
 unusable. It has been for at least a couple of days. We're trying to decide 
 if we should be using Jackrabbit as a back-end storage system. Does this 
 indicate we shouldn't be using Jackrabbit as it's not being maintained? 
 Should we be looking to Oak instead?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCRSITE-46) Pages use mixed content

2014-09-04 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCRSITE-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121269#comment-14121269
 ] 

Robert Munteanu commented on JCRSITE-46:


Dupe of JCRSITE-43?

 Pages use mixed content
 ---

 Key: JCRSITE-46
 URL: https://issues.apache.org/jira/browse/JCRSITE-46
 Project: Jackrabbit Site
  Issue Type: Bug
  Components: site
Reporter: Grégoire Paris
Priority: Minor

 On a page that uses https, all referenced content should use https too. [See 
 here 
 why|https://support.mozilla.org/en-US/kb/how-does-content-isnt-secure-affect-my-safety].
  On firefox, http content is blocked on secure pages, and the site is ugly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JCRVLT-57) Update maven-scr-plugin to 1.19.0 to allow building with Java 8

2014-08-20 Thread Robert Munteanu (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCRVLT-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated JCRVLT-57:
--

Status: Patch Available  (was: Open)

 Update maven-scr-plugin to 1.19.0 to allow building with Java 8
 ---

 Key: JCRVLT-57
 URL: https://issues.apache.org/jira/browse/JCRVLT-57
 Project: Jackrabbit FileVault
  Issue Type: Improvement
Affects Versions: 3.1.6
Reporter: Robert Munteanu
Priority: Minor

 When building with Java 8 the execution hangs when invoking the 
 maven-scr-plugin ( version 1.14.0 ) . Upgrading to the latest version - 
 1.19.0 - makes the build succeed.
 {code}
 diff --git a/parent/pom.xml b/parent/pom.xml
 index 00e2e7d..f244b0b 100644
 --- a/parent/pom.xml
 +++ b/parent/pom.xml
 @@ -105,7 +105,7 @@
  plugin
  groupIdorg.apache.felix/groupId
  artifactIdmaven-scr-plugin/artifactId
 -version1.14.0/version
 +version1.19.0/version
  executions
  execution
  idgenerate-scr-scrdescriptor/id
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (JCRVLT-55) vlt st should notify the user executed in a directory not under vault control

2014-08-11 Thread Robert Munteanu (JIRA)

Robert Munteanu created JCRVLT-55:
-

 Summary: vlt st should notify the user executed in a directory not 
under vault control
 Key: JCRVLT-55
 URL: https://issues.apache.org/jira/browse/JCRVLT-55
 Project: Jackrabbit FileVault
  Issue Type: Bug
Affects Versions: 3.1.6
Reporter: Robert Munteanu
Priority: Critical


See the following sequence of commands:

{noformat}
$ vlt st
$ vlt up
[ERROR] update: org.apache.jackrabbit.vault.vlt.VltException: Directory is not 
under vault control.
{noformat}

I would've expected the vlt st command to return the same error, or at least a 
warning




--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (JCRVLT-52) Set maven-compiler-plugin target/source version to 1.6

2014-07-03 Thread Robert Munteanu (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCRVLT-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated JCRVLT-52:
--

Attachment: JCRVLT-52-1.diff

 Set maven-compiler-plugin target/source version to 1.6
 --

 Key: JCRVLT-52
 URL: https://issues.apache.org/jira/browse/JCRVLT-52
 Project: Jackrabbit FileVault
  Issue Type: Task
Affects Versions: 3.1.2
Reporter: Robert Munteanu
 Attachments: JCRVLT-52-1.diff


 The parent pom sets the maven-compiler-plugin version source/target version 
 to 1.5. However, Java 6 specific methods are already used, such as 
 * String#isEmpty
 * IOException(String, Exception)
 * TreeMap.firstEntry
 The source/target versions should be set to 1.6 .



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (JCRVLT-52) Set maven-compiler-plugin target/source version to 1.6

2014-07-03 Thread Robert Munteanu (JIRA)

Robert Munteanu created JCRVLT-52:
-

 Summary: Set maven-compiler-plugin target/source version to 1.6
 Key: JCRVLT-52
 URL: https://issues.apache.org/jira/browse/JCRVLT-52
 Project: Jackrabbit FileVault
  Issue Type: Task
Affects Versions: 3.1.2
Reporter: Robert Munteanu
 Attachments: JCRVLT-52-1.diff

The parent pom sets the maven-compiler-plugin version source/target version to 
1.5. However, Java 6 specific methods are already used, such as 

* String#isEmpty
* IOException(String, Exception)
* TreeMap.firstEntry

The source/target versions should be set to 1.6 .



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (JCRVLT-52) Set maven-compiler-plugin target/source version to 1.6

2014-07-03 Thread Robert Munteanu (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCRVLT-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated JCRVLT-52:
--

Status: Patch Available  (was: Open)

 Set maven-compiler-plugin target/source version to 1.6
 --

 Key: JCRVLT-52
 URL: https://issues.apache.org/jira/browse/JCRVLT-52
 Project: Jackrabbit FileVault
  Issue Type: Task
Affects Versions: 3.1.2
Reporter: Robert Munteanu
 Attachments: JCRVLT-52-1.diff


 The parent pom sets the maven-compiler-plugin version source/target version 
 to 1.5. However, Java 6 specific methods are already used, such as 
 * String#isEmpty
 * IOException(String, Exception)
 * TreeMap.firstEntry
 The source/target versions should be set to 1.6 .



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (JCR-3745) Add JackrabbitObservationManager with additional methods for registering event listeners

2014-03-13 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-3745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933138#comment-13933138
 ] 

Robert Munteanu commented on JCR-3745:
--

The suggested method to be added has the signature

{code:java}
void addEventListener(EventListener listener, JackrabbitEventFilter filter) 
throws RepositoryException;
{code}

Won't that cause issues when the ObservationManager will be updated to the JCR 
2.1 API? That interface will have new method: 

{code:java}
void addEventListener(EventListener listener, EventFilter filter) throws 
RepositoryException;
{code}

And we'll basically narrow down the type accepted by the interface, which is an 
incompatible change AFAICT.

 Add JackrabbitObservationManager with additional methods for registering 
 event listeners
 

 Key: JCR-3745
 URL: https://issues.apache.org/jira/browse/JCR-3745
 Project: Jackrabbit Content Repository
  Issue Type: New Feature
  Components: jackrabbit-api
Reporter: Michael Dürig
Assignee: Michael Dürig
 Attachments: JCR-3745.patch


 I'd like to add an additional method for adding event listeners to the 
 Jackrabbit API: 
 void addEventListener(EventListener listener, int eventTypes, String[] 
 absPaths, boolean isDeep, String[] uuid, String[] nodeTypeName, boolean 
 noLocal, boolean noExternal) throws RepositoryException; 
 Compared to the JCR method of the same name, this method takes an array of 
 absPath and additional boolean argument: 
 Only events whose associated parent node is at one of the paths in 
 codeabsPaths/code (or within its subgraph, if codeisDeep/code is 
 codetrue/code) will be received. 
 and 
 Additionally, if codenoExternal/code is codetrue/code, then events 
 from external cluster nodes are ignored. Otherwise, they are not ignored.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (JCR-3745) Add JackrabbitObservationManager with additional methods for registering event listeners

2014-03-13 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-3745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933198#comment-13933198
 ] 

Robert Munteanu commented on JCR-3745:
--

{quote}should the extended functionality go into 
ObservationManager.addEventListener() or only be available in 
JackrabbitObservationManager.addEventListener() once JCR 2.1 is out?{quote}

IMO it should, since we can deprecate the JackrabbitObservationManager at that 
time and evolve only by extending the JackrabbitEventListener, potentially 
pushing changes into future versions of the JCR API easily.

It's also what I would expect as an API consumer.

 Add JackrabbitObservationManager with additional methods for registering 
 event listeners
 

 Key: JCR-3745
 URL: https://issues.apache.org/jira/browse/JCR-3745
 Project: Jackrabbit Content Repository
  Issue Type: New Feature
  Components: jackrabbit-api
Reporter: Michael Dürig
Assignee: Michael Dürig
 Attachments: JCR-3745.patch


 I'd like to add an additional method for adding event listeners to the 
 Jackrabbit API: 
 void addEventListener(EventListener listener, int eventTypes, String[] 
 absPaths, boolean isDeep, String[] uuid, String[] nodeTypeName, boolean 
 noLocal, boolean noExternal) throws RepositoryException; 
 Compared to the JCR method of the same name, this method takes an array of 
 absPath and additional boolean argument: 
 Only events whose associated parent node is at one of the paths in 
 codeabsPaths/code (or within its subgraph, if codeisDeep/code is 
 codetrue/code) will be received. 
 and 
 Additionally, if codenoExternal/code is codetrue/code, then events 
 from external cluster nodes are ignored. Otherwise, they are not ignored.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (JCR-3745) Add JackrabbitObservationManager with additional methods for registering event listeners

2014-03-12 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-3745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932312#comment-13932312
 ] 

Robert Munteanu commented on JCR-3745:
--

As a suggestion, would it be possible to model this new API after the ones 
which would be introduced by JSR-333? That would look something like

{code:java}
public interface JackrabbitEventFilter extends 
javax.jcr.observation.EventFilter {
  void setAdditionalAbsPaths(String[] absPaths);
  String[] getAdditionalAbsPaths();
  void setNoExternal(boolean noExternal);
  boolean getNoExternal();
}
{code}

{code:java}
public class ObservationManagerImpl implements ObservationManager, 
EventStateCollectionFactory {
   // skipping existing code
  public JackrabbitEventFilter createEventFilter();
  /** Knows how to handle instances of JackrabbitEventFilter in addition to the 
spec-compliant behaviour */
  public void addEventListener(EventListener listener, EventFilter filter) 
throws RepositoryException;
}
{code}

The advantage would be that it minimizes the discrepancies with the proposed 
JSR-333 API and that it is a bit more future-proof, in case we decide to 
introduce additional fields to the EventFilter.

 Add JackrabbitObservationManager with additional methods for registering 
 event listeners
 

 Key: JCR-3745
 URL: https://issues.apache.org/jira/browse/JCR-3745
 Project: Jackrabbit Content Repository
  Issue Type: New Feature
  Components: jackrabbit-api
Reporter: Michael Dürig
Assignee: Michael Dürig

 I'd like to add an additional method for adding event listeners to the 
 Jackrabbit API: 
 void addEventListener(EventListener listener, int eventTypes, String[] 
 absPaths, boolean isDeep, String[] uuid, String[] nodeTypeName, boolean 
 noLocal, boolean noExternal) throws RepositoryException; 
 Compared to the JCR method of the same name, this method takes an array of 
 absPath and additional boolean argument: 
 Only events whose associated parent node is at one of the paths in 
 codeabsPaths/code (or within its subgraph, if codeisDeep/code is 
 codetrue/code) will be received. 
 and 
 Additionally, if codenoExternal/code is codetrue/code, then events 
 from external cluster nodes are ignored. Otherwise, they are not ignored.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (JCR-3745) Add JackrabbitObservationManager with additional methods for registering event listeners

2014-03-12 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-3745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932542#comment-13932542
 ] 

Robert Munteanu commented on JCR-3745:
--

Hm, good point. I'm not sure if it's possible to just 'inline' the JSR-333 API 
in the JackrabbitEventFilter and then when JSR-333 is out retrofit it to 
implement the interface. It would definitely work for new clients, but I'm 
concerned about clients migrating from the pre-JSR-333 API to the new one...

 Add JackrabbitObservationManager with additional methods for registering 
 event listeners
 

 Key: JCR-3745
 URL: https://issues.apache.org/jira/browse/JCR-3745
 Project: Jackrabbit Content Repository
  Issue Type: New Feature
  Components: jackrabbit-api
Reporter: Michael Dürig
Assignee: Michael Dürig

 I'd like to add an additional method for adding event listeners to the 
 Jackrabbit API: 
 void addEventListener(EventListener listener, int eventTypes, String[] 
 absPaths, boolean isDeep, String[] uuid, String[] nodeTypeName, boolean 
 noLocal, boolean noExternal) throws RepositoryException; 
 Compared to the JCR method of the same name, this method takes an array of 
 absPath and additional boolean argument: 
 Only events whose associated parent node is at one of the paths in 
 codeabsPaths/code (or within its subgraph, if codeisDeep/code is 
 codetrue/code) will be received. 
 and 
 Additionally, if codenoExternal/code is codetrue/code, then events 
 from external cluster nodes are ignored. Otherwise, they are not ignored.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (JCRSITE-43) jackrabbit.apache.org loads HTTP resources when accessed over HTTPS

2014-02-11 Thread Robert Munteanu (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCRSITE-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated JCRSITE-43:
---

Attachment: jackrabbit.apache.org-accessed-over-https.png

 jackrabbit.apache.org loads HTTP resources when accessed over HTTPS
 ---

 Key: JCRSITE-43
 URL: https://issues.apache.org/jira/browse/JCRSITE-43
 Project: Jackrabbit Site
  Issue Type: Bug
  Components: site
Reporter: Robert Munteanu
 Attachments: jackrabbit.apache.org-accessed-over-https.png


 When accessing https://jackrabbit.apache.org/ some resources ( style sheets, 
 image files ) are loaded over HTTP. Recent versions of Firefox block loading 
 of active content in such a scenario, and as a result the layout is broken.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (JCRSITE-43) jackrabbit.apache.org loads HTTP resources when accessed over HTTPS

2014-02-11 Thread Robert Munteanu (JIRA)

Robert Munteanu created JCRSITE-43:
--

 Summary: jackrabbit.apache.org loads HTTP resources when accessed 
over HTTPS
 Key: JCRSITE-43
 URL: https://issues.apache.org/jira/browse/JCRSITE-43
 Project: Jackrabbit Site
  Issue Type: Bug
  Components: site
Reporter: Robert Munteanu
 Attachments: jackrabbit.apache.org-accessed-over-https.png

When accessing https://jackrabbit.apache.org/ some resources ( style sheets, 
image files ) are loaded over HTTP. Recent versions of Firefox block loading of 
active content in such a scenario, and as a result the layout is broken.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (JCR-3680) Add entries for jcr:title and jcr:description to JcrConstants

2013-10-21 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-3680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800441#comment-13800441
 ] 

Robert Munteanu commented on JCR-3680:
--

I'm using the items names in Apache Sling, and I know for a fact that the jcr 
namespace will always be available under the {{jcr}} prefix. Additionally, I'm 
using the Sling resource API and I don't have a way of using properties in 
expanded form.

 Add entries for jcr:title and jcr:description to JcrConstants
 -

 Key: JCR-3680
 URL: https://issues.apache.org/jira/browse/JCR-3680
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
  Components: jackrabbit-jcr-commons
Reporter: Robert Munteanu
Priority: Trivial
 Attachments: JCR-3680-1.patch


 As a central location for item names defined in the JCR spec, it would be 
 useful to have jcr:title and jcr:content included in JcrConstants.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (JCR-3680) Add entries for jcr:title and jcr:description to JcrConstants

2013-10-15 Thread Robert Munteanu (JIRA)

Robert Munteanu created JCR-3680:


 Summary: Add entries for jcr:title and jcr:description to 
JcrConstants
 Key: JCR-3680
 URL: https://issues.apache.org/jira/browse/JCR-3680
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
  Components: jackrabbit-jcr-commons
Reporter: Robert Munteanu
Priority: Trivial


As a central location for item names defined in the JCR spec, it would be 
useful to have jcr:title and jcr:content included in JcrConstants.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (JCR-3680) Add entries for jcr:title and jcr:description to JcrConstants

2013-10-15 Thread Robert Munteanu (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCR-3680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated JCR-3680:
-

Status: Patch Available  (was: Open)

 Add entries for jcr:title and jcr:description to JcrConstants
 -

 Key: JCR-3680
 URL: https://issues.apache.org/jira/browse/JCR-3680
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
  Components: jackrabbit-jcr-commons
Reporter: Robert Munteanu
Priority: Trivial
 Attachments: JCR-3680-1.patch


 As a central location for item names defined in the JCR spec, it would be 
 useful to have jcr:title and jcr:content included in JcrConstants.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (JCR-3680) Add entries for jcr:title and jcr:description to JcrConstants

2013-10-15 Thread Robert Munteanu (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCR-3680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated JCR-3680:
-

Attachment: JCR-3680-1.patch

 Add entries for jcr:title and jcr:description to JcrConstants
 -

 Key: JCR-3680
 URL: https://issues.apache.org/jira/browse/JCR-3680
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
  Components: jackrabbit-jcr-commons
Reporter: Robert Munteanu
Priority: Trivial
 Attachments: JCR-3680-1.patch


 As a central location for item names defined in the JCR spec, it would be 
 useful to have jcr:title and jcr:content included in JcrConstants.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (JCR-3680) Add entries for jcr:title and jcr:description to JcrConstants

2013-10-15 Thread Robert Munteanu (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-3680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795362#comment-13795362
 ] 

Robert Munteanu commented on JCR-3680:
--

I see your point. Is there a way to use the 'unexpanded' form from Property? 
For instance 'jcr:title' instead of '{http://www.jcp.org/jcr/1.0}title' .

 Add entries for jcr:title and jcr:description to JcrConstants
 -

 Key: JCR-3680
 URL: https://issues.apache.org/jira/browse/JCR-3680
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
  Components: jackrabbit-jcr-commons
Reporter: Robert Munteanu
Priority: Trivial
 Attachments: JCR-3680-1.patch


 As a central location for item names defined in the JCR spec, it would be 
 useful to have jcr:title and jcr:content included in JcrConstants.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (JCR-3666) FileVault: VaultFsConfig11 references incorrect classes from prior versions

2013-09-12 Thread Robert Munteanu (JIRA)

Robert Munteanu created JCR-3666:


 Summary: FileVault: VaultFsConfig11 references incorrect classes 
from prior versions
 Key: JCR-3666
 URL: https://issues.apache.org/jira/browse/JCR-3666
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-jcr-commons
Reporter: Robert Munteanu
Priority: Minor


I stumbled upon this by accident, so I can't say whether this has unintended 
side effects or not, but just to make sure...

VaultFsConfig11 references classes from prior mappings 

{code}
MapString, String m = helper.getMappings();
m.put(org.apache.jackrabbit.vault.fs.imprt.FolderArtifactHandler, 
org.apache.jackrabbit.vault.fs.impl.io.FileArtifactHandler);
m.put(org.apache.jackrabbit.vault.fs.imprt.FileArtifactHandler, 
org.apache.jackrabbit.vault.fs.impl.io.FileArtifactHandler);
m.put(org.apache.jackrabbit.vault.fs.imprt.GenericArtifactHandler, 
org.apache.jackrabbit.vault.fs.impl.io.GenericArtifactHandler);
m.put(org.apache.jackrabbit.vault.fs.imprt.NodeTypeArtifactHandler, 
org.apache.jackrabbit.vault.fs.impl.io.NodeTypeArtifactHandler);

m.put(org.apache.jackrabbit.vault.fs.filter.ItemFilter, 
org.apache.jackrabbit.vault.fs.api.ItemFilter);
m.put(org.apache.jackrabbit.vault.fs.filter.PathFilter, 
org.apache.jackrabbit.vault.fs.api.PathFilter);
{code}

But since there was no prior org.apache.jackrabbit.vault.fs.imprt package, I 
guess that this is incorrect, and that the mappings should include both the 
previous class names and the class names which were in effect before FileVault 
was donated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (JCR-3664) FileVault: fix javadoc for PlatformNameFormatter

2013-09-05 Thread Robert Munteanu (JIRA)

Robert Munteanu created JCR-3664:


 Summary: FileVault: fix javadoc for PlatformNameFormatter
 Key: JCR-3664
 URL: https://issues.apache.org/jira/browse/JCR-3664
 Project: Jackrabbit Content Repository
  Issue Type: Task
  Components: jackrabbit-jcr-commons
Reporter: Robert Munteanu
Priority: Trivial


The javadoc for this class is incorrectly formatted - it is written as plain 
text rather than HTML. It's missing some p and pre tags to make it render as 
expected.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (JCR-3664) FileVault: fix javadoc for PlatformNameFormatter

2013-09-05 Thread Robert Munteanu (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCR-3664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated JCR-3664:
-

Status: Patch Available  (was: Open)

 FileVault: fix javadoc for PlatformNameFormatter
 

 Key: JCR-3664
 URL: https://issues.apache.org/jira/browse/JCR-3664
 Project: Jackrabbit Content Repository
  Issue Type: Task
  Components: jackrabbit-jcr-commons
Reporter: Robert Munteanu
Priority: Trivial
 Attachments: JCR-3664-1.patch


 The javadoc for this class is incorrectly formatted - it is written as plain 
 text rather than HTML. It's missing some p and pre tags to make it render as 
 expected.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (JCR-3664) FileVault: fix javadoc for PlatformNameFormatter

2013-09-05 Thread Robert Munteanu (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCR-3664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated JCR-3664:
-

Attachment: JCR-3664-1.patch

 FileVault: fix javadoc for PlatformNameFormatter
 

 Key: JCR-3664
 URL: https://issues.apache.org/jira/browse/JCR-3664
 Project: Jackrabbit Content Repository
  Issue Type: Task
  Components: jackrabbit-jcr-commons
Reporter: Robert Munteanu
Priority: Trivial
 Attachments: JCR-3664-1.patch


 The javadoc for this class is incorrectly formatted - it is written as plain 
 text rather than HTML. It's missing some p and pre tags to make it render as 
 expected.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (JCR-3663) FileVault: tweak gitignore file

2013-09-03 Thread Robert Munteanu (JIRA)

Robert Munteanu created JCR-3663:


 Summary: FileVault: tweak gitignore file
 Key: JCR-3663
 URL: https://issues.apache.org/jira/browse/JCR-3663
 Project: Jackrabbit Content Repository
  Issue Type: Task
  Components: jackrabbit-jcr-commons
Reporter: Robert Munteanu
Priority: Trivial


After a full build the bin directory and derby.log files are shown as 
untracked. I'll attach a trivial patch which fixes this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (JCR-3663) FileVault: tweak gitignore file

2013-09-03 Thread Robert Munteanu (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCR-3663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated JCR-3663:
-

Attachment: JCR-3663-1.patch

 FileVault: tweak gitignore file
 ---

 Key: JCR-3663
 URL: https://issues.apache.org/jira/browse/JCR-3663
 Project: Jackrabbit Content Repository
  Issue Type: Task
  Components: jackrabbit-jcr-commons
Reporter: Robert Munteanu
Priority: Trivial
 Attachments: JCR-3663-1.patch


 After a full build the bin directory and derby.log files are shown as 
 untracked. I'll attach a trivial patch which fixes this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (JCR-3647) FileVault - update maven-scr-plugin and maven-bundle-plugin versions

2013-08-17 Thread Robert Munteanu (JIRA)

Robert Munteanu created JCR-3647:


 Summary: FileVault - update maven-scr-plugin and 
maven-bundle-plugin versions
 Key: JCR-3647
 URL: https://issues.apache.org/jira/browse/JCR-3647
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
  Components: jackrabbit-jcr-commons
Reporter: Robert Munteanu
Priority: Minor


Updating these plugin versions brings improvements and bugfixes and also allows 
the projects to be imported into Eclipse  without any errors.

After making the change I 've verified the the build passes and that 'vlt' 
still works on a Sling instance.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

1 2 >

1 - 100 of 111 matches

Mail list logo