[GitHub] cziegeler commented on issue #11: SLING-8032 - Add a MOJO which is able to validate JSON Feature file against the JSON Schema
cziegeler commented on issue #11: SLING-8032 - Add a MOJO which is able to validate JSON Feature file against the JSON Schema URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/11#issuecomment-436885201 While a general purpose JSON schema mojo would be nice, I see at least two problems with this: - the configuration of where the json files are and which are included / excluded needs to be sync'ed with the configuration of where feature files are. Usually not a big deal as everyone uses the default configuration but as soon as you don't it can be come a subtle problem - the reference to the json schema needs to reference an external schema for the general purpose (a url). This might become tricky as you make sure that your schema is available publically in the internet and is accessible at build time I would rather prefer that we really only validate feature files. This way we can leverage the ProjectHelper.getFeatures to get the features. This method returns a map, and the key of each entry is the file path. This allows access to the raw feature files without having to repeat the configuration and the scanning logic. In addition if we bake in the schema for feature files we don't have any external dependency 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: Parameterizing Sling Feature model extensions
Rethinking my own proposal from below, I think it's mixing the concern
of how to configure it in a maven plugin with how to handle it in the
respective component. So instead of doing the filtering in the
component, I guess it makes more sense to let the caller do this.
Or in other words instead of passing a map with string keys and string
values in the below described format, we should rather pass a map with
string keys and a Properties object as the value, something like:
mytask={
foo=one
hi=hello
}
nexttask={
bla=two
}
*={
debug=true
}
And we use the special key "*" for parameters passed to all components.
Regards
Carsten
Am 07.11.2018 um 18:49 schrieb Carsten Ziegeler:
Hi,
we're currently discussing a similar problem for SLING-8078 with Simo.
So maybe we can have a similar approach here (at least for how this is
configured in the plugin configuration).
I'm fine to extend the HandlerContext to provide configuration
properties. I guess we should plan for clashes in the names of those
properties between the handlers.
In the above mentioned issue we have a similar problem where
configuration is passed to tasks. In that case each task has a name and
the configuration map will contain keys in the form of
"taskname_propertyname". When the actually configuration is passed down
to the task, this map will be filtered and only properties without a
prefix or with the right prefix will be passed. And that prefixed is
removed.
For example if these parameters are passed from the plugin
mytask_foo=one
mytask_hi=hello
nexttask_bla=two
debug=true
and the task named "mytask" is invoked, the following paramters are
available through the context to that task:
foo=one
hi=hello
debug=true
And then we have two types of handlers in your case, the
PostProcessHandler and the MergeHandler. Do we need to distinguish
between those when it comes to configuration?
Regards
Carsten
Am 07.11.2018 um 17:46 schrieb David Bosschaert:
Hi all,
I would like to be able to send some parameters to my Feature Model
PostProcessHandler when its run from the slingfeature-maven-plugin. The
handlers in the org.apache.sling.feature.extension.apiregions component
generate files for the runtime component. I would like to be able to
configure where these files are written out so that I can later use them.
I was wondering what would be the best way to pass configuration to a
PostProcessHandler from the slingfeature-maven-plugin? There is
already the
HandlerContext class passed to the handler, so maybe we can expand that
with a configuration map? Maybe as an extra tag in the
section:
myvalue
Best regards,
David
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
[jira] [Commented] (SLING-8032) Add a MOJO which is able to validate JSON Feature file against the JSON Schema
[
https://issues.apache.org/jira/browse/SLING-8032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678834#comment-16678834
]
ASF GitHub Bot commented on SLING-8032:
---
simonetripodi commented on issue #11: SLING-8032 - Add a MOJO which is able to
validate JSON Feature file against the JSON Schema
URL:
https://github.com/apache/sling-slingfeature-maven-plugin/pull/11#issuecomment-436790341
I would consider that MOJO as a special exception for configuration, respect
to all other MOJOs, since it doesn't access to already parsed `Feature`, but it
needs to access to the original JSON format to validate it, so I'd leave it as
it is... at the end of the day it does nothing related to Feature itself, but
it could become even a general-purpose JSON Schema MOJO.
@bosschaert @cziegeler 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
> Add a MOJO which is able to validate JSON Feature file against the JSON Schema
> --
>
> Key: SLING-8032
> URL: https://issues.apache.org/jira/browse/SLING-8032
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model, Maven Plugins and Archetypes
>Reporter: Simone Tripodi
>Assignee: David Bosschaert
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0
>
>
> While SLING-7990 contributed the Schema definition, I would like to
> contribute a simple MOJO which is able to validate Feature files against the
> Schema.
> JSON Schema validation does not fit as an {{AnalyserTask}} implementation,
> since {{Feature}} instances are parsed already here, anyway the {{Analyser}}
> takes in charge semantic analysis, while JSON Schema validation is is strict
> about syntax and structure, this is why I would have a separated MOJO which
> can be optionally enabled.
> PR is coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] simonetripodi commented on issue #11: SLING-8032 - Add a MOJO which is able to validate JSON Feature file against the JSON Schema
simonetripodi commented on issue #11: SLING-8032 - Add a MOJO which is able to validate JSON Feature file against the JSON Schema URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/11#issuecomment-436790341 I would consider that MOJO as a special exception for configuration, respect to all other MOJOs, since it doesn't access to already parsed `Feature`, but it needs to access to the original JSON format to validate it, so I'd leave it as it is... at the end of the day it does nothing related to Feature itself, but it could become even a general-purpose JSON Schema MOJO. @bosschaert @cziegeler 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
Re: [PROPOSAL] Moving integration tests closer to the code they test
On Wed, Nov 7, 2018 at 5:29 PM Robert Munteanu wrote: > Hi, > > We discussed a couple of time that it would be desireable to move tests > closer to the code they're testing. > > I wrote a proposal about how this could look like in terms of results > > > https://cwiki.apache.org/confluence/display/SLING/Moving+integration+tests+closer+to+the+code+they+test > > I purposefully avoided looking into implementation details to avoid > doing too much work for nothing. > > What do you think about this possibility? > > Thanks, > > Robert > > Hi Robert, I just wanted to drop [1] which can give you some guidelines on where to put the tests. It shows the drawbacks of having the tests in src/test/ and it states that the preferred way is to create a separate project. [1] https://maven.apache.org/plugins/maven-jar-plugin/examples/create-test-jar.html Valentin
[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=16678662#comment-16678662
]
ASF GitHub Bot commented on SLING-8078:
---
simonetripodi commented on issue #7: 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/7#issuecomment-436742987
Thanks @cziegeler , I just pushed another commit implementing your
suggestion!
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: 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=16678659#comment-16678659
]
ASF GitHub Bot commented on SLING-8078:
---
simonetripodi commented on issue #16: SLING-8078 - New Analyser task which is
able to detect Export-Package dependencies between regions
URL:
https://github.com/apache/sling-slingfeature-maven-plugin/pull/16#issuecomment-436742788
thanks a lot for your feedbacks @bosschaert , I just implemented both
suggestions in the Analyzer and the IT! :)
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: 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 #7: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
simonetripodi commented on issue #7: 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/7#issuecomment-436742987 Thanks @cziegeler , I just pushed another commit implementing your suggestion! 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] simonetripodi commented on issue #16: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
simonetripodi commented on issue #16: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/16#issuecomment-436742788 thanks a lot for your feedbacks @bosschaert , I just implemented both suggestions in the Analyzer and the IT! :) 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: Parameterizing Sling Feature model extensions
Hi, we're currently discussing a similar problem for SLING-8078 with Simo. So maybe we can have a similar approach here (at least for how this is configured in the plugin configuration). I'm fine to extend the HandlerContext to provide configuration properties. I guess we should plan for clashes in the names of those properties between the handlers. In the above mentioned issue we have a similar problem where configuration is passed to tasks. In that case each task has a name and the configuration map will contain keys in the form of "taskname_propertyname". When the actually configuration is passed down to the task, this map will be filtered and only properties without a prefix or with the right prefix will be passed. And that prefixed is removed. For example if these parameters are passed from the plugin mytask_foo=one mytask_hi=hello nexttask_bla=two debug=true and the task named "mytask" is invoked, the following paramters are available through the context to that task: foo=one hi=hello debug=true And then we have two types of handlers in your case, the PostProcessHandler and the MergeHandler. Do we need to distinguish between those when it comes to configuration? Regards Carsten Am 07.11.2018 um 17:46 schrieb David Bosschaert: Hi all, I would like to be able to send some parameters to my Feature Model PostProcessHandler when its run from the slingfeature-maven-plugin. The handlers in the org.apache.sling.feature.extension.apiregions component generate files for the runtime component. I would like to be able to configure where these files are written out so that I can later use them. I was wondering what would be the best way to pass configuration to a PostProcessHandler from the slingfeature-maven-plugin? There is already the HandlerContext class passed to the handler, so maybe we can expand that with a configuration map? Maybe as an extra tag in the section: myvalue Best regards, David -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[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=16678551#comment-16678551
]
ASF GitHub Bot commented on SLING-8078:
---
cziegeler commented on issue #7: 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/7#issuecomment-436711291
In order to avoid that you talk to yourself :) Yes, correct, it needs a
little bit of filtering code in the Analyser
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: 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] cziegeler commented on issue #7: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
cziegeler commented on issue #7: 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/7#issuecomment-436711291 In order to avoid that you talk to yourself :) Yes, correct, it needs a little bit of filtering code in the Analyser 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-8080) Almost all ITs fail after the Starter 11 release
[
https://issues.apache.org/jira/browse/SLING-8080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678549#comment-16678549
]
Carsten Ziegeler commented on SLING-8080:
-
[~rombert] This sounds like a bug in the maven plugin to me; on the other hand
I'm not a fan of using pom dependencies in the feature files but thats probably
just me...
> Almost all ITs fail after the Starter 11 release
>
>
> Key: SLING-8080
> URL: https://issues.apache.org/jira/browse/SLING-8080
> Project: Sling
> Issue Type: Bug
> Components: Starter, Testing
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Critical
>
> Almost all tests fail:
> {noformat}
> [ERROR] Tests run: 575, Failures: 561, Errors: 10, Skipped: 1
> {noformat}
> I noticed that Sling is permanently in the 'Apache Sling is starting up'
> phase.
--
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=16678505#comment-16678505
]
ASF GitHub Bot commented on SLING-8078:
---
simonetripodi edited a comment on issue #7: 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/7#issuecomment-436690547
Thanks @cziegeler for the feedback, very appreciated!
IIUC, this is something that could be managed completely in the plugin
configuration, right?
EDIT I just reply myself: it is not possible, due to the fact that the MOJO
doesn't have Task visibility, but Analyser only
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: 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 edited a comment on issue #7: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
simonetripodi edited a comment on issue #7: 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/7#issuecomment-436690547 Thanks @cziegeler for the feedback, very appreciated! IIUC, this is something that could be managed completely in the plugin configuration, right? EDIT I just reply myself: it is not possible, due to the fact that the MOJO doesn't have Task visibility, but Analyser only 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
Parameterizing Sling Feature model extensions
Hi all, I would like to be able to send some parameters to my Feature Model PostProcessHandler when its run from the slingfeature-maven-plugin. The handlers in the org.apache.sling.feature.extension.apiregions component generate files for the runtime component. I would like to be able to configure where these files are written out so that I can later use them. I was wondering what would be the best way to pass configuration to a PostProcessHandler from the slingfeature-maven-plugin? There is already the HandlerContext class passed to the handler, so maybe we can expand that with a configuration map? Maybe as an extra tag in the section: myvalue Best regards, David
[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=16678488#comment-16678488
]
ASF GitHub Bot commented on SLING-8078:
---
simonetripodi commented on issue #7: 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/7#issuecomment-436690547
Thanks @cziegeler for the feedback, very appreciated!
IIUC, this is something that could be managed completely in the plugin
configuration, right?
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: 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 #7: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
simonetripodi commented on issue #7: 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/7#issuecomment-436690547 Thanks @cziegeler for the feedback, very appreciated! IIUC, this is something that could be managed completely in the plugin configuration, right? 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: Sling 12 themes
On Tue, 2018-10-23 at 16:29 +0200, Robert Munteanu wrote: > I think it would be an interesting and worthwhile exercise to see > what > various contributors would like to see as the major themes of Sling > 12. Well, since I was the one asking :-) My areas of focus for Sling 12 would be mostly internal-facing: - moving tests closer to the code they test - improved build checks for Github PRs - move to a PR-only model for the starter module Of course, these topics where we need to discuss upfront, and I'll do that for each item when the time comes. Thanks, Robert
[PROPOSAL] Moving integration tests closer to the code they test
Hi, We discussed a couple of time that it would be desireable to move tests closer to the code they're testing. I wrote a proposal about how this could look like in terms of results https://cwiki.apache.org/confluence/display/SLING/Moving+integration+tests+closer+to+the+code+they+test I purposefully avoided looking into implementation details to avoid doing too much work for nothing. What do you think about this possibility? Thanks, Robert
[jira] [Commented] (SLING-8032) Add a MOJO which is able to validate JSON Feature file against the JSON Schema
[
https://issues.apache.org/jira/browse/SLING-8032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678442#comment-16678442
]
ASF GitHub Bot commented on SLING-8032:
---
simonetripodi commented on issue #11: SLING-8032 - Add a MOJO which is able to
validate JSON Feature file against the JSON Schema
URL:
https://github.com/apache/sling-slingfeature-maven-plugin/pull/11#issuecomment-436677684
Let me rebase `master` first, I need to double check! :P
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
> Add a MOJO which is able to validate JSON Feature file against the JSON Schema
> --
>
> Key: SLING-8032
> URL: https://issues.apache.org/jira/browse/SLING-8032
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model, Maven Plugins and Archetypes
>Reporter: Simone Tripodi
>Assignee: David Bosschaert
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0
>
>
> While SLING-7990 contributed the Schema definition, I would like to
> contribute a simple MOJO which is able to validate Feature files against the
> Schema.
> JSON Schema validation does not fit as an {{AnalyserTask}} implementation,
> since {{Feature}} instances are parsed already here, anyway the {{Analyser}}
> takes in charge semantic analysis, while JSON Schema validation is is strict
> about syntax and structure, this is why I would have a separated MOJO which
> can be optionally enabled.
> PR is coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] simonetripodi commented on issue #11: SLING-8032 - Add a MOJO which is able to validate JSON Feature file against the JSON Schema
simonetripodi commented on issue #11: SLING-8032 - Add a MOJO which is able to validate JSON Feature file against the JSON Schema URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/11#issuecomment-436677684 Let me rebase `master` first, I need to double check! :P 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-8032) Add a MOJO which is able to validate JSON Feature file against the JSON Schema
[
https://issues.apache.org/jira/browse/SLING-8032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678439#comment-16678439
]
ASF GitHub Bot commented on SLING-8032:
---
bosschaert commented on issue #11: SLING-8032 - Add a MOJO which is able to
validate JSON Feature file against the JSON Schema
URL:
https://github.com/apache/sling-slingfeature-maven-plugin/pull/11#issuecomment-436676367
Hi @simonetripodi - is this PR still good to go in after the recent
refactoring of the codebase?
The code itself looks good to me.
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
> Add a MOJO which is able to validate JSON Feature file against the JSON Schema
> --
>
> Key: SLING-8032
> URL: https://issues.apache.org/jira/browse/SLING-8032
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model, Maven Plugins and Archetypes
>Reporter: Simone Tripodi
>Assignee: David Bosschaert
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0
>
>
> While SLING-7990 contributed the Schema definition, I would like to
> contribute a simple MOJO which is able to validate Feature files against the
> Schema.
> JSON Schema validation does not fit as an {{AnalyserTask}} implementation,
> since {{Feature}} instances are parsed already here, anyway the {{Analyser}}
> takes in charge semantic analysis, while JSON Schema validation is is strict
> about syntax and structure, this is why I would have a separated MOJO which
> can be optionally enabled.
> PR is coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] bosschaert commented on issue #11: SLING-8032 - Add a MOJO which is able to validate JSON Feature file against the JSON Schema
bosschaert commented on issue #11: SLING-8032 - Add a MOJO which is able to validate JSON Feature file against the JSON Schema URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/11#issuecomment-436676367 Hi @simonetripodi - is this PR still good to go in after the recent refactoring of the codebase? The code itself looks good to me. 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
[VOTE] Release Apache Sling Service User Mapper 1.4.4
I would like to call a vote on the following release, Apache Sling Service User Mapper 1.4.4 We solved 1 issue in this release: https://issues.apache.org/jira/projects/SLING/versions/12344048 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2009/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 2009 /tmp/sling-staging Please vote to approve these releases: [ ] +1 Approve the releases [ ] 0 Don't care [ ] -1 Don't release, because ...
[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=16678427#comment-16678427
]
ASF GitHub Bot commented on SLING-8078:
---
bosschaert commented on a change in pull request #16: SLING-8078 - New Analyser
task which is able to detect Export-Package dependencies between regions
URL:
https://github.com/apache/sling-slingfeature-maven-plugin/pull/16#discussion_r231562296
##
File path: src/it/analyzer-apiregions-errors-detected/pom.xml
##
@@ -0,0 +1,56 @@
+
+
+http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;>
+
+ 4.0.0
+ org.apache.sling
+ slingfeature-maven-plugin-test
+ jar
+ 1.0.0-SNAPSHOT
+
+ Apache Sling Features Maven plugin test
+
+
+
+
+@project.groupId@
+@project.artifactId@
+@project.version@
+true
+
+
+analyze
+validate
+
+ analyse-features
+
+
+
+
+
+
+ **/*.json
+ api-regions-dependencies
+
+my-global
+my-deprecated
Review comment:
I would prefix these with something common so that it's clear that they
belong to the same task, something like:
```
my-global
my-deprecated
```
I guess this is along the same lines as what @cziegeler has commented on
https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/7#issuecomment-436665548
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: 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=16678426#comment-16678426
]
ASF GitHub Bot commented on SLING-8078:
---
bosschaert commented on a change in pull request #16: SLING-8078 - New Analyser
task which is able to detect Export-Package dependencies between regions
URL:
https://github.com/apache/sling-slingfeature-maven-plugin/pull/16#discussion_r231562296
##
File path: src/it/analyzer-apiregions-errors-detected/pom.xml
##
@@ -0,0 +1,56 @@
+
+
+http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;>
+
+ 4.0.0
+ org.apache.sling
+ slingfeature-maven-plugin-test
+ jar
+ 1.0.0-SNAPSHOT
+
+ Apache Sling Features Maven plugin test
+
+
+
+
+@project.groupId@
+@project.artifactId@
+@project.version@
+true
+
+
+analyze
+validate
+
+ analyse-features
+
+
+
+
+
+
+ **/*.json
+ api-regions-dependencies
+
+my-global
+my-deprecated
Review comment:
I would prefix these with something common so that it's clear that they
belong to the same task, something like:
`
my-global
my-deprecated
`
I guess this is along the same lines as what @cziegeler has commented on
https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/7#issuecomment-436665548
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: 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 commented on a change in pull request #16: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
bosschaert commented on a change in pull request #16: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/16#discussion_r231562296 ## File path: src/it/analyzer-apiregions-errors-detected/pom.xml ## @@ -0,0 +1,56 @@ + + +http://maven.apache.org/POM/4.0.0; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd;> + + 4.0.0 + org.apache.sling + slingfeature-maven-plugin-test + jar + 1.0.0-SNAPSHOT + + Apache Sling Features Maven plugin test + + + + +@project.groupId@ +@project.artifactId@ +@project.version@ +true + + +analyze +validate + + analyse-features + + + + + + + **/*.json + api-regions-dependencies + +my-global +my-deprecated Review comment: I would prefix these with something common so that it's clear that they belong to the same task, something like: ``` my-global my-deprecated ``` I guess this is along the same lines as what @cziegeler has commented on https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/7#issuecomment-436665548 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 a change in pull request #16: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
bosschaert commented on a change in pull request #16: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/16#discussion_r231562296 ## File path: src/it/analyzer-apiregions-errors-detected/pom.xml ## @@ -0,0 +1,56 @@ + + +http://maven.apache.org/POM/4.0.0; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd;> + + 4.0.0 + org.apache.sling + slingfeature-maven-plugin-test + jar + 1.0.0-SNAPSHOT + + Apache Sling Features Maven plugin test + + + + +@project.groupId@ +@project.artifactId@ +@project.version@ +true + + +analyze +validate + + analyse-features + + + + + + + **/*.json + api-regions-dependencies + +my-global +my-deprecated Review comment: I would prefix these with something common so that it's clear that they belong to the same task, something like: ` my-global my-deprecated ` I guess this is along the same lines as what @cziegeler has commented on https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/7#issuecomment-436665548 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-7935) Consolidate all 'launchpad-testing' modules into a single git repository
[ https://issues.apache.org/jira/browse/SLING-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678424#comment-16678424 ] Robert Munteanu commented on SLING-7935: [~olli] - that's something I hadn't considered before, sorry. My medium-term plan is the following ( will send a proposal to dev@ before starting work on it ): - extract integration tests for specific bundles and move then to the respective bundle - run those ITs alongside the bundle in the regular build (this is IMO the big win) - in the launchpad-testing module, collect IT modules for modules part of the starter and run then like we do today In this scenario, the tests will be released with the bundle, so you will always refer to then by a released version. Would that work for you? > Consolidate all 'launchpad-testing' modules into a single git repository > > > Key: SLING-7935 > URL: https://issues.apache.org/jira/browse/SLING-7935 > Project: Sling > Issue Type: Task > Components: Launchpad >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Fix For: Starter 12 > > > We currently have seven testing-related modules in Git: > * org-apache-sling-launchpad-integration-tests > * org-apache-sling-launchpad-test-bundles > * org-apache-sling-launchpad-test-fragment > * org-apache-sling-launchpad-testing > * org-apache-sling-launchpad-testing-war > * org-apache-sling-launchpad-test-services > * org-apache-sling-launchpad-test-services-war > All of these are related to testing the starter application and typically we > only release them when the starter is also released. As such, it's a pain to > manually keep versions in sync and release the modules one by one. This is > one scenario where a single git repository would make sense. > Whether this should be the actual starter repository or a starter-testing one > is something that is not set in stone, but the current situation is not > optimal. -- 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=16678421#comment-16678421
]
ASF GitHub Bot commented on SLING-8078:
---
bosschaert commented on a change in pull request #16: SLING-8078 - New Analyser
task which is able to detect Export-Package dependencies between regions
URL:
https://github.com/apache/sling-slingfeature-maven-plugin/pull/16#discussion_r231560554
##
File path: src/main/java/org/apache/sling/feature/maven/mojos/Scan.java
##
@@ -41,10 +45,14 @@ public void setExcludeTask(final String name) {
return this.excludeTasks.isEmpty() ? null : this.excludeTasks;
}
+public Map getContextConfiguration() {
Review comment:
Would it be an idea to call this `taskConfiguration` instead?
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: 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 commented on a change in pull request #16: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
bosschaert commented on a change in pull request #16: SLING-8078 - New Analyser
task which is able to detect Export-Package dependencies between regions
URL:
https://github.com/apache/sling-slingfeature-maven-plugin/pull/16#discussion_r231560554
##
File path: src/main/java/org/apache/sling/feature/maven/mojos/Scan.java
##
@@ -41,10 +45,14 @@ public void setExcludeTask(final String name) {
return this.excludeTasks.isEmpty() ? null : this.excludeTasks;
}
+public Map getContextConfiguration() {
Review comment:
Would it be an idea to call this `taskConfiguration` instead?
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-8080) Almost all ITs fail after the Starter 11 release
[
https://issues.apache.org/jira/browse/SLING-8080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678415#comment-16678415
]
Robert Munteanu commented on SLING-8080:
Worked around the problem by not using pom dependencies in
[sling-org-apache-sling-launchpad-testing commit
7dab254|https://github.com/apache/sling-org-apache-sling-launchpad-testing/commit/7dab254].
[~cziegeler] - I noticed that when using pom dependencies for the feature model
slingstart and slingfeature artifacts are expanded, but not removed for the
merged provisioning model. Is this something can can/should be fixed in the
provisioning model/maven plugin?
> Almost all ITs fail after the Starter 11 release
>
>
> Key: SLING-8080
> URL: https://issues.apache.org/jira/browse/SLING-8080
> Project: Sling
> Issue Type: Bug
> Components: Starter, Testing
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Critical
>
> Almost all tests fail:
> {noformat}
> [ERROR] Tests run: 575, Failures: 561, Errors: 10, Skipped: 1
> {noformat}
> I noticed that Sling is permanently in the 'Apache Sling is starting up'
> phase.
--
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=16678396#comment-16678396
]
ASF GitHub Bot commented on SLING-8078:
---
simonetripodi commented on issue #16: SLING-8078 - New Analyser task which is
able to detect Export-Package dependencies between regions
URL:
https://github.com/apache/sling-slingfeature-maven-plugin/pull/16#issuecomment-436665191
Just to give you more background, Given a generic Feature File where
`api-regions` names are arbitrary:
```{
"id":"org.apache.sling:slingfeature-maven-plugin-test:1.0.0-SNAPSHOT",
"bundles":[
{
"id":"org.apache.aries.versioning:org.apache.aries.versioning.checker:0.3.1",
"start-level":"20"
}
],
"api-regions:JSON|false": [
{
"name": "my-global",
"exports": [
"org.apache.aries.versioning.check"
]
},
{
"name": "my-deprecated",
"exports": [
"org.objectweb.asm"
]
}
]
}```
the plugin can be now configured in order to handle that two regions:
```
**/*.json
api-regions-dependencies
my-global
my-deprecated
```
and produces expected error:
```[ERROR] Bundle
'org.apache.aries.versioning:org.apache.aries.versioning.checker:0.3.1'
(defined in feature
'org.apache.sling:slingfeature-maven-plugin-test:1.0.0-SNAPSHOT') declares
'org.apache.aries.versioning.check' in the 'Export-Package' header, enlisted in
the 'my-global' region, which requires 'org.objectweb.asm' package that is in
the 'my-deprecated' region```
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: 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-8080) Almost all ITs fail after the Starter 11 release
[
https://issues.apache.org/jira/browse/SLING-8080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678408#comment-16678408
]
Robert Munteanu commented on SLING-8080:
The last launchpad-testing version that was working for me was
[sling-org-apache-sling-launchpad-testing commit
138ff27|https://github.com/apache/sling-org-apache-sling-launchpad-testing/commit/138ff27]
. I generated a diff between the old and the new slingstart files from
{{target/slingstart-tmp/standalone/resources/provisioning/model.txt}}:
{noformat}
$ diff slingstart-{old,new}.txt
147c147
< org.apache.sling/org.apache.sling.launchpad.test-fragment/2.0.16
---
> org.apache.sling/org.apache.sling.launchpad.test-fragment/12-SNAPSHOT
150,151c150,151
< org.apache.sling/org.apache.sling.launchpad.test-services-war/2.0.16/war
< org.apache.sling/org.apache.sling.launchpad.test-services/2.0.16
---
>
> org.apache.sling/org.apache.sling.launchpad.test-services-war/12-SNAPSHOT/war
> org.apache.sling/org.apache.sling.launchpad.test-services/12-SNAPSHOT
159c159
< org.apache.sling/org.apache.sling.launchpad.test-services/2.0.16
---
> org.apache.sling/org.apache.sling.launchpad.test-services/12-SNAPSHOT
181a182,186
>
> # Dependencies
> [artifacts]
>
> org.apache.sling/org.apache.sling.launchpad.test-bundles/12-SNAPSHOT/slingfeature
> org.apache.sling/org.apache.sling.starter/12-SNAPSHOT/slingstart
{noformat}
Besides the version changes, which are expected, I see that the 'new'
slingstart file has the unprocessed dependencies to the starter and the
test-bundles artifacts still defined, which is the root cause of the error.
> Almost all ITs fail after the Starter 11 release
>
>
> Key: SLING-8080
> URL: https://issues.apache.org/jira/browse/SLING-8080
> Project: Sling
> Issue Type: Bug
> Components: Starter, Testing
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Critical
>
> Almost all tests fail:
> {noformat}
> [ERROR] Tests run: 575, Failures: 561, Errors: 10, Skipped: 1
> {noformat}
> I noticed that Sling is permanently in the 'Apache Sling is starting up'
> phase.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] cziegeler commented on issue #7: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
cziegeler commented on issue #7: 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/7#issuecomment-436665548 The patch looks good to me, the only minor thing is that we should think about prefixing the parameters with something task related, otherwise we might run into a clash between two tasks using the same parameter name. Obviously as XML is used in maven we can't use a colon, so maybe an underscore and keys will become taskname_parametername. The analyser would get such keys, and when it invokes a task it will only pass in the parameters with the right prefix or parameters not having a prefix and removes the prefix. For example if these parameters are passed into the Analyser mytask_foo=one mytask_hi=hello nexttask_bla=two debug=true and the analyser invokes the task named "mytask", the following paramters are available through the context foo=one hi=hello debug=true 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=16678401#comment-16678401
]
ASF GitHub Bot commented on SLING-8078:
---
simonetripodi edited a comment on issue #16: SLING-8078 - New Analyser task
which is able to detect Export-Package dependencies between regions
URL:
https://github.com/apache/sling-slingfeature-maven-plugin/pull/16#issuecomment-436665191
Just to give you more background, Given a generic Feature File where
`api-regions` names are arbitrary:
```
{
"id":"org.apache.sling:slingfeature-maven-plugin-test:1.0.0-SNAPSHOT",
"bundles":[
{
"id":"org.apache.aries.versioning:org.apache.aries.versioning.checker:0.3.1",
"start-level":"20"
}
],
"api-regions:JSON|false": [
{
"name": "my-global",
"exports": [
"org.apache.aries.versioning.check"
]
},
{
"name": "my-deprecated",
"exports": [
"org.objectweb.asm"
]
}
]
}
```
the plugin can be now configured in order to handle that two regions:
```
**/*.json
api-regions-dependencies
my-global
my-deprecated
```
and produces expected error:
```
[ERROR] Bundle
'org.apache.aries.versioning:org.apache.aries.versioning.checker:0.3.1'
(defined in feature
'org.apache.sling:slingfeature-maven-plugin-test:1.0.0-SNAPSHOT') declares
'org.apache.aries.versioning.check' in the 'Export-Package' header, enlisted in
the 'my-global' region, which requires 'org.objectweb.asm' package that is in
the 'my-deprecated' region
```
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: 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=16678400#comment-16678400
]
ASF GitHub Bot commented on SLING-8078:
---
cziegeler commented on issue #7: 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/7#issuecomment-436665548
The patch looks good to me, the only minor thing is that we should think
about prefixing the parameters with something task related, otherwise we might
run into a clash between two tasks using the same parameter name. Obviously as
XML is used in maven we can't use a colon, so maybe an underscore and keys will
become taskname_parametername.
The analyser would get such keys, and when it invokes a task it will only
pass in the parameters with the right prefix or parameters not having a prefix
and removes the prefix.
For example if these parameters are passed into the Analyser
mytask_foo=one
mytask_hi=hello
nexttask_bla=two
debug=true
and the analyser invokes the task named "mytask", the following paramters
are available through the context
foo=one
hi=hello
debug=true
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: 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=16678399#comment-16678399
]
ASF GitHub Bot commented on SLING-8078:
---
simonetripodi edited a comment on issue #16: SLING-8078 - New Analyser task
which is able to detect Export-Package dependencies between regions
URL:
https://github.com/apache/sling-slingfeature-maven-plugin/pull/16#issuecomment-436665191
Just to give you more background, Given a generic Feature File where
`api-regions` names are arbitrary:
```{
"id":"org.apache.sling:slingfeature-maven-plugin-test:1.0.0-SNAPSHOT",
"bundles":[
{
"id":"org.apache.aries.versioning:org.apache.aries.versioning.checker:0.3.1",
"start-level":"20"
}
],
"api-regions:JSON|false": [
{
"name": "my-global",
"exports": [
"org.apache.aries.versioning.check"
]
},
{
"name": "my-deprecated",
"exports": [
"org.objectweb.asm"
]
}
]
}```
the plugin can be now configured in order to handle that two regions:
```
**/*.json
api-regions-dependencies
my-global
my-deprecated
```
and produces expected error:
```
[ERROR] Bundle
'org.apache.aries.versioning:org.apache.aries.versioning.checker:0.3.1'
(defined in feature
'org.apache.sling:slingfeature-maven-plugin-test:1.0.0-SNAPSHOT') declares
'org.apache.aries.versioning.check' in the 'Export-Package' header, enlisted in
the 'my-global' region, which requires 'org.objectweb.asm' package that is in
the 'my-deprecated' region
```
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: 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 edited a comment on issue #16: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
simonetripodi edited a comment on issue #16: SLING-8078 - New Analyser task
which is able to detect Export-Package dependencies between regions
URL:
https://github.com/apache/sling-slingfeature-maven-plugin/pull/16#issuecomment-436665191
Just to give you more background, Given a generic Feature File where
`api-regions` names are arbitrary:
```
{
"id":"org.apache.sling:slingfeature-maven-plugin-test:1.0.0-SNAPSHOT",
"bundles":[
{
"id":"org.apache.aries.versioning:org.apache.aries.versioning.checker:0.3.1",
"start-level":"20"
}
],
"api-regions:JSON|false": [
{
"name": "my-global",
"exports": [
"org.apache.aries.versioning.check"
]
},
{
"name": "my-deprecated",
"exports": [
"org.objectweb.asm"
]
}
]
}
```
the plugin can be now configured in order to handle that two regions:
```
**/*.json
api-regions-dependencies
my-global
my-deprecated
```
and produces expected error:
```
[ERROR] Bundle
'org.apache.aries.versioning:org.apache.aries.versioning.checker:0.3.1'
(defined in feature
'org.apache.sling:slingfeature-maven-plugin-test:1.0.0-SNAPSHOT') declares
'org.apache.aries.versioning.check' in the 'Export-Package' header, enlisted in
the 'my-global' region, which requires 'org.objectweb.asm' package that is in
the 'my-deprecated' region
```
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] simonetripodi commented on issue #16: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
simonetripodi commented on issue #16: SLING-8078 - New Analyser task which is
able to detect Export-Package dependencies between regions
URL:
https://github.com/apache/sling-slingfeature-maven-plugin/pull/16#issuecomment-436665191
Just to give you more background, Given a generic Feature File where
`api-regions` names are arbitrary:
```{
"id":"org.apache.sling:slingfeature-maven-plugin-test:1.0.0-SNAPSHOT",
"bundles":[
{
"id":"org.apache.aries.versioning:org.apache.aries.versioning.checker:0.3.1",
"start-level":"20"
}
],
"api-regions:JSON|false": [
{
"name": "my-global",
"exports": [
"org.apache.aries.versioning.check"
]
},
{
"name": "my-deprecated",
"exports": [
"org.objectweb.asm"
]
}
]
}```
the plugin can be now configured in order to handle that two regions:
```
**/*.json
api-regions-dependencies
my-global
my-deprecated
```
and produces expected error:
```[ERROR] Bundle
'org.apache.aries.versioning:org.apache.aries.versioning.checker:0.3.1'
(defined in feature
'org.apache.sling:slingfeature-maven-plugin-test:1.0.0-SNAPSHOT') declares
'org.apache.aries.versioning.check' in the 'Export-Package' header, enlisted in
the 'my-global' region, which requires 'org.objectweb.asm' package that is in
the 'my-deprecated' region```
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] simonetripodi edited a comment on issue #16: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
simonetripodi edited a comment on issue #16: SLING-8078 - New Analyser task
which is able to detect Export-Package dependencies between regions
URL:
https://github.com/apache/sling-slingfeature-maven-plugin/pull/16#issuecomment-436665191
Just to give you more background, Given a generic Feature File where
`api-regions` names are arbitrary:
```{
"id":"org.apache.sling:slingfeature-maven-plugin-test:1.0.0-SNAPSHOT",
"bundles":[
{
"id":"org.apache.aries.versioning:org.apache.aries.versioning.checker:0.3.1",
"start-level":"20"
}
],
"api-regions:JSON|false": [
{
"name": "my-global",
"exports": [
"org.apache.aries.versioning.check"
]
},
{
"name": "my-deprecated",
"exports": [
"org.objectweb.asm"
]
}
]
}```
the plugin can be now configured in order to handle that two regions:
```
**/*.json
api-regions-dependencies
my-global
my-deprecated
```
and produces expected error:
```[ERROR] Bundle
'org.apache.aries.versioning:org.apache.aries.versioning.checker:0.3.1'
(defined in feature
'org.apache.sling:slingfeature-maven-plugin-test:1.0.0-SNAPSHOT') declares
'org.apache.aries.versioning.check' in the 'Export-Package' header, enlisted in
the 'my-global' region, which requires 'org.objectweb.asm' package that is in
the 'my-deprecated' region```
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=16678397#comment-16678397
]
ASF GitHub Bot commented on SLING-8078:
---
simonetripodi edited a comment on issue #16: SLING-8078 - New Analyser task
which is able to detect Export-Package dependencies between regions
URL:
https://github.com/apache/sling-slingfeature-maven-plugin/pull/16#issuecomment-436665191
Just to give you more background, Given a generic Feature File where
`api-regions` names are arbitrary:
```{
"id":"org.apache.sling:slingfeature-maven-plugin-test:1.0.0-SNAPSHOT",
"bundles":[
{
"id":"org.apache.aries.versioning:org.apache.aries.versioning.checker:0.3.1",
"start-level":"20"
}
],
"api-regions:JSON|false": [
{
"name": "my-global",
"exports": [
"org.apache.aries.versioning.check"
]
},
{
"name": "my-deprecated",
"exports": [
"org.objectweb.asm"
]
}
]
}```
the plugin can be now configured in order to handle that two regions:
```
**/*.json
api-regions-dependencies
my-global
my-deprecated
```
and produces expected error:
```[ERROR] Bundle
'org.apache.aries.versioning:org.apache.aries.versioning.checker:0.3.1'
(defined in feature
'org.apache.sling:slingfeature-maven-plugin-test:1.0.0-SNAPSHOT') declares
'org.apache.aries.versioning.check' in the 'Export-Package' header, enlisted in
the 'my-global' region, which requires 'org.objectweb.asm' package that is in
the 'my-deprecated' region```
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: 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 edited a comment on issue #16: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
simonetripodi edited a comment on issue #16: SLING-8078 - New Analyser task
which is able to detect Export-Package dependencies between regions
URL:
https://github.com/apache/sling-slingfeature-maven-plugin/pull/16#issuecomment-436665191
Just to give you more background, Given a generic Feature File where
`api-regions` names are arbitrary:
```{
"id":"org.apache.sling:slingfeature-maven-plugin-test:1.0.0-SNAPSHOT",
"bundles":[
{
"id":"org.apache.aries.versioning:org.apache.aries.versioning.checker:0.3.1",
"start-level":"20"
}
],
"api-regions:JSON|false": [
{
"name": "my-global",
"exports": [
"org.apache.aries.versioning.check"
]
},
{
"name": "my-deprecated",
"exports": [
"org.objectweb.asm"
]
}
]
}```
the plugin can be now configured in order to handle that two regions:
```
**/*.json
api-regions-dependencies
my-global
my-deprecated
```
and produces expected error:
```
[ERROR] Bundle
'org.apache.aries.versioning:org.apache.aries.versioning.checker:0.3.1'
(defined in feature
'org.apache.sling:slingfeature-maven-plugin-test:1.0.0-SNAPSHOT') declares
'org.apache.aries.versioning.check' in the 'Export-Package' header, enlisted in
the 'my-global' region, which requires 'org.objectweb.asm' package that is in
the 'my-deprecated' region
```
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=16678391#comment-16678391
]
ASF GitHub Bot commented on SLING-8078:
---
simonetripodi commented on issue #7: 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/7#issuecomment-436663909
@cziegeler required modifications included in latest commit
@bosschaert requested show case is included in
https://github.com/apache/sling-slingfeature-maven-plugin/pull/16 Integration
Test
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: 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 #7: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
simonetripodi commented on issue #7: 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/7#issuecomment-436663909 @cziegeler required modifications included in latest commit @bosschaert requested show case is included in https://github.com/apache/sling-slingfeature-maven-plugin/pull/16 Integration Test 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=16678389#comment-16678389
]
ASF GitHub Bot commented on SLING-8078:
---
simonetripodi opened a new pull request #16: SLING-8078 - New Analyser task
which is able to detect Export-Package dependencies between regions
URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/16
AnalyseFeaturesMojo modified in order to include the context configuration
this PR requires
https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/7 - the
MOJO is now able to configure the context configuration so api-regions name
dependencies can be arbitrary.
The PR includes Integration Test
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: 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 #16: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
simonetripodi opened a new pull request #16: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/16 AnalyseFeaturesMojo modified in order to include the context configuration this PR requires https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/7 - the MOJO is now able to configure the context configuration so api-regions name dependencies can be arbitrary. The PR includes Integration Test 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-7930) Provide default ServiceUserMapped services
[ https://issues.apache.org/jira/browse/SLING-7930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved SLING-7930. --- Resolution: Fixed Basically, I think this issues comes down to two things namely, only provide ServiceUserMapped services for mappings where the service user is valid provide ServiceUserMapped service(s) for the default user (if any). In regard to 1) it turns out, we already have verification around - we just didn't use it for the mappings. Consequently, I just piggyback on the existing verification and only make services available that have a valid service user (i.e., filter out all that don't). That should work ok for the case where we don't have jcr around as in that case there is no verifier (and hence, all service users are valid) - unless somebody provides a different one (i.e., it is up to the resource providers to provide verifiers). In regard to 2) I publish a default ServiceUserMapped in case default user is enabled (or provided). I then turn around in the hooks and make sure it is a valid one (its a little more complicated in there because we don't want to check for them unless we have to as that generated warnings). Done in https://github.com/apache/sling-org-apache-sling-serviceusermapper/pull/1 > Provide default ServiceUserMapped services > -- > > Key: SLING-7930 > URL: https://issues.apache.org/jira/browse/SLING-7930 > Project: Sling > Issue Type: Improvement > Components: Service User Mapper >Reporter: Carsten Ziegeler >Assignee: Karl Pauls >Priority: Major > Fix For: Service User Mapper 1.4.4 > > > One goal of Sling is to be configurationless. With SLING-6772, the service > user mapper module introduces a default for service user mappings. However > this does not include registering a ServiceUserMapped service - but, other > services in the system have a reference on such services to ensure that a > mapping is available. > In addition, currently ServiceUserMapped only ensures that a "mapping" is > available, but not the service user itself > This has been recently discussed in the Sling mailing list > [https://lists.apache.org/thread.html/b7a00588cd6c44078d38572b38002965916c9f18dedd9a64380428ad@%3Cdev.sling.apache.org%3E] > > We would use the existing service hooks to see if for any given > ServiceUserMapped requested we can actually log into all registered resource > providers that require authentication and are not lazy. If a login exception > occurs, it's not available and we don't register the ServiceUserMapped. > Obviously, if a resource provider gets added that requires authentication and > is not lazy we need to recheck but this way we at least would neither exposes > service users to the world nor, require API changes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-7930) Provide default ServiceUserMapped services
[ https://issues.apache.org/jira/browse/SLING-7930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls updated SLING-7930: -- Fix Version/s: Service User Mapper 1.4.4 > Provide default ServiceUserMapped services > -- > > Key: SLING-7930 > URL: https://issues.apache.org/jira/browse/SLING-7930 > Project: Sling > Issue Type: Improvement > Components: Service User Mapper >Reporter: Carsten Ziegeler >Assignee: Karl Pauls >Priority: Major > Fix For: Service User Mapper 1.4.4 > > > One goal of Sling is to be configurationless. With SLING-6772, the service > user mapper module introduces a default for service user mappings. However > this does not include registering a ServiceUserMapped service - but, other > services in the system have a reference on such services to ensure that a > mapping is available. > In addition, currently ServiceUserMapped only ensures that a "mapping" is > available, but not the service user itself > This has been recently discussed in the Sling mailing list > [https://lists.apache.org/thread.html/b7a00588cd6c44078d38572b38002965916c9f18dedd9a64380428ad@%3Cdev.sling.apache.org%3E] > > We would use the existing service hooks to see if for any given > ServiceUserMapped requested we can actually log into all registered resource > providers that require authentication and are not lazy. If a login exception > occurs, it's not available and we don't register the ServiceUserMapped. > Obviously, if a resource provider gets added that requires authentication and > is not lazy we need to recheck but this way we at least would neither exposes > service users to the world nor, require API changes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] karlpauls closed pull request #1: Initial attempt on providing default ServiceUserMapped and only mappi…
karlpauls closed pull request #1: Initial attempt on providing default ServiceUserMapped and only mappi… URL: https://github.com/apache/sling-org-apache-sling-serviceusermapper/pull/1 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-8080) Almost all ITs fail after the Starter 11 release
[
https://issues.apache.org/jira/browse/SLING-8080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678366#comment-16678366
]
Robert Munteanu commented on SLING-8080:
The OSGi installer status page shows we have two untransformed resources:
{noformat}Untransformed Resources
---
Files:
- 1541603668000/50,
launchpad:resources/install/0/org.apache.sling.starter-12-SNAPSHOT.jar
- 1541603668000/50,
launchpad:resources/install/0/org.apache.sling.launchpad.test-bundles-12-SNAPSHOT.txt
{noformat}
> Almost all ITs fail after the Starter 11 release
>
>
> Key: SLING-8080
> URL: https://issues.apache.org/jira/browse/SLING-8080
> Project: Sling
> Issue Type: Bug
> Components: Starter, Testing
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Critical
>
> Almost all tests fail:
> {noformat}
> [ERROR] Tests run: 575, Failures: 561, Errors: 10, Skipped: 1
> {noformat}
> I noticed that Sling is permanently in the 'Apache Sling is starting up'
> phase.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-8080) Almost all ITs fail after the Starter 11 release
[
https://issues.apache.org/jira/browse/SLING-8080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-8080:
---
Priority: Critical (was: Major)
> Almost all ITs fail after the Starter 11 release
>
>
> Key: SLING-8080
> URL: https://issues.apache.org/jira/browse/SLING-8080
> Project: Sling
> Issue Type: Bug
> Components: Starter, Testing
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Critical
>
> Almost all tests fail:
> {noformat}
> [ERROR] Tests run: 575, Failures: 561, Errors: 10, Skipped: 1
> {noformat}
> I noticed that Sling is permanently in the 'Apache Sling is starting up'
> phase.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SLING-8080) Almost all ITs fail after the Starter 11 release
Robert Munteanu created SLING-8080:
--
Summary: Almost all ITs fail after the Starter 11 release
Key: SLING-8080
URL: https://issues.apache.org/jira/browse/SLING-8080
Project: Sling
Issue Type: Bug
Components: Starter, Testing
Reporter: Robert Munteanu
Assignee: Robert Munteanu
Almost all tests fail:
{noformat}
[ERROR] Tests run: 575, Failures: 561, Errors: 10, Skipped: 1
{noformat}
I noticed that Sling is permanently in the 'Apache Sling is starting up' phase.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [VOTE] Release Apache Sling Distributed Event Admin 1.1.4
+1 > On 23 Oct 2018, at 17:21, Robert Munteanu wrote: > > 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. > > Thanks, > > Robert
Re: [VOTE] Release Apache Sling Distributed Event Admin 1.1.4
Anyone else? Thanks, Robert
[jira] [Commented] (SLING-7545) Groovy Scripting Engine not loading in Apache Sling 10
[
https://issues.apache.org/jira/browse/SLING-7545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678289#comment-16678289
]
Robert Munteanu commented on SLING-7545:
[~fortuna] - Sling 11 contains the latest version of scripting.core - there was
no release done with the fixes for this bug. I've made a note to start a
release this week.
> Groovy Scripting Engine not loading in Apache Sling 10
> --
>
> Key: SLING-7545
> URL: https://issues.apache.org/jira/browse/SLING-7545
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting Core 2.0.54
>Reporter: Ben Fortuna
>Assignee: Bertrand Delacretaz
>Priority: Major
> Fix For: Scripting Core 2.0.56
>
>
> With the latest release of Apache Sling (10) the Groovy Scripting engine is
> no longer loading.
> The impact is that scripts with a (*.groovy) extension aren't rendering.
> This works with Apache Sling 9, so I believe there was a change in the Apache
> Sling Scripting Core that broke the Groovy implementation.
>
> How to reproduce:
> Load groovy-all JAR into Apache Sling as a bundle, under the url
> [http://localhost:8080/system/console/status-slingscripting] the following
> should display:
> {code:java}
> Groovy Scripting Engine 2.0
> -
> - Language : Groovy, 2.4.14
> - Extensions : groovy
> - MIME Types : application/x-groovy
> - Names : groovy, Groovy{code}
>
> This works with Apache Sling 9, not with Sling 10
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [Feature Model] Initial API Regions implementation
Thanks Robert! David On Wed, 7 Nov 2018 at 12:47, Robert Munteanu wrote: > Hi David, > > On Wed, 2018-11-07 at 12:01 +, David Bosschaert wrote: > > Hi all, > > > > I started migrating the code from the sling-whiteboard to individual > > repositories. > > The final step is to add the sources to the kibble demo instance > > http://demo.kibble.apache.org > > > > When I add > > https://github.com/apache/sling-org-apache-sling-feature-apiregions.git > > > https://github.com/apache/sling-org-apache-sling-feature-extension-apiregions.git > > as new github sources, Kibble responds with: > > "You don't have permission to add sources to this organisation." > > > > Anyone an idea? > > Apparently the demo user does not have rights, you need to sign up with > a different user. I've added them myself and will update the > documentation to reflect that information. > > Thanks, > > Robert > > > > > David > > > > On Wed, 7 Nov 2018 at 10:57, Carsten Ziegeler > > wrote: > > > > > +1 to gradudate > > > > > > Carsten > > > > > > Am 06.11.2018 um 16:50 schrieb David Bosschaert: > > > > Hi all, > > > > > > > > Over the past little while I have worked on an implementation for > > > > a > > > runtime > > > > enforcement component for API Regions for Sling Features [1]. > > > > > > > > The implementation is based on 2 components. > > > > > > > > a. Merge/PostProcessor handlers that work on the 'api-regions' > > > > section in > > > > the feature files. These components know how to merge api-regions > > > sections > > > > into a target feature and the PostProcessor handlers generate a > > > > number of > > > > properties files that drive the runtime enforcement > > > > implementation of > > > this. > > > > For details see [2]. > > > > > > > > b. The runtime component which is implemented as an OSGi > > > > Framework > > > > extension bundle. Registers a ResolverHookFactory service with > > > > the > > > > framework which is consulted by the OSGi resolver. The hook can > > > > prevent > > > > certain resolutions from happening and is driven by the > > > > properties files > > > > generated by the process in a. to enforce the regions as defined > > > > in the > > > > feature files. For details see [3]. > > > > > > > > Currently these two new components [2][3] are in the sling- > > > > whiteboard, > > > but > > > > it would be great to graduate them out of there into their own > > > > Sling > > > > repositories. Does the sling community think that this would be > > > > the right > > > > thing to do? > > > > > > > > Many thanks, > > > > > > > > David > > > > > > > > [1] > > > > > > > > https://github.com/apache/sling-org-apache-sling-feature/blob/master/apicontroller.md > > > > [2] > > > > > > > > https://github.com/apache/sling-whiteboard/tree/master/featuremodel/feature-extension-apiregions > > > > [3] > > > > > > > > https://github.com/apache/sling-whiteboard/tree/master/featuremodel/feature-apiregions > > > > > > -- > > > Carsten Ziegeler > > > Adobe Research Switzerland > > > cziege...@apache.org > > > > > >
Re: [VOTE] Release Apache Sling App CMS version 0.11.0
+1 > On 7 Nov 2018, at 01:57, Daniel Klco wrote: > > 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.
[jira] [Commented] (SLING-8047) Rendered/exported JSON requested via SlingRequestProcessor is not written to output stream
[
https://issues.apache.org/jira/browse/SLING-8047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678258#comment-16678258
]
Philip Mundt commented on SLING-8047:
-
[~jsedding] thanks again for your alternative fix. I allowed myself to rebase
your commit in my fork and add a test case for the underlying issue. I'd be
happy to hear/get your input on it.
> Rendered/exported JSON requested via SlingRequestProcessor is not written to
> output stream
> --
>
> Key: SLING-8047
> URL: https://issues.apache.org/jira/browse/SLING-8047
> Project: Sling
> Issue Type: Bug
> Components: Servlets
>Reporter: Philip Mundt
>Assignee: Jason E Bailey
>Priority: Major
> Attachments:
> SLING-8047-DefaultGetServlet-does-not-write-to-output-stream.patch,
> SLING-8047-ExportServlet-does-not-write-to-output-stream.patch
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> While trying to facilitate the {{SlingRequestProcessor}} to get a rendered or
> exported JSON representation of a resource, we ran into the problem of the
> response always being empty. The HTML rendering worked without any issue.
> (See example code of [Get the rendered HTML for an AEM resource, component or
> page|http://www.nateyolles.com/blog/2015/10/get-rendered-html-for-an-aem-resource-or-component]
> or [https://stackoverflow.com/a/34218708])
> Main, observed difference seem to be the method calls to print writer:
> h4. JsonRenderer
> {{org.apache.sling.servlets.get.impl.helpers.JsonRenderer#render}} uses
> {{#write}} method of response's print writer.
> h4. ExportServlet (via JacksonExporter)
> {{org.apache.sling.models.impl.ExportServlet#doGet}} uses {{#write}} method
> of response's print writer.
> h4. HTMLRenderer
> {{org.apache.sling.servlets.get.impl.helpers.HtmlRenderer#render}} uses
> {{#print}} and {{#println}} methods of response's print writer.
> h3. Further observations
> When the print writer's {{autoFlush}} property is set to true and one uses
> the {{#println}} method instead of {{#write}}, the {{JsonRenderer}} will
> flush the print writer's buffer to the output stream. Due to wrapping the
> response in
> {{org.apache.sling.scripting.core.impl.helper.OnDemandWriterResponse}} (where
> {{autoFlush=false}}) this does not work for the {{ExportServlet}}.
> When adding implicit {{#flush()}} calls to both classes, both request
> scenarios will work. According to the servlet specification, it should not be
> necessary to flush the print writer, as the container must immediately flush
> all remaining content to the client upon "termination of the service method
> of the servlet".
> Please find two test cases for (where implicit {{#flush()}} calls were added):
> * JsonRenderer ({{sling-org-apache-sling-servlets-get}}):
> [^SLING-8047-DefaultGetServlet-does-not-write-to-output-stream.patch]
> * ExportServlet ({{sling-org-apache-sling-models-impl}}):
> [^SLING-8047-ExportServlet-does-not-write-to-output-stream.patch]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] philipmundt opened a new pull request #5: SLING-8047 Flush response's buffer once request has been processed
philipmundt opened a new pull request #5: SLING-8047 Flush response's buffer once request has been processed URL: https://github.com/apache/sling-org-apache-sling-engine/pull/5 Rendered/exported JSON requested via `SlingRequestProcessor` was previously not written to output stream. 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 App CMS version 0.11.0
+1 non-binding - Jason On Wed, Nov 7, 2018, at 8:08 AM, Robert Munteanu wrote: > On Tue, 2018-11-06 at 19:57 -0500, Daniel Klco wrote: > > Please vote to approve this release: > > +1 > > Robert > Email had 1 attachment: > + signature.asc > 1k (application/pgp-signature)
[jira] [Commented] (SLING-7545) Groovy Scripting Engine not loading in Apache Sling 10
[
https://issues.apache.org/jira/browse/SLING-7545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678230#comment-16678230
]
Ben Fortuna commented on SLING-7545:
[~bdelacretaz] just curious to note that the latest Sling release (V11) doesn't
include the latest sling-scripting-core bundle (still using 2.0.54).
Any reason why this fix wasn't included? Many thanks.
> Groovy Scripting Engine not loading in Apache Sling 10
> --
>
> Key: SLING-7545
> URL: https://issues.apache.org/jira/browse/SLING-7545
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Affects Versions: Scripting Core 2.0.54
>Reporter: Ben Fortuna
>Assignee: Bertrand Delacretaz
>Priority: Major
> Fix For: Scripting Core 2.0.56
>
>
> With the latest release of Apache Sling (10) the Groovy Scripting engine is
> no longer loading.
> The impact is that scripts with a (*.groovy) extension aren't rendering.
> This works with Apache Sling 9, so I believe there was a change in the Apache
> Sling Scripting Core that broke the Groovy implementation.
>
> How to reproduce:
> Load groovy-all JAR into Apache Sling as a bundle, under the url
> [http://localhost:8080/system/console/status-slingscripting] the following
> should display:
> {code:java}
> Groovy Scripting Engine 2.0
> -
> - Language : Groovy, 2.4.14
> - Extensions : groovy
> - MIME Types : application/x-groovy
> - Names : groovy, Groovy{code}
>
> This works with Apache Sling 9, not with Sling 10
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [VOTE] Release Apache Sling App CMS version 0.11.0
On Tue, 2018-11-06 at 19:57 -0500, Daniel Klco wrote: > Please vote to approve this release: +1 Robert signature.asc Description: This is a digitally signed message part
[VOTE RESULT] Release Apache Sling Engine 2.6.16
I think we can close this vote now. The vote passes with four binding +1 votes, no other votes have been cast. Regards Carstem -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Sling Engine 2.6.16
+1 Am 07.11.2018 um 11:52 schrieb Karl Pauls: +1 regards, Karl On Mon, Oct 29, 2018 at 8:31 PM Daniel Klco wrote: +1 On Mon, Oct 29, 2018 at 10:47 AM Robert Munteanu wrote: On Mon, 2018-10-29 at 15:29 +0100, Julian Sedding wrote: Please vote to approve this release: +1 Robert -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [Feature Model] Initial API Regions implementation
Hi David, On Wed, 2018-11-07 at 12:01 +, David Bosschaert wrote: > Hi all, > > I started migrating the code from the sling-whiteboard to individual > repositories. > The final step is to add the sources to the kibble demo instance > http://demo.kibble.apache.org > > When I add > https://github.com/apache/sling-org-apache-sling-feature-apiregions.git > https://github.com/apache/sling-org-apache-sling-feature-extension-apiregions.git > as new github sources, Kibble responds with: > "You don't have permission to add sources to this organisation." > > Anyone an idea? Apparently the demo user does not have rights, you need to sign up with a different user. I've added them myself and will update the documentation to reflect that information. Thanks, Robert > > David > > On Wed, 7 Nov 2018 at 10:57, Carsten Ziegeler > wrote: > > > +1 to gradudate > > > > Carsten > > > > Am 06.11.2018 um 16:50 schrieb David Bosschaert: > > > Hi all, > > > > > > Over the past little while I have worked on an implementation for > > > a > > runtime > > > enforcement component for API Regions for Sling Features [1]. > > > > > > The implementation is based on 2 components. > > > > > > a. Merge/PostProcessor handlers that work on the 'api-regions' > > > section in > > > the feature files. These components know how to merge api-regions > > sections > > > into a target feature and the PostProcessor handlers generate a > > > number of > > > properties files that drive the runtime enforcement > > > implementation of > > this. > > > For details see [2]. > > > > > > b. The runtime component which is implemented as an OSGi > > > Framework > > > extension bundle. Registers a ResolverHookFactory service with > > > the > > > framework which is consulted by the OSGi resolver. The hook can > > > prevent > > > certain resolutions from happening and is driven by the > > > properties files > > > generated by the process in a. to enforce the regions as defined > > > in the > > > feature files. For details see [3]. > > > > > > Currently these two new components [2][3] are in the sling- > > > whiteboard, > > but > > > it would be great to graduate them out of there into their own > > > Sling > > > repositories. Does the sling community think that this would be > > > the right > > > thing to do? > > > > > > Many thanks, > > > > > > David > > > > > > [1] > > > > > https://github.com/apache/sling-org-apache-sling-feature/blob/master/apicontroller.md > > > [2] > > > > > https://github.com/apache/sling-whiteboard/tree/master/featuremodel/feature-extension-apiregions > > > [3] > > > > > https://github.com/apache/sling-whiteboard/tree/master/featuremodel/feature-apiregions > > > > -- > > Carsten Ziegeler > > Adobe Research Switzerland > > cziege...@apache.org > >
[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=16678156#comment-16678156
]
ASF GitHub Bot commented on SLING-8078:
---
simonetripodi commented on issue #7: 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/7#issuecomment-436609252
Thanks for the feedback @cziegeler , I'll modify the PR according to your
suggestions, I'll also submit a PR for the slingfeature-m-p with an IT showing
the use case (I am already on that, but I need to modify it)
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: 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 #7: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
simonetripodi commented on issue #7: 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/7#issuecomment-436609252 Thanks for the feedback @cziegeler , I'll modify the PR according to your suggestions, I'll also submit a PR for the slingfeature-m-p with an IT showing the use case (I am already on that, but I need to modify it) 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 App CMS version 0.11.0
+1 On Tue, Nov 6, 2018 at 6:57 PM Daniel Klco wrote: > Hi, > > We solved 24 issues in this release: > https://issues.apache.org/jira/projects/SLING/versions/12344150 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-2008/ > > 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 2008 /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. >
Re: [Feature Model] Initial API Regions implementation
Hi all, I started migrating the code from the sling-whiteboard to individual repositories. The final step is to add the sources to the kibble demo instance http://demo.kibble.apache.org When I add https://github.com/apache/sling-org-apache-sling-feature-apiregions.git https://github.com/apache/sling-org-apache-sling-feature-extension-apiregions.git as new github sources, Kibble responds with: "You don't have permission to add sources to this organisation." Anyone an idea? David On Wed, 7 Nov 2018 at 10:57, Carsten Ziegeler wrote: > +1 to gradudate > > Carsten > > Am 06.11.2018 um 16:50 schrieb David Bosschaert: > > Hi all, > > > > Over the past little while I have worked on an implementation for a > runtime > > enforcement component for API Regions for Sling Features [1]. > > > > The implementation is based on 2 components. > > > > a. Merge/PostProcessor handlers that work on the 'api-regions' section in > > the feature files. These components know how to merge api-regions > sections > > into a target feature and the PostProcessor handlers generate a number of > > properties files that drive the runtime enforcement implementation of > this. > > For details see [2]. > > > > b. The runtime component which is implemented as an OSGi Framework > > extension bundle. Registers a ResolverHookFactory service with the > > framework which is consulted by the OSGi resolver. The hook can prevent > > certain resolutions from happening and is driven by the properties files > > generated by the process in a. to enforce the regions as defined in the > > feature files. For details see [3]. > > > > Currently these two new components [2][3] are in the sling-whiteboard, > but > > it would be great to graduate them out of there into their own Sling > > repositories. Does the sling community think that this would be the right > > thing to do? > > > > Many thanks, > > > > David > > > > [1] > > > https://github.com/apache/sling-org-apache-sling-feature/blob/master/apicontroller.md > > [2] > > > https://github.com/apache/sling-whiteboard/tree/master/featuremodel/feature-extension-apiregions > > [3] > > > https://github.com/apache/sling-whiteboard/tree/master/featuremodel/feature-apiregions > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org >
[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=16678087#comment-16678087
]
ASF GitHub Bot commented on SLING-8078:
---
cziegeler commented on issue #7: 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/7#issuecomment-436595682
I think the parameters should either be part of the constructor or become an
additional argument of the scan method. Right now, once you construct a
scanner, it can be shared without side effects. With introducing a setter
method for the properties, this changes and someone calling it can cause
problems to another one using the same shared instance.
As these properties influence the tasks which are set using the constructor
I think the parameters should be come part of the constructor as well
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: 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] cziegeler commented on issue #7: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
cziegeler commented on issue #7: 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/7#issuecomment-436595682 I think the parameters should either be part of the constructor or become an additional argument of the scan method. Right now, once you construct a scanner, it can be shared without side effects. With introducing a setter method for the properties, this changes and someone calling it can cause problems to another one using the same shared instance. As these properties influence the tasks which are set using the constructor I think the parameters should be come part of the constructor as well 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-8079) Returning false in a model PostConstruct causes an java.lang.IllegalStateException
[
https://issues.apache.org/jira/browse/SLING-8079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678060#comment-16678060
]
Santiago García Pimentel commented on SLING-8079:
-
One difficulty is that the createModel method is not expected to return null,
so an exception must be thrown, but Im not sure which one.
> Returning false in a model PostConstruct causes an
> java.lang.IllegalStateException
> --
>
> Key: SLING-8079
> URL: https://issues.apache.org/jira/browse/SLING-8079
> Project: Sling
> Issue Type: Bug
>Affects Versions: Sling Models Impl 1.4.10
>Reporter: Santiago García Pimentel
>Priority: Major
>
> I was just trying the exporter framework and the feature from SLING-7124,
> where you can return false in a post construct to prevent a model to being
> returned.
> Unfortunately I found myself with an IllegalStateException:
>
> {quote}java.lang.IllegalStateException: No throwable available at
> org.apache.sling.models.impl.Result.getThrowable(Result.java:61) at
> org.apache.sling.models.impl.ModelAdapterFactory.createModel(ModelAdapterFactory.java:316)
> at
> org.apache.sling.models.impl.ExportServlet$RequestAccessor.getExportedString(ExportServlet.java:202)
> at org.apache.sling.models.impl.ExportServlet.doGet(ExportServlet.java:106)
> at
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.mayService(SlingSafeMethodsServlet.java:266)
> at
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:342)
> at
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:374)
> at
> org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:552){quote}
> It seems like the ModelAdapterFactory assumes that there should be an
> exception if a model was not returned, which is no longer the case. I don't
> think this exception should be thrown.
> The easiest solution I think is to make o.a.s.models.impl.Result not throw
> that exception and let the ModelAdapterFactory handle it, but Im not sure
> that would the be most appropriate way.
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-8079) Returning false in a model PostConstruct causes an java.lang.IllegalStateException
[
https://issues.apache.org/jira/browse/SLING-8079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Santiago García Pimentel updated SLING-8079:
Description:
I was just trying the exporter framework and the feature from SLING-7124, where
you can return false in a post construct to prevent a model to being returned.
Unfortunately I found myself with an IllegalStateException:
{quote}java.lang.IllegalStateException: No throwable available at
org.apache.sling.models.impl.Result.getThrowable(Result.java:61) at
org.apache.sling.models.impl.ModelAdapterFactory.createModel(ModelAdapterFactory.java:316)
at
org.apache.sling.models.impl.ExportServlet$RequestAccessor.getExportedString(ExportServlet.java:202)
at org.apache.sling.models.impl.ExportServlet.doGet(ExportServlet.java:106) at
org.apache.sling.api.servlets.SlingSafeMethodsServlet.mayService(SlingSafeMethodsServlet.java:266)
at
org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:342)
at
org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:374)
at
org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:552){quote}
It seems like the ModelAdapterFactory assumes that there should be an exception
if a model was not returned, which is no longer the case. I don't think this
exception should be thrown.
The easiest solution I think is to make o.a.s.models.impl.Result not throw that
exception and let the ModelAdapterFactory handle it, but Im not sure that would
the be most appropriate way.
was:
I was just trying the exporter framework and the feature from SLING-7124, where
you can return false in a post construct to prevent a model to being returned.
Unfortunately I found myself with an IllegalStateException:
{quote}java.lang.IllegalStateException: No throwable available at
org.apache.sling.models.impl.Result.getThrowable(Result.java:61) at
org.apache.sling.models.impl.ModelAdapterFactory.createModel(ModelAdapterFactory.java:263)
at
org.apache.sling.models.impl.ExportServlet$RequestAccessor.getExportedString(ExportServlet.java:202)
at org.apache.sling.models.impl.ExportServlet.doGet(ExportServlet.java:106) at
org.apache.sling.api.servlets.SlingSafeMethodsServlet.mayService(SlingSafeMethodsServlet.java:266)
at
org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:342)
at
org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:374){quote}
It seems like the ModelAdapterFactory assumes that there should be an exception
if a model was not returned, which is no longer the case. I don't think this
exception should be thrown.
The easiest solution I think is to make o.a.s.models.impl.Result not throw that
exception and let the ModelAdapterFactory handle it, but Im not sure that would
the be most appropriate way.
> Returning false in a model PostConstruct causes an
> java.lang.IllegalStateException
> --
>
> Key: SLING-8079
> URL: https://issues.apache.org/jira/browse/SLING-8079
> Project: Sling
> Issue Type: Bug
>Affects Versions: Sling Models Impl 1.4.10
>Reporter: Santiago García Pimentel
>Priority: Major
>
> I was just trying the exporter framework and the feature from SLING-7124,
> where you can return false in a post construct to prevent a model to being
> returned.
> Unfortunately I found myself with an IllegalStateException:
>
> {quote}java.lang.IllegalStateException: No throwable available at
> org.apache.sling.models.impl.Result.getThrowable(Result.java:61) at
> org.apache.sling.models.impl.ModelAdapterFactory.createModel(ModelAdapterFactory.java:316)
> at
> org.apache.sling.models.impl.ExportServlet$RequestAccessor.getExportedString(ExportServlet.java:202)
> at org.apache.sling.models.impl.ExportServlet.doGet(ExportServlet.java:106)
> at
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.mayService(SlingSafeMethodsServlet.java:266)
> at
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:342)
> at
> org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:374)
> at
> org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:552){quote}
> It seems like the ModelAdapterFactory assumes that there should be an
> exception if a model was not returned, which is no longer the case. I don't
> think this exception should be thrown.
> The easiest solution I think is to make o.a.s.models.impl.Result not throw
> that exception and let the ModelAdapterFactory handle it, but Im not sure
> that would the be most appropriate way.
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SLING-8079) Returning false in a model PostConstruct causes an java.lang.IllegalStateException
Santiago García Pimentel created SLING-8079:
---
Summary: Returning false in a model PostConstruct causes an
java.lang.IllegalStateException
Key: SLING-8079
URL: https://issues.apache.org/jira/browse/SLING-8079
Project: Sling
Issue Type: Bug
Affects Versions: Sling Models Impl 1.4.10
Reporter: Santiago García Pimentel
I was just trying the exporter framework and the feature from SLING-7124, where
you can return false in a post construct to prevent a model to being returned.
Unfortunately I found myself with an IllegalStateException:
{quote}java.lang.IllegalStateException: No throwable available at
org.apache.sling.models.impl.Result.getThrowable(Result.java:61) at
org.apache.sling.models.impl.ModelAdapterFactory.createModel(ModelAdapterFactory.java:263)
at
org.apache.sling.models.impl.ExportServlet$RequestAccessor.getExportedString(ExportServlet.java:202)
at org.apache.sling.models.impl.ExportServlet.doGet(ExportServlet.java:106) at
org.apache.sling.api.servlets.SlingSafeMethodsServlet.mayService(SlingSafeMethodsServlet.java:266)
at
org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:342)
at
org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:374){quote}
It seems like the ModelAdapterFactory assumes that there should be an exception
if a model was not returned, which is no longer the case. I don't think this
exception should be thrown.
The easiest solution I think is to make o.a.s.models.impl.Result not throw that
exception and let the ModelAdapterFactory handle it, but Im not sure that would
the be most appropriate way.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] cziegeler commented on issue #1: Initial attempt on providing default ServiceUserMapped and only mappi…
cziegeler commented on issue #1: Initial attempt on providing default ServiceUserMapped and only mappi… URL: https://github.com/apache/sling-org-apache-sling-serviceusermapper/pull/1#issuecomment-436589108 @karlpauls The patch and described behaviour looks basically good to me, I think we should get it in and see what happens :) 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: [Feature Model] Initial API Regions implementation
+1 to gradudate Carsten Am 06.11.2018 um 16:50 schrieb David Bosschaert: Hi all, Over the past little while I have worked on an implementation for a runtime enforcement component for API Regions for Sling Features [1]. The implementation is based on 2 components. a. Merge/PostProcessor handlers that work on the 'api-regions' section in the feature files. These components know how to merge api-regions sections into a target feature and the PostProcessor handlers generate a number of properties files that drive the runtime enforcement implementation of this. For details see [2]. b. The runtime component which is implemented as an OSGi Framework extension bundle. Registers a ResolverHookFactory service with the framework which is consulted by the OSGi resolver. The hook can prevent certain resolutions from happening and is driven by the properties files generated by the process in a. to enforce the regions as defined in the feature files. For details see [3]. Currently these two new components [2][3] are in the sling-whiteboard, but it would be great to graduate them out of there into their own Sling repositories. Does the sling community think that this would be the right thing to do? Many thanks, David [1] https://github.com/apache/sling-org-apache-sling-feature/blob/master/apicontroller.md [2] https://github.com/apache/sling-whiteboard/tree/master/featuremodel/feature-extension-apiregions [3] https://github.com/apache/sling-whiteboard/tree/master/featuremodel/feature-apiregions -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Sling Engine 2.6.16
+1 regards, Karl On Mon, Oct 29, 2018 at 8:31 PM Daniel Klco wrote: > > +1 > > On Mon, Oct 29, 2018 at 10:47 AM Robert Munteanu wrote: > > > On Mon, 2018-10-29 at 15:29 +0100, Julian Sedding wrote: > > > Please vote to approve this release: > > > > +1 > > > > Robert > > -- Karl Pauls karlpa...@gmail.com
Re: [Feature Model] Initial API Regions implementation
Thanks Radu and Robert, I was looking here instead: https://sling.apache.org/project-information.html#source-repository I'll add the 'Using Git with Sling' link to that page as well. Best regards, David On Wed, 7 Nov 2018 at 10:14, Robert Munteanu wrote: > On Wed, 2018-11-07 at 11:04 +0100, Radu Cotescu wrote: > > Hi David, > > > > I was pointed to [0] recently, when I had to create a new repository > > for the HTL runtime. > > > > > On 7 Nov 2018, at 09:32, David Bosschaert < > > > david.bosscha...@gmail.com> wrote: > > > > > > Are there any sling-specific instructions on how to create these > > > repos? > > I've done a quick update to that page to reflect some things that have > changed, see [1]. > > Robert > > > > > Cheers, > > Radu > > > > [0] - > > https://cwiki.apache.org/confluence/display/SLING/Using+Git+with+Sling > > [1]: > https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=75957583=4=5 > >
[GitHub] karlpauls commented on issue #6: Configurable startup timeout.
karlpauls commented on issue #6: Configurable startup timeout. URL: https://github.com/apache/sling-org-apache-sling-feature-launcher/pull/6#issuecomment-436578644 @trekawek, makes sense - thanks a lot! 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] karlpauls closed pull request #6: Configurable startup timeout.
karlpauls closed pull request #6: Configurable startup timeout.
URL: https://github.com/apache/sling-org-apache-sling-feature-launcher/pull/6
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/src/main/java/org/apache/sling/feature/launcher/impl/launchers/FrameworkRunner.java
b/src/main/java/org/apache/sling/feature/launcher/impl/launchers/FrameworkRunner.java
index 7546b02..3f3ebb6 100644
---
a/src/main/java/org/apache/sling/feature/launcher/impl/launchers/FrameworkRunner.java
+++
b/src/main/java/org/apache/sling/feature/launcher/impl/launchers/FrameworkRunner.java
@@ -34,6 +34,8 @@
*/
public class FrameworkRunner extends AbstractRunner {
+private static final String START_TIMEOUT =
"sling.framework.start.timeout";
+
private static final String SHUTDOWN_GRACE_TIME =
"sling.framework.shutdown.graceTime";
private volatile int type = -1;
@@ -59,13 +61,13 @@ public FrameworkRunner(final Map
frameworkProperties,
// initialize the framework
framework.init();
-long graceTime =
Long.parseLong(frameworkProperties.getOrDefault(SHUTDOWN_GRACE_TIME, "6"));
+long graceTime =
Long.parseLong(frameworkProperties.getOrDefault(SHUTDOWN_GRACE_TIME, "60"));
Runtime.getRuntime().addShutdownHook(new Thread() {
@Override
public void run() {
try {
framework.stop();
-FrameworkEvent waitForStop =
framework.waitForStop(graceTime);
+FrameworkEvent waitForStop =
framework.waitForStop(graceTime * 1000);
if (waitForStop.getType() != FrameworkEvent.STOPPED)
{
Main.LOG().warn("Framework stopped with: " +
waitForStop.getType(), waitForStop.getThrowable());
@@ -85,10 +87,11 @@ public void run() {
long time = System.currentTimeMillis();
+long startTimeout =
Long.parseLong(frameworkProperties.getOrDefault(START_TIMEOUT,
String.valueOf(10 * 60)));
// finally start
-if (!this.startFramework(framework, 10, TimeUnit.MINUTES)) {
-throw new TimeoutException("Waited for more than 10 minutes to
startup framework.");
+if (!this.startFramework(framework, startTimeout, TimeUnit.SECONDS)) {
+throw new TimeoutException("Waited for more than " + startTimeout
+ " seconds to startup framework.");
}
Main.LOG().debug("Startup took: " + (System.currentTimeMillis() -
time));
@@ -96,8 +99,8 @@ public void run() {
while ((type = framework.waitForStop(Long.MAX_VALUE).getType()) ==
FrameworkEvent.STOPPED_UPDATE) {
Main.LOG().info("Framework restart due to update");
time = System.currentTimeMillis();
-if (!this.startFramework(framework, 10, TimeUnit.MINUTES)) {
-throw new TimeoutException("Waited for more than 10 minutes to
startup framework.");
+if (!this.startFramework(framework, startTimeout,
TimeUnit.SECONDS)) {
+throw new TimeoutException("Waited for more than " +
startTimeout + " seconds to startup framework.");
}
Main.LOG().debug("Restart took: " + (System.currentTimeMillis() -
time));
}
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-8058) Make configuration of slingfeature-maven-plugin consistent
[
https://issues.apache.org/jira/browse/SLING-8058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved SLING-8058.
-
Resolution: Fixed
> Make configuration of slingfeature-maven-plugin consistent
> --
>
> Key: SLING-8058
> URL: https://issues.apache.org/jira/browse/SLING-8058
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model, Maven Plugins and Archetypes
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0
>
>
> The slingfeature-maven-plugin as 2 goals: aggregate-features and repository
> that both have slightly different ways of selecting included features. Then
> it's also possibly to select via includes at the top level configuration of
> the feature.
> The top-level includes specifies the initial set of feature files used, the
> other goals can then refine this subset.
> We should make these consistent.
> They should have the same way to:
> 1. include/exclude feature files from the total set
> 2. refer to a feature file in a maven repository
> 3. refer to an aggregated feature done in the same pom, e.g. by just
> referring to its classifier, e.g.
> The code that handles this should probably be shared in the ProjectHelper and
> it might make sense to create a new shared parent base class, e.g.
> AbstractIncludingFeatureMojo extends AbstractFeatureMojo to hold the fields
> or something like this.
> The way it works is:
> * The plugin is configured with a directory (features parameter), includes
> and excludes for that directory (featuresIncludes, featuresExcludes
> parameters) - all of these are defined in the AbstractFeatureMojo
> * There is a similar set for testing features in the AbstractFeatureMojo
> * The DependencyLifecycleParticipant for the plugin triggers the Preprocessor
> which uses all of the above information to create the set of available
> features for this project, let's call it the global set of features
> * The global set of features is the set of features every mojo should use.
> The mojo gets them through the ProjectHelper
> * The above mechanism should stay as is and as the Preprocessor is the only
> one reading the above mentioned parameters, they are private and not to be
> used by any mojo directly
> * The aggregate and the repository mojo (and potentially more mojos in the
> future) use the above created global set of features and *further* filter it
> using includes and excludes. These are additional includes/excludes that only
> work on this global set, therefore they should not be part of the
> AbstractFeatureMojo
> * All these mojos (aggregate and repository) should use the same
> configuration and work similar with selecting features
> * It makes sense to create a new abstract class to unify this selection, this
> abstract class would inherit from AbstractFeatureMojo, add the additional
> includes/excludes handling and be used by the mojos like the aggregate and
> the repository mojo
> I suggest we use the following general configuration format.
> For includes, excludes of files from the current projects
> {noformat}
>
>base.json
>something/*.json
>something/badfile.json
>
> {noformat}
> For features from external projects
> {noformat}
>
> etc.
>
> {noformat}
> For aggregates from the same project
> {noformat}
> CLASSIFIER_NAME
> {noformat}
> The configuration for the aggregate mojo is then:
> {noformat}
>
> *
> *
> *
>
> {noformat}
> The configuration for the repository mojo becomes similarly:
> {noformat}
>
> *
> *
> *
> *
>
> {noformat}
> Note that the repository mojo gets an additional configuration for artifacts
> to be added to the repository, these are not features
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-8058) Make configuration of slingfeature-maven-plugin consistent
[
https://issues.apache.org/jira/browse/SLING-8058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677993#comment-16677993
]
Carsten Ziegeler commented on SLING-8058:
-
I've updated the analysis mojo in rev 870f428. The analysis mojo without any
additonal configuration works as before. But you can also specify a list of
scans:
{noformat}
{noformat}
> Make configuration of slingfeature-maven-plugin consistent
> --
>
> Key: SLING-8058
> URL: https://issues.apache.org/jira/browse/SLING-8058
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model, Maven Plugins and Archetypes
>Reporter: Carsten Ziegeler
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0
>
>
> The slingfeature-maven-plugin as 2 goals: aggregate-features and repository
> that both have slightly different ways of selecting included features. Then
> it's also possibly to select via includes at the top level configuration of
> the feature.
> The top-level includes specifies the initial set of feature files used, the
> other goals can then refine this subset.
> We should make these consistent.
> They should have the same way to:
> 1. include/exclude feature files from the total set
> 2. refer to a feature file in a maven repository
> 3. refer to an aggregated feature done in the same pom, e.g. by just
> referring to its classifier, e.g.
> The code that handles this should probably be shared in the ProjectHelper and
> it might make sense to create a new shared parent base class, e.g.
> AbstractIncludingFeatureMojo extends AbstractFeatureMojo to hold the fields
> or something like this.
> The way it works is:
> * The plugin is configured with a directory (features parameter), includes
> and excludes for that directory (featuresIncludes, featuresExcludes
> parameters) - all of these are defined in the AbstractFeatureMojo
> * There is a similar set for testing features in the AbstractFeatureMojo
> * The DependencyLifecycleParticipant for the plugin triggers the Preprocessor
> which uses all of the above information to create the set of available
> features for this project, let's call it the global set of features
> * The global set of features is the set of features every mojo should use.
> The mojo gets them through the ProjectHelper
> * The above mechanism should stay as is and as the Preprocessor is the only
> one reading the above mentioned parameters, they are private and not to be
> used by any mojo directly
> * The aggregate and the repository mojo (and potentially more mojos in the
> future) use the above created global set of features and *further* filter it
> using includes and excludes. These are additional includes/excludes that only
> work on this global set, therefore they should not be part of the
> AbstractFeatureMojo
> * All these mojos (aggregate and repository) should use the same
> configuration and work similar with selecting features
> * It makes sense to create a new abstract class to unify this selection, this
> abstract class would inherit from AbstractFeatureMojo, add the additional
> includes/excludes handling and be used by the mojos like the aggregate and
> the repository mojo
> I suggest we use the following general configuration format.
> For includes, excludes of files from the current projects
> {noformat}
>
>base.json
>something/*.json
>something/badfile.json
>
> {noformat}
> For features from external projects
> {noformat}
>
> etc.
>
> {noformat}
> For aggregates from the same project
> {noformat}
> CLASSIFIER_NAME
> {noformat}
> The configuration for the aggregate mojo is then:
> {noformat}
>
> *
> *
> *
>
> {noformat}
> The configuration for the repository mojo becomes similarly:
> {noformat}
>
> *
> *
> *
> *
>
> {noformat}
> Note that the repository mojo gets an additional configuration for artifacts
> to be added to the repository, these are not features
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (SLING-8058) Make configuration of slingfeature-maven-plugin consistent
[
https://issues.apache.org/jira/browse/SLING-8058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler reassigned SLING-8058:
---
Assignee: Carsten Ziegeler
> Make configuration of slingfeature-maven-plugin consistent
> --
>
> Key: SLING-8058
> URL: https://issues.apache.org/jira/browse/SLING-8058
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model, Maven Plugins and Archetypes
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0
>
>
> The slingfeature-maven-plugin as 2 goals: aggregate-features and repository
> that both have slightly different ways of selecting included features. Then
> it's also possibly to select via includes at the top level configuration of
> the feature.
> The top-level includes specifies the initial set of feature files used, the
> other goals can then refine this subset.
> We should make these consistent.
> They should have the same way to:
> 1. include/exclude feature files from the total set
> 2. refer to a feature file in a maven repository
> 3. refer to an aggregated feature done in the same pom, e.g. by just
> referring to its classifier, e.g.
> The code that handles this should probably be shared in the ProjectHelper and
> it might make sense to create a new shared parent base class, e.g.
> AbstractIncludingFeatureMojo extends AbstractFeatureMojo to hold the fields
> or something like this.
> The way it works is:
> * The plugin is configured with a directory (features parameter), includes
> and excludes for that directory (featuresIncludes, featuresExcludes
> parameters) - all of these are defined in the AbstractFeatureMojo
> * There is a similar set for testing features in the AbstractFeatureMojo
> * The DependencyLifecycleParticipant for the plugin triggers the Preprocessor
> which uses all of the above information to create the set of available
> features for this project, let's call it the global set of features
> * The global set of features is the set of features every mojo should use.
> The mojo gets them through the ProjectHelper
> * The above mechanism should stay as is and as the Preprocessor is the only
> one reading the above mentioned parameters, they are private and not to be
> used by any mojo directly
> * The aggregate and the repository mojo (and potentially more mojos in the
> future) use the above created global set of features and *further* filter it
> using includes and excludes. These are additional includes/excludes that only
> work on this global set, therefore they should not be part of the
> AbstractFeatureMojo
> * All these mojos (aggregate and repository) should use the same
> configuration and work similar with selecting features
> * It makes sense to create a new abstract class to unify this selection, this
> abstract class would inherit from AbstractFeatureMojo, add the additional
> includes/excludes handling and be used by the mojos like the aggregate and
> the repository mojo
> I suggest we use the following general configuration format.
> For includes, excludes of files from the current projects
> {noformat}
>
>base.json
>something/*.json
>something/badfile.json
>
> {noformat}
> For features from external projects
> {noformat}
>
> etc.
>
> {noformat}
> For aggregates from the same project
> {noformat}
> CLASSIFIER_NAME
> {noformat}
> The configuration for the aggregate mojo is then:
> {noformat}
>
> *
> *
> *
>
> {noformat}
> The configuration for the repository mojo becomes similarly:
> {noformat}
>
> *
> *
> *
> *
>
> {noformat}
> Note that the repository mojo gets an additional configuration for artifacts
> to be added to the repository, these are not features
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [Feature Model] Initial API Regions implementation
On Wed, 2018-11-07 at 11:04 +0100, Radu Cotescu wrote: > Hi David, > > I was pointed to [0] recently, when I had to create a new repository > for the HTL runtime. > > > On 7 Nov 2018, at 09:32, David Bosschaert < > > david.bosscha...@gmail.com> wrote: > > > > Are there any sling-specific instructions on how to create these > > repos? I've done a quick update to that page to reflect some things that have changed, see [1]. Robert > > Cheers, > Radu > > [0] - > https://cwiki.apache.org/confluence/display/SLING/Using+Git+with+Sling [1]: https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=75957583=4=5
Re: [Feature Model] Initial API Regions implementation
Hi David, I was pointed to [0] recently, when I had to create a new repository for the HTL runtime. > On 7 Nov 2018, at 09:32, David Bosschaert wrote: > > Are there any sling-specific instructions on how to create these repos? Cheers, Radu [0] - https://cwiki.apache.org/confluence/display/SLING/Using+Git+with+Sling
[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=16677941#comment-16677941
]
ASF GitHub Bot commented on SLING-8078:
---
bosschaert commented on issue #7: 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/7#issuecomment-436569075
Hi @simonetripodi thanks for this PR. For me to understand it better, could
you please provide a pom.xml snippet that shows how this would be configured in
practise?
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: 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 commented on issue #7: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
bosschaert commented on issue #7: 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/7#issuecomment-436569075 Hi @simonetripodi thanks for this PR. For me to understand it better, could you please provide a pom.xml snippet that shows how this would be configured in practise? 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] trekawek opened a new pull request #6: Configurable startup timeout.
trekawek opened a new pull request #6: Configurable startup timeout. URL: https://github.com/apache/sling-org-apache-sling-feature-launcher/pull/6 Similarly to #5, let's have a configurable startup timeout. - introduced new framework property `sling.framework.start.timeout` (in seconds) - changed the unit of `sling.framework.shutdown.graceTime` to seconds, to make it consistent 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-8058) Make configuration of slingfeature-maven-plugin consistent
[
https://issues.apache.org/jira/browse/SLING-8058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677904#comment-16677904
]
Carsten Ziegeler commented on SLING-8058:
-
I've updated the repository mojos in rev f035d8d. The repository mojo without
any additonal configuration works as before. But you can also specify a list of
repositories:
{noformat}
{noformat}
> Make configuration of slingfeature-maven-plugin consistent
> --
>
> Key: SLING-8058
> URL: https://issues.apache.org/jira/browse/SLING-8058
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model, Maven Plugins and Archetypes
>Reporter: Carsten Ziegeler
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0
>
>
> The slingfeature-maven-plugin as 2 goals: aggregate-features and repository
> that both have slightly different ways of selecting included features. Then
> it's also possibly to select via includes at the top level configuration of
> the feature.
> The top-level includes specifies the initial set of feature files used, the
> other goals can then refine this subset.
> We should make these consistent.
> They should have the same way to:
> 1. include/exclude feature files from the total set
> 2. refer to a feature file in a maven repository
> 3. refer to an aggregated feature done in the same pom, e.g. by just
> referring to its classifier, e.g.
> The code that handles this should probably be shared in the ProjectHelper and
> it might make sense to create a new shared parent base class, e.g.
> AbstractIncludingFeatureMojo extends AbstractFeatureMojo to hold the fields
> or something like this.
> The way it works is:
> * The plugin is configured with a directory (features parameter), includes
> and excludes for that directory (featuresIncludes, featuresExcludes
> parameters) - all of these are defined in the AbstractFeatureMojo
> * There is a similar set for testing features in the AbstractFeatureMojo
> * The DependencyLifecycleParticipant for the plugin triggers the Preprocessor
> which uses all of the above information to create the set of available
> features for this project, let's call it the global set of features
> * The global set of features is the set of features every mojo should use.
> The mojo gets them through the ProjectHelper
> * The above mechanism should stay as is and as the Preprocessor is the only
> one reading the above mentioned parameters, they are private and not to be
> used by any mojo directly
> * The aggregate and the repository mojo (and potentially more mojos in the
> future) use the above created global set of features and *further* filter it
> using includes and excludes. These are additional includes/excludes that only
> work on this global set, therefore they should not be part of the
> AbstractFeatureMojo
> * All these mojos (aggregate and repository) should use the same
> configuration and work similar with selecting features
> * It makes sense to create a new abstract class to unify this selection, this
> abstract class would inherit from AbstractFeatureMojo, add the additional
> includes/excludes handling and be used by the mojos like the aggregate and
> the repository mojo
> I suggest we use the following general configuration format.
> For includes, excludes of files from the current projects
> {noformat}
>
>base.json
>something/*.json
>something/badfile.json
>
> {noformat}
> For features from external projects
> {noformat}
>
> etc.
>
> {noformat}
> For aggregates from the same project
> {noformat}
> CLASSIFIER_NAME
> {noformat}
> The configuration for the aggregate mojo is then:
> {noformat}
>
> *
> *
> *
>
> {noformat}
> The configuration for the repository mojo becomes similarly:
> {noformat}
>
> *
> *
> *
> *
>
> {noformat}
> Note that the repository mojo gets an additional configuration for artifacts
> to be added to the repository, these are not features
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SLING-8058) Make configuration of slingfeature-maven-plugin consistent
[
https://issues.apache.org/jira/browse/SLING-8058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677823#comment-16677823
]
Carsten Ziegeler edited comment on SLING-8058 at 11/7/18 8:34 AM:
--
In rev 5d06826 I've adjusted the AggregateFeaturesMojo to use the new
configuration mechanism. The configuration for the mojo now looks like this:
{noformat}
{noformat}
was (Author: cziegeler):
In rev 5d06826 I've adjusted the AggregateFeaturesMojo to use the new
configuration mechanism. The configuration for the mojo now looks like this:
{noformat}
{noformat}
> Make configuration of slingfeature-maven-plugin consistent
> --
>
> Key: SLING-8058
> URL: https://issues.apache.org/jira/browse/SLING-8058
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model, Maven Plugins and Archetypes
>Reporter: Carsten Ziegeler
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0
>
>
> The slingfeature-maven-plugin as 2 goals: aggregate-features and repository
> that both have slightly different ways of selecting included features. Then
> it's also possibly to select via includes at the top level configuration of
> the feature.
> The top-level includes specifies the initial set of feature files used, the
> other goals can then refine this subset.
> We should make these consistent.
> They should have the same way to:
> 1. include/exclude feature files from the total set
> 2. refer to a feature file in a maven repository
> 3. refer to an aggregated feature done in the same pom, e.g. by just
> referring to its classifier, e.g.
> The code that handles this should probably be shared in the ProjectHelper and
> it might make sense to create a new shared parent base class, e.g.
> AbstractIncludingFeatureMojo extends AbstractFeatureMojo to hold the fields
> or something like this.
> The way it works is:
> * The plugin is configured with a directory (features parameter), includes
> and excludes for that directory (featuresIncludes, featuresExcludes
> parameters) - all of these are defined in the AbstractFeatureMojo
> * There is a similar set for testing features in the AbstractFeatureMojo
> * The DependencyLifecycleParticipant for the plugin triggers the Preprocessor
> which uses all of the above information to create the set of available
> features for this project, let's call it the global set of features
> * The global set of features is the set of features every mojo should use.
> The mojo gets them through the ProjectHelper
> * The above mechanism should stay as is and as the Preprocessor is the only
> one reading the above mentioned parameters, they are private and not to be
> used by any mojo directly
> * The aggregate and the repository mojo (and potentially more mojos in the
> future) use the above created global set of features and *further* filter it
> using includes and excludes. These are additional includes/excludes that only
> work on this global set, therefore they should not be part of the
> AbstractFeatureMojo
> * All these mojos (aggregate and repository) should use the same
> configuration and work similar with selecting features
> * It makes sense to create a new abstract class to unify this selection, this
> abstract class would inherit from AbstractFeatureMojo, add the additional
> includes/excludes handling and be used by the mojos like the aggregate and
> the repository mojo
> I suggest we use the following general configuration format.
> For includes, excludes of files from the current projects
> {noformat}
>
>base.json
>something/*.json
>something/badfile.json
>
> {noformat}
> For features from external projects
> {noformat}
>
> etc.
>
> {noformat}
> For aggregates from the same project
> {noformat}
> CLASSIFIER_NAME
> {noformat}
> The configuration for the aggregate mojo is then:
> {noformat}
>
> *
> *
> *
>
> {noformat}
> The configuration for the repository mojo becomes similarly:
> {noformat}
>
> *
> *
> *
> *
>
> {noformat}
> Note that the repository mojo gets an additional configuration for artifacts
> to be added to the repository, these are not features
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SLING-8058) Make configuration of slingfeature-maven-plugin consistent
[
https://issues.apache.org/jira/browse/SLING-8058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676350#comment-16676350
]
Carsten Ziegeler edited comment on SLING-8058 at 11/7/18 8:33 AM:
--
Due to the way the maven mojo mapping works, the actual syntax for the
configuration is slightly different than above. This is the current
implementation of the FeatureSelectionConfig:
{noformat}
**/*.json
foo.json
lalalla
g
a
1.0
g2
a2
2.0
foo
myclassifier
aggregate
{noformat}
The various mojos can use this approach by creating a configuration subclass of
FeatureSelectionConfig (an example is the AggregateConfig class) and the mojo
should extend AbstractIncludingFeatureMojo and call
getSelectedFeatures(config) with the config object to get all selected features.
was (Author: cziegeler):
Due to the way the maven mojo mapping works, the actual syntax for the
configuration is slightly different than above. This is the current
implementation of the FeatureSelectionConfig:
{noformat}
**/*.json
foo.json
lalalla
g
a
1.0
g2
a2
2.0
foo
myclassifier
aggregate
{noformat}
The various mojos can use this approach by creating a configuration subclass of
FeatureSelectionConfig (an example is the AggregateConfig class) and the mojo
should extend AbstractIncludingFeatureMojo and call
getSelectedFeatures(config) with the config object to get all selected features.
Please note that AggregateConfig should be named Aggregate but that would clash
with the current mojos. As soon as the mojos are changed to use this new
approach the renaming can be done. (Maven looks for a class in the same project
based on the property name)
> Make configuration of slingfeature-maven-plugin consistent
> --
>
> Key: SLING-8058
> URL: https://issues.apache.org/jira/browse/SLING-8058
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model, Maven Plugins and Archetypes
>Reporter: Carsten Ziegeler
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0
>
>
> The slingfeature-maven-plugin as 2 goals: aggregate-features and repository
> that both have slightly different ways of selecting included features. Then
> it's also possibly to select via includes at the top level configuration of
> the feature.
> The top-level includes specifies the initial set of feature files used, the
> other goals can then refine this subset.
> We should make these consistent.
> They should have the same way to:
> 1. include/exclude feature files from the total set
> 2. refer to a feature file in a maven repository
> 3. refer to an aggregated feature done in the same pom, e.g. by just
> referring to its classifier, e.g.
> The code that handles this should probably be shared in the ProjectHelper and
> it might make sense to create a new shared parent base class, e.g.
> AbstractIncludingFeatureMojo extends AbstractFeatureMojo to hold the fields
> or something like this.
> The way it works is:
> * The plugin is configured with a directory (features parameter), includes
> and excludes for that directory (featuresIncludes, featuresExcludes
> parameters) - all of these are defined in the AbstractFeatureMojo
> * There is a similar set for testing features in the AbstractFeatureMojo
> * The DependencyLifecycleParticipant for the plugin triggers the Preprocessor
> which uses all of the above information to create the set of available
> features for this project, let's call it the global set of features
> * The global
Re: [Feature Model] Initial API Regions implementation
Hi all, If nobody objects I'd like to create two new Sling Git Repositories for this: sling-org-apache-sling-feature-extension-apiregions for the extension handlers and sling-org-apache-sling-feature-apiregions for the runtime framework extension bundle. Are there any sling-specific instructions on how to create these repos? Best regards David On Tue, 6 Nov 2018 at 15:50, David Bosschaert wrote: > Hi all, > > Over the past little while I have worked on an implementation for a > runtime enforcement component for API Regions for Sling Features [1]. > > The implementation is based on 2 components. > > a. Merge/PostProcessor handlers that work on the 'api-regions' section in > the feature files. These components know how to merge api-regions sections > into a target feature and the PostProcessor handlers generate a number of > properties files that drive the runtime enforcement implementation of this. > For details see [2]. > > b. The runtime component which is implemented as an OSGi Framework > extension bundle. Registers a ResolverHookFactory service with the > framework which is consulted by the OSGi resolver. The hook can prevent > certain resolutions from happening and is driven by the properties files > generated by the process in a. to enforce the regions as defined in the > feature files. For details see [3]. > > Currently these two new components [2][3] are in the sling-whiteboard, but > it would be great to graduate them out of there into their own Sling > repositories. Does the sling community think that this would be the right > thing to do? > > Many thanks, > > David > > [1] > https://github.com/apache/sling-org-apache-sling-feature/blob/master/apicontroller.md > [2] > https://github.com/apache/sling-whiteboard/tree/master/featuremodel/feature-extension-apiregions > [3] > https://github.com/apache/sling-whiteboard/tree/master/featuremodel/feature-apiregions >
[jira] [Commented] (SLING-8058) Make configuration of slingfeature-maven-plugin consistent
[
https://issues.apache.org/jira/browse/SLING-8058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677823#comment-16677823
]
Carsten Ziegeler commented on SLING-8058:
-
In rev 5d06826 I've adjusted the AggregateFeaturesMojo to use the new
configuration mechanism. The configuration for the mojo now looks like this:
{noformat}
{noformat}
> Make configuration of slingfeature-maven-plugin consistent
> --
>
> Key: SLING-8058
> URL: https://issues.apache.org/jira/browse/SLING-8058
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model, Maven Plugins and Archetypes
>Reporter: Carsten Ziegeler
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0
>
>
> The slingfeature-maven-plugin as 2 goals: aggregate-features and repository
> that both have slightly different ways of selecting included features. Then
> it's also possibly to select via includes at the top level configuration of
> the feature.
> The top-level includes specifies the initial set of feature files used, the
> other goals can then refine this subset.
> We should make these consistent.
> They should have the same way to:
> 1. include/exclude feature files from the total set
> 2. refer to a feature file in a maven repository
> 3. refer to an aggregated feature done in the same pom, e.g. by just
> referring to its classifier, e.g.
> The code that handles this should probably be shared in the ProjectHelper and
> it might make sense to create a new shared parent base class, e.g.
> AbstractIncludingFeatureMojo extends AbstractFeatureMojo to hold the fields
> or something like this.
> The way it works is:
> * The plugin is configured with a directory (features parameter), includes
> and excludes for that directory (featuresIncludes, featuresExcludes
> parameters) - all of these are defined in the AbstractFeatureMojo
> * There is a similar set for testing features in the AbstractFeatureMojo
> * The DependencyLifecycleParticipant for the plugin triggers the Preprocessor
> which uses all of the above information to create the set of available
> features for this project, let's call it the global set of features
> * The global set of features is the set of features every mojo should use.
> The mojo gets them through the ProjectHelper
> * The above mechanism should stay as is and as the Preprocessor is the only
> one reading the above mentioned parameters, they are private and not to be
> used by any mojo directly
> * The aggregate and the repository mojo (and potentially more mojos in the
> future) use the above created global set of features and *further* filter it
> using includes and excludes. These are additional includes/excludes that only
> work on this global set, therefore they should not be part of the
> AbstractFeatureMojo
> * All these mojos (aggregate and repository) should use the same
> configuration and work similar with selecting features
> * It makes sense to create a new abstract class to unify this selection, this
> abstract class would inherit from AbstractFeatureMojo, add the additional
> includes/excludes handling and be used by the mojos like the aggregate and
> the repository mojo
> I suggest we use the following general configuration format.
> For includes, excludes of files from the current projects
> {noformat}
>
>base.json
>something/*.json
>something/badfile.json
>
> {noformat}
> For features from external projects
> {noformat}
>
> etc.
>
> {noformat}
> For aggregates from the same project
> {noformat}
> CLASSIFIER_NAME
> {noformat}
> The configuration for the aggregate mojo is then:
> {noformat}
>
> *
> *
> *
>
> {noformat}
> The configuration for the repository mojo becomes similarly:
> {noformat}
>
> *
> *
> *
> *
>
> {noformat}
> Note that the repository mojo gets an additional configuration for artifacts
> to be added to the repository, these are not features
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
