[VOTE] Release Apache Sling App CMS version 0.11.0
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.
[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=16677388#comment-16677388
]
ASF GitHub Bot commented on SLING-8078:
---
simonetripodi opened a new pull request #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
Hi there @bosschaert ,
Please find my Analyser "parametrisation" proposal: auxiliary arguments can
be taken by the Analyser itself in a Properties instance, which holds
configuration parameters, that can be taken by any task via the context.
That looked the less-intrusive modification to current codebase in order to
not break any possible backward compatibility.
Once this will be applied, it would be quiet easy to let the Analyser being
configured from the slingfeature-m-p
Any feedback will be more than appreciated.
/CC @cziegeler
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)
Re: [VOTE] Release Apache Sling Models API 1.3.8
+1 On 2018-11-06 15:14, Radu Cotescu wrote: +1 On 5 Nov 2018, at 19:00, Stefan Seifert 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.
[GitHub] simonetripodi opened a new pull request #7: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
simonetripodi opened a new pull request #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 Hi there @bosschaert , Please find my Analyser "parametrisation" proposal: auxiliary arguments can be taken by the Analyser itself in a Properties instance, which holds configuration parameters, that can be taken by any task via the context. That looked the less-intrusive modification to current codebase in order to not break any possible backward compatibility. Once this will be applied, it would be quiet easy to let the Analyser being configured from the slingfeature-m-p Any feedback will be more than appreciated. /CC @cziegeler 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-8060) Sling Testing Mocks: Transitive dependencies necessary at test execution time should be defined with scope "compile"
[
https://issues.apache.org/jira/browse/SLING-8060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677008#comment-16677008
]
Stefan Seifert commented on SLING-8060:
---
the using project might use a different OSGi version - in the past this was R5
vs. R6, now it will be R6 vs. R7 (although we have no explicit R7 support yet
in OSGi mock). and the problem with the different artifact ids depending which
alternative you use to address the OSGi artifacts as described above.
i'm not fully against setting the OSGi dependencies to compile scope, but fear
that it may create no only benefits but also problems for the using projects.
and we change the current behavior.
> Sling Testing Mocks: Transitive dependencies necessary at test execution time
> should be defined with scope "compile"
>
>
> Key: SLING-8060
> URL: https://issues.apache.org/jira/browse/SLING-8060
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Affects Versions: Testing OSGi Mock 2.4.2, Testing Sling Mock 2.3.4
>Reporter: Konrad Windszus
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently Testing OSGi Mock and Testing Sling Mock have a class execution
> time dependency to e.g. OSGi Configuration Admin and Event Admin (in
> https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/b04e06522379d32552353304746fbcdb09258460/core/src/main/java/org/apache/sling/testing/mock/osgi/MockOsgi.java#L312
> and in
> https://github.com/apache/sling-org-apache-sling-testing-sling-mock/blob/ef994bfbc9ae2288c66ef8be7fd3997913cc9144/core/src/main/java/org/apache/sling/testing/mock/sling/ResourceResolverFactoryInitializer.java#L42).
> Still the dependency to it is only defined with scope "provided" in
> https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/b04e06522379d32552353304746fbcdb09258460/parent/pom.xml#L49
> and
> https://github.com/apache/sling-org-apache-sling-testing-sling-mock/blob/986bdfbbf6c3f5f416d6acc24329eb431f67494a/core/pom.xml#L37.
> That is a problem as transitive dependencies with scope "provided" are not
> included in the classpath. That may lead to the fact that the
> ConfigurationAdmin/EventAdmin is not part of the testing classpath (in case
> it isn't explicitly defined for some other reason) . Please make sure that
> all dependencies which are actually always necessary at test execution time
> are included with scope "compile"
> (https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope).
> This issue does not happen that often, as in most of the cases the to be
> tested modules already define an explicit dependency to
> {{org.osgi:osgi.cmpn}} and {{org.osgi:osgi.core}}, but since nowadays the
> OSGi foundation provides not only the aggregate dependencies but also
> individual ones, this is no longer necessarily the case (compare with
> https://issues.apache.org/jira/browse/SLING-7384?focusedCommentId=16327433=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16327433).
> At the same time of converting the dependency scope to "compile" we should
> switch from the aggregate to the individual osgi artifacts (to be able to
> more granularly define which OSGi level is used).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-8077) Transform ContentOrderMergeProcessor into MergeHandler
[
https://issues.apache.org/jira/browse/SLING-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676960#comment-16676960
]
ASF GitHub Bot commented on SLING-8077:
---
bosschaert closed pull request #2: SLING-8077 - refactor
ContentorderMergeProcessor to MergeHandler adju…
URL:
https://github.com/apache/sling-org-apache-sling-feature-extension-content/pull/2
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/extension/content/ContentOrderMergeProcessor.java
b/src/main/java/org/apache/sling/feature/extension/content/ContentOrderMergeProcessor.java
index f85f18a..05b1133 100644
---
a/src/main/java/org/apache/sling/feature/extension/content/ContentOrderMergeProcessor.java
+++
b/src/main/java/org/apache/sling/feature/extension/content/ContentOrderMergeProcessor.java
@@ -23,25 +23,50 @@
import org.apache.sling.feature.FeatureConstants;
import org.apache.sling.feature.KeyValueMap;
import org.apache.sling.feature.builder.HandlerContext;
+import org.apache.sling.feature.builder.MergeHandler;
import org.apache.sling.feature.builder.PostProcessHandler;
-public class ContentOrderMergeProcessor implements PostProcessHandler {
+public class ContentOrderMergeProcessor implements MergeHandler {
private static final String DEFAULT_CONTENT_START_ORDER =
"default.content.startorder";
-@Override
-public void postProcess(HandlerContext context, Feature feature, Extension
extension) {
-if (extension.getType() == ExtensionType.ARTIFACTS
-&&
extension.getName().equals(FeatureConstants.EXTENSION_NAME_CONTENT_PACKAGES)) {
-String defaultOrder =
feature.getVariables().get(DEFAULT_CONTENT_START_ORDER);
-if (defaultOrder != null) {
-for (Artifact a : extension.getArtifacts()) {
-KeyValueMap kvm = a.getMetadata();
-if(kvm.get(Artifact.KEY_START_ORDER) == null) {
-kvm.put(Artifact.KEY_START_ORDER, defaultOrder);
-}
+private void processFeature(HandlerContext context, Feature feature,
Extension extension) {
+String defaultOrder =
feature.getVariables().get(DEFAULT_CONTENT_START_ORDER);
+if (defaultOrder != null) {
+for (Artifact a : extension.getArtifacts()) {
+KeyValueMap kvm = a.getMetadata();
+if(kvm.get(Artifact.KEY_START_ORDER) == null) {
+kvm.put(Artifact.KEY_START_ORDER, defaultOrder);
}
-feature.getVariables().remove(DEFAULT_CONTENT_START_ORDER);
+}
+feature.getVariables().remove(DEFAULT_CONTENT_START_ORDER);
+}
+}
+
+@Override
+public boolean canMerge(Extension extension) {
+return extension.getType() == ExtensionType.ARTIFACTS
+&&
extension.getName().equals(FeatureConstants.EXTENSION_NAME_CONTENT_PACKAGES);
+}
+
+@Override
+public void merge(HandlerContext context, Feature target, Feature source,
Extension targetEx, Extension sourceEx) {
+if (targetEx == null) {
+target.getExtensions().add(sourceEx);
+return;
+}
+processFeature(context, target, targetEx);
+processFeature(context, source, sourceEx);
+for (final Artifact a : sourceEx.getArtifacts()) {
+boolean replace = true;
+final Artifact existing =
targetEx.getArtifacts().getSame(a.getId());
+if (existing != null &&
existing.getId().getOSGiVersion().compareTo(a.getId().getOSGiVersion()) > 0) {
+replace = false;
+}
+
+if (replace) {
+targetEx.getArtifacts().removeSame(a.getId());
+targetEx.getArtifacts().add(a);
}
}
}
diff --git
a/src/main/resources/META-INF/services/org.apache.sling.feature.builder.PostProcessHandler
b/src/main/resources/META-INF/services/org.apache.sling.feature.builder.MergeHandler
similarity index 100%
rename from
src/main/resources/META-INF/services/org.apache.sling.feature.builder.PostProcessHandler
rename to
src/main/resources/META-INF/services/org.apache.sling.feature.builder.MergeHandler
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
> Transform ContentOrderMergeProcessor into MergeHandler
> --
>
>
[jira] [Commented] (SLING-8077) Transform ContentOrderMergeProcessor into MergeHandler
[ https://issues.apache.org/jira/browse/SLING-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676961#comment-16676961 ] ASF GitHub Bot commented on SLING-8077: --- bosschaert commented on issue #2: SLING-8077 - refactor ContentorderMergeProcessor to MergeHandler adju… URL: https://github.com/apache/sling-org-apache-sling-feature-extension-content/pull/2#issuecomment-436314790 Thanks for your pull request @DominikSuess - it's merged! This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Transform ContentOrderMergeProcessor into MergeHandler > -- > > Key: SLING-8077 > URL: https://issues.apache.org/jira/browse/SLING-8077 > Project: Sling > Issue Type: Improvement > Components: Feature Model >Reporter: Dominik Süß >Priority: Major > > ContentOrderMergeProcessor as implemented in "Featuremodel - Content > Deployment Exension" currently postprocesses features after merge to set the > default start-order. this only works for cases where features with same order > are getting merged and mandates a sequential merge of features of different > order. > To tackle this issue the extension should take over the actual merge which > allows to preprocess the features before merging and setting the defaults > according to the defaults declared in the particular features before doing > the merge. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] bosschaert commented on issue #2: SLING-8077 - refactor ContentorderMergeProcessor to MergeHandler adju…
bosschaert commented on issue #2: SLING-8077 - refactor ContentorderMergeProcessor to MergeHandler adju… URL: https://github.com/apache/sling-org-apache-sling-feature-extension-content/pull/2#issuecomment-436314790 Thanks for your pull request @DominikSuess - it's merged! This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] bosschaert closed pull request #2: SLING-8077 - refactor ContentorderMergeProcessor to MergeHandler adju…
bosschaert closed pull request #2: SLING-8077 - refactor
ContentorderMergeProcessor to MergeHandler adju…
URL:
https://github.com/apache/sling-org-apache-sling-feature-extension-content/pull/2
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/extension/content/ContentOrderMergeProcessor.java
b/src/main/java/org/apache/sling/feature/extension/content/ContentOrderMergeProcessor.java
index f85f18a..05b1133 100644
---
a/src/main/java/org/apache/sling/feature/extension/content/ContentOrderMergeProcessor.java
+++
b/src/main/java/org/apache/sling/feature/extension/content/ContentOrderMergeProcessor.java
@@ -23,25 +23,50 @@
import org.apache.sling.feature.FeatureConstants;
import org.apache.sling.feature.KeyValueMap;
import org.apache.sling.feature.builder.HandlerContext;
+import org.apache.sling.feature.builder.MergeHandler;
import org.apache.sling.feature.builder.PostProcessHandler;
-public class ContentOrderMergeProcessor implements PostProcessHandler {
+public class ContentOrderMergeProcessor implements MergeHandler {
private static final String DEFAULT_CONTENT_START_ORDER =
"default.content.startorder";
-@Override
-public void postProcess(HandlerContext context, Feature feature, Extension
extension) {
-if (extension.getType() == ExtensionType.ARTIFACTS
-&&
extension.getName().equals(FeatureConstants.EXTENSION_NAME_CONTENT_PACKAGES)) {
-String defaultOrder =
feature.getVariables().get(DEFAULT_CONTENT_START_ORDER);
-if (defaultOrder != null) {
-for (Artifact a : extension.getArtifacts()) {
-KeyValueMap kvm = a.getMetadata();
-if(kvm.get(Artifact.KEY_START_ORDER) == null) {
-kvm.put(Artifact.KEY_START_ORDER, defaultOrder);
-}
+private void processFeature(HandlerContext context, Feature feature,
Extension extension) {
+String defaultOrder =
feature.getVariables().get(DEFAULT_CONTENT_START_ORDER);
+if (defaultOrder != null) {
+for (Artifact a : extension.getArtifacts()) {
+KeyValueMap kvm = a.getMetadata();
+if(kvm.get(Artifact.KEY_START_ORDER) == null) {
+kvm.put(Artifact.KEY_START_ORDER, defaultOrder);
}
-feature.getVariables().remove(DEFAULT_CONTENT_START_ORDER);
+}
+feature.getVariables().remove(DEFAULT_CONTENT_START_ORDER);
+}
+}
+
+@Override
+public boolean canMerge(Extension extension) {
+return extension.getType() == ExtensionType.ARTIFACTS
+&&
extension.getName().equals(FeatureConstants.EXTENSION_NAME_CONTENT_PACKAGES);
+}
+
+@Override
+public void merge(HandlerContext context, Feature target, Feature source,
Extension targetEx, Extension sourceEx) {
+if (targetEx == null) {
+target.getExtensions().add(sourceEx);
+return;
+}
+processFeature(context, target, targetEx);
+processFeature(context, source, sourceEx);
+for (final Artifact a : sourceEx.getArtifacts()) {
+boolean replace = true;
+final Artifact existing =
targetEx.getArtifacts().getSame(a.getId());
+if (existing != null &&
existing.getId().getOSGiVersion().compareTo(a.getId().getOSGiVersion()) > 0) {
+replace = false;
+}
+
+if (replace) {
+targetEx.getArtifacts().removeSame(a.getId());
+targetEx.getArtifacts().add(a);
}
}
}
diff --git
a/src/main/resources/META-INF/services/org.apache.sling.feature.builder.PostProcessHandler
b/src/main/resources/META-INF/services/org.apache.sling.feature.builder.MergeHandler
similarity index 100%
rename from
src/main/resources/META-INF/services/org.apache.sling.feature.builder.PostProcessHandler
rename to
src/main/resources/META-INF/services/org.apache.sling.feature.builder.MergeHandler
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=16676921#comment-16676921
]
ASF GitHub Bot commented on SLING-8078:
---
bosschaert commented on issue #6: 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/6#issuecomment-436304388
Thanks for your pull request @simonetripodi - I guess we need to add a
mechanism to make the region names that are being checked configurable, but
that can be done in a separate pull request.
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 #6: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
bosschaert commented on issue #6: 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/6#issuecomment-436304388 Thanks for your pull request @simonetripodi - I guess we need to add a mechanism to make the region names that are being checked configurable, but that can be done in a separate pull request. 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=16676920#comment-16676920
]
ASF GitHub Bot commented on SLING-8078:
---
bosschaert closed pull request #6: 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/6
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 closed pull request #6: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
bosschaert closed pull request #6: 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/6 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
[Feature Model] Initial API Regions implementation
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
[GitHub] karlpauls commented on issue #5: Configurable shutdown grace time.
karlpauls commented on issue #5: Configurable shutdown grace time. URL: https://github.com/apache/sling-org-apache-sling-feature-launcher/pull/5#issuecomment-436297999 Makes sense to me - thanks a lot for the patch! 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 #5: Configurable shutdown grace time.
karlpauls closed pull request #5: Configurable shutdown grace time.
URL: https://github.com/apache/sling-org-apache-sling-feature-launcher/pull/5
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 25ce117..7546b02 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 SHUTDOWN_GRACE_TIME =
"sling.framework.shutdown.graceTime";
+
private volatile int type = -1;
public FrameworkRunner(final Map frameworkProperties,
@@ -57,12 +59,13 @@ public FrameworkRunner(final Map
frameworkProperties,
// initialize the framework
framework.init();
+long graceTime =
Long.parseLong(frameworkProperties.getOrDefault(SHUTDOWN_GRACE_TIME, "6"));
Runtime.getRuntime().addShutdownHook(new Thread() {
@Override
public void run() {
try {
framework.stop();
-FrameworkEvent waitForStop = framework.waitForStop(60 *
1000);
+FrameworkEvent waitForStop =
framework.waitForStop(graceTime);
if (waitForStop.getType() != FrameworkEvent.STOPPED)
{
Main.LOG().warn("Framework stopped with: " +
waitForStop.getType(), waitForStop.getThrowable());
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-8063) CMS - UI restructure action resources
[ https://issues.apache.org/jira/browse/SLING-8063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676904#comment-16676904 ] Dan Klco commented on SLING-8063: - Moving out of 0.10.2 release. > CMS - UI restructure action resources > - > > Key: SLING-8063 > URL: https://issues.apache.org/jira/browse/SLING-8063 > Project: Sling > Issue Type: Improvement > Components: App CMS >Reporter: Jason E Bailey >Assignee: Jason E Bailey >Priority: Minor > > Currently modals which represent actions are individually located under > specific views. By separating these out to a structure which represents all > the actions allows us to create a single location where we can view all > potential actions and cognitively separates them from a view. Making the > actions independent end points. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-8063) CMS - UI restructure action resources
[ https://issues.apache.org/jira/browse/SLING-8063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Klco updated SLING-8063: Fix Version/s: (was: App CMS 0.10.2) > CMS - UI restructure action resources > - > > Key: SLING-8063 > URL: https://issues.apache.org/jira/browse/SLING-8063 > Project: Sling > Issue Type: Improvement > Components: App CMS >Reporter: Jason E Bailey >Assignee: Jason E Bailey >Priority: Minor > > Currently modals which represent actions are individually located under > specific views. By separating these out to a structure which represents all > the actions allows us to create a single location where we can view all > potential actions and cognitively separates them from a view. Making the > actions independent end points. -- 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=16676897#comment-16676897
]
ASF GitHub Bot commented on SLING-8078:
---
simonetripodi opened a new pull request #6: 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/6
Hi there @bosschaert ,
please find my proposal in the commit: I did a little small amount of
refactoring in order to minimise the code duplication (the `CheckApiRegions`
task has a lot in common with that new task) and I also attached a unit test
for validation.
Please let me know what you think about it and if it requires modifications
in order the PR is accepted.
TIA!
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 #6: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
simonetripodi opened a new pull request #6: 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/6 Hi there @bosschaert , please find my proposal in the commit: I did a little small amount of refactoring in order to minimise the code duplication (the `CheckApiRegions` task has a lot in common with that new task) and I also attached a unit test for validation. Please let me know what you think about it and if it requires modifications in order the PR is accepted. TIA! 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 #5: Configurable shutdown grace time.
trekawek opened a new pull request #5: Configurable shutdown grace time. URL: https://github.com/apache/sling-org-apache-sling-feature-launcher/pull/5 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 commented on issue #5: Configurable shutdown grace time.
trekawek commented on issue #5: Configurable shutdown grace time. URL: https://github.com/apache/sling-org-apache-sling-feature-launcher/pull/5#issuecomment-436293197 @karlpauls, @cziegeler - I noticed that 1 minute is sometimes not enough for the framework to shut down. WDYT about introducing a new variable for the feature launcher? 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] [Created] (SLING-8078) New Analyser task which is able to detect Export-Package dependencies between regions
Simone Tripodi created SLING-8078:
-
Summary: 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
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] [Resolved] (SLING-8062) CMS - UI move modal structure to resource
[ https://issues.apache.org/jira/browse/SLING-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason E Bailey resolved SLING-8062. --- Resolution: Fixed > CMS - UI move modal structure to resource > - > > Key: SLING-8062 > URL: https://issues.apache.org/jira/browse/SLING-8062 > Project: Sling > Issue Type: Improvement > Components: App CMS >Reporter: Jason E Bailey >Assignee: Jason E Bailey >Priority: Minor > Fix For: App CMS 0.10.2 > > > Currently requests for a modal page is wrapped with the html to structure the > modal from the client side. a new modal page template has been created, and > the modal structure can be placed in that, reducing javascript. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-8060) Sling Testing Mocks: Transitive dependencies necessary at test execution time should be defined with scope "compile"
[
https://issues.apache.org/jira/browse/SLING-8060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676827#comment-16676827
]
Konrad Windszus commented on SLING-8060:
bq. sling-mock should not force the using project which alternative is used -
or which osgi version is used. esp. it may lead to subtle problems if it
introduces another version of a dependency already referenced in the using
project by an alternative way to address the dependency.
Sling Mocks should IMHO reference one(!) default version of OSGi with which it
is supposed to work and against which it was tested. This does not only affect
compendium classes but also core classes and even dependencies outside of OSGi!
IMHO even projects not defining any dependencies should be able to use
sling-mocks with just that single test dependency. If someone wants to
overwrite the version of compendium/core classes used internally during testing
he can still do that by leveraging dependencyManagement. I think it should just
be documented which GAV needs to be managed in this case.
What is the exact use case you have in mind, why you would want to overwrite
the OSGi compendium class version?
> Sling Testing Mocks: Transitive dependencies necessary at test execution time
> should be defined with scope "compile"
>
>
> Key: SLING-8060
> URL: https://issues.apache.org/jira/browse/SLING-8060
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Affects Versions: Testing OSGi Mock 2.4.2, Testing Sling Mock 2.3.4
>Reporter: Konrad Windszus
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently Testing OSGi Mock and Testing Sling Mock have a class execution
> time dependency to e.g. OSGi Configuration Admin and Event Admin (in
> https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/b04e06522379d32552353304746fbcdb09258460/core/src/main/java/org/apache/sling/testing/mock/osgi/MockOsgi.java#L312
> and in
> https://github.com/apache/sling-org-apache-sling-testing-sling-mock/blob/ef994bfbc9ae2288c66ef8be7fd3997913cc9144/core/src/main/java/org/apache/sling/testing/mock/sling/ResourceResolverFactoryInitializer.java#L42).
> Still the dependency to it is only defined with scope "provided" in
> https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/b04e06522379d32552353304746fbcdb09258460/parent/pom.xml#L49
> and
> https://github.com/apache/sling-org-apache-sling-testing-sling-mock/blob/986bdfbbf6c3f5f416d6acc24329eb431f67494a/core/pom.xml#L37.
> That is a problem as transitive dependencies with scope "provided" are not
> included in the classpath. That may lead to the fact that the
> ConfigurationAdmin/EventAdmin is not part of the testing classpath (in case
> it isn't explicitly defined for some other reason) . Please make sure that
> all dependencies which are actually always necessary at test execution time
> are included with scope "compile"
> (https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope).
> This issue does not happen that often, as in most of the cases the to be
> tested modules already define an explicit dependency to
> {{org.osgi:osgi.cmpn}} and {{org.osgi:osgi.core}}, but since nowadays the
> OSGi foundation provides not only the aggregate dependencies but also
> individual ones, this is no longer necessarily the case (compare with
> https://issues.apache.org/jira/browse/SLING-7384?focusedCommentId=16327433=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16327433).
> At the same time of converting the dependency scope to "compile" we should
> switch from the aggregate to the individual osgi artifacts (to be able to
> more granularly define which OSGi level is used).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [VOTE] Release Apache Sling Models API 1.3.8
+1 > On 5 Nov 2018, at 19:00, Stefan Seifert 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-8077) Transform ContentOrderMergeProcessor into MergeHandler
[
https://issues.apache.org/jira/browse/SLING-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676785#comment-16676785
]
ASF GitHub Bot commented on SLING-8077:
---
bosschaert commented on a change in pull request #2: SLING-8077 - refactor
ContentorderMergeProcessor to MergeHandler adju…
URL:
https://github.com/apache/sling-org-apache-sling-feature-extension-content/pull/2#discussion_r231129960
##
File path:
src/main/java/org/apache/sling/feature/extension/content/ContentOrderMergeProcessor.java
##
@@ -51,6 +51,9 @@ public boolean canMerge(Extension extension) {
@Override
public void merge(HandlerContext context, Feature target, Feature source,
Extension targetEx, Extension sourceEx) {
+if (target == null) {
+return;
Review comment:
Sorry - I was wrong. Instead of just returning, it should be:
```
if (target == null) {
target.getExtensions().add(sourceEx)
return;
}
```
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
> Transform ContentOrderMergeProcessor into MergeHandler
> --
>
> Key: SLING-8077
> URL: https://issues.apache.org/jira/browse/SLING-8077
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Reporter: Dominik Süß
>Priority: Major
>
> ContentOrderMergeProcessor as implemented in "Featuremodel - Content
> Deployment Exension" currently postprocesses features after merge to set the
> default start-order. this only works for cases where features with same order
> are getting merged and mandates a sequential merge of features of different
> order.
> To tackle this issue the extension should take over the actual merge which
> allows to preprocess the features before merging and setting the defaults
> according to the defaults declared in the particular features before doing
> the merge.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] bosschaert commented on a change in pull request #2: SLING-8077 - refactor ContentorderMergeProcessor to MergeHandler adju…
bosschaert commented on a change in pull request #2: SLING-8077 - refactor
ContentorderMergeProcessor to MergeHandler adju…
URL:
https://github.com/apache/sling-org-apache-sling-feature-extension-content/pull/2#discussion_r231129960
##
File path:
src/main/java/org/apache/sling/feature/extension/content/ContentOrderMergeProcessor.java
##
@@ -51,6 +51,9 @@ public boolean canMerge(Extension extension) {
@Override
public void merge(HandlerContext context, Feature target, Feature source,
Extension targetEx, Extension sourceEx) {
+if (target == null) {
+return;
Review comment:
Sorry - I was wrong. Instead of just returning, it should be:
```
if (target == null) {
target.getExtensions().add(sourceEx)
return;
}
```
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-8077) Transform ContentOrderMergeProcessor into MergeHandler
[
https://issues.apache.org/jira/browse/SLING-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676737#comment-16676737
]
ASF GitHub Bot commented on SLING-8077:
---
bosschaert commented on a change in pull request #2: SLING-8077 - refactor
ContentorderMergeProcessor to MergeHandler adju…
URL:
https://github.com/apache/sling-org-apache-sling-feature-extension-content/pull/2#discussion_r231116555
##
File path:
src/main/java/org/apache/sling/feature/extension/content/ContentOrderMergeProcessor.java
##
@@ -23,25 +23,46 @@
import org.apache.sling.feature.FeatureConstants;
import org.apache.sling.feature.KeyValueMap;
import org.apache.sling.feature.builder.HandlerContext;
+import org.apache.sling.feature.builder.MergeHandler;
import org.apache.sling.feature.builder.PostProcessHandler;
-public class ContentOrderMergeProcessor implements PostProcessHandler {
+public class ContentOrderMergeProcessor implements MergeHandler {
private static final String DEFAULT_CONTENT_START_ORDER =
"default.content.startorder";
-@Override
-public void postProcess(HandlerContext context, Feature feature, Extension
extension) {
-if (extension.getType() == ExtensionType.ARTIFACTS
-&&
extension.getName().equals(FeatureConstants.EXTENSION_NAME_CONTENT_PACKAGES)) {
-String defaultOrder =
feature.getVariables().get(DEFAULT_CONTENT_START_ORDER);
-if (defaultOrder != null) {
-for (Artifact a : extension.getArtifacts()) {
-KeyValueMap kvm = a.getMetadata();
-if(kvm.get(Artifact.KEY_START_ORDER) == null) {
-kvm.put(Artifact.KEY_START_ORDER, defaultOrder);
-}
+private void processFeature(HandlerContext context, Feature feature,
Extension extension) {
+String defaultOrder =
feature.getVariables().get(DEFAULT_CONTENT_START_ORDER);
+if (defaultOrder != null) {
+for (Artifact a : extension.getArtifacts()) {
+KeyValueMap kvm = a.getMetadata();
+if(kvm.get(Artifact.KEY_START_ORDER) == null) {
+kvm.put(Artifact.KEY_START_ORDER, defaultOrder);
}
-feature.getVariables().remove(DEFAULT_CONTENT_START_ORDER);
+}
+feature.getVariables().remove(DEFAULT_CONTENT_START_ORDER);
+}
+}
+
+@Override
+public boolean canMerge(Extension extension) {
+return extension.getType() == ExtensionType.ARTIFACTS
+&&
extension.getName().equals(FeatureConstants.EXTENSION_NAME_CONTENT_PACKAGES);
+}
+
+@Override
+public void merge(HandlerContext context, Feature target, Feature source,
Extension targetEx, Extension sourceEx) {
+processFeature(context, target, targetEx);
Review comment:
Hi @DominikSuess with this commit
https://github.com/apache/sling-org-apache-sling-feature/commit/f7e74ebe1532c13ebfa96a935fa6fdcc544b6b43
the `target` argument can also be `null`. Basically the handler receives an
extra call when the first extension is applied to the aggregate. Some handlers
also need to be able to process those.
I think in your case you don't need to do something in that case, so you
could just add
```
if (target == null) return
```
at the top of this method.
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
> Transform ContentOrderMergeProcessor into MergeHandler
> --
>
> Key: SLING-8077
> URL: https://issues.apache.org/jira/browse/SLING-8077
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Reporter: Dominik Süß
>Priority: Major
>
> ContentOrderMergeProcessor as implemented in "Featuremodel - Content
> Deployment Exension" currently postprocesses features after merge to set the
> default start-order. this only works for cases where features with same order
> are getting merged and mandates a sequential merge of features of different
> order.
> To tackle this issue the extension should take over the actual merge which
> allows to preprocess the features before merging and setting the defaults
> according to the defaults declared in the particular features before doing
> the merge.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] bosschaert commented on a change in pull request #2: SLING-8077 - refactor ContentorderMergeProcessor to MergeHandler adju…
bosschaert commented on a change in pull request #2: SLING-8077 - refactor
ContentorderMergeProcessor to MergeHandler adju…
URL:
https://github.com/apache/sling-org-apache-sling-feature-extension-content/pull/2#discussion_r231116555
##
File path:
src/main/java/org/apache/sling/feature/extension/content/ContentOrderMergeProcessor.java
##
@@ -23,25 +23,46 @@
import org.apache.sling.feature.FeatureConstants;
import org.apache.sling.feature.KeyValueMap;
import org.apache.sling.feature.builder.HandlerContext;
+import org.apache.sling.feature.builder.MergeHandler;
import org.apache.sling.feature.builder.PostProcessHandler;
-public class ContentOrderMergeProcessor implements PostProcessHandler {
+public class ContentOrderMergeProcessor implements MergeHandler {
private static final String DEFAULT_CONTENT_START_ORDER =
"default.content.startorder";
-@Override
-public void postProcess(HandlerContext context, Feature feature, Extension
extension) {
-if (extension.getType() == ExtensionType.ARTIFACTS
-&&
extension.getName().equals(FeatureConstants.EXTENSION_NAME_CONTENT_PACKAGES)) {
-String defaultOrder =
feature.getVariables().get(DEFAULT_CONTENT_START_ORDER);
-if (defaultOrder != null) {
-for (Artifact a : extension.getArtifacts()) {
-KeyValueMap kvm = a.getMetadata();
-if(kvm.get(Artifact.KEY_START_ORDER) == null) {
-kvm.put(Artifact.KEY_START_ORDER, defaultOrder);
-}
+private void processFeature(HandlerContext context, Feature feature,
Extension extension) {
+String defaultOrder =
feature.getVariables().get(DEFAULT_CONTENT_START_ORDER);
+if (defaultOrder != null) {
+for (Artifact a : extension.getArtifacts()) {
+KeyValueMap kvm = a.getMetadata();
+if(kvm.get(Artifact.KEY_START_ORDER) == null) {
+kvm.put(Artifact.KEY_START_ORDER, defaultOrder);
}
-feature.getVariables().remove(DEFAULT_CONTENT_START_ORDER);
+}
+feature.getVariables().remove(DEFAULT_CONTENT_START_ORDER);
+}
+}
+
+@Override
+public boolean canMerge(Extension extension) {
+return extension.getType() == ExtensionType.ARTIFACTS
+&&
extension.getName().equals(FeatureConstants.EXTENSION_NAME_CONTENT_PACKAGES);
+}
+
+@Override
+public void merge(HandlerContext context, Feature target, Feature source,
Extension targetEx, Extension sourceEx) {
+processFeature(context, target, targetEx);
Review comment:
Hi @DominikSuess with this commit
https://github.com/apache/sling-org-apache-sling-feature/commit/f7e74ebe1532c13ebfa96a935fa6fdcc544b6b43
the `target` argument can also be `null`. Basically the handler receives an
extra call when the first extension is applied to the aggregate. Some handlers
also need to be able to process those.
I think in your case you don't need to do something in that case, so you
could just add
```
if (target == null) return
```
at the top of this method.
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-8077) Transform ContentOrderMergeProcessor into MergeHandler
[ https://issues.apache.org/jira/browse/SLING-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676732#comment-16676732 ] ASF GitHub Bot commented on SLING-8077: --- DominikSuess opened a new pull request #2: SLING-8077 - refactor ContentorderMergeProcessor to MergeHandler adju… URL: https://github.com/apache/sling-org-apache-sling-feature-extension-content/pull/2 …sting Features pre merging instead of postprocessing 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 > Transform ContentOrderMergeProcessor into MergeHandler > -- > > Key: SLING-8077 > URL: https://issues.apache.org/jira/browse/SLING-8077 > Project: Sling > Issue Type: Improvement > Components: Feature Model >Reporter: Dominik Süß >Priority: Major > > ContentOrderMergeProcessor as implemented in "Featuremodel - Content > Deployment Exension" currently postprocesses features after merge to set the > default start-order. this only works for cases where features with same order > are getting merged and mandates a sequential merge of features of different > order. > To tackle this issue the extension should take over the actual merge which > allows to preprocess the features before merging and setting the defaults > according to the defaults declared in the particular features before doing > the merge. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] DominikSuess opened a new pull request #2: SLING-8077 - refactor ContentorderMergeProcessor to MergeHandler adju…
DominikSuess opened a new pull request #2: SLING-8077 - refactor ContentorderMergeProcessor to MergeHandler adju… URL: https://github.com/apache/sling-org-apache-sling-feature-extension-content/pull/2 …sting Features pre merging instead of postprocessing 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] [Created] (SLING-8077) Transform ContentOrderMergeProcessor into MergeHandler
Dominik Süß created SLING-8077: -- Summary: Transform ContentOrderMergeProcessor into MergeHandler Key: SLING-8077 URL: https://issues.apache.org/jira/browse/SLING-8077 Project: Sling Issue Type: Improvement Components: Feature Model Reporter: Dominik Süß ContentOrderMergeProcessor as implemented in "Featuremodel - Content Deployment Exension" currently postprocesses features after merge to set the default start-order. this only works for cases where features with same order are getting merged and mandates a sequential merge of features of different order. To tackle this issue the extension should take over the actual merge which allows to preprocess the features before merging and setting the defaults according to the defaults declared in the particular features before doing the merge. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-8076) Merge Handlers should also be called on the first extension being merged in
[
https://issues.apache.org/jira/browse/SLING-8076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert updated SLING-8076:
Description:
When feature model extensions are merged via
BuilderUtil.mergeExtensions(Feature, Feature,
ArtifactMerge, BuilderContext) any merge extensions are only invoked when the
second extension instance is being merged. The first extension is simply copied
into the target.
However the Merge Handler may also need to perform some action on the first
copy, for example record what feature the extension came from. This is
currently not possible.
Proposal is to also call the Merge Handlers for the first merge (which is
currently just a copy), so that they can also act in these cases.
was:
When feature model extensions are merged via
{{BuilderUtil.mergeExtensions(Feature, Feature,
ArtifactMerge, BuilderContext)}} any merge extensions are only invoked when the
second extension instance is being merged. The first extension is simply copied
into the target.
However the Merge Handler may also need to perform some action on the first
copy, for example record what feature the extension came from. This is
currently not possible.
Proposal is to also call the Merge Handlers for the first merge (which is
currently just a copy), so that they can also act in these cases.
> Merge Handlers should also be called on the first extension being merged in
> ---
>
> Key: SLING-8076
> URL: https://issues.apache.org/jira/browse/SLING-8076
> Project: Sling
> Issue Type: Bug
> Components: Feature Model
>Affects Versions: Feature Model 0.2.0
>Reporter: David Bosschaert
>Priority: Major
> Fix For: Feature Model 0.2.2
>
>
> When feature model extensions are merged via
> BuilderUtil.mergeExtensions(Feature, Feature,
> ArtifactMerge, BuilderContext) any merge extensions are only invoked when
> the second extension instance is being merged. The first extension is simply
> copied into the target.
> However the Merge Handler may also need to perform some action on the first
> copy, for example record what feature the extension came from. This is
> currently not possible.
> Proposal is to also call the Merge Handlers for the first merge (which is
> currently just a copy), so that they can also act in these cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (SLING-8076) Merge Handlers should also be called on the first extension being merged in
[ https://issues.apache.org/jira/browse/SLING-8076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert reassigned SLING-8076: --- Assignee: David Bosschaert > Merge Handlers should also be called on the first extension being merged in > --- > > Key: SLING-8076 > URL: https://issues.apache.org/jira/browse/SLING-8076 > Project: Sling > Issue Type: Bug > Components: Feature Model >Affects Versions: Feature Model 0.2.0 >Reporter: David Bosschaert >Assignee: David Bosschaert >Priority: Major > Fix For: Feature Model 0.2.2 > > > When feature model extensions are merged via > BuilderUtil.mergeExtensions(Feature, Feature, > ArtifactMerge, BuilderContext) any merge extensions are only invoked when > the second extension instance is being merged. The first extension is simply > copied into the target. > However the Merge Handler may also need to perform some action on the first > copy, for example record what feature the extension came from. This is > currently not possible. > Proposal is to also call the Merge Handlers for the first merge (which is > currently just a copy), so that they can also act in these cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-8076) Merge Handlers should also be called on the first extension being merged in
David Bosschaert created SLING-8076:
---
Summary: Merge Handlers should also be called on the first
extension being merged in
Key: SLING-8076
URL: https://issues.apache.org/jira/browse/SLING-8076
Project: Sling
Issue Type: Bug
Components: Feature Model
Affects Versions: Feature Model 0.2.0
Reporter: David Bosschaert
Fix For: Feature Model 0.2.2
When feature model extensions are merged via
{{BuilderUtil.mergeExtensions(Feature, Feature,
ArtifactMerge, BuilderContext)}} any merge extensions are only invoked when the
second extension instance is being merged. The first extension is simply copied
into the target.
However the Merge Handler may also need to perform some action on the first
copy, for example record what feature the extension came from. This is
currently not possible.
Proposal is to also call the Merge Handlers for the first merge (which is
currently just a copy), so that they can also act in these cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [VOTE] Release Apache Sling Models API 1.3.8
+1 regards, Karl On Tue, Nov 6, 2018 at 10:02 AM Robert Munteanu wrote: > > On Mon, 2018-11-05 at 18:00 +, Stefan Seifert wrote: > > Please vote to approve this release: > > +1 > > Robert -- Karl Pauls karlpa...@gmail.com
Re: [VOTE] Release Apache Sling Models API 1.3.8
On Mon, 2018-11-05 at 18:00 +, Stefan Seifert wrote: > Please vote to approve this release: +1 Robert signature.asc Description: This is a digitally signed message part
[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=16676350#comment-16676350
]
Carsten Ziegeler commented on SLING-8058:
-
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 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}
>
>
[GitHub] philipmundt commented on a change in pull request #10: SLING-8047 ExportServlet does not write to output stream
philipmundt commented on a change in pull request #10: SLING-8047 ExportServlet
does not write to output stream
URL:
https://github.com/apache/sling-org-apache-sling-models-impl/pull/10#discussion_r231033150
##
File path: src/test/java/org/apache/sling/models/impl/ExportServletTest.java
##
@@ -0,0 +1,129 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.sling.models.impl;
+
+import org.apache.sling.api.SlingHttpServletRequest;
+import org.apache.sling.api.SlingHttpServletResponse;
+import org.apache.sling.api.request.RequestPathInfo;
+import org.apache.sling.api.resource.Resource;
+import org.apache.sling.api.resource.ResourceResolver;
+import org.apache.sling.models.factory.ModelFactory;
+import org.apache.sling.models.testmodels.classes.DefaultStringModel;
+import org.apache.sling.scripting.api.BindingsValuesProvidersByContext;
+import org.hamcrest.CoreMatchers;
+import org.junit.Assert;
+import org.junit.Before;
+import org.junit.Test;
+import org.junit.runner.RunWith;
+import org.mockito.Matchers;
+import org.mockito.Mock;
+import org.mockito.Mockito;
+import org.mockito.runners.MockitoJUnitRunner;
+import org.osgi.framework.BundleContext;
+
+import javax.json.Json;
+import javax.json.JsonReader;
+import java.io.ByteArrayOutputStream;
+import java.io.PrintWriter;
+import java.io.StringReader;
+import java.util.Collections;
+import java.util.Map;
+
+@RunWith(MockitoJUnitRunner.class)
+public class ExportServletTest {
+
+private static final String SELECTOR = "model";
+
+private ExportServlet exportServlet;
+
+@Mock
+private BundleContext bundleContext;
+
+@Mock
+private ModelFactory modelFactory;
+
+@Mock
+private BindingsValuesProvidersByContext bindingsValueProviderByContext;
+
+@Mock
+private SlingModelsScriptEngineFactory scriptFactory;
+
+@Mock
+private ExportServlet.ExportedObjectAccessor exportedObjectAccessor;
+
+@Mock
+private SlingHttpServletRequest slingHttpServletRequest;
+
+@Mock
+private SlingHttpServletResponse slingHttpServletResponse;
+
+@Mock
+private RequestPathInfo requestPathInfo;
+
+@Mock
+private Resource resource;
+
+@Mock
+private ResourceResolver resourceResolver;
+
+private Map baseOption = Collections.emptyMap();
+private Class annotatedClass = DefaultStringModel.class;
+private String registeredSelector = SELECTOR;
+private String exporterName = "exporterName";
+
+@Before
+public void setUp() {
+
Mockito.when(resource.getResourceResolver()).thenReturn(resourceResolver);
Review comment:
@paul-bjorkstrand would have been no issue what so ever, but the underlying
fix is not correct. I'm therefore closing the PR for the time being. I'm not
sure how I'm supposed to test/verify the new fix in
`sling-org-apache-sling-engine`, class
`org.apache.sling.engine.impl.SlingRequestProcessorImpl` in the realm of the
export servlet!
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] philipmundt closed pull request #10: SLING-8047 ExportServlet does not write to output stream
philipmundt closed pull request #10: SLING-8047 ExportServlet does not write to
output stream
URL: https://github.com/apache/sling-org-apache-sling-models-impl/pull/10
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/pom.xml b/pom.xml
index 6ef84dc..8ec4849 100644
--- a/pom.xml
+++ b/pom.xml
@@ -239,5 +239,11 @@
16.0.2
provided
+
+org.apache.sling
+org.apache.sling.commons.johnzon
+1.1.0
+test
+
diff --git a/src/main/java/org/apache/sling/models/impl/ExportServlet.java
b/src/main/java/org/apache/sling/models/impl/ExportServlet.java
index f557713..5d6f47a 100644
--- a/src/main/java/org/apache/sling/models/impl/ExportServlet.java
+++ b/src/main/java/org/apache/sling/models/impl/ExportServlet.java
@@ -118,6 +118,7 @@ protected void doGet(SlingHttpServletRequest request,
SlingHttpServletResponse r
return;
}
response.getWriter().write(exported);
+response.getWriter().flush();
} finally {
scriptHelper.cleanup();
}
@@ -202,6 +203,6 @@ public String getExportedString(SlingHttpServletRequest
request, Maphttp://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.sling.models.impl;
+
+import org.apache.sling.api.SlingHttpServletRequest;
+import org.apache.sling.api.SlingHttpServletResponse;
+import org.apache.sling.api.request.RequestPathInfo;
+import org.apache.sling.api.resource.Resource;
+import org.apache.sling.api.resource.ResourceResolver;
+import org.apache.sling.models.factory.ModelFactory;
+import org.apache.sling.models.testmodels.classes.DefaultStringModel;
+import org.apache.sling.scripting.api.BindingsValuesProvidersByContext;
+import org.hamcrest.CoreMatchers;
+import org.junit.Assert;
+import org.junit.Before;
+import org.junit.Test;
+import org.junit.runner.RunWith;
+import org.mockito.Matchers;
+import org.mockito.Mock;
+import org.mockito.Mockito;
+import org.mockito.runners.MockitoJUnitRunner;
+import org.osgi.framework.BundleContext;
+
+import javax.json.Json;
+import javax.json.JsonReader;
+import java.io.ByteArrayOutputStream;
+import java.io.PrintWriter;
+import java.io.StringReader;
+import java.util.Collections;
+import java.util.Map;
+
+@RunWith(MockitoJUnitRunner.class)
+public class ExportServletTest {
+
+private static final String SELECTOR = "model";
+
+private ExportServlet exportServlet;
+
+@Mock
+private BundleContext bundleContext;
+
+@Mock
+private ModelFactory modelFactory;
+
+@Mock
+private BindingsValuesProvidersByContext bindingsValueProviderByContext;
+
+@Mock
+private SlingModelsScriptEngineFactory scriptFactory;
+
+@Mock
+private ExportServlet.ExportedObjectAccessor exportedObjectAccessor;
+
+@Mock
+private SlingHttpServletRequest slingHttpServletRequest;
+
+@Mock
+private SlingHttpServletResponse slingHttpServletResponse;
+
+@Mock
+private RequestPathInfo requestPathInfo;
+
+@Mock
+private Resource resource;
+
+@Mock
+private ResourceResolver resourceResolver;
+
+private Map baseOption = Collections.emptyMap();
+private Class annotatedClass = DefaultStringModel.class;
+private String registeredSelector = SELECTOR;
+private String exporterName = "exporterName";
+
+@Before
+public void setUp() {
+
Mockito.when(resource.getResourceResolver()).thenReturn(resourceResolver);
+Mockito.when(requestPathInfo.getSelectors()).thenReturn(new
String[]{SELECTOR});
+
Mockito.when(slingHttpServletRequest.getResponseContentType()).thenReturn("application/json");
+
Mockito.when(slingHttpServletRequest.getParameterMap()).thenReturn(Collections.emptyMap());
+
Mockito.when(slingHttpServletRequest.getRequestPathInfo()).thenReturn(requestPathInfo);
+
Mockito.when(slingHttpServletRequest.getResource()).thenReturn(resource);
+
Mockito.when(slingHttpServletRequest.getProtocol()).thenReturn("HTTP/1.1");
+Mockito.when(slingHttpServletRequest.getMethod()).thenReturn("GET");
+
+exportServlet = new ExportServlet(bundleContext, modelFactory,
bindingsValueProviderByContext, scriptFactory,
+annotatedClass, registeredSelector, exporterName,
exportedObjectAccessor, baseOption);
+}
+
+@Test
+public void
