[
https://issues.apache.org/jira/browse/JCRVLT-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981982#comment-16981982
]
Tobias Bocanegra commented on JCRVLT-394:
-----------------------------------------
I would not change the scope because the primary use is in an osgi context.
users that want to use it directly, can still specify the dependencies
explicitly.
alternatively, we could create a `filevault-all` project that has all the
dependencies with a different scope.
> Get rid of "provided" scope for FileVault dependencies
> ------------------------------------------------------
>
> Key: JCRVLT-394
> URL: https://issues.apache.org/jira/browse/JCRVLT-394
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: vlt
> Affects Versions: 3.4.0
> Reporter: Konrad Windszus
> Priority: Major
> Fix For: 3.4.2
>
>
> Almost all dependencies of Jackrabbit FileVault have scope "provided".
> Although in an OSGi context this seems reasonable, FileVault is also used
> outside of OSGi (e.g. within filevault-package-maven-plugin). Using it may
> lead to the following exceptions
> {code}
> java.lang.NoClassDefFoundError: org/apache/jackrabbit/api/ReferenceBinary
> at
> org.apache.jackrabbit.vault.validation.impl.util.DocumentViewXmlContentHandler.getDocViewNode
> (DocumentViewXmlContentHandler.java:163)
> at
> org.apache.jackrabbit.vault.validation.impl.util.DocumentViewXmlContentHandler.startElement
> (DocumentViewXmlContentHandler.java:134)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement
> (AbstractSAXParser.java:509)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement
> (AbstractXMLDocumentParser.java:182)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement
> (XMLNSDocumentScannerImpl.java:351)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDriver.scanRootElementHook
> (XMLNSDocumentScannerImpl.java:613)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next
> (XMLDocumentFragmentScannerImpl.java:3132)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next
> (XMLDocumentScannerImpl.java:852)
> at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next
> (XMLDocumentScannerImpl.java:602)
> at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next
> (XMLNSDocumentScannerImpl.java:112)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument
> (XMLDocumentFragmentScannerImpl.java:505)
> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
> (XML11Configuration.java:842)
> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
> (XML11Configuration.java:771)
> at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse
> (XMLParser.java:141)
> at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse
> (AbstractSAXParser.java:1213)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse
> (SAXParserImpl.java:643)
> at
> org.apache.jackrabbit.vault.validation.spi.impl.DocumentViewParserValidator.validateDocumentViewXml
> (DocumentViewParserValidator.java:147)
> at
> org.apache.jackrabbit.vault.validation.spi.impl.DocumentViewParserValidator.validateJcrData
> (DocumentViewParserValidator.java:82)
> at
> org.apache.jackrabbit.vault.validation.ValidationExecutor.validateGenericJcrData
> (ValidationExecutor.java:279)
> at
> org.apache.jackrabbit.vault.validation.ValidationExecutor.validateJcrRoot
> (ValidationExecutor.java:181)
> at
> org.apache.jackrabbit.filevault.maven.packaging.ValidatePackageMojo.validateInputStream
> (ValidatePackageMojo.java:120)
> at
> org.apache.jackrabbit.filevault.maven.packaging.ValidatePackageMojo.validateEntry
> (ValidatePackageMojo.java:106)
> at
> org.apache.jackrabbit.filevault.maven.packaging.ValidatePackageMojo.validateEntry
> (ValidatePackageMojo.java:103)
> at
> org.apache.jackrabbit.filevault.maven.packaging.ValidatePackageMojo.validateEntry
> (ValidatePackageMojo.java:103)
> at
> org.apache.jackrabbit.filevault.maven.packaging.ValidatePackageMojo.validateEntry
> (ValidatePackageMojo.java:103)
> at
> org.apache.jackrabbit.filevault.maven.packaging.ValidatePackageMojo.validateArchive
> (ValidatePackageMojo.java:95)
> at
> org.apache.jackrabbit.filevault.maven.packaging.ValidatePackageMojo.validatePackage
> (ValidatePackageMojo.java:85)
> at
> org.apache.jackrabbit.filevault.maven.packaging.ValidatePackageMojo.doExecute
> (ValidatePackageMojo.java:66)
> at
> org.apache.jackrabbit.filevault.maven.packaging.AbstractValidateMojo.execute
> (AbstractValidateMojo.java:217)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> {code}
> This is because the transitive dependency of Filevault named jackrabbit-api
> is only referenced with scope provided.
> Currently this forces downstream consumers of FileVault to directly reference
> those transitive reference (even if they don't use them directly).
> IMHO all transitive dependencies of FileVault should have scope "compile".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
