[jira] [Commented] (SLING-8104) Avoid magic when merging features
[ https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689080#comment-16689080 ] ASF GitHub Bot commented on SLING-8104: --- cziegeler commented on issue #8: SLING-8104 Avoid magic when merging features URL: https://github.com/apache/sling-org-apache-sling-feature/pull/8#issuecomment-439295972 This looks basically good to me, two comments: The other methods in the BuilderContext should be renamed from *Overwrites to *Overrides as well The new mechanism is now also used to process an include; however I think an include should be processable without providing additional information. So far, the latest artifact won, meaning that the one from the feature that has the include wins, which seems logical. On the other hand, this prevents the use case of having both versions. We already have the "remove" section in an include, we could add a "replace" section there as well which then means: Let's assume feature A includes feature I. If A lists a bundle in the replace section, this bundle version will win (== LATEST) If A lists a bundle in the bundles section, both versions will be included (== ALL) The decision for a HIGHEST is done by the feature author. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Avoid magic when merging features > - > > Key: SLING-8104 > URL: https://issues.apache.org/jira/browse/SLING-8104 > Project: Sling > Issue Type: Improvement > Components: Feature Model >Reporter: Carsten Ziegeler >Assignee: David Bosschaert >Priority: Blocker > Fix For: slingfeature-maven-plugin 1.0.0, Feature Model 0.2.2 > > > Currently when features are merged a simple algorithm is applied which just > picks the highest version based on the artifact version. However this version > might not have no meaning at all and might not really reflect what has > changed inside the bundle. > Especially when there is a major version change, this approach seems to be > clearly wrong > But in the end, picking a single version is magic. > While the problem could probably be solved by using something like a resolver > and figure out if just one version is enough or if both versions are needed, > without a resolver there is no way to figure this out. > Therefore we should provide a similar way as we do for variables at the > moment: if there is a clash the caller needs to provide context on what to > choose. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] cziegeler commented on issue #8: SLING-8104 Avoid magic when merging features
cziegeler commented on issue #8: SLING-8104 Avoid magic when merging features URL: https://github.com/apache/sling-org-apache-sling-feature/pull/8#issuecomment-439295972 This looks basically good to me, two comments: The other methods in the BuilderContext should be renamed from *Overwrites to *Overrides as well The new mechanism is now also used to process an include; however I think an include should be processable without providing additional information. So far, the latest artifact won, meaning that the one from the feature that has the include wins, which seems logical. On the other hand, this prevents the use case of having both versions. We already have the "remove" section in an include, we could add a "replace" section there as well which then means: Let's assume feature A includes feature I. If A lists a bundle in the replace section, this bundle version will win (== LATEST) If A lists a bundle in the bundles section, both versions will be included (== ALL) The decision for a HIGHEST is done by the feature author. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
Re: [VOTE] Release Apache Sling Testing JCR Mock 1.4.2, OSGi Mock 2.4.4
+1 Le jeu. 15 nov. 2018 à 16:01, Stefan Seifert a écrit : > +1 > > >
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[ https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16688246#comment-16688246 ] ASF GitHub Bot commented on SLING-8104: --- bosschaert commented on issue #8: SLING-8104 Avoid magic when merging features URL: https://github.com/apache/sling-org-apache-sling-feature/pull/8#issuecomment-439086668 Note that the slingfeature-maven-plugin changes to provide the artifact override list is being developed here: https://github.com/bosschaert/sling-slingfeature-maven-plugin/tree/SLING-8104 @cziegeler @karlpauls WDYT? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Avoid magic when merging features > - > > Key: SLING-8104 > URL: https://issues.apache.org/jira/browse/SLING-8104 > Project: Sling > Issue Type: Improvement > Components: Feature Model >Reporter: Carsten Ziegeler >Assignee: David Bosschaert >Priority: Blocker > Fix For: slingfeature-maven-plugin 1.0.0, Feature Model 0.2.2 > > > Currently when features are merged a simple algorithm is applied which just > picks the highest version based on the artifact version. However this version > might not have no meaning at all and might not really reflect what has > changed inside the bundle. > Especially when there is a major version change, this approach seems to be > clearly wrong > But in the end, picking a single version is magic. > While the problem could probably be solved by using something like a resolver > and figure out if just one version is enough or if both versions are needed, > without a resolver there is no way to figure this out. > Therefore we should provide a similar way as we do for variables at the > moment: if there is a clash the caller needs to provide context on what to > choose. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] bosschaert commented on issue #8: SLING-8104 Avoid magic when merging features
bosschaert commented on issue #8: SLING-8104 Avoid magic when merging features URL: https://github.com/apache/sling-org-apache-sling-feature/pull/8#issuecomment-439086668 Note that the slingfeature-maven-plugin changes to provide the artifact override list is being developed here: https://github.com/bosschaert/sling-slingfeature-maven-plugin/tree/SLING-8104 @cziegeler @karlpauls WDYT? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[ https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16688237#comment-16688237 ] ASF GitHub Bot commented on SLING-8104: --- bosschaert opened a new pull request #8: SLING-8104 Avoid magic when merging features URL: https://github.com/apache/sling-org-apache-sling-feature/pull/8 When merging artifacts/bundles, they need to be selected from a provided override list if the artifact versions are not the same. The list has the following syntax: groupid1:artifactid1: groupid2:artifactid2: Where is one of the following: ALL - select all the artifacts HIGHEST - select only the artifact with the highest version number LATEST - select only the artifact provided latest - select this specific version When comparing version numbers these are converted to OSGi version numbers and the OSGi version number ordering is applied. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Avoid magic when merging features > - > > Key: SLING-8104 > URL: https://issues.apache.org/jira/browse/SLING-8104 > Project: Sling > Issue Type: Improvement > Components: Feature Model >Reporter: Carsten Ziegeler >Assignee: David Bosschaert >Priority: Blocker > Fix For: slingfeature-maven-plugin 1.0.0, Feature Model 0.2.2 > > > Currently when features are merged a simple algorithm is applied which just > picks the highest version based on the artifact version. However this version > might not have no meaning at all and might not really reflect what has > changed inside the bundle. > Especially when there is a major version change, this approach seems to be > clearly wrong > But in the end, picking a single version is magic. > While the problem could probably be solved by using something like a resolver > and figure out if just one version is enough or if both versions are needed, > without a resolver there is no way to figure this out. > Therefore we should provide a similar way as we do for variables at the > moment: if there is a clash the caller needs to provide context on what to > choose. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] bosschaert opened a new pull request #8: SLING-8104 Avoid magic when merging features
bosschaert opened a new pull request #8: SLING-8104 Avoid magic when merging features URL: https://github.com/apache/sling-org-apache-sling-feature/pull/8 When merging artifacts/bundles, they need to be selected from a provided override list if the artifact versions are not the same. The list has the following syntax: groupid1:artifactid1: groupid2:artifactid2: Where is one of the following: ALL - select all the artifacts HIGHEST - select only the artifact with the highest version number LATEST - select only the artifact provided latest - select this specific version When comparing version numbers these are converted to OSGi version numbers and the OSGi version number ordering is applied. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (SLING-7934) Add the ability for a resource to adapt to a JSONObject
[ https://issues.apache.org/jira/browse/SLING-7934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16688184#comment-16688184 ] Carsten Ziegeler commented on SLING-7934: - Pretty cool idea +1 > Add the ability for a resource to adapt to a JSONObject > --- > > Key: SLING-7934 > URL: https://issues.apache.org/jira/browse/SLING-7934 > Project: Sling > Issue Type: Improvement >Reporter: Jason E Bailey >Assignee: Jason E Bailey >Priority: Major > > There are multiple implementations all doing the same process of converting a > resource to a JSONObject. If it's that common we should just add the ability > to adapt the resource and centralize the implementation so that it's > consistent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-8066) MockProperty.setValue(final String[] newValues) throws null pointer exception
[ https://issues.apache.org/jira/browse/SLING-8066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16688176#comment-16688176 ] Stefan Seifert commented on SLING-8066: --- i've started the release process - if all is going well release should be available early next week > MockProperty.setValue(final String[] newValues) throws null pointer exception > -- > > Key: SLING-8066 > URL: https://issues.apache.org/jira/browse/SLING-8066 > Project: Sling > Issue Type: Bug > Components: Testing >Affects Versions: Testing JCR Mock 1.4.0 >Reporter: Pankaj Parashar >Assignee: Stefan Seifert >Priority: Blocker > Fix For: Testing JCR Mock 1.4.2 > > Time Spent: 50m > Remaining Estimate: 0h > > There is no null check in this api method. In our case product code is > passing a null value in the below form for a multivalve property. > currentNode.setProperty(propertyName, (String[])null); > MockProperty api throws null pointer exception when we use JCR mocking. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
RE: [VOTE] Release Apache Sling Testing JCR Mock 1.4.2, OSGi Mock 2.4.4
+1
[VOTE] Release Apache Sling Testing JCR Mock 1.4.2, OSGi Mock 2.4.4
Hi, Apache Sling Testing JCR Mock 1.4.2 (1 issue) https://issues.apache.org/jira/browse/SLING/fixforversion/12343953 Apache Sling Testing OSGi Mock 2.4.4 (1 issue) https://issues.apache.org/jira/browse/SLING/fixforversion/12343988 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2015/ You can use this UNIX script to download the release and verify the signatures: https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD Usage: sh check_staged_release.sh 2015 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. stefan
[jira] [Updated] (SLING-7284) Extend OsgiServiceUtil#invokeBindUnbindMethod to support more DS 1.3+ method signatures
[
https://issues.apache.org/jira/browse/SLING-7284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert updated SLING-7284:
--
Fix Version/s: (was: Testing OSGi Mock 2.4.4)
Testing OSGi Mock 2.4.6
> Extend OsgiServiceUtil#invokeBindUnbindMethod to support more DS 1.3+ method
> signatures
> ---
>
> Key: SLING-7284
> URL: https://issues.apache.org/jira/browse/SLING-7284
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing OSGi Mock 1.0.0
>Reporter: Radu Cotescu
>Priority: Major
> Fix For: Testing OSGi Mock 2.4.6
>
>
> The
> {{org.apache.sling.testing.mock.osgi.OsgiServiceUtil#invokeBindUnbindMethod}}
> should be extended to support more DS 1.3+ method signatures.
> For more details check
> https://github.com/apache/felix/blob/a4755e768329a29252b1d7d8e52537941768606d/scr/src/main/java/org/apache/felix/scr/impl/inject/BindMethod.java#L86.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-8110) Take *extensions" service property into account for path-mounted servlets
[ https://issues.apache.org/jira/browse/SLING-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16688089#comment-16688089 ] Konrad Windszus commented on SLING-8110: You can no longer wrongly configure this with the new servlet annotations: https://sling.apache.org/documentation/the-sling-engine/servlets.html#registering-a-servlet-using-java-annotations and https://github.com/apache/sling-org-apache-sling-servlets-annotations. > Take *extensions" service property into account for path-mounted servlets > - > > Key: SLING-8110 > URL: https://issues.apache.org/jira/browse/SLING-8110 > Project: Sling > Issue Type: Improvement > Components: Servlets >Reporter: Bertrand Delacretaz >Priority: Minor > > If a Sling Servlet has both _paths_ and _extensions_ service properties, > currently the _paths_ take over and the _extensions_ are ignored. > This has caused confusion with users who have set both properties on a > servlet - my initial thought was to reject such illegal combinations, but a > colleague rightly notes that it would make sense to honor the _extensions_ > property as well, and only route requests to that servlet if there's a match > on the extension. > This requires more analysis, for now I'm just creating this ticket to remind > us to have another look. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-8110) Take *extensions" service property into account for path-mounted servlets
[ https://issues.apache.org/jira/browse/SLING-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16688077#comment-16688077 ] Alex COLLIGNON commented on SLING-8110: --- While I understand the conservative approach and agree it is documented, I recommend logging some warnings (yes, I mean warning log level) when such a configuration is encountered during the servlet registration process. > Take *extensions" service property into account for path-mounted servlets > - > > Key: SLING-8110 > URL: https://issues.apache.org/jira/browse/SLING-8110 > Project: Sling > Issue Type: Improvement > Components: Servlets >Reporter: Bertrand Delacretaz >Priority: Minor > > If a Sling Servlet has both _paths_ and _extensions_ service properties, > currently the _paths_ take over and the _extensions_ are ignored. > This has caused confusion with users who have set both properties on a > servlet - my initial thought was to reject such illegal combinations, but a > colleague rightly notes that it would make sense to honor the _extensions_ > property as well, and only route requests to that servlet if there's a match > on the extension. > This requires more analysis, for now I'm just creating this ticket to remind > us to have another look. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-7934) Add the ability for a resource to adapt to a JSONObject
[ https://issues.apache.org/jira/browse/SLING-7934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16688051#comment-16688051 ] Jason E Bailey commented on SLING-7934: --- By converting the get(string,class) method to a default method in the interface? One that uses the converter. Then we modify the implementations where we can to use the default method. We couldn't stop people overwriting that but it becomes less likely. > Add the ability for a resource to adapt to a JSONObject > --- > > Key: SLING-7934 > URL: https://issues.apache.org/jira/browse/SLING-7934 > Project: Sling > Issue Type: Improvement >Reporter: Jason E Bailey >Assignee: Jason E Bailey >Priority: Major > > There are multiple implementations all doing the same process of converting a > resource to a JSONObject. If it's that common we should just add the ability > to adapt the resource and centralize the implementation so that it's > consistent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-8110) Take *extensions" service property into account for path-mounted servlets
[ https://issues.apache.org/jira/browse/SLING-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687978#comment-16687978 ] Konrad Windszus commented on SLING-8110: This limitation is clearly mentioned in http://sling.apache.org/documentation/the-sling-engine/servlets.html#servlet-registration and also affects "selectors" and "methods". All those are not taken into account for path based registration of servlets! > Take *extensions" service property into account for path-mounted servlets > - > > Key: SLING-8110 > URL: https://issues.apache.org/jira/browse/SLING-8110 > Project: Sling > Issue Type: Improvement > Components: Servlets >Reporter: Bertrand Delacretaz >Priority: Minor > > If a Sling Servlet has both _paths_ and _extensions_ service properties, > currently the _paths_ take over and the _extensions_ are ignored. > This has caused confusion with users who have set both properties on a > servlet - my initial thought was to reject such illegal combinations, but a > colleague rightly notes that it would make sense to honor the _extensions_ > property as well, and only route requests to that servlet if there's a match > on the extension. > This requires more analysis, for now I'm just creating this ticket to remind > us to have another look. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-8110) Take *extensions" service property into account for path-mounted servlets
[ https://issues.apache.org/jira/browse/SLING-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687983#comment-16687983 ] Carsten Ziegeler commented on SLING-8110: - And we should probably leave it like this; it's well documented and if we change this now it might have unwanted side effects > Take *extensions" service property into account for path-mounted servlets > - > > Key: SLING-8110 > URL: https://issues.apache.org/jira/browse/SLING-8110 > Project: Sling > Issue Type: Improvement > Components: Servlets >Reporter: Bertrand Delacretaz >Priority: Minor > > If a Sling Servlet has both _paths_ and _extensions_ service properties, > currently the _paths_ take over and the _extensions_ are ignored. > This has caused confusion with users who have set both properties on a > servlet - my initial thought was to reject such illegal combinations, but a > colleague rightly notes that it would make sense to honor the _extensions_ > property as well, and only route requests to that servlet if there's a match > on the extension. > This requires more analysis, for now I'm just creating this ticket to remind > us to have another look. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-8110) Take *extensions" service property into account for path-mounted servlets
Bertrand Delacretaz created SLING-8110: -- Summary: Take *extensions" service property into account for path-mounted servlets Key: SLING-8110 URL: https://issues.apache.org/jira/browse/SLING-8110 Project: Sling Issue Type: Improvement Components: Servlets Reporter: Bertrand Delacretaz If a Sling Servlet has both _paths_ and _extensions_ service properties, currently the _paths_ take over and the _extensions_ are ignored. This has caused confusion with users who have set both properties on a servlet - my initial thought was to reject such illegal combinations, but a colleague rightly notes that it would make sense to honor the _extensions_ property as well, and only route requests to that servlet if there's a match on the extension. This requires more analysis, for now I'm just creating this ticket to remind us to have another look. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[ https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687839#comment-16687839 ] David Bosschaert commented on SLING-8104: - Works for me :) thanks! > Avoid magic when merging features > - > > Key: SLING-8104 > URL: https://issues.apache.org/jira/browse/SLING-8104 > Project: Sling > Issue Type: Improvement > Components: Feature Model >Reporter: Carsten Ziegeler >Assignee: David Bosschaert >Priority: Blocker > Fix For: slingfeature-maven-plugin 1.0.0, Feature Model 0.2.2 > > > Currently when features are merged a simple algorithm is applied which just > picks the highest version based on the artifact version. However this version > might not have no meaning at all and might not really reflect what has > changed inside the bundle. > Especially when there is a major version change, this approach seems to be > clearly wrong > But in the end, picking a single version is magic. > While the problem could probably be solved by using something like a resolver > and figure out if just one version is enough or if both versions are needed, > without a resolver there is no way to figure this out. > Therefore we should provide a similar way as we do for variables at the > moment: if there is a clash the caller needs to provide context on what to > choose. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[
https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687832#comment-16687832
]
Carsten Ziegeler commented on SLING-8104:
-
This looks a little bit strange :) What about :
{noformat}
mygid:org.foo.my.bundle:1.2.3
mygid:org.foo.my.bundle:HIGHEST
mygid:org.foo.my.bundle:ALL
> Key: SLING-8104
> URL: https://issues.apache.org/jira/browse/SLING-8104
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Reporter: Carsten Ziegeler
>Assignee: David Bosschaert
>Priority: Blocker
> Fix For: slingfeature-maven-plugin 1.0.0, Feature Model 0.2.2
>
>
> Currently when features are merged a simple algorithm is applied which just
> picks the highest version based on the artifact version. However this version
> might not have no meaning at all and might not really reflect what has
> changed inside the bundle.
> Especially when there is a major version change, this approach seems to be
> clearly wrong
> But in the end, picking a single version is magic.
> While the problem could probably be solved by using something like a resolver
> and figure out if just one version is enough or if both versions are needed,
> without a resolver there is no way to figure this out.
> Therefore we should provide a similar way as we do for variables at the
> moment: if there is a clash the caller needs to provide context on what to
> choose.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-8104) Avoid magic when merging features
[
https://issues.apache.org/jira/browse/SLING-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687809#comment-16687809
]
David Bosschaert commented on SLING-8104:
-
{quote}In addition your syntax above does not work in XML as a colon is
separating namespace from the element name.
{quote}
Of course, yes. And the forward slash {{/}} is also not allowed.
Maybe the cleanest solution would be to embed the elements in group ID tags,
like this.
{code:java}
1.2.3
{code}
Although I'm not 100% sure I can parse this in the MOJO. Another possibility
could be to use another separator, like an underscore:
{code:java}
1.2.3
{code}
> Avoid magic when merging features
> -
>
> Key: SLING-8104
> URL: https://issues.apache.org/jira/browse/SLING-8104
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Reporter: Carsten Ziegeler
>Assignee: David Bosschaert
>Priority: Blocker
> Fix For: slingfeature-maven-plugin 1.0.0, Feature Model 0.2.2
>
>
> Currently when features are merged a simple algorithm is applied which just
> picks the highest version based on the artifact version. However this version
> might not have no meaning at all and might not really reflect what has
> changed inside the bundle.
> Especially when there is a major version change, this approach seems to be
> clearly wrong
> But in the end, picking a single version is magic.
> While the problem could probably be solved by using something like a resolver
> and figure out if just one version is enough or if both versions are needed,
> without a resolver there is no way to figure this out.
> Therefore we should provide a similar way as we do for variables at the
> moment: if there is a clash the caller needs to provide context on what to
> choose.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-8078) New Analyser task which is able to detect Export-Package dependencies between regions
[
https://issues.apache.org/jira/browse/SLING-8078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687817#comment-16687817
]
ASF GitHub Bot commented on SLING-8078:
---
simonetripodi commented on issue #9: SLING-8078 - New Analyser task which is
able to detect Export-Package dependencies between regions
URL:
https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/9#issuecomment-438998916
Thanks to you @bosschaert for merging and please apologise for the
misspelling!
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> New Analyser task which is able to detect Export-Package dependencies between
> regions
> -
>
> Key: SLING-8078
> URL: https://issues.apache.org/jira/browse/SLING-8078
> Project: Sling
> Issue Type: New Feature
> Components: Feature Model, Maven Plugins and Archetypes
>Affects Versions: Feature Model Analyser 0.2.0
>Reporter: Simone Tripodi
>Assignee: David Bosschaert
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0, Feature Model Analyser
> 0.2.2
>
>
> It may be helpful users have the need to define a {{deprecated}} region in
> order to mark which APIs don't have to be exposed to end users, a new
> Analyser Task implementation will help to detect if {{global}} exported APIs
> don't have {{uses}} dependencies to APIs that are declared in the
> {{deprecated}} region.
> i.e. given a feature:
> {noformat}
> ...
> [
> {
> "name": "global"
> "exports": ["org.osgi.util.function"]
> },
> {
> "name": "deprecated",
>"exports": ["org.objectweb.asm"]
> }
> ]
> ...
> {noformat}
> and a bundle declares the OSGi header in the Manifest as below:
> {noformat}
> Export-Package: org.osgi.util.function;uses:="org.objectweb.asm"
> {noformat}
> the new Analyser Task implementation will detect that "violation"
> {noformat}
> Bundle 'org.osgi:org.osgi.util.function:1.0.0', defined in feature
> 'org.apache.sling.testing:org.apache.sling.testing.apiregions:1.0.0',
> declares 'org.osgi.util.function' in the 'Export-Package' header which
> requires 'org.objectweb.asm' package that is in the 'deprecated' region
> {noformat}
> PR is coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] simonetripodi commented on issue #9: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
simonetripodi commented on issue #9: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions URL: https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/9#issuecomment-438998916 Thanks to you @bosschaert for merging and please apologise for the misspelling! This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] bosschaert commented on issue #9: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
bosschaert commented on issue #9: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions URL: https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/9#issuecomment-438992884 Thanks for the PR @simonetripodi ! It's merged. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (SLING-8078) New Analyser task which is able to detect Export-Package dependencies between regions
[
https://issues.apache.org/jira/browse/SLING-8078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687764#comment-16687764
]
ASF GitHub Bot commented on SLING-8078:
---
bosschaert closed pull request #9: SLING-8078 - New Analyser task which is able
to detect Export-Package dependencies between regions
URL: https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/9
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> New Analyser task which is able to detect Export-Package dependencies between
> regions
> -
>
> Key: SLING-8078
> URL: https://issues.apache.org/jira/browse/SLING-8078
> Project: Sling
> Issue Type: New Feature
> Components: Feature Model, Maven Plugins and Archetypes
>Affects Versions: Feature Model Analyser 0.2.0
>Reporter: Simone Tripodi
>Assignee: David Bosschaert
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0, Feature Model Analyser
> 0.2.2
>
>
> It may be helpful users have the need to define a {{deprecated}} region in
> order to mark which APIs don't have to be exposed to end users, a new
> Analyser Task implementation will help to detect if {{global}} exported APIs
> don't have {{uses}} dependencies to APIs that are declared in the
> {{deprecated}} region.
> i.e. given a feature:
> {noformat}
> ...
> [
> {
> "name": "global"
> "exports": ["org.osgi.util.function"]
> },
> {
> "name": "deprecated",
>"exports": ["org.objectweb.asm"]
> }
> ]
> ...
> {noformat}
> and a bundle declares the OSGi header in the Manifest as below:
> {noformat}
> Export-Package: org.osgi.util.function;uses:="org.objectweb.asm"
> {noformat}
> the new Analyser Task implementation will detect that "violation"
> {noformat}
> Bundle 'org.osgi:org.osgi.util.function:1.0.0', defined in feature
> 'org.apache.sling.testing:org.apache.sling.testing.apiregions:1.0.0',
> declares 'org.osgi.util.function' in the 'Export-Package' header which
> requires 'org.objectweb.asm' package that is in the 'deprecated' region
> {noformat}
> PR is coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-8078) New Analyser task which is able to detect Export-Package dependencies between regions
[
https://issues.apache.org/jira/browse/SLING-8078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687766#comment-16687766
]
ASF GitHub Bot commented on SLING-8078:
---
bosschaert commented on issue #9: SLING-8078 - New Analyser task which is able
to detect Export-Package dependencies between regions
URL:
https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/9#issuecomment-438992884
Thanks for the PR @simonetripodi ! It's merged.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> New Analyser task which is able to detect Export-Package dependencies between
> regions
> -
>
> Key: SLING-8078
> URL: https://issues.apache.org/jira/browse/SLING-8078
> Project: Sling
> Issue Type: New Feature
> Components: Feature Model, Maven Plugins and Archetypes
>Affects Versions: Feature Model Analyser 0.2.0
>Reporter: Simone Tripodi
>Assignee: David Bosschaert
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0, Feature Model Analyser
> 0.2.2
>
>
> It may be helpful users have the need to define a {{deprecated}} region in
> order to mark which APIs don't have to be exposed to end users, a new
> Analyser Task implementation will help to detect if {{global}} exported APIs
> don't have {{uses}} dependencies to APIs that are declared in the
> {{deprecated}} region.
> i.e. given a feature:
> {noformat}
> ...
> [
> {
> "name": "global"
> "exports": ["org.osgi.util.function"]
> },
> {
> "name": "deprecated",
>"exports": ["org.objectweb.asm"]
> }
> ]
> ...
> {noformat}
> and a bundle declares the OSGi header in the Manifest as below:
> {noformat}
> Export-Package: org.osgi.util.function;uses:="org.objectweb.asm"
> {noformat}
> the new Analyser Task implementation will detect that "violation"
> {noformat}
> Bundle 'org.osgi:org.osgi.util.function:1.0.0', defined in feature
> 'org.apache.sling.testing:org.apache.sling.testing.apiregions:1.0.0',
> declares 'org.osgi.util.function' in the 'Export-Package' header which
> requires 'org.objectweb.asm' package that is in the 'deprecated' region
> {noformat}
> PR is coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] bosschaert closed pull request #9: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
bosschaert closed pull request #9: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions URL: https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/9 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Resolved] (SLING-8094) Add OSGi sling servlet annotations to dependencyMgmt
[ https://issues.apache.org/jira/browse/SLING-8094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved SLING-8094. Resolution: Fixed Fixed in https://github.com/apache/sling-parent/commit/7534af76b08cf226897b3ac198a5edb684205cdd. > Add OSGi sling servlet annotations to dependencyMgmt > > > Key: SLING-8094 > URL: https://issues.apache.org/jira/browse/SLING-8094 > Project: Sling > Issue Type: Improvement > Components: General >Reporter: Konrad Windszus >Priority: Major > Fix For: Bundle Parent 35 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (SLING-8094) Add OSGi sling servlet annotations to dependencyMgmt
[ https://issues.apache.org/jira/browse/SLING-8094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus reassigned SLING-8094: -- Assignee: Konrad Windszus > Add OSGi sling servlet annotations to dependencyMgmt > > > Key: SLING-8094 > URL: https://issues.apache.org/jira/browse/SLING-8094 > Project: Sling > Issue Type: Improvement > Components: General >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: Bundle Parent 35 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-8078) New Analyser task which is able to detect Export-Package dependencies between regions
[
https://issues.apache.org/jira/browse/SLING-8078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687740#comment-16687740
]
ASF GitHub Bot commented on SLING-8078:
---
simonetripodi opened a new pull request #9: SLING-8078 - New Analyser task
which is able to detect Export-Package dependencies between regions
URL: https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/9
s/requires/uses, according to the OSGi clausole
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> New Analyser task which is able to detect Export-Package dependencies between
> regions
> -
>
> Key: SLING-8078
> URL: https://issues.apache.org/jira/browse/SLING-8078
> Project: Sling
> Issue Type: New Feature
> Components: Feature Model, Maven Plugins and Archetypes
>Affects Versions: Feature Model Analyser 0.2.0
>Reporter: Simone Tripodi
>Assignee: David Bosschaert
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0, Feature Model Analyser
> 0.2.2
>
>
> It may be helpful users have the need to define a {{deprecated}} region in
> order to mark which APIs don't have to be exposed to end users, a new
> Analyser Task implementation will help to detect if {{global}} exported APIs
> don't have {{uses}} dependencies to APIs that are declared in the
> {{deprecated}} region.
> i.e. given a feature:
> {noformat}
> ...
> [
> {
> "name": "global"
> "exports": ["org.osgi.util.function"]
> },
> {
> "name": "deprecated",
>"exports": ["org.objectweb.asm"]
> }
> ]
> ...
> {noformat}
> and a bundle declares the OSGi header in the Manifest as below:
> {noformat}
> Export-Package: org.osgi.util.function;uses:="org.objectweb.asm"
> {noformat}
> the new Analyser Task implementation will detect that "violation"
> {noformat}
> Bundle 'org.osgi:org.osgi.util.function:1.0.0', defined in feature
> 'org.apache.sling.testing:org.apache.sling.testing.apiregions:1.0.0',
> declares 'org.osgi.util.function' in the 'Export-Package' header which
> requires 'org.objectweb.asm' package that is in the 'deprecated' region
> {noformat}
> PR is coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] simonetripodi opened a new pull request #9: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
simonetripodi opened a new pull request #9: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions URL: https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/9 s/requires/uses, according to the OSGi clausole This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
