[jira] [Commented] (JCRVLT-416) Adding a package dependency to a package containing it as subpackage leads to a dependency cycle
[
https://issues.apache.org/jira/browse/JCRVLT-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17046588#comment-17046588
]
Konrad Windszus commented on JCRVLT-416:
[~tripod] How can we make the dependency to the container package explicit
without causing dependency cycles?
> Adding a package dependency to a package containing it as subpackage leads to
> a dependency cycle
>
>
> Key: JCRVLT-416
> URL: https://issues.apache.org/jira/browse/JCRVLT-416
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.1.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.1.2
>
>
> Consider the case where {{a}} is a subpackage of {{b}}. This requires {{a}}
> being a Maven dependency of Maven Module {{b}}. Since every package
> installation of {{b}} adds {{b}} as package dependency to {{a}} implicitly
> (compare with https://issues.apache.org/jira/browse/JCRVLT-140) it should
> also be possible to make this implicit dependency and explicit one (to make
> the validator be able to detect e.g. filter roots being provided by {{b}}).
> But once you also add {{a}} as dependency to {{b}} you get a dependency cycle.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (JCRVLT-416) Adding a package dependency to a package containing it as subpackage leads to a dependency cycle
Konrad Windszus created JCRVLT-416:
--
Summary: Adding a package dependency to a package containing it as
subpackage leads to a dependency cycle
Key: JCRVLT-416
URL: https://issues.apache.org/jira/browse/JCRVLT-416
Project: Jackrabbit FileVault
Issue Type: Bug
Components: package maven plugin
Affects Versions: package-maven-plugin-1.1.0
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Fix For: package-maven-plugin-1.1.2
Consider the case where {{a}} is a subpackage of {{b}}. This requires {{a}}
being a Maven dependency of Maven Module {{b}}. Since every package
installation of {{b}} adds {{b}} as package dependency to {{a}} implicitly
(compare with https://issues.apache.org/jira/browse/JCRVLT-140) it should also
be possible to make this implicit dependency and explicit one (to make the
validator be able to detect e.g. filter roots being provided by {{b}}). But
once you also add {{a}} as dependency to {{b}} you get a dependency cycle.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-414) Embedding of Woodstox leads to non-necessary Import-Package statements
[ https://issues.apache.org/jira/browse/JCRVLT-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17046568#comment-17046568 ] Konrad Windszus commented on JCRVLT-414: The workaround should no longer be necessary with Woodstox 6.1.1 (compare with https://github.com/FasterXML/woodstox/pull/102#issuecomment-590991977). > Embedding of Woodstox leads to non-necessary Import-Package statements > -- > > Key: JCRVLT-414 > URL: https://issues.apache.org/jira/browse/JCRVLT-414 > Project: Jackrabbit FileVault > Issue Type: Bug >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.4.4 > > > After switching to Woodstox in JCRVLT-391 the maven-bundle-plugin generates a > lot of non-necessary/non resolvable Import-Package statements, e.g. for > # com.sun.org.apache.xml.internal.resolver > # com.sun.org.apache.xml.internal.resolver.tools > # org.apache.crimson.jaxp > # org.apache.xerces.jaxp > # oracle.xml.jaxp > This is most probably caused by the shaded dependency MSV > (https://github.com/FasterXML/woodstox/issues/96). -- This message was sent by Atlassian Jira (v8.3.4#803005)
