Re: [feature model] Designating a feature as 'complete'
Am 09.11.2018 um 14:23 schrieb Robert Munteanu: On Fri, 2018-11-09 at 13:49 +0100, Carsten Ziegeler wrote: - what exactly does complete imply? can it be launched with other features? etc. I guess we just need to define this. My personal optinion is that we should be able to launch a complete feature with other features. One scenario which would be supported is , having a complete feature which can be launched standalone and then adding instrumentation/monitoring on top of that. One thing I am not sure about is whether there should be any barriers preventing two complete features from being launched together. At first glance it does not make sense, but on the other hand people find creative uses which were not originally taken into account :-) Right, there is also the question if you assemble a complete and a non complete feature, is the result complete? (I guess the answer is no) So there are some smaller things to find out. As we're close to finalize the feature API, I think we should create an issue for this and make sure we include it as early as possible Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [DISCUSS] Feature Files I/O long-therm proposal: improving the processing pipeline
We have to distinguish between the json representation of a feature as defined in our "specification" and the additional support of our maven plugin. A feature must have an ID and we don't allow interpolation of placeholders within the feature. Therefore the json code that we have to read a feature in the feature-io module works on this basis. And we should not change that. However, for maven based projects, the maven plugin allows to leave out the id; it then gets calculated based on the project coordinates and the file name. And the maven plugin also allows to interpolate placeholders in the feature file. Now in a maven project, the above two things need to happen before validation, otherwise the validation might fail. If we can make these steps more efficient, great - but we must not break the separation of the functionality. In addition, do we have any numbers that claim how "slow" this currently is and how much we can improve this? Feature files are rather small and all processing happens in memory. In addition we're talking about a build time tool here, so if it spends some extra milliseconds this doesn't really matter. Again, if we can improve, let's do it - but I think it's not our most urgent problem to fix wrt the feature model Regards Carsten Am 13.11.2018 um 02:53 schrieb Justin Edelson: Hi Simo, Take this with several grains of salt as I don't know the internals of the feature processing, but just looking at your email from a generic "how do I process a JSON file" it still seems inefficient. Ideally, IMO, the substitution would be done as a filter applied to the stream of parser events. That way the entire String is not held in memory -- only the parsed DOM. I suspect it is also "safer" in the sense that you can more tightly control the context in which interpolation occurs (for example, interpolation should be allowed in string values, but not keys); the flip side is that it also is more restrictive, i.e. supporting interpolation of non-String values would be non-trivial (then again, doing this would make the original document invalid JSON so I'm not sure this is a real use case). I would suggest taking a look at Jackson's JsonParserDelegate. Regards, Justin On Mon, Nov 12, 2018 at 2:46 PM Simone Tripodi wrote: Hi all mates, during the last couple of months the work we've been doing on Feature files processing is HUGE, so the iterations to refine the pipeline process introduced some "overhead" operations we can improve, what we currently do is: * the pre processor starts by reading the whole file to memory, storing it in a String reference; * parse the JSON file to create the javax.json DOM and check the `id` property is missing, adding it if necessary and then serializing it to string again: * JSON Schema validation takes the string as input, creates the Jackson DOM to validate it against the defined schema; * if schema validation is OK, the Substitution takes the JSON string as input to interpolate variables, which creates a new JSON string representation; * the JS Min takes the JSON string representation and converts it to a new JSON string representation where useless stuff are removed; * at that point, the JSON Feature reader takes the final string and creates a javax.json DOM once again to map it to a Feature instance. My proposal is improving a little our pipeline in order to speed up the JSON processing in that way: * the JS Min starts by reading the whole file to memory, storing it in a String reference; * the Substitution takes the JSON string as input to interpolate variables, which creates a new JSON string representation; * a Jackson DOM will be created in order to check the `id` property is missing, adding it if necessary; * the Jackson DOM will be validated against the defined schema; * the Jackson DOM will be mapped to a Feature instance. WDYT? Many thanks in advance! ~Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Commented] (SLING-7934) Add the ability for a resource to adapt to a JSONObject
[ https://issues.apache.org/jira/browse/SLING-7934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16684782#comment-16684782 ] Carsten Ziegeler commented on SLING-7934: - True, but if you want to stream json out, creating a JsonObject in between is not really efficient, direct streaming would be better and the JsonObjectCreator is for the general case whereas if you have a specific case you know what you have and into what you want to convert it. Again, I'm not potentially trying to kill this proposal, I'm trying to understand where/how this could help. If JsonObject would be mutable, it would imho be a different story > Add the ability for a resource to adapt to a JSONObject > --- > > Key: SLING-7934 > URL: https://issues.apache.org/jira/browse/SLING-7934 > Project: Sling > Issue Type: Improvement >Reporter: Jason E Bailey >Assignee: Jason E Bailey >Priority: Major > > There are multiple implementations all doing the same process of converting a > resource to a JSONObject. If it's that common we should just add the ability > to adapt the resource and centralize the implementation so that it's > consistent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [DISCUSS] Feature Files I/O long-therm proposal: improving the processing pipeline
Hi Simo, Take this with several grains of salt as I don't know the internals of the feature processing, but just looking at your email from a generic "how do I process a JSON file" it still seems inefficient. Ideally, IMO, the substitution would be done as a filter applied to the stream of parser events. That way the entire String is not held in memory -- only the parsed DOM. I suspect it is also "safer" in the sense that you can more tightly control the context in which interpolation occurs (for example, interpolation should be allowed in string values, but not keys); the flip side is that it also is more restrictive, i.e. supporting interpolation of non-String values would be non-trivial (then again, doing this would make the original document invalid JSON so I'm not sure this is a real use case). I would suggest taking a look at Jackson's JsonParserDelegate. Regards, Justin On Mon, Nov 12, 2018 at 2:46 PM Simone Tripodi wrote: > Hi all mates, > > during the last couple of months the work we've been doing on Feature > files processing is HUGE, so the iterations to refine the pipeline > process introduced some "overhead" operations we can improve, what we > currently do is: > > * the pre processor starts by reading the whole file to memory, > storing it in a String reference; > * parse the JSON file to create the javax.json DOM and check the `id` > property is missing, adding it if necessary and then serializing it to > string again: > * JSON Schema validation takes the string as input, creates the > Jackson DOM to validate it against the defined schema; > * if schema validation is OK, the Substitution takes the JSON string > as input to interpolate variables, which creates a new JSON string > representation; > * the JS Min takes the JSON string representation and converts it to > a new JSON string representation where useless stuff are removed; > * at that point, the JSON Feature reader takes the final string and > creates a javax.json DOM once again to map it to a Feature instance. > > My proposal is improving a little our pipeline in order to speed up > the JSON processing in that way: > > * the JS Min starts by reading the whole file to memory, storing it > in a String reference; > * the Substitution takes the JSON string as input to interpolate > variables, which creates a new JSON string representation; > * a Jackson DOM will be created in order to check the `id` property > is missing, adding it if necessary; > * the Jackson DOM will be validated against the defined schema; > * the Jackson DOM will be mapped to a Feature instance. > > WDYT? > > Many thanks in advance! > ~Simo > > http://people.apache.org/~simonetripodi/ > http://twitter.com/simonetripodi >
[jira] [Commented] (SLING-7934) Add the ability for a resource to adapt to a JSONObject
[ https://issues.apache.org/jira/browse/SLING-7934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16684342#comment-16684342 ] Jason E Bailey commented on SLING-7934: --- I'm not sure what you're definition of easily done is in this case. There's a whole class, org.apache.sling.servlets.get.impl.util.JsonObjectCreator, which was created to convert a resource to a JsonObject via a ValueMap and that is an internal class. If someone would like to do the same thing they would need to copy this class over or write their own. > Add the ability for a resource to adapt to a JSONObject > --- > > Key: SLING-7934 > URL: https://issues.apache.org/jira/browse/SLING-7934 > Project: Sling > Issue Type: Improvement >Reporter: Jason E Bailey >Assignee: Jason E Bailey >Priority: Major > > There are multiple implementations all doing the same process of converting a > resource to a JSONObject. If it's that common we should just add the ability > to adapt the resource and centralize the implementation so that it's > consistent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[DISCUSS] Feature Files I/O long-therm proposal: improving the processing pipeline
Hi all mates, during the last couple of months the work we've been doing on Feature files processing is HUGE, so the iterations to refine the pipeline process introduced some "overhead" operations we can improve, what we currently do is: * the pre processor starts by reading the whole file to memory, storing it in a String reference; * parse the JSON file to create the javax.json DOM and check the `id` property is missing, adding it if necessary and then serializing it to string again: * JSON Schema validation takes the string as input, creates the Jackson DOM to validate it against the defined schema; * if schema validation is OK, the Substitution takes the JSON string as input to interpolate variables, which creates a new JSON string representation; * the JS Min takes the JSON string representation and converts it to a new JSON string representation where useless stuff are removed; * at that point, the JSON Feature reader takes the final string and creates a javax.json DOM once again to map it to a Feature instance. My proposal is improving a little our pipeline in order to speed up the JSON processing in that way: * the JS Min starts by reading the whole file to memory, storing it in a String reference; * the Substitution takes the JSON string as input to interpolate variables, which creates a new JSON string representation; * a Jackson DOM will be created in order to check the `id` property is missing, adding it if necessary; * the Jackson DOM will be validated against the defined schema; * the Jackson DOM will be mapped to a Feature instance. WDYT? Many thanks in advance! ~Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi
[jira] [Resolved] (SLING-8096) Make it possible to configure Merge Handlers and Post Processors
[ https://issues.apache.org/jira/browse/SLING-8096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert resolved SLING-8096. - Resolution: Fixed Fixed with https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-feature.git;a=commitdiff;h=975da485457cbc8a85a4d3f4cdd00ae6403633cd and https://gitbox.apache.org/repos/asf?p=sling-slingfeature-maven-plugin.git;a=commitdiff;h=6dbfffcf01e9785114f36e5628bb4d735d4e09bd Configuration is not yet implemented for the launcher, if there is a use for that it can be added. > Make it possible to configure Merge Handlers and Post Processors > > > Key: SLING-8096 > URL: https://issues.apache.org/jira/browse/SLING-8096 > Project: Sling > Issue Type: New Feature > 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 > > > Feature merge handlers and postprocessors are provided via the ServiceLoader > extension mechanism. We need to create a way to pass configuration to these. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (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 resolved SLING-8076. - Resolution: Fixed Resolved with https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-feature.git;a=commitdiff;h=f7e74ebe1532c13ebfa96a935fa6fdcc544b6b43 > 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] [Commented] (SLING-8099) Potential NPE condition in ContentOrderMergeProcessor
[
https://issues.apache.org/jira/browse/SLING-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16683985#comment-16683985
]
ASF GitHub Bot commented on SLING-8099:
---
bosschaert commented on issue #6: SLING-8099 - eliminating NPE condition
URL:
https://github.com/apache/sling-org-apache-sling-feature-extension-content/pull/6#issuecomment-437932381
Thanks @DominikSuess for the PR - 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
> Potential NPE condition in ContentOrderMergeProcessor
> -
>
> Key: SLING-8099
> URL: https://issues.apache.org/jira/browse/SLING-8099
> Project: Sling
> Issue Type: Bug
> Components: Feature Model
>Reporter: Dominik Süß
>Priority: Major
>
> When a feature doesn't contain the content-package extension but anyhow
> contains the {{default.content.startorder}} property this currently leads to
> a NullPointerException.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-8099) Potential NPE condition in ContentOrderMergeProcessor
[
https://issues.apache.org/jira/browse/SLING-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16683984#comment-16683984
]
ASF GitHub Bot commented on SLING-8099:
---
bosschaert closed pull request #6: SLING-8099 - eliminating NPE condition
URL:
https://github.com/apache/sling-org-apache-sling-feature-extension-content/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/extension/content/ContentOrderMergeProcessor.java
b/src/main/java/org/apache/sling/feature/extension/content/ContentOrderMergeProcessor.java
index 9289e4c..82ad7db 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
@@ -30,7 +30,7 @@
public static final String DEFAULT_CONTENT_START_ORDER =
"default.content.startorder";
private void processFeature(Feature feature, Extension extension) {
-if (feature == null) {
+if (feature == null || extension == null) {
return;
}
String defaultOrder =
feature.getVariables().get(DEFAULT_CONTENT_START_ORDER);
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
> Potential NPE condition in ContentOrderMergeProcessor
> -
>
> Key: SLING-8099
> URL: https://issues.apache.org/jira/browse/SLING-8099
> Project: Sling
> Issue Type: Bug
> Components: Feature Model
>Reporter: Dominik Süß
>Priority: Major
>
> When a feature doesn't contain the content-package extension but anyhow
> contains the {{default.content.startorder}} property this currently leads to
> a NullPointerException.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] bosschaert commented on issue #6: SLING-8099 - eliminating NPE condition
bosschaert commented on issue #6: SLING-8099 - eliminating NPE condition URL: https://github.com/apache/sling-org-apache-sling-feature-extension-content/pull/6#issuecomment-437932381 Thanks @DominikSuess for the PR - 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 #6: SLING-8099 - eliminating NPE condition
bosschaert closed pull request #6: SLING-8099 - eliminating NPE condition
URL:
https://github.com/apache/sling-org-apache-sling-feature-extension-content/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/extension/content/ContentOrderMergeProcessor.java
b/src/main/java/org/apache/sling/feature/extension/content/ContentOrderMergeProcessor.java
index 9289e4c..82ad7db 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
@@ -30,7 +30,7 @@
public static final String DEFAULT_CONTENT_START_ORDER =
"default.content.startorder";
private void processFeature(Feature feature, Extension extension) {
-if (feature == null) {
+if (feature == null || extension == null) {
return;
}
String defaultOrder =
feature.getVariables().get(DEFAULT_CONTENT_START_ORDER);
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-8097) Expose queue capabilities as resource property
[ https://issues.apache.org/jira/browse/SLING-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret resolved SLING-8097. --- Resolution: Fixed Done in https://github.com/apache/sling-org-apache-sling-distribution-core/commit/5bf8e095024b3ecd395d786084baaf13ea4e9590 > Expose queue capabilities as resource property > -- > > Key: SLING-8097 > URL: https://issues.apache.org/jira/browse/SLING-8097 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Affects Versions: Content Distribution Core 0.3.4 >Reporter: Timothee Maret >Assignee: Timothee Maret >Priority: Major > Fix For: Content Distribution Core 0.3.6 > > > With SLING-8086 queues can specify their capabilities. We should expose those > capabilities as resource property. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-8099) Potential NPE condition in ContentOrderMergeProcessor
[
https://issues.apache.org/jira/browse/SLING-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16683978#comment-16683978
]
ASF GitHub Bot commented on SLING-8099:
---
DominikSuess opened a new pull request #6: SLING-8099 - eliminating NPE
condition
URL:
https://github.com/apache/sling-org-apache-sling-feature-extension-content/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
> Potential NPE condition in ContentOrderMergeProcessor
> -
>
> Key: SLING-8099
> URL: https://issues.apache.org/jira/browse/SLING-8099
> Project: Sling
> Issue Type: Bug
> Components: Feature Model
>Reporter: Dominik Süß
>Priority: Major
>
> When a feature doesn't contain the content-package extension but anyhow
> contains the {{default.content.startorder}} property this currently leads to
> a NullPointerException.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] DominikSuess opened a new pull request #6: SLING-8099 - eliminating NPE condition
DominikSuess opened a new pull request #6: SLING-8099 - eliminating NPE condition URL: https://github.com/apache/sling-org-apache-sling-feature-extension-content/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
[jira] [Created] (SLING-8099) Potential NPE condition in ContentOrderMergeProcessor
Dominik Süß created SLING-8099:
--
Summary: Potential NPE condition in ContentOrderMergeProcessor
Key: SLING-8099
URL: https://issues.apache.org/jira/browse/SLING-8099
Project: Sling
Issue Type: Bug
Components: Feature Model
Reporter: Dominik Süß
When a feature doesn't contain the content-package extension but anyhow
contains the {{default.content.startorder}} property this currently leads to a
NullPointerException.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (SLING-8083) Installer Hook: Installer events are not in all cases received
[
https://issues.apache.org/jira/browse/SLING-8083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Georg Henzler closed SLING-8083.
> Installer Hook: Installer events are not in all cases received
> --
>
> Key: SLING-8083
> URL: https://issues.apache.org/jira/browse/SLING-8083
> Project: Sling
> Issue Type: Bug
> Components: Installer
>Affects Versions: Installer Vault Package Install Hook 1.0.2
>Reporter: Georg Henzler
>Assignee: Georg Henzler
>Priority: Major
> Fix For: Installer Vault Package Install Hook 1.0.4
>
>
> In some cases, the installer hook does not receive the events for the
> installation of the installable. This may be connected to the dynamic class
> loader (that is used to load the hook) not active anymore. To ensure this is
> not happening, classes like InstallerHookOsgiEventListener shall be loaded at
> the very beginning of the hook (before it starts registering
> InstallableResources) and
> infoProvider.getInstallationState().getInstalledResources() should be taken
> into account when waiting for the installables to be installed.
> {code}
> 02.11.2018 23:43:52.566 *ERROR* [qtp2051186638-83]
> org.apache.sling.commons.classloader.impl.ClassLoaderFacade Dynamic class
> loader has already been deactivated.
> org.apache.sling.commons.classloader.impl.ClassLoaderFacade$StackTraceProbe:
> Dynamic class loader has already been deactivated.
> at
> org.apache.sling.commons.classloader.impl.ClassLoaderFacade.checkManagerActive(ClassLoaderFacade.java:69)
> [org.apache.sling.commons.classloader:1.4.2]
> at
> org.apache.sling.commons.classloader.impl.ClassLoaderFacade.loadClass(ClassLoaderFacade.java:133)
> [org.apache.sling.commons.classloader:1.4.2]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
> at java.net.FactoryURLClassLoader.loadClass(URLClassLoader.java:814)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
> org.apache.sling.installer.provider.installhook.OsgiInstallerHook.waitForServiceChanges(OsgiInstallerHook.java:410)
> at
> org.apache.sling.installer.provider.installhook.OsgiInstallerHook.execute(OsgiInstallerHook.java:201)
> at
> org.apache.jackrabbit.vault.packaging.impl.InstallHookProcessorImpl.execute(InstallHookProcessorImpl.java:148)
> [org.apache.jackrabbit.vault:3.1.44]
> at
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:241)
> [org.apache.jackrabbit.vault:3.1.44]
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:398)
> [org.apache.jackrabbit.vault:3.1.44]
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:357)
> [org.apache.jackrabbit.vault:3.1.44]
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.install(JcrPackageImpl.java:351)
> [org.apache.jackrabbit.vault:3.1.44]
> at
> com.day.crx.packmgr.impl.servlets.ServiceServlet.doInstall(ServiceServlet.java:437)
> [com.adobe.granite.crx-packagemgr:1.2.60]
> at
> com.day.crx.packmgr.impl.servlets.ServiceServlet.upload(ServiceServlet.java:512)
> [com.adobe.granite.crx-packagemgr:1.2.60]
> at
> com.day.crx.packmgr.impl.servlets.ServiceServlet.doService(ServiceServlet.java:180)
> [com.adobe.granite.crx-packagemgr:1.2.60]
> at
> com.day.crx.packmgr.impl.AbstractServlet.service(AbstractServlet.java:54)
> [com.adobe.granite.crx-packagemgr:1.2.60]
> at com.day.crx.packmgr.impl.MainServlet.doService(MainServlet.java:157)
> [com.adobe.granite.crx-packagemgr:1.2.60]
> at com.day.crx.packmgr.impl.MainServlet.service(MainServlet.java:134)
> [com.adobe.granite.crx-packagemgr:1.2.60]
> at
> org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:120)
> [org.apache.felix.http.jetty:3.4.7.B012]
> at
> org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:86)
> [org.apache.felix.http.jetty:3.4.7.B012]
> at
> com.adobe.granite.cors.impl.CORSHandler.doFilter(CORSHandler.java:120)
> [com.adobe.granite.cors:1.0.6]
> at
> org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:135)
> [org.apache.felix.http.jetty:3.4.7.B012]
> at
> org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:81)
> [org.apache.felix.http.jetty:3.4.7.B012]
> at
> org.apache.sling.security.impl.ReferrerFilter.doFilter(ReferrerFilter.java:328)
> [org.apache.sling.security:1.1.12]
> at
> org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:135)
> [org.apache.felix.http.jetty:3.4.7.B012]
> at
>
[jira] [Commented] (SLING-8098) Update DistributionQueue method/variable to deal with entries
[
https://issues.apache.org/jira/browse/SLING-8098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16683951#comment-16683951
]
Timothee Maret commented on SLING-8098:
---
Done in
https://github.com/apache/sling-org-apache-sling-distribution-core/commit/c3aa04c6e03af966388a6bffd96b92a32df05216
> Update DistributionQueue method/variable to deal with entries
> -
>
> Key: SLING-8098
> URL: https://issues.apache.org/jira/browse/SLING-8098
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Affects Versions: Content Distribution Core 0.3.4
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Core 0.3.6
>
>
> The documentation of the {{DistributionQueue}} API refer to items instead of
> entries. Similarly, the variable are named {{items}} when they are in fact
> {{entries}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (SLING-8098) Update DistributionQueue method/variable to deal with entries
[
https://issues.apache.org/jira/browse/SLING-8098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret resolved SLING-8098.
---
Resolution: Fixed
> Update DistributionQueue method/variable to deal with entries
> -
>
> Key: SLING-8098
> URL: https://issues.apache.org/jira/browse/SLING-8098
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Affects Versions: Content Distribution Core 0.3.4
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Core 0.3.6
>
>
> The documentation of the {{DistributionQueue}} API refer to items instead of
> entries. Similarly, the variable are named {{items}} when they are in fact
> {{entries}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-8098) Update DistributionQueue method/variable to deal with entries
[
https://issues.apache.org/jira/browse/SLING-8098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated SLING-8098:
--
Summary: Update DistributionQueue method/variable to deal with entries
(was: Update DistributionQueue documentation and method/variable names)
> Update DistributionQueue method/variable to deal with entries
> -
>
> Key: SLING-8098
> URL: https://issues.apache.org/jira/browse/SLING-8098
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Affects Versions: Content Distribution Core 0.3.4
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Core 0.3.6
>
>
> The documentation of the {{DistributionQueue}} API refer to items instead of
> entries. Similarly, the variable are named {{items}} when they are in fact
> {{entries}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-8098) Update DistributionQueue documentation and method/variable names
[
https://issues.apache.org/jira/browse/SLING-8098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret updated SLING-8098:
--
Summary: Update DistributionQueue documentation and method/variable names
(was: Update DistributionQueue documentation and variable names)
> Update DistributionQueue documentation and method/variable names
>
>
> Key: SLING-8098
> URL: https://issues.apache.org/jira/browse/SLING-8098
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Affects Versions: Content Distribution Core 0.3.4
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Core 0.3.6
>
>
> The documentation of the {{DistributionQueue}} API refer to items instead of
> entries. Similarly, the variable are named {{items}} when they are in fact
> {{entries}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[RESULT][VOTE] Release Apache Sling Installer Vault Package Install Hook 1.0.4
Hi, The vote has passed with the following result: +1 (binding): Konrad Windszus, Daniel Klco, Carsten Ziegeler, Radu Cotescu I'll promote the artifacts to the central Maven repository and will copy this release to the Sling dist directory. -Georg On 2018-11-09 15:42, Radu Cotescu wrote: +1 On 9 Nov 2018, at 13:42, Georg Henzler 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] [Resolved] (SLING-8086) Extend distribution queue SPI with the ability to clear and batch remove items
[
https://issues.apache.org/jira/browse/SLING-8086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret resolved SLING-8086.
---
Resolution: Fixed
> Extend distribution queue SPI with the ability to clear and batch remove items
> --
>
> Key: SLING-8086
> URL: https://issues.apache.org/jira/browse/SLING-8086
> Project: Sling
> Issue Type: Improvement
>Affects Versions: Content Distribution Core 0.3.4
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Core 0.3.6
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently, the {{DistributionQueue}} API only allows to remove a single
> random item from the queue. Clearing the queue, and batch removal of items
> are useful features which can't currently be supported in an optimised way
> for the {{DistributionQueue}} API.
> In this issue, we would extend the
> {{org.apache.sling.distribution.queue.spi}} SPI with new trait interfaces to
> allow clearing and batch removing items.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-8086) Extend distribution queue SPI with the ability to clear and batch remove items
[
https://issues.apache.org/jira/browse/SLING-8086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16683921#comment-16683921
]
Timothee Maret commented on SLING-8086:
---
Done in
https://github.com/apache/sling-org-apache-sling-distribution-core/commit/cac45808dd4efbd1089f3a34d8b4bd456ac2dc26
> Extend distribution queue SPI with the ability to clear and batch remove items
> --
>
> Key: SLING-8086
> URL: https://issues.apache.org/jira/browse/SLING-8086
> Project: Sling
> Issue Type: Improvement
>Affects Versions: Content Distribution Core 0.3.4
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Core 0.3.6
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently, the {{DistributionQueue}} API only allows to remove a single
> random item from the queue. Clearing the queue, and batch removal of items
> are useful features which can't currently be supported in an optimised way
> for the {{DistributionQueue}} API.
> In this issue, we would extend the
> {{org.apache.sling.distribution.queue.spi}} SPI with new trait interfaces to
> allow clearing and batch removing items.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SLING-8098) Update DistributionQueue documentation and variable names
Timothee Maret created SLING-8098:
-
Summary: Update DistributionQueue documentation and variable names
Key: SLING-8098
URL: https://issues.apache.org/jira/browse/SLING-8098
Project: Sling
Issue Type: Improvement
Components: Content Distribution
Affects Versions: Content Distribution Core 0.3.4
Reporter: Timothee Maret
Assignee: Timothee Maret
Fix For: Content Distribution Core 0.3.6
The documentation of the {{DistributionQueue}} API refer to items instead of
entries. Similarly, the variable are named {{items}} when they are in fact
{{entries}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (SLING-8096) Make it possible to configure Merge Handlers and Post Processors
[ https://issues.apache.org/jira/browse/SLING-8096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert reassigned SLING-8096: --- Assignee: David Bosschaert > Make it possible to configure Merge Handlers and Post Processors > > > Key: SLING-8096 > URL: https://issues.apache.org/jira/browse/SLING-8096 > Project: Sling > Issue Type: New Feature > 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 > > > Feature merge handlers and postprocessors are provided via the ServiceLoader > extension mechanism. We need to create a way to pass configuration to these. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SLING-8065) Introduce ReadOnlyDistributionQueue API
[
https://issues.apache.org/jira/browse/SLING-8065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret resolved SLING-8065.
---
Resolution: Won't Do
Instead of extracting trait APIs, we used a queue meta data approach to specify
the queue capabilities in SLING-8086.
> Introduce ReadOnlyDistributionQueue API
> ---
>
> Key: SLING-8065
> URL: https://issues.apache.org/jira/browse/SLING-8065
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
>Affects Versions: Content Distribution Core 0.3.4
>Reporter: Timothee Maret
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Core 0.3.6
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We currently export an
> [SPI|https://github.com/apache/sling-org-apache-sling-distribution-core/tree/master/src/main/java/org/apache/sling/distribution/queue/spi]
> with a fully editable queue,
> [DistributionQueue|https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/queue/spi/DistributionQueue.java].
> Some distribution queue implementation are read-only meaning that they don't
> provide the ability to add/remove items. Example of such read-only queue is
> an implementation on top of an append only messaging service.
> In this issue, I suggest to introduce add and export the
> {{ReadOnlyDistributionQueue}} interface. The existing read-only method
> signatures from {{DistributionQueue}} would be moved from
> {{DistributionQueue}} to {{ReadOnlyDistributionQueue}}. {{DistributionQueue}}
> would extend from {{ReadOnlyDistributionQueue}}. This change is backward
> compatible.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SLING-8097) Expose queue capabilities as resource property
Timothee Maret created SLING-8097: - Summary: Expose queue capabilities as resource property Key: SLING-8097 URL: https://issues.apache.org/jira/browse/SLING-8097 Project: Sling Issue Type: Improvement Components: Content Distribution Affects Versions: Content Distribution Core 0.3.4 Reporter: Timothee Maret Assignee: Timothee Maret Fix For: Content Distribution Core 0.3.6 With SLING-8086 queues can specify their capabilities. We should expose those capabilities as resource property. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-7970) Add Feature Model introspection service
[ https://issues.apache.org/jira/browse/SLING-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert updated SLING-7970: Fix Version/s: Feature Model Launcher 0.2.0 > Add Feature Model introspection service > --- > > Key: SLING-7970 > URL: https://issues.apache.org/jira/browse/SLING-7970 > Project: Sling > Issue Type: New Feature > Components: Feature Model >Reporter: David Bosschaert >Assignee: David Bosschaert >Priority: Major > Fix For: Feature Model Launcher 0.2.0 > > > We need a service that can report on the feature model that is launched by > the launcher, for introspection purposes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-8096) Make it possible to configure Merge Handlers and Post Processors
David Bosschaert created SLING-8096: --- Summary: Make it possible to configure Merge Handlers and Post Processors Key: SLING-8096 URL: https://issues.apache.org/jira/browse/SLING-8096 Project: Sling Issue Type: New Feature Components: Feature Model Affects Versions: Feature Model 0.2.0 Reporter: David Bosschaert Fix For: Feature Model 0.2.2 Feature merge handlers and postprocessors are provided via the ServiceLoader extension mechanism. We need to create a way to pass configuration to these. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-7970) Add Feature Model introspection service
[
https://issues.apache.org/jira/browse/SLING-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16683840#comment-16683840
]
David Bosschaert commented on SLING-7970:
-
A mechanism to look up the effective feature model is provided via the
{{sling.feature}} OSGi framework property which can be looked up and returns
the URL of a resource that provides the effective feature.
> Add Feature Model introspection service
> ---
>
> Key: SLING-7970
> URL: https://issues.apache.org/jira/browse/SLING-7970
> Project: Sling
> Issue Type: New Feature
> Components: Feature Model
>Reporter: David Bosschaert
>Assignee: David Bosschaert
>Priority: Major
>
> We need a service that can report on the feature model that is launched by
> the launcher, for introspection purposes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [RT] Simple File System Resource Provider
+1 on a simple resource provider, I'm curious about the focus on a filesystem provider. I've started playing around with creating one and I see a clear logical association between what a resource provider needs and a key-value store. Good key-value stores already have versioning, and non blocking read and writes. Things that are architecturally nice to have removed from our hands. Something like mvstore - http://www.h2database.com/html/mvstore.html or lmdb - https://symas.com/lmdb/ would be really good to build on. - Jason On Sun, Nov 11, 2018, at 4:55 AM, Carsten Ziegeler wrote: > I've recently tried to run a minimal Sling without JCR. Obviously you > need at least one resource provider to have some content, so I picked > the easiest choice, the file system resource provider. > > However, it turned out that this is not the easiest choice for this > scenario as it has a lot of features, especially support for handling > content XML files and vault files, which again brings in the whole > dependency list to jcr related bundles. In my case I just want to stream > binaries and json files, so none of the above is needed. But still I > need to deploy all the bundles. In addition there are other things like > the json parsing library is embedded in the bundle etc. > > Now, I think we should really have a simple file system resource > provider which only does the basics and has not an endless list of > bundles. I see two ways to get there: make the current provider > extensible and provide all this extra cruft as extensions or write a new > simple provider. > > Thoughts? > > Regards > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
[jira] [Resolved] (SLING-7970) Add Feature Model introspection service
[ https://issues.apache.org/jira/browse/SLING-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert resolved SLING-7970. - Resolution: Fixed > Add Feature Model introspection service > --- > > Key: SLING-7970 > URL: https://issues.apache.org/jira/browse/SLING-7970 > Project: Sling > Issue Type: New Feature > Components: Feature Model >Reporter: David Bosschaert >Assignee: David Bosschaert >Priority: Major > > We need a service that can report on the feature model that is launched by > the launcher, for introspection purposes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [RT] Simple File System Resource Provider
Am 12.11.2018 um 14:31 schrieb Bertrand Delacretaz: Hi, On Mon, Nov 12, 2018 at 12:20 PM Carsten Ziegeler wrote: ...As a side note, the markdown resource provider in the whiteboard is another file system based rp which is closer to my use case, except that it supports markdown files instead of json... Having a GitHub-friendly resource provider would be cool IMO, and that one looks like a good option for that. Absolutely, but it's mixing concerns, it mixes where to fetch resources from (file system) with the type of resources (markdown files). If my md files are somewhere else I can't use that RP. And if I have mixed files in my file system it might get challenging as well. Ultimately, the current fs provider has the same problem. Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [RT] Simple File System Resource Provider
Hi, On Mon, Nov 12, 2018 at 12:20 PM Carsten Ziegeler wrote: > ...As a side note, the markdown resource provider in the whiteboard is > another file system based rp which is closer to my use case, except that > it supports markdown files instead of json... Having a GitHub-friendly resource provider would be cool IMO, and that one looks like a good option for that. -Bertrand
[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=16683780#comment-16683780
]
ASF GitHub Bot commented on SLING-8078:
---
simonetripodi commented on issue #8: 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/8#issuecomment-437872968
awesome, thanks a lot to your for the review! :)
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> New Analyser task which is able to detect Export-Package dependencies between
> regions
> -
>
> Key: SLING-8078
> URL: https://issues.apache.org/jira/browse/SLING-8078
> Project: Sling
> Issue Type: New Feature
> Components: Feature Model, Maven Plugins and Archetypes
>Affects Versions: Feature Model Analyser 0.2.0
>Reporter: Simone Tripodi
>Assignee: David Bosschaert
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0, Feature Model Analyser
> 0.2.2
>
>
> It may be helpful users have the need to define a {{deprecated}} region in
> order to mark which APIs don't have to be exposed to end users, a new
> Analyser Task implementation will help to detect if {{global}} exported APIs
> don't have {{uses}} dependencies to APIs that are declared in the
> {{deprecated}} region.
> i.e. given a feature:
> {noformat}
> ...
> [
> {
> "name": "global"
> "exports": ["org.osgi.util.function"]
> },
> {
> "name": "deprecated",
>"exports": ["org.objectweb.asm"]
> }
> ]
> ...
> {noformat}
> and a bundle declares the OSGi header in the Manifest as below:
> {noformat}
> Export-Package: org.osgi.util.function;uses:="org.objectweb.asm"
> {noformat}
> the new Analyser Task implementation will detect that "violation"
> {noformat}
> Bundle 'org.osgi:org.osgi.util.function:1.0.0', defined in feature
> 'org.apache.sling.testing:org.apache.sling.testing.apiregions:1.0.0',
> declares 'org.osgi.util.function' in the 'Export-Package' header which
> requires 'org.objectweb.asm' package that is in the 'deprecated' region
> {noformat}
> PR is coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] simonetripodi commented on issue #8: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
simonetripodi commented on issue #8: 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/8#issuecomment-437872968 awesome, thanks a lot to your for the review! :) 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=16683737#comment-16683737
]
ASF GitHub Bot commented on SLING-8078:
---
bosschaert commented on issue #8: 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/8#issuecomment-437865324
Thanks @simonetripodi for code and test case - it's merged!
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> New Analyser task which is able to detect Export-Package dependencies between
> regions
> -
>
> Key: SLING-8078
> URL: https://issues.apache.org/jira/browse/SLING-8078
> Project: Sling
> Issue Type: New Feature
> Components: Feature Model, Maven Plugins and Archetypes
>Affects Versions: Feature Model Analyser 0.2.0
>Reporter: Simone Tripodi
>Assignee: David Bosschaert
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0, Feature Model Analyser
> 0.2.2
>
>
> It may be helpful users have the need to define a {{deprecated}} region in
> order to mark which APIs don't have to be exposed to end users, a new
> Analyser Task implementation will help to detect if {{global}} exported APIs
> don't have {{uses}} dependencies to APIs that are declared in the
> {{deprecated}} region.
> i.e. given a feature:
> {noformat}
> ...
> [
> {
> "name": "global"
> "exports": ["org.osgi.util.function"]
> },
> {
> "name": "deprecated",
>"exports": ["org.objectweb.asm"]
> }
> ]
> ...
> {noformat}
> and a bundle declares the OSGi header in the Manifest as below:
> {noformat}
> Export-Package: org.osgi.util.function;uses:="org.objectweb.asm"
> {noformat}
> the new Analyser Task implementation will detect that "violation"
> {noformat}
> Bundle 'org.osgi:org.osgi.util.function:1.0.0', defined in feature
> 'org.apache.sling.testing:org.apache.sling.testing.apiregions:1.0.0',
> declares 'org.osgi.util.function' in the 'Export-Package' header which
> requires 'org.objectweb.asm' package that is in the 'deprecated' region
> {noformat}
> PR is coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[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=16683736#comment-16683736
]
ASF GitHub Bot commented on SLING-8078:
---
bosschaert closed pull request #8: 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/8
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> New Analyser task which is able to detect Export-Package dependencies between
> regions
> -
>
> Key: SLING-8078
> URL: https://issues.apache.org/jira/browse/SLING-8078
> Project: Sling
> Issue Type: New Feature
> Components: Feature Model, Maven Plugins and Archetypes
>Affects Versions: Feature Model Analyser 0.2.0
>Reporter: Simone Tripodi
>Assignee: David Bosschaert
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0, Feature Model Analyser
> 0.2.2
>
>
> It may be helpful users have the need to define a {{deprecated}} region in
> order to mark which APIs don't have to be exposed to end users, a new
> Analyser Task implementation will help to detect if {{global}} exported APIs
> don't have {{uses}} dependencies to APIs that are declared in the
> {{deprecated}} region.
> i.e. given a feature:
> {noformat}
> ...
> [
> {
> "name": "global"
> "exports": ["org.osgi.util.function"]
> },
> {
> "name": "deprecated",
>"exports": ["org.objectweb.asm"]
> }
> ]
> ...
> {noformat}
> and a bundle declares the OSGi header in the Manifest as below:
> {noformat}
> Export-Package: org.osgi.util.function;uses:="org.objectweb.asm"
> {noformat}
> the new Analyser Task implementation will detect that "violation"
> {noformat}
> Bundle 'org.osgi:org.osgi.util.function:1.0.0', defined in feature
> 'org.apache.sling.testing:org.apache.sling.testing.apiregions:1.0.0',
> declares 'org.osgi.util.function' in the 'Export-Package' header which
> requires 'org.objectweb.asm' package that is in the 'deprecated' region
> {noformat}
> PR is coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] bosschaert commented on issue #8: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
bosschaert commented on issue #8: 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/8#issuecomment-437865324 Thanks @simonetripodi for code and test case - 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 #8: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
bosschaert closed pull request #8: 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/8 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-8095) Include Sling Servlet Annotations in Aggregate Javadoc
[ https://issues.apache.org/jira/browse/SLING-8095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16683729#comment-16683729 ] Konrad Windszus commented on SLING-8095: Just pushed a proposed fix in https://github.com/apache/sling-tooling-release/commit/37398977654e56939fe26487a3990c3170a5fdde. [~rombert] Can I ask you to build and push the updated javadoc as I still suffer from the problems outlined in https://issues.apache.org/jira/browse/SLING-6766?focusedCommentId=16358554=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16358554. > Include Sling Servlet Annotations in Aggregate Javadoc > -- > > Key: SLING-8095 > URL: https://issues.apache.org/jira/browse/SLING-8095 > Project: Sling > Issue Type: Improvement > Components: General >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > > Currently the javadoc for the new modules added in SLING-7624 are not > contained in the javadoc for Sling 11 > (https://sling.apache.org/apidocs/sling11/index.html). -- 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=16683718#comment-16683718
]
ASF GitHub Bot commented on SLING-8078:
---
simonetripodi commented on issue #8: 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/8#issuecomment-437860775
`testPackageEnlistedInBothRegions()` added, see latest commit! Please
apologise once again :)
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> New Analyser task which is able to detect Export-Package dependencies between
> regions
> -
>
> Key: SLING-8078
> URL: https://issues.apache.org/jira/browse/SLING-8078
> Project: Sling
> Issue Type: New Feature
> Components: Feature Model, Maven Plugins and Archetypes
>Affects Versions: Feature Model Analyser 0.2.0
>Reporter: Simone Tripodi
>Assignee: David Bosschaert
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0, Feature Model Analyser
> 0.2.2
>
>
> It may be helpful users have the need to define a {{deprecated}} region in
> order to mark which APIs don't have to be exposed to end users, a new
> Analyser Task implementation will help to detect if {{global}} exported APIs
> don't have {{uses}} dependencies to APIs that are declared in the
> {{deprecated}} region.
> i.e. given a feature:
> {noformat}
> ...
> [
> {
> "name": "global"
> "exports": ["org.osgi.util.function"]
> },
> {
> "name": "deprecated",
>"exports": ["org.objectweb.asm"]
> }
> ]
> ...
> {noformat}
> and a bundle declares the OSGi header in the Manifest as below:
> {noformat}
> Export-Package: org.osgi.util.function;uses:="org.objectweb.asm"
> {noformat}
> the new Analyser Task implementation will detect that "violation"
> {noformat}
> Bundle 'org.osgi:org.osgi.util.function:1.0.0', defined in feature
> 'org.apache.sling.testing:org.apache.sling.testing.apiregions:1.0.0',
> declares 'org.osgi.util.function' in the 'Export-Package' header which
> requires 'org.objectweb.asm' package that is in the 'deprecated' region
> {noformat}
> PR is coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SLING-8095) Include Sling Servlet Annotations in Aggregate Javadoc
Konrad Windszus created SLING-8095: -- Summary: Include Sling Servlet Annotations in Aggregate Javadoc Key: SLING-8095 URL: https://issues.apache.org/jira/browse/SLING-8095 Project: Sling Issue Type: Improvement Components: General Reporter: Konrad Windszus Assignee: Konrad Windszus Currently the javadoc for the new modules added in SLING-7624 are not contained in the javadoc for Sling 11 (https://sling.apache.org/apidocs/sling11/index.html). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-8095) Include Sling Servlet Annotations in Aggregate Javadoc
[ https://issues.apache.org/jira/browse/SLING-8095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16683719#comment-16683719 ] Konrad Windszus commented on SLING-8095: Most probably the word splitting (https://mywiki.wooledge.org/WordSplitting) of bash is not working correctly as there is a missing space between the artifacts (https://github.com/apache/sling-tooling-release/blob/b649c164145e05c613e120c5270de22cf82a4064/generate_javadoc_for_release.sh#L26). > Include Sling Servlet Annotations in Aggregate Javadoc > -- > > Key: SLING-8095 > URL: https://issues.apache.org/jira/browse/SLING-8095 > Project: Sling > Issue Type: Improvement > Components: General >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > > Currently the javadoc for the new modules added in SLING-7624 are not > contained in the javadoc for Sling 11 > (https://sling.apache.org/apidocs/sling11/index.html). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] simonetripodi commented on issue #8: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
simonetripodi commented on issue #8: 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/8#issuecomment-437860775 `testPackageEnlistedInBothRegions()` added, see latest commit! Please apologise once again :) 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-8095) Include Sling Servlet Annotations in Aggregate Javadoc
[ https://issues.apache.org/jira/browse/SLING-8095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16683714#comment-16683714 ] Konrad Windszus commented on SLING-8095: The artifacts has been explicitly added in https://github.com/apache/sling-tooling-release/blob/b649c164145e05c613e120c5270de22cf82a4064/generate_javadoc_for_release.sh#L26 though. [~rombert] Do you know why the javadoc does still not appear? > Include Sling Servlet Annotations in Aggregate Javadoc > -- > > Key: SLING-8095 > URL: https://issues.apache.org/jira/browse/SLING-8095 > Project: Sling > Issue Type: Improvement > Components: General >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > > Currently the javadoc for the new modules added in SLING-7624 are not > contained in the javadoc for Sling 11 > (https://sling.apache.org/apidocs/sling11/index.html). -- 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=16683710#comment-16683710
]
ASF GitHub Bot commented on SLING-8078:
---
simonetripodi commented on issue #8: 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/8#issuecomment-437859716
of course, please apologise for the missing test, I'll soon push!
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> New Analyser task which is able to detect Export-Package dependencies between
> regions
> -
>
> Key: SLING-8078
> URL: https://issues.apache.org/jira/browse/SLING-8078
> Project: Sling
> Issue Type: New Feature
> Components: Feature Model, Maven Plugins and Archetypes
>Affects Versions: Feature Model Analyser 0.2.0
>Reporter: Simone Tripodi
>Assignee: David Bosschaert
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0, Feature Model Analyser
> 0.2.2
>
>
> It may be helpful users have the need to define a {{deprecated}} region in
> order to mark which APIs don't have to be exposed to end users, a new
> Analyser Task implementation will help to detect if {{global}} exported APIs
> don't have {{uses}} dependencies to APIs that are declared in the
> {{deprecated}} region.
> i.e. given a feature:
> {noformat}
> ...
> [
> {
> "name": "global"
> "exports": ["org.osgi.util.function"]
> },
> {
> "name": "deprecated",
>"exports": ["org.objectweb.asm"]
> }
> ]
> ...
> {noformat}
> and a bundle declares the OSGi header in the Manifest as below:
> {noformat}
> Export-Package: org.osgi.util.function;uses:="org.objectweb.asm"
> {noformat}
> the new Analyser Task implementation will detect that "violation"
> {noformat}
> Bundle 'org.osgi:org.osgi.util.function:1.0.0', defined in feature
> 'org.apache.sling.testing:org.apache.sling.testing.apiregions:1.0.0',
> declares 'org.osgi.util.function' in the 'Export-Package' header which
> requires 'org.objectweb.asm' package that is in the 'deprecated' region
> {noformat}
> PR is coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] simonetripodi commented on issue #8: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
simonetripodi commented on issue #8: 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/8#issuecomment-437859716 of course, please apologise for the missing test, I'll soon push! 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-8093) Raise OSGi annotations and DS, metatype and configuration admin versions to R7
[ https://issues.apache.org/jira/browse/SLING-8093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved SLING-8093. Resolution: Fixed Fixed with https://github.com/apache/sling-parent/commit/e77f7ca09def1d684b1ea93245993518c62f7519. > Raise OSGi annotations and DS, metatype and configuration admin versions to R7 > -- > > Key: SLING-8093 > URL: https://issues.apache.org/jira/browse/SLING-8093 > Project: Sling > Issue Type: Improvement >Affects Versions: Parent 34 >Reporter: Konrad Windszus >Priority: Major > Fix For: Bundle Parent 35 > > > Compare with SLING-8090. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-8094) Add OSGi sling servlet annotations to dependencyMgmt
[ https://issues.apache.org/jira/browse/SLING-8094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated SLING-8094: --- Summary: Add OSGi sling servlet annotations to dependencyMgmt (was: Add OSGi sling servlet annotations to pluginMgmt) > Add OSGi sling servlet annotations to dependencyMgmt > > > Key: SLING-8094 > URL: https://issues.apache.org/jira/browse/SLING-8094 > Project: Sling > Issue Type: Improvement > Components: General >Reporter: Konrad Windszus >Priority: Major > Fix For: Bundle Parent 35 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-8094) Add OSGi sling servlet annotations to pluginMgmt
Konrad Windszus created SLING-8094: -- Summary: Add OSGi sling servlet annotations to pluginMgmt Key: SLING-8094 URL: https://issues.apache.org/jira/browse/SLING-8094 Project: Sling Issue Type: Improvement Components: General Reporter: Konrad Windszus Fix For: Bundle Parent 35 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (SLING-8093) Raise OSGi annotations and DS, metatype and configuration admin versions to R7
[ https://issues.apache.org/jira/browse/SLING-8093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus reassigned SLING-8093: -- Assignee: Konrad Windszus > Raise OSGi annotations and DS, metatype and configuration admin versions to R7 > -- > > Key: SLING-8093 > URL: https://issues.apache.org/jira/browse/SLING-8093 > Project: Sling > Issue Type: Improvement >Affects Versions: Parent 34 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: Bundle Parent 35 > > > Compare with SLING-8090. -- 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=16683670#comment-16683670
]
ASF GitHub Bot commented on SLING-8078:
---
bosschaert commented on issue #8: 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/8#issuecomment-437854827
Hi Simo, thanks for the PR! Would it be possible to also include a unit 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: slingfeature-maven-plugin 1.0.0, Feature Model Analyser
> 0.2.2
>
>
> It may be helpful users have the need to define a {{deprecated}} region in
> order to mark which APIs don't have to be exposed to end users, a new
> Analyser Task implementation will help to detect if {{global}} exported APIs
> don't have {{uses}} dependencies to APIs that are declared in the
> {{deprecated}} region.
> i.e. given a feature:
> {noformat}
> ...
> [
> {
> "name": "global"
> "exports": ["org.osgi.util.function"]
> },
> {
> "name": "deprecated",
>"exports": ["org.objectweb.asm"]
> }
> ]
> ...
> {noformat}
> and a bundle declares the OSGi header in the Manifest as below:
> {noformat}
> Export-Package: org.osgi.util.function;uses:="org.objectweb.asm"
> {noformat}
> the new Analyser Task implementation will detect that "violation"
> {noformat}
> Bundle 'org.osgi:org.osgi.util.function:1.0.0', defined in feature
> 'org.apache.sling.testing:org.apache.sling.testing.apiregions:1.0.0',
> declares 'org.osgi.util.function' in the 'Export-Package' header which
> requires 'org.objectweb.asm' package that is in the 'deprecated' region
> {noformat}
> PR is coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] bosschaert commented on issue #8: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
bosschaert commented on issue #8: 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/8#issuecomment-437854827 Hi Simo, thanks for the PR! Would it be possible to also include a unit 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] [Updated] (SLING-8090) Use newest OSGi annotation versions
[ https://issues.apache.org/jira/browse/SLING-8090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated SLING-8090: --- Fix Version/s: (was: Bundle Parent 35) > Use newest OSGi annotation versions > --- > > Key: SLING-8090 > URL: https://issues.apache.org/jira/browse/SLING-8090 > Project: Sling > Issue Type: Bug > Components: General >Reporter: Konrad Windszus >Priority: Major > > As OSGi annotations are only processed at build time and only need support > from the according build tool (bnd in our case), we should upgrade to the > newest R7 version of all annotations. Those are supported by bnd 4.1 and do > not imply any runtime dependencies to R7 bundles. > Compare also with https://github.com/bndtools/bnd/issues/2643 and > https://github.com/bndtools/bnd/pull/2603. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-8090) Use newest OSGi annotation versions
[ https://issues.apache.org/jira/browse/SLING-8090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16683669#comment-16683669 ] Konrad Windszus commented on SLING-8090: Ok, I track the newer versions in SLING-8093 and close this one as "Won't Fix". > Use newest OSGi annotation versions > --- > > Key: SLING-8090 > URL: https://issues.apache.org/jira/browse/SLING-8090 > Project: Sling > Issue Type: Bug > Components: General >Reporter: Konrad Windszus >Priority: Major > > As OSGi annotations are only processed at build time and only need support > from the according build tool (bnd in our case), we should upgrade to the > newest R7 version of all annotations. Those are supported by bnd 4.1 and do > not imply any runtime dependencies to R7 bundles. > Compare also with https://github.com/bndtools/bnd/issues/2643 and > https://github.com/bndtools/bnd/pull/2603. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SLING-8090) Use newest OSGi annotation versions
[ https://issues.apache.org/jira/browse/SLING-8090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved SLING-8090. Resolution: Won't Fix > Use newest OSGi annotation versions > --- > > Key: SLING-8090 > URL: https://issues.apache.org/jira/browse/SLING-8090 > Project: Sling > Issue Type: Bug > Components: General >Reporter: Konrad Windszus >Priority: Major > > As OSGi annotations are only processed at build time and only need support > from the according build tool (bnd in our case), we should upgrade to the > newest R7 version of all annotations. Those are supported by bnd 4.1 and do > not imply any runtime dependencies to R7 bundles. > Compare also with https://github.com/bndtools/bnd/issues/2643 and > https://github.com/bndtools/bnd/pull/2603. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-8093) Raise OSGi annotations and DS, metatype and configuration admin versions to R7
Konrad Windszus created SLING-8093: -- Summary: Raise OSGi annotations and DS, metatype and configuration admin versions to R7 Key: SLING-8093 URL: https://issues.apache.org/jira/browse/SLING-8093 Project: Sling Issue Type: Improvement Affects Versions: Parent 34 Reporter: Konrad Windszus Fix For: Bundle Parent 35 Compare with SLING-8090. -- 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=16683596#comment-16683596
]
ASF GitHub Bot commented on SLING-8078:
---
simonetripodi opened a new pull request #8: 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/8
handling the error case where the same package is listed in both the
exporting and hiding regions
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> New Analyser task which is able to detect Export-Package dependencies between
> regions
> -
>
> Key: SLING-8078
> URL: https://issues.apache.org/jira/browse/SLING-8078
> Project: Sling
> Issue Type: New Feature
> Components: Feature Model, Maven Plugins and Archetypes
>Affects Versions: Feature Model Analyser 0.2.0
>Reporter: Simone Tripodi
>Assignee: David Bosschaert
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0, Feature Model Analyser
> 0.2.2
>
>
> It may be helpful users have the need to define a {{deprecated}} region in
> order to mark which APIs don't have to be exposed to end users, a new
> Analyser Task implementation will help to detect if {{global}} exported APIs
> don't have {{uses}} dependencies to APIs that are declared in the
> {{deprecated}} region.
> i.e. given a feature:
> {noformat}
> ...
> [
> {
> "name": "global"
> "exports": ["org.osgi.util.function"]
> },
> {
> "name": "deprecated",
>"exports": ["org.objectweb.asm"]
> }
> ]
> ...
> {noformat}
> and a bundle declares the OSGi header in the Manifest as below:
> {noformat}
> Export-Package: org.osgi.util.function;uses:="org.objectweb.asm"
> {noformat}
> the new Analyser Task implementation will detect that "violation"
> {noformat}
> Bundle 'org.osgi:org.osgi.util.function:1.0.0', defined in feature
> 'org.apache.sling.testing:org.apache.sling.testing.apiregions:1.0.0',
> declares 'org.osgi.util.function' in the 'Export-Package' header which
> requires 'org.objectweb.asm' package that is in the 'deprecated' region
> {noformat}
> PR is coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] simonetripodi opened a new pull request #8: SLING-8078 - New Analyser task which is able to detect Export-Package dependencies between regions
simonetripodi opened a new pull request #8: 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/8 handling the error case where the same package is listed in both the exporting and hiding regions 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: [RT] Simple File System Resource Provider
Yes, I was thinking of using the 1.x branch, however that branch is at version 1.3.x which contains a lot of the unneeded (from my pov) as well. Maybe I just start a prototype in the whiteboard and then we can figure out what to do about it :) As a side note, the markdown resource provider in the whiteboard is another file system based rp which is closer to my use case, except that it supports markdown files instead of json. Regards Carsten Am 12.11.2018 um 12:03 schrieb Stefan Seifert: ah, ok - this sounds like fsresource 1.2.2 (all the new stuff was added in 2.x). in this case it might make sense to create a new bundle without the existing one, or maintain the 1.x branch in parallel to 2.x or fork it to a new bundle. stefan -Original Message- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: Monday, November 12, 2018 11:51 AM To: dev@sling.apache.org; Stefan Seifert Subject: Re: [RT] Simple File System Resource Provider It's only 1 - 2 from your list is taking a structured json and creates resources out of the structure (if I'm not mistaken) which is something I don't need. With the approach I hope there is no need for b) (caching) as the mapping is 1:1 (more or less). As there is no need for cachign I don't think a) is needed either. Regards Carsten Am 12.11.2018 um 11:23 schrieb Stefan Seifert: so from my list below your use case is 1. + 2. + a) + probably b) and leaving out the other parts? or something different from what is implemented currently? stefan -Original Message- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: Monday, November 12, 2018 11:20 AM To: dev@sling.apache.org; Stefan Seifert Subject: Re: [RT] Simple File System Resource Provider Hi, I would be totally happy if we can factor out the extensions, I'm wondering however if this is worth the effort. In my use case, I would like to have a simple mapping to directories and files, supporting json and binary files. So a resource maps to a json file 1:1 regardless of the structure of the json file and a such a resource can have an additional binary. I understand the need for the support of all the other features we have today, but they are not needed for other use cases. Regards Carsten Am 12.11.2018 um 11:06 schrieb Stefan Seifert: yes, the current implementation of the fsresource provider is no longer any simple. it currently supports three (configurable) modes: 1. simple mapping of folders and binary files from filesystem (this was the starting point of fsresource) 2. reading structured resource data from JSON files and folders in the same way it is done by the content loader 3. reading structured resource data from FileVault XML files as it's stored in content packages and features: a) sending resource events if any of these files are changed in runtime b) implement some caching to speed things up c) support not only the Sling Resource API, but also simulate an underlying JCR API for code that runs on top which is still using the JCR API for cases where also the Sling Resource API would suffice but cannot be changed because it's part of a product... so the use case ranges from simple mapping of a bunch of static files to full-blown emulation of a JCR repository out of a complex project structure in the filesystem e.g. for usage in a development environemnt (see [0]). --- removing the embedded json libraries should be simple, it was only for convenience when the fsresource bundle is to deployed afterwards to an existing instance. but the dependencies to all those JCR-related bundles remains as long as all three modes and features need to be supported. i'm not sure if implementing a new fsresource provider e.g. only for 1.+2. from scratch would be the best way. there is a lot of special logic for edge cases esp. in 2. to make sure it behaves the same as the content loader which we have then to duplicate another time. it should be possible to split the existing fsresource into a core and extension bundle as it's somewhat separated already due to the different supported modes 1./2./3., and the virtual JCR API support could be made configurable as well. supporting Java 8 features for the filesystem changes detection would be a good thing; last time i was looking into it i failed to make good use of it due to strange implementation differences on windows and unix file systems (and those differences where covered by the JavaDocs). but maybe there is a way to do it right. stefan [0] https://adapt.to/2017/en/schedule/ease-development-with-apache- sling- file-system-resource-provider.html -Original Message- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: Sunday, November 11, 2018 10:56 AM To: Sling Developers Subject: [RT] Simple File System Resource Provider I've recently tried to run a minimal Sling without JCR. Obviously you need at least one resource provider to have some content, so I picked the
RE: [RT] Simple File System Resource Provider
ah, ok - this sounds like fsresource 1.2.2 (all the new stuff was added in 2.x). in this case it might make sense to create a new bundle without the existing one, or maintain the 1.x branch in parallel to 2.x or fork it to a new bundle. stefan >-Original Message- >From: Carsten Ziegeler [mailto:cziege...@apache.org] >Sent: Monday, November 12, 2018 11:51 AM >To: dev@sling.apache.org; Stefan Seifert >Subject: Re: [RT] Simple File System Resource Provider > >It's only 1 - 2 from your list is taking a structured json and creates >resources out of the structure (if I'm not mistaken) which is something >I don't need. > >With the approach I hope there is no need for b) (caching) as the >mapping is 1:1 (more or less). As there is no need for cachign I don't >think a) is needed either. > >Regards >Carsten > >Am 12.11.2018 um 11:23 schrieb Stefan Seifert: >> so from my list below your use case is 1. + 2. + a) + probably b) and >leaving out the other parts? >> or something different from what is implemented currently? >> >> stefan >> >>> -Original Message- >>> From: Carsten Ziegeler [mailto:cziege...@apache.org] >>> Sent: Monday, November 12, 2018 11:20 AM >>> To: dev@sling.apache.org; Stefan Seifert >>> Subject: Re: [RT] Simple File System Resource Provider >>> >>> Hi, >>> >>> I would be totally happy if we can factor out the extensions, I'm >>> wondering however if this is worth the effort. >>> >>> In my use case, I would like to have a simple mapping to directories and >>> files, supporting json and binary files. So a resource maps to a json >>> file 1:1 regardless of the structure of the json file and a such a >>> resource can have an additional binary. >>> >>> I understand the need for the support of all the other features we have >>> today, but they are not needed for other use cases. >>> >>> Regards >>> Carsten >>> >>> Am 12.11.2018 um 11:06 schrieb Stefan Seifert: yes, the current implementation of the fsresource provider is no longer >>> any simple. it currently supports three (configurable) modes: 1. simple mapping of folders and binary files from filesystem (this was >>> the starting point of fsresource) 2. reading structured resource data from JSON files and folders in the >>> same way it is done by the content loader 3. reading structured resource data from FileVault XML files as it's >>> stored in content packages and features: a) sending resource events if any of these files are changed in runtime b) implement some caching to speed things up c) support not only the Sling Resource API, but also simulate an >>> underlying JCR API for code that runs on top which is still using the >JCR >>> API for cases where also the Sling Resource API would suffice but cannot >be >>> changed because it's part of a product... so the use case ranges from simple mapping of a bunch of static files >to >>> full-blown emulation of a JCR repository out of a complex project >structure >>> in the filesystem e.g. for usage in a development environemnt (see [0]). --- removing the embedded json libraries should be simple, it was only for >>> convenience when the fsresource bundle is to deployed afterwards to an >>> existing instance. but the dependencies to all those JCR-related bundles remains as long >as >>> all three modes and features need to be supported. i'm not sure if implementing a new fsresource provider e.g. only for >>> 1.+2. from scratch would be the best way. there is a lot of special >logic >>> for edge cases esp. in 2. to make sure it behaves the same as the >content >>> loader which we have then to duplicate another time. it should be >possible >>> to split the existing fsresource into a core and extension bundle as >it's >>> somewhat separated already due to the different supported modes >1./2./3., >>> and the virtual JCR API support could be made configurable as well. supporting Java 8 features for the filesystem changes detection would >be >>> a good thing; last time i was looking into it i failed to make good use >of >>> it due to strange implementation differences on windows and unix file >>> systems (and those differences where covered by the JavaDocs). but maybe >>> there is a way to do it right. stefan [0] https://adapt.to/2017/en/schedule/ease-development-with-apache- >sling- >>> file-system-resource-provider.html > -Original Message- > From: Carsten Ziegeler [mailto:cziege...@apache.org] > Sent: Sunday, November 11, 2018 10:56 AM > To: Sling Developers > Subject: [RT] Simple File System Resource Provider > > I've recently tried to run a minimal Sling without JCR. Obviously you > need at least one resource provider to have some content, so I picked > the easiest choice, the file system resource provider. > > However, it turned out that this is not the easiest choice for this > scenario as
[jira] [Commented] (SLING-8092) Relocation in Content Extension to bold
[
https://issues.apache.org/jira/browse/SLING-8092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16683555#comment-16683555
]
ASF GitHub Bot commented on SLING-8092:
---
karlpauls closed pull request #5: SLING-8092 - using relocation to workaround
the relocation issue of M…
URL:
https://github.com/apache/sling-org-apache-sling-feature-extension-content/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/pom.xml b/pom.xml
index a9d4c04..dc15f7f 100644
--- a/pom.xml
+++ b/pom.xml
@@ -92,6 +92,10 @@
org.apache.sling.feature.**
+
+ org.UNSHADE.apache
+ org.apache
+
diff --git
a/src/main/java/org/apache/sling/feature/extension/content/ContentHandler.java
b/src/main/java/org/apache/sling/feature/extension/content/ContentHandler.java
index 8f039b7..8986d41 100644
---
a/src/main/java/org/apache/sling/feature/extension/content/ContentHandler.java
+++
b/src/main/java/org/apache/sling/feature/extension/content/ContentHandler.java
@@ -119,11 +119,12 @@ public boolean handle(Extension extension,
LauncherPrepareContext prepareContext
builder.save(baos);
executionPlans.add(baos.toString("UTF-8"));
}
-final Configuration initcfg = new
Configuration("org.apache.sling.jcr.packageinit.impl.ExecutionPlanRepoInitializer");
+// Workaround for too bold relocation mechanism - corresponding
details at https://issues.apache.org/jira/browse/MSHADE-156
+final Configuration initcfg = new
Configuration("org.UNSHADE.apache.sling.jcr.packageinit.impl.ExecutionPlanRepoInitializer");
initcfg.getProperties().put("executionplans",
executionPlans.toArray(new String[executionPlans.size()]));
installationContext.addConfiguration(initcfg.getPid(),
initcfg.getFactoryPid(), initcfg.getProperties());
-
-final Configuration registrycfg = new
Configuration("org.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry");
+ // Workaround for too bold relocation mechanism - corresponding
details at https://issues.apache.org/jira/browse/MSHADE-156
+final Configuration registrycfg = new
Configuration("org.UNSHADE.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry");
registrycfg.getProperties().put("homePath", REGISTRY_FOLDER);
installationContext.addConfiguration(registrycfg.getPid(),
registrycfg.getFactoryPid(), registrycfg.getProperties());;
diff --git
a/src/test/java/org/apache/sling/feature/extension/content/ContentHandlerTest.java
b/src/test/java/org/apache/sling/feature/extension/content/ContentHandlerTest.java
index 3e97c18..06b7cff 100644
---
a/src/test/java/org/apache/sling/feature/extension/content/ContentHandlerTest.java
+++
b/src/test/java/org/apache/sling/feature/extension/content/ContentHandlerTest.java
@@ -105,8 +105,8 @@ public void testMultipleStartOrders() throws Exception {
ArgumentCaptor> executionPlanCaptor =
ArgumentCaptor.forClass(Dictionary.class);
ch.handle(ext, prepareContext, installationContext);
-
verify(installationContext).addConfiguration(eq("org.apache.sling.jcr.packageinit.impl.ExecutionPlanRepoInitializer"),
any(), executionPlanCaptor.capture());
-
verify(installationContext).addConfiguration(eq("org.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry"),
any(), any());
+
verify(installationContext).addConfiguration(eq("org.UNSHADE.apache.sling.jcr.packageinit.impl.ExecutionPlanRepoInitializer"),
any(), executionPlanCaptor.capture());
+
verify(installationContext).addConfiguration(eq("org.UNSHADE.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry"),
any(), any());
Iterator> dictIt =
executionPlanCaptor.getAllValues().iterator();
final String[] executionplans = (String[])
dictIt.next().get("executionplans");
final String expected_0 =
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
> Relocation in Content Extension to bold
> ---
>
> Key: SLING-8092
> URL:
Re: [RT] Simple File System Resource Provider
It's only 1 - 2 from your list is taking a structured json and creates resources out of the structure (if I'm not mistaken) which is something I don't need. With the approach I hope there is no need for b) (caching) as the mapping is 1:1 (more or less). As there is no need for cachign I don't think a) is needed either. Regards Carsten Am 12.11.2018 um 11:23 schrieb Stefan Seifert: so from my list below your use case is 1. + 2. + a) + probably b) and leaving out the other parts? or something different from what is implemented currently? stefan -Original Message- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: Monday, November 12, 2018 11:20 AM To: dev@sling.apache.org; Stefan Seifert Subject: Re: [RT] Simple File System Resource Provider Hi, I would be totally happy if we can factor out the extensions, I'm wondering however if this is worth the effort. In my use case, I would like to have a simple mapping to directories and files, supporting json and binary files. So a resource maps to a json file 1:1 regardless of the structure of the json file and a such a resource can have an additional binary. I understand the need for the support of all the other features we have today, but they are not needed for other use cases. Regards Carsten Am 12.11.2018 um 11:06 schrieb Stefan Seifert: yes, the current implementation of the fsresource provider is no longer any simple. it currently supports three (configurable) modes: 1. simple mapping of folders and binary files from filesystem (this was the starting point of fsresource) 2. reading structured resource data from JSON files and folders in the same way it is done by the content loader 3. reading structured resource data from FileVault XML files as it's stored in content packages and features: a) sending resource events if any of these files are changed in runtime b) implement some caching to speed things up c) support not only the Sling Resource API, but also simulate an underlying JCR API for code that runs on top which is still using the JCR API for cases where also the Sling Resource API would suffice but cannot be changed because it's part of a product... so the use case ranges from simple mapping of a bunch of static files to full-blown emulation of a JCR repository out of a complex project structure in the filesystem e.g. for usage in a development environemnt (see [0]). --- removing the embedded json libraries should be simple, it was only for convenience when the fsresource bundle is to deployed afterwards to an existing instance. but the dependencies to all those JCR-related bundles remains as long as all three modes and features need to be supported. i'm not sure if implementing a new fsresource provider e.g. only for 1.+2. from scratch would be the best way. there is a lot of special logic for edge cases esp. in 2. to make sure it behaves the same as the content loader which we have then to duplicate another time. it should be possible to split the existing fsresource into a core and extension bundle as it's somewhat separated already due to the different supported modes 1./2./3., and the virtual JCR API support could be made configurable as well. supporting Java 8 features for the filesystem changes detection would be a good thing; last time i was looking into it i failed to make good use of it due to strange implementation differences on windows and unix file systems (and those differences where covered by the JavaDocs). but maybe there is a way to do it right. stefan [0] https://adapt.to/2017/en/schedule/ease-development-with-apache-sling- file-system-resource-provider.html -Original Message- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: Sunday, November 11, 2018 10:56 AM To: Sling Developers Subject: [RT] Simple File System Resource Provider I've recently tried to run a minimal Sling without JCR. Obviously you need at least one resource provider to have some content, so I picked the easiest choice, the file system resource provider. However, it turned out that this is not the easiest choice for this scenario as it has a lot of features, especially support for handling content XML files and vault files, which again brings in the whole dependency list to jcr related bundles. In my case I just want to stream binaries and json files, so none of the above is needed. But still I need to deploy all the bundles. In addition there are other things like the json parsing library is embedded in the bundle etc. Now, I think we should really have a simple file system resource provider which only does the basics and has not an endless list of bundles. I see two ways to get there: make the current provider extensible and provide all this extra cruft as extensions or write a new simple provider. Thoughts? Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org --
[GitHub] karlpauls closed pull request #5: SLING-8092 - using relocation to workaround the relocation issue of M…
karlpauls closed pull request #5: SLING-8092 - using relocation to workaround
the relocation issue of M…
URL:
https://github.com/apache/sling-org-apache-sling-feature-extension-content/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/pom.xml b/pom.xml
index a9d4c04..dc15f7f 100644
--- a/pom.xml
+++ b/pom.xml
@@ -92,6 +92,10 @@
org.apache.sling.feature.**
+
+ org.UNSHADE.apache
+ org.apache
+
diff --git
a/src/main/java/org/apache/sling/feature/extension/content/ContentHandler.java
b/src/main/java/org/apache/sling/feature/extension/content/ContentHandler.java
index 8f039b7..8986d41 100644
---
a/src/main/java/org/apache/sling/feature/extension/content/ContentHandler.java
+++
b/src/main/java/org/apache/sling/feature/extension/content/ContentHandler.java
@@ -119,11 +119,12 @@ public boolean handle(Extension extension,
LauncherPrepareContext prepareContext
builder.save(baos);
executionPlans.add(baos.toString("UTF-8"));
}
-final Configuration initcfg = new
Configuration("org.apache.sling.jcr.packageinit.impl.ExecutionPlanRepoInitializer");
+// Workaround for too bold relocation mechanism - corresponding
details at https://issues.apache.org/jira/browse/MSHADE-156
+final Configuration initcfg = new
Configuration("org.UNSHADE.apache.sling.jcr.packageinit.impl.ExecutionPlanRepoInitializer");
initcfg.getProperties().put("executionplans",
executionPlans.toArray(new String[executionPlans.size()]));
installationContext.addConfiguration(initcfg.getPid(),
initcfg.getFactoryPid(), initcfg.getProperties());
-
-final Configuration registrycfg = new
Configuration("org.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry");
+ // Workaround for too bold relocation mechanism - corresponding
details at https://issues.apache.org/jira/browse/MSHADE-156
+final Configuration registrycfg = new
Configuration("org.UNSHADE.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry");
registrycfg.getProperties().put("homePath", REGISTRY_FOLDER);
installationContext.addConfiguration(registrycfg.getPid(),
registrycfg.getFactoryPid(), registrycfg.getProperties());;
diff --git
a/src/test/java/org/apache/sling/feature/extension/content/ContentHandlerTest.java
b/src/test/java/org/apache/sling/feature/extension/content/ContentHandlerTest.java
index 3e97c18..06b7cff 100644
---
a/src/test/java/org/apache/sling/feature/extension/content/ContentHandlerTest.java
+++
b/src/test/java/org/apache/sling/feature/extension/content/ContentHandlerTest.java
@@ -105,8 +105,8 @@ public void testMultipleStartOrders() throws Exception {
ArgumentCaptor> executionPlanCaptor =
ArgumentCaptor.forClass(Dictionary.class);
ch.handle(ext, prepareContext, installationContext);
-
verify(installationContext).addConfiguration(eq("org.apache.sling.jcr.packageinit.impl.ExecutionPlanRepoInitializer"),
any(), executionPlanCaptor.capture());
-
verify(installationContext).addConfiguration(eq("org.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry"),
any(), any());
+
verify(installationContext).addConfiguration(eq("org.UNSHADE.apache.sling.jcr.packageinit.impl.ExecutionPlanRepoInitializer"),
any(), executionPlanCaptor.capture());
+
verify(installationContext).addConfiguration(eq("org.UNSHADE.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry"),
any(), any());
Iterator> dictIt =
executionPlanCaptor.getAllValues().iterator();
final String[] executionplans = (String[])
dictIt.next().get("executionplans");
final String expected_0 =
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-8066) MockProperty.setValue(final String[] newValues) throws null pointer exception
[ https://issues.apache.org/jira/browse/SLING-8066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-8066. --- Resolution: Fixed fixed in https://github.com/apache/sling-org-apache-sling-testing-jcr-mock/commit/ca519dbb7ca79b0d50830e212345a4846e239094 > MockProperty.setValue(final String[] newValues) throws null pointer exception > -- > > Key: SLING-8066 > URL: https://issues.apache.org/jira/browse/SLING-8066 > Project: Sling > Issue Type: Bug > Components: Testing >Affects Versions: Testing JCR Mock 1.4.0 >Reporter: Pankaj Parashar >Assignee: Stefan Seifert >Priority: Blocker > Fix For: Testing JCR Mock 1.4.2 > > Time Spent: 50m > Remaining Estimate: 0h > > There is no null check in this api method. In our case product code is > passing a null value in the below form for a multivalve property. > currentNode.setProperty(propertyName, (String[])null); > MockProperty api throws null pointer exception when we use JCR mocking. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] stefanseifert closed pull request #4: SLING-8066 remove property if set to null (for all nullable property value types)
stefanseifert closed pull request #4: SLING-8066 remove property if set to null (for all nullable property value types) URL: https://github.com/apache/sling-org-apache-sling-testing-jcr-mock/pull/4 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] stefanseifert closed pull request #3: SLING-8066 MockProperty.setValue(final String[] newValues) throws null pointer exception
stefanseifert closed pull request #3: SLING-8066 MockProperty.setValue(final
String[] newValues) throws null pointer exception
URL: https://github.com/apache/sling-org-apache-sling-testing-jcr-mock/pull/3
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/testing/mock/jcr/MockProperty.java
b/src/main/java/org/apache/sling/testing/mock/jcr/MockProperty.java
index 291a165..5a5bb75 100644
--- a/src/main/java/org/apache/sling/testing/mock/jcr/MockProperty.java
+++ b/src/main/java/org/apache/sling/testing/mock/jcr/MockProperty.java
@@ -86,9 +86,12 @@ public void setValue(final Value newValue) throws
RepositoryException {
@Override
public void setValue(final Value[] newValues) throws RepositoryException {
-Value[] values = new Value[newValues.length];
-for (int i = 0; i < newValues.length; i++) {
-values[i] = newValues[i];
+Value[] values = null;
+if(newValues!=null){
+values = new Value[newValues.length];
+for (int i = 0; i < newValues.length; i++) {
+values[i] = newValues[i];
+}
}
this.itemData.setValues(values);
this.itemData.setMultiple(true);
@@ -102,9 +105,12 @@ public void setValue(final String newValue) throws
RepositoryException {
@Override
public void setValue(final String[] newValues) throws RepositoryException {
-Value[] values = new Value[newValues.length];
-for (int i = 0; i < newValues.length; i++) {
-values[i] =
getSession().getValueFactory().createValue(newValues[i]);
+Value[] values = null;
+if(newValues!=null){
+values = new Value[newValues.length];
+for (int i = 0; i < newValues.length; i++) {
+values[i] =
getSession().getValueFactory().createValue(newValues[i]);
+}
}
this.itemData.setValues(values);
this.itemData.setMultiple(true);
@@ -206,7 +212,7 @@ public int getType() throws RepositoryException {
}
else {
return PropertyType.UNDEFINED;
-}
+}
}
@Override
@@ -253,7 +259,7 @@ public boolean equals(Object obj) {
}
return false;
}
-
+
// --- unsupported operations ---
@Override
public Node getNode() throws RepositoryException {
@@ -286,7 +292,7 @@ public boolean isMandatory() {
public boolean isProtected() {
return false;
}
-
+
@Override
public boolean isFullTextSearchable() {
return false;
@@ -296,7 +302,7 @@ public boolean isFullTextSearchable() {
public boolean isQueryOrderable() {
return false;
}
-
+
// --- unsupported operations ---
@Override
public Value[] getDefaultValues() {
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-8092) Relocation in Content Extension to bold
[ https://issues.apache.org/jira/browse/SLING-8092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16683526#comment-16683526 ] ASF GitHub Bot commented on SLING-8092: --- DominikSuess opened a new pull request #5: SLING-8092 - using relocation to workaround the relocation issue of M… URL: https://github.com/apache/sling-org-apache-sling-feature-extension-content/pull/5 …SHADE-156 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 > Relocation in Content Extension to bold > --- > > Key: SLING-8092 > URL: https://issues.apache.org/jira/browse/SLING-8092 > Project: Sling > Issue Type: Bug > Components: Feature Model >Reporter: Dominik Süß >Priority: Major > > The relocation introduced in SLING-8068 is too bold and also relocates the > configuration names (String values) - This doesn't surface in unit testing as > shading happens afterward and due to the active fallback logic wasn't > recognized in a test run. > Background of the aggressive relocation behavior can be found in MSHADE-156 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] DominikSuess opened a new pull request #5: SLING-8092 - using relocation to workaround the relocation issue of M…
DominikSuess opened a new pull request #5: SLING-8092 - using relocation to workaround the relocation issue of M… URL: https://github.com/apache/sling-org-apache-sling-feature-extension-content/pull/5 …SHADE-156 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-8092) Relocation in Content Extension to bold
[ https://issues.apache.org/jira/browse/SLING-8092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16683524#comment-16683524 ] Dominik Süß commented on SLING-8092: The workaround, for now, is to depend on the shading mechanism and "encode"/"mark" the corresponding strings and have a corresponding relocation rule to restore the intended value. > Relocation in Content Extension to bold > --- > > Key: SLING-8092 > URL: https://issues.apache.org/jira/browse/SLING-8092 > Project: Sling > Issue Type: Bug > Components: Feature Model >Reporter: Dominik Süß >Priority: Major > > The relocation introduced in SLING-8068 is too bold and also relocates the > configuration names (String values) - This doesn't surface in unit testing as > shading happens afterward and due to the active fallback logic wasn't > recognized in a test run. > Background of the aggressive relocation behavior can be found in MSHADE-156 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-8092) Relocation in Content Extension to bold
Dominik Süß created SLING-8092: -- Summary: Relocation in Content Extension to bold Key: SLING-8092 URL: https://issues.apache.org/jira/browse/SLING-8092 Project: Sling Issue Type: Bug Components: Feature Model Reporter: Dominik Süß The relocation introduced in SLING-8068 is too bold and also relocates the configuration names (String values) - This doesn't surface in unit testing as shading happens afterward and due to the active fallback logic wasn't recognized in a test run. Background of the aggressive relocation behavior can be found in MSHADE-156 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
RE: [RT] Simple File System Resource Provider
so from my list below your use case is 1. + 2. + a) + probably b) and leaving out the other parts? or something different from what is implemented currently? stefan >-Original Message- >From: Carsten Ziegeler [mailto:cziege...@apache.org] >Sent: Monday, November 12, 2018 11:20 AM >To: dev@sling.apache.org; Stefan Seifert >Subject: Re: [RT] Simple File System Resource Provider > >Hi, > >I would be totally happy if we can factor out the extensions, I'm >wondering however if this is worth the effort. > >In my use case, I would like to have a simple mapping to directories and >files, supporting json and binary files. So a resource maps to a json >file 1:1 regardless of the structure of the json file and a such a >resource can have an additional binary. > >I understand the need for the support of all the other features we have >today, but they are not needed for other use cases. > >Regards >Carsten > >Am 12.11.2018 um 11:06 schrieb Stefan Seifert: >> yes, the current implementation of the fsresource provider is no longer >any simple. >> >> it currently supports three (configurable) modes: >> 1. simple mapping of folders and binary files from filesystem (this was >the starting point of fsresource) >> 2. reading structured resource data from JSON files and folders in the >same way it is done by the content loader >> 3. reading structured resource data from FileVault XML files as it's >stored in content packages >> >> and features: >> a) sending resource events if any of these files are changed in runtime >> b) implement some caching to speed things up >> c) support not only the Sling Resource API, but also simulate an >underlying JCR API for code that runs on top which is still using the JCR >API for cases where also the Sling Resource API would suffice but cannot be >changed because it's part of a product... >> >> so the use case ranges from simple mapping of a bunch of static files to >full-blown emulation of a JCR repository out of a complex project structure >in the filesystem e.g. for usage in a development environemnt (see [0]). >> >> --- >> >> removing the embedded json libraries should be simple, it was only for >convenience when the fsresource bundle is to deployed afterwards to an >existing instance. >> but the dependencies to all those JCR-related bundles remains as long as >all three modes and features need to be supported. >> >> i'm not sure if implementing a new fsresource provider e.g. only for >1.+2. from scratch would be the best way. there is a lot of special logic >for edge cases esp. in 2. to make sure it behaves the same as the content >loader which we have then to duplicate another time. it should be possible >to split the existing fsresource into a core and extension bundle as it's >somewhat separated already due to the different supported modes 1./2./3., >and the virtual JCR API support could be made configurable as well. >> >> supporting Java 8 features for the filesystem changes detection would be >a good thing; last time i was looking into it i failed to make good use of >it due to strange implementation differences on windows and unix file >systems (and those differences where covered by the JavaDocs). but maybe >there is a way to do it right. >> >> stefan >> >> [0] https://adapt.to/2017/en/schedule/ease-development-with-apache-sling- >file-system-resource-provider.html >> >> >> >>> -Original Message- >>> From: Carsten Ziegeler [mailto:cziege...@apache.org] >>> Sent: Sunday, November 11, 2018 10:56 AM >>> To: Sling Developers >>> Subject: [RT] Simple File System Resource Provider >>> >>> I've recently tried to run a minimal Sling without JCR. Obviously you >>> need at least one resource provider to have some content, so I picked >>> the easiest choice, the file system resource provider. >>> >>> However, it turned out that this is not the easiest choice for this >>> scenario as it has a lot of features, especially support for handling >>> content XML files and vault files, which again brings in the whole >>> dependency list to jcr related bundles. In my case I just want to stream >>> binaries and json files, so none of the above is needed. But still I >>> need to deploy all the bundles. In addition there are other things like >>> the json parsing library is embedded in the bundle etc. >>> >>> Now, I think we should really have a simple file system resource >>> provider which only does the basics and has not an endless list of >>> bundles. I see two ways to get there: make the current provider >>> extensible and provide all this extra cruft as extensions or write a new >>> simple provider. >>> >>> Thoughts? >>> >>> Regards >>> Carsten >>> -- >>> Carsten Ziegeler >>> Adobe Research Switzerland >>> cziege...@apache.org >> > >-- >Carsten Ziegeler >Adobe Research Switzerland >cziege...@apache.org
Re: [RT] Simple File System Resource Provider
Hi, I would be totally happy if we can factor out the extensions, I'm wondering however if this is worth the effort. In my use case, I would like to have a simple mapping to directories and files, supporting json and binary files. So a resource maps to a json file 1:1 regardless of the structure of the json file and a such a resource can have an additional binary. I understand the need for the support of all the other features we have today, but they are not needed for other use cases. Regards Carsten Am 12.11.2018 um 11:06 schrieb Stefan Seifert: yes, the current implementation of the fsresource provider is no longer any simple. it currently supports three (configurable) modes: 1. simple mapping of folders and binary files from filesystem (this was the starting point of fsresource) 2. reading structured resource data from JSON files and folders in the same way it is done by the content loader 3. reading structured resource data from FileVault XML files as it's stored in content packages and features: a) sending resource events if any of these files are changed in runtime b) implement some caching to speed things up c) support not only the Sling Resource API, but also simulate an underlying JCR API for code that runs on top which is still using the JCR API for cases where also the Sling Resource API would suffice but cannot be changed because it's part of a product... so the use case ranges from simple mapping of a bunch of static files to full-blown emulation of a JCR repository out of a complex project structure in the filesystem e.g. for usage in a development environemnt (see [0]). --- removing the embedded json libraries should be simple, it was only for convenience when the fsresource bundle is to deployed afterwards to an existing instance. but the dependencies to all those JCR-related bundles remains as long as all three modes and features need to be supported. i'm not sure if implementing a new fsresource provider e.g. only for 1.+2. from scratch would be the best way. there is a lot of special logic for edge cases esp. in 2. to make sure it behaves the same as the content loader which we have then to duplicate another time. it should be possible to split the existing fsresource into a core and extension bundle as it's somewhat separated already due to the different supported modes 1./2./3., and the virtual JCR API support could be made configurable as well. supporting Java 8 features for the filesystem changes detection would be a good thing; last time i was looking into it i failed to make good use of it due to strange implementation differences on windows and unix file systems (and those differences where covered by the JavaDocs). but maybe there is a way to do it right. stefan [0] https://adapt.to/2017/en/schedule/ease-development-with-apache-sling-file-system-resource-provider.html -Original Message- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: Sunday, November 11, 2018 10:56 AM To: Sling Developers Subject: [RT] Simple File System Resource Provider I've recently tried to run a minimal Sling without JCR. Obviously you need at least one resource provider to have some content, so I picked the easiest choice, the file system resource provider. However, it turned out that this is not the easiest choice for this scenario as it has a lot of features, especially support for handling content XML files and vault files, which again brings in the whole dependency list to jcr related bundles. In my case I just want to stream binaries and json files, so none of the above is needed. But still I need to deploy all the bundles. In addition there are other things like the json parsing library is embedded in the bundle etc. Now, I think we should really have a simple file system resource provider which only does the basics and has not an endless list of bundles. I see two ways to get there: make the current provider extensible and provide all this extra cruft as extensions or write a new simple provider. Thoughts? Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Sling Servlets Resolver 2.4.24, Take II
+1 > On 10 Nov 2018, at 11:23, Carsten Ziegeler 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.
Re: [VOTE] Release Apache Sling Servlets Get 2.1.38, Take II
+1 > On 10 Nov 2018, at 11:29, Carsten Ziegeler 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.
RE: [RT] Simple File System Resource Provider
yes, the current implementation of the fsresource provider is no longer any simple. it currently supports three (configurable) modes: 1. simple mapping of folders and binary files from filesystem (this was the starting point of fsresource) 2. reading structured resource data from JSON files and folders in the same way it is done by the content loader 3. reading structured resource data from FileVault XML files as it's stored in content packages and features: a) sending resource events if any of these files are changed in runtime b) implement some caching to speed things up c) support not only the Sling Resource API, but also simulate an underlying JCR API for code that runs on top which is still using the JCR API for cases where also the Sling Resource API would suffice but cannot be changed because it's part of a product... so the use case ranges from simple mapping of a bunch of static files to full-blown emulation of a JCR repository out of a complex project structure in the filesystem e.g. for usage in a development environemnt (see [0]). --- removing the embedded json libraries should be simple, it was only for convenience when the fsresource bundle is to deployed afterwards to an existing instance. but the dependencies to all those JCR-related bundles remains as long as all three modes and features need to be supported. i'm not sure if implementing a new fsresource provider e.g. only for 1.+2. from scratch would be the best way. there is a lot of special logic for edge cases esp. in 2. to make sure it behaves the same as the content loader which we have then to duplicate another time. it should be possible to split the existing fsresource into a core and extension bundle as it's somewhat separated already due to the different supported modes 1./2./3., and the virtual JCR API support could be made configurable as well. supporting Java 8 features for the filesystem changes detection would be a good thing; last time i was looking into it i failed to make good use of it due to strange implementation differences on windows and unix file systems (and those differences where covered by the JavaDocs). but maybe there is a way to do it right. stefan [0] https://adapt.to/2017/en/schedule/ease-development-with-apache-sling-file-system-resource-provider.html >-Original Message- >From: Carsten Ziegeler [mailto:cziege...@apache.org] >Sent: Sunday, November 11, 2018 10:56 AM >To: Sling Developers >Subject: [RT] Simple File System Resource Provider > >I've recently tried to run a minimal Sling without JCR. Obviously you >need at least one resource provider to have some content, so I picked >the easiest choice, the file system resource provider. > >However, it turned out that this is not the easiest choice for this >scenario as it has a lot of features, especially support for handling >content XML files and vault files, which again brings in the whole >dependency list to jcr related bundles. In my case I just want to stream >binaries and json files, so none of the above is needed. But still I >need to deploy all the bundles. In addition there are other things like >the json parsing library is embedded in the bundle etc. > >Now, I think we should really have a simple file system resource >provider which only does the basics and has not an endless list of >bundles. I see two ways to get there: make the current provider >extensible and provide all this extra cruft as extensions or write a new >simple provider. > >Thoughts? > >Regards >Carsten >-- >Carsten Ziegeler >Adobe Research Switzerland >cziege...@apache.org
[jira] [Commented] (SLING-8090) Use newest OSGi annotation versions
[ https://issues.apache.org/jira/browse/SLING-8090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16683506#comment-16683506 ] Carsten Ziegeler commented on SLING-8090: - [~kwin] I think it's fine to go with R7 for DS, metatype, config admin etc. We shouldn't require an R7 framework though > Use newest OSGi annotation versions > --- > > Key: SLING-8090 > URL: https://issues.apache.org/jira/browse/SLING-8090 > Project: Sling > Issue Type: Bug > Components: General >Reporter: Konrad Windszus >Priority: Major > Fix For: Bundle Parent 35 > > > As OSGi annotations are only processed at build time and only need support > from the according build tool (bnd in our case), we should upgrade to the > newest R7 version of all annotations. Those are supported by bnd 4.1 and do > not imply any runtime dependencies to R7 bundles. > Compare also with https://github.com/bndtools/bnd/issues/2643 and > https://github.com/bndtools/bnd/pull/2603. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-8090) Use newest OSGi annotation versions
[ https://issues.apache.org/jira/browse/SLING-8090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16683470#comment-16683470 ] Konrad Windszus commented on SLING-8090: Unfortunately the annotation version determines currently also the runtime version required for DS and metatype (compare with https://github.com/bndtools/bnd/issues/2545#issuecomment-437699686). So we have to stick with R6 until we decide to only support R7 with the newest parent. [~cziegeler] Do you think it is too early to raise the DS and metatype dependencies to R7 in our parent? > Use newest OSGi annotation versions > --- > > Key: SLING-8090 > URL: https://issues.apache.org/jira/browse/SLING-8090 > Project: Sling > Issue Type: Bug > Components: General >Reporter: Konrad Windszus >Priority: Major > Fix For: Bundle Parent 35 > > > As OSGi annotations are only processed at build time and only need support > from the according build tool (bnd in our case), we should upgrade to the > newest R7 version of all annotations. Those are supported by bnd 4.1 and do > not imply any runtime dependencies to R7 bundles. > Compare also with https://github.com/bndtools/bnd/issues/2643 and > https://github.com/bndtools/bnd/pull/2603. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [VOTE] Release Apache Sling Servlets Resolver 2.4.24, Take II
+1 regards, Karl On Sunday, November 11, 2018, Daniel Klco wrote: > +1 > > On Sat, Nov 10, 2018 at 5:24 AM Carsten Ziegeler > wrote: > > > +1 > > > > Am 10.11.2018 um 11:23 schrieb Carsten Ziegeler: > > > Hi, > > > > > > We solved 3 issues in this release > > > https://issues.apache.org/jira/projects/SLING/versions/12342700 > > > > > > > > > Staging repository: > > > https://repository.apache.org/content/repositories/orgapachesling-2013 > > > > > > 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 2013 /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. > > > > > > Regards > > > Carsten > > > > -- > > Carsten Ziegeler > > Adobe Research Switzerland > > cziege...@apache.org > > > -- Karl Pauls karlpa...@gmail.com
Re: [VOTE] Release Apache Sling Servlets Get 2.1.38, Take II
+1 regards, Karl On Sunday, November 11, 2018, Daniel Klco wrote: > +1 > > On Sat, Nov 10, 2018 at 7:40 AM Carsten Ziegeler > wrote: > > > +1 > > > > Am 10.11.2018 um 11:29 schrieb Carsten Ziegeler: > > > Hi, > > > > > > We solved 2 issues in this release > > > https://issues.apache.org/jira/projects/SLING/versions/12344154 > > > > > > > > > Staging repository: > > > https://repository.apache.org/content/repositories/orgapachesling-2014 > > > > > > 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 2014 /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. > > > > > > Regards > > > Carsten > > > > -- > > Carsten Ziegeler > > Adobe Research Switzerland > > cziege...@apache.org > > > -- Karl Pauls karlpa...@gmail.com
