[jira] [Updated] (SLING-9417) Content-type and InputStream are null when accessing nt:file resources with ";v="
[
https://issues.apache.org/jira/browse/SLING-9417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Herold updated SLING-9417:
---
Description:
When using the methods resource.getMetadata().getContentType() or
resource.adaptTo(InputStream.class), both methods return null when:
# the resource is a child of a versionable node,
# the resource is of type nt:file, and
# resource has been looked up with a version identifier in the URL (";v=").
>From my understanding, both methods should return the relevant values from the
>frozen node. The error occurs because of line 185 in JcrNodeResource.java
{{Node content = node.isNodeType(NT_FILE)}}
{{? node.getNode(JCR_CONTENT)}}
{{: node.isNodeType(NT_LINKEDFILE) ? node.getProperty(JCR_CONTENT).getNode() :
node;}}
When the resource is looked up with a version modifier, the node type will not
nt:file. Instead it is jcr:frozenNode with a property jcr:frozenPrimaryType set
to nt:file. Therefore, the above code fails and will not use the jcr:content
subnode, but the node itself. In my opinion, it would be better to change this
to:
Node content = (node.isNodeType(NodeType.NT_FILE) ||
(node.isNodeType("nt:frozenNode") && node.hasProperty("jcr:frozenPrimaryType")
{{ && node.getProperty("jcr:frozenPrimaryType").getString().equals(NT_FILE)))}}
{{ ? node.getNode(Node.JCR_CONTENT)
{{ : node.isNodeType(JcrConstants.NT_LINKEDFILE) ?
node.getProperty(Node.JCR_CONTENT).getNode() : node;}}
JcrResourceMetadata has the same issue (line 65):
{{ if ( (!nodePromotionChecked) && node.isNodeType(NT_FILE)) {}}
This could be changed to:
{{ if ( (!nodePromotionChecked) && (node.isNodeType(NT_FILE) ||}}
{{ (node.isNodeType("nt:frozenNode") &&
node.hasProperty("jcr:frozenPrimaryType") }}
{{ && node.getProperty("jcr:frozenPrimaryType").getString().equals(NT_FILE
{}}
As I'm still a newbie in Sling, I'm not sure if the proposed solution is
completely right. At the moment, I use a ResourceDecorator for my project with
these changes and this fixes my problem - but there might be a better way to
solve this.
was:
When using the methods resource.getMetadata().getContentType() or
resource.adaptTo(InputStream.class), both methods return null when:
# the resource is a child of a versionable node,
# the resource is of type nt:file, and
# resource has been looked up with a version identifier in the URL (";v=").
>From my understanding, both methods should return the relevant values from the
>frozen node. The error occurs because of line 185 in JcrNodeResource.java
{\{ Node content = node.isNodeType(NT_FILE)}}
\{{ ? node.getNode(JCR_CONTENT)}}
\{{ : node.isNodeType(NT_LINKEDFILE) ? node.getProperty(JCR_CONTENT).getNode()
: node;}}
When the resource is looked up with a version modifier, the node type will not
nt:file. Instead it is jcr:frozenNode with a property jcr:frozenPrimaryType set
to nt:file. Therefore, the above code fails and will not use the jcr:content
subnode, but the node itself. In my opinion, it would be better to change this
to:
{{Node content = (node.isNodeType(NodeType.NT_FILE) ||
(node.isNodeType("nt:frozenNode") && node.hasProperty("jcr:frozenPrimaryType")
}}
\{{ &&
node.getProperty("jcr:frozenPrimaryType").getString().equals(NT_FILE)))}}
\{{ ? node.getNode(Node.JCR_CONTENT)}}
\{{ : node.isNodeType(JcrConstants.NT_LINKEDFILE) ?
node.getProperty(Node.JCR_CONTENT).getNode() : node;}}
JcrResourceMetadata has the same issue (line 65):
{\{ if ( (!nodePromotionChecked) && node.isNodeType(NT_FILE)) {}}
This could be changed to:
{\{ if ( (!nodePromotionChecked) && (node.isNodeType(NT_FILE) ||}}
\{{ (node.isNodeType("nt:frozenNode") &&
node.hasProperty("jcr:frozenPrimaryType") }}
\{{ &&
node.getProperty("jcr:frozenPrimaryType").getString().equals(NT_FILE {}}
As I'm still a newbie in Sling, I'm not sure if the proposed solution is
completely right. At the moment, I use a ResourceDecorator for my project with
these changes and this fixes my problem - but there might be a better way to
solve this.
> Content-type and InputStream are null when accessing nt:file resources with
> ";v="
> -
>
> Key: SLING-9417
> URL: https://issues.apache.org/jira/browse/SLING-9417
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Reporter: Matthias Herold
>Priority: Minor
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> When using the methods resource.getMetadata().getContentType() or
> resource.adaptTo(InputStream.class), both methods return null when:
> # the resource is a child of a versionable node,
> # the resource is of type nt:file, and
> # resource has been looked up with a version identifier in the URL (";v=").
> From my understanding, both methods
[jira] [Updated] (SLING-9417) Content-type and InputStream are null when accessing nt:file resources with ";v="
[
https://issues.apache.org/jira/browse/SLING-9417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Herold updated SLING-9417:
---
Description:
When using the methods resource.getMetadata().getContentType() or
resource.adaptTo(InputStream.class), both methods return null when:
# the resource is a child of a versionable node,
# the resource is of type nt:file, and
# resource has been looked up with a version identifier in the URL (";v=").
>From my understanding, both methods should return the relevant values from the
>frozen node. The error occurs because of line 185 in JcrNodeResource.java
{\{ Node content = node.isNodeType(NT_FILE)}}
\{{ ? node.getNode(JCR_CONTENT)}}
\{{ : node.isNodeType(NT_LINKEDFILE) ? node.getProperty(JCR_CONTENT).getNode()
: node;}}
When the resource is looked up with a version modifier, the node type will not
nt:file. Instead it is jcr:frozenNode with a property jcr:frozenPrimaryType set
to nt:file. Therefore, the above code fails and will not use the jcr:content
subnode, but the node itself. In my opinion, it would be better to change this
to:
{{Node content = (node.isNodeType(NodeType.NT_FILE) ||
(node.isNodeType("nt:frozenNode") && node.hasProperty("jcr:frozenPrimaryType")
}}
\{{ &&
node.getProperty("jcr:frozenPrimaryType").getString().equals(NT_FILE)))}}
\{{ ? node.getNode(Node.JCR_CONTENT)}}
\{{ : node.isNodeType(JcrConstants.NT_LINKEDFILE) ?
node.getProperty(Node.JCR_CONTENT).getNode() : node;}}
JcrResourceMetadata has the same issue (line 65):
{\{ if ( (!nodePromotionChecked) && node.isNodeType(NT_FILE)) {}}
This could be changed to:
{\{ if ( (!nodePromotionChecked) && (node.isNodeType(NT_FILE) ||}}
\{{ (node.isNodeType("nt:frozenNode") &&
node.hasProperty("jcr:frozenPrimaryType") }}
\{{ &&
node.getProperty("jcr:frozenPrimaryType").getString().equals(NT_FILE {}}
As I'm still a newbie in Sling, I'm not sure if the proposed solution is
completely right. At the moment, I use a ResourceDecorator for my project with
these changes and this fixes my problem - but there might be a better way to
solve this.
was:
When using the methods resource.getMetadata().getContentType() or
resource.adaptTo(InputStream.class), both methods return null when:
# the resource is a child of a versionable node,
# the resource is of type nt:file, and
# resource has been looked up with a version identifier in the URL (";v=").
>From my understanding, both methods should return the relevant values from the
>frozen node. The error occurs because of line 185 in JcrNodeResource.java
{\{ Node content = node.isNodeType(NT_FILE)}}
\{{ ? node.getNode(JCR_CONTENT)}}
\{{ : node.isNodeType(NT_LINKEDFILE) ? node.getProperty(JCR_CONTENT).getNode()
: node;}}
When the resource is looked up with the version modifier, the ode type will not
nt:file. Instead it is jcr:frozenNode with a property jcr:frozenPrimaryType set
to nt:file. Therefore, the above code fails and will not use the jcr:content
subnode, but the node itself. In my opinion, it would be right to change this
to:
{{Node content = (node.isNodeType(NodeType.NT_FILE) ||
(node.isNodeType("nt:frozenNode") && node.hasProperty("jcr:frozenPrimaryType")
}}
\{{ &&
node.getProperty("jcr:frozenPrimaryType").getString().equals(NT_FILE)))}}
\{{ ? node.getNode(Node.JCR_CONTENT)}}
\{{ : node.isNodeType(JcrConstants.NT_LINKEDFILE) ?
node.getProperty(Node.JCR_CONTENT).getNode() : node;}}
JcrResourceMetadata has the same issue (line 65):
{\{ if ( (!nodePromotionChecked) && node.isNodeType(NT_FILE)) {}}
This could be changed to:
{\{ if ( (!nodePromotionChecked) && (node.isNodeType(NT_FILE) ||}}
\{{ (node.isNodeType("nt:frozenNode") &&
node.hasProperty("jcr:frozenPrimaryType") }}
\{{ &&
node.getProperty("jcr:frozenPrimaryType").getString().equals(NT_FILE {}}
As I'm still a newbie in Sling, I'm not sure if the proposed solution is
completely right. At the moment, I use a ResourceDecorator for my project with
these changes and this fixes my problem - but there might be a better way to
solve this.
> Content-type and InputStream are null when accessing nt:file resources with
> ";v="
> -
>
> Key: SLING-9417
> URL: https://issues.apache.org/jira/browse/SLING-9417
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Reporter: Matthias Herold
>Priority: Minor
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> When using the methods resource.getMetadata().getContentType() or
> resource.adaptTo(InputStream.class), both methods return null when:
> # the resource is a child of a versionable node,
> # the resource is of type nt:file, and
> # resource has been looked up with a version identifier in the URL (";v=").
> From my understanding,
[jira] [Updated] (SLING-9417) Content-type and InputStream are null when accessing nt:file resources with ";v="
[
https://issues.apache.org/jira/browse/SLING-9417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Herold updated SLING-9417:
---
Description:
When using the methods resource.getMetadata().getContentType() or
resource.adaptTo(InputStream.class), both methods return null when:
# the resource is a child of a versionable node,
# the resource is of type nt:file, and
# resource has been looked up with a version identifier in the URL (";v=").
>From my understanding, both methods should return the relevant values from the
>frozen node. The error occurs because of line 185 in JcrNodeResource.java
{\{ Node content = node.isNodeType(NT_FILE)}}
\{{ ? node.getNode(JCR_CONTENT)}}
\{{ : node.isNodeType(NT_LINKEDFILE) ? node.getProperty(JCR_CONTENT).getNode()
: node;}}
When the resource is looked up with the version modifier, the ode type will not
nt:file. Instead it is jcr:frozenNode with a property jcr:frozenPrimaryType set
to nt:file. Therefore, the above code fails and will not use the jcr:content
subnode, but the node itself. In my opinion, it would be right to change this
to:
{{Node content = (node.isNodeType(NodeType.NT_FILE) ||
(node.isNodeType("nt:frozenNode") && node.hasProperty("jcr:frozenPrimaryType")
}}
\{{ &&
node.getProperty("jcr:frozenPrimaryType").getString().equals(NT_FILE)))}}
\{{ ? node.getNode(Node.JCR_CONTENT)}}
\{{ : node.isNodeType(JcrConstants.NT_LINKEDFILE) ?
node.getProperty(Node.JCR_CONTENT).getNode() : node;}}
JcrResourceMetadata has the same issue (line 65):
{\{ if ( (!nodePromotionChecked) && node.isNodeType(NT_FILE)) {}}
This could be changed to:
{\{ if ( (!nodePromotionChecked) && (node.isNodeType(NT_FILE) ||}}
\{{ (node.isNodeType("nt:frozenNode") &&
node.hasProperty("jcr:frozenPrimaryType") }}
\{{ &&
node.getProperty("jcr:frozenPrimaryType").getString().equals(NT_FILE {}}
As I'm still a newbie in Sling, I'm not sure if the proposed solution is
completely right. At the moment, I use a ResourceDecorator for my project with
these changes and this fixes my problem - but there might be a better way to
solve this.
was:
When using the methods resource.getMetadata().getContentType() or
resource.adaptTo(InputStream.class), both methods return null when:
# the resource is a child of a versionable node,
# the resource is of type nt:file, and
# resource has been looked up with a version identifier in the URL (";v=").
>From my understanding, both methods should return the relevant values from the
>versioned node in this code. The error occurs because of line 185 in
>JcrNodeResource.java
{{ Node content = node.isNodeType(NT_FILE)}}
{{ ? node.getNode(JCR_CONTENT)}}
{{ : node.isNodeType(NT_LINKEDFILE) ? node.getProperty(JCR_CONTENT).getNode() :
node;}}
When the resource is looked up with the version modifier, the ode type will not
nt:file. Instead it is jcr:frozenNode with a property jcr:frozenPrimaryType set
to nt:file. Therefore, the above code fails and will not use the jcr:content
subnode, but the node itself. In my opinion, it would be right to change this
to:
{{Node content = (node.isNodeType(NodeType.NT_FILE) ||
(node.isNodeType("nt:frozenNode") && node.hasProperty("jcr:frozenPrimaryType")
}}
{{ && node.getProperty("jcr:frozenPrimaryType").getString().equals(NT_FILE)))}}
{{ ? node.getNode(Node.JCR_CONTENT)}}
{{ : node.isNodeType(JcrConstants.NT_LINKEDFILE) ?
node.getProperty(Node.JCR_CONTENT).getNode() : node;}}
JcrResourceMetadata has the same issue (line 65):
{{ if ( (!nodePromotionChecked) && node.isNodeType(NT_FILE)) {}}
This could be changed to:
{{ if ( (!nodePromotionChecked) && (node.isNodeType(NT_FILE) ||}}
{{ (node.isNodeType("nt:frozenNode") &&
node.hasProperty("jcr:frozenPrimaryType") }}
{{ && node.getProperty("jcr:frozenPrimaryType").getString().equals(NT_FILE
{}}
As I'm still a newbie in Sling, I'm not sure if the proposed solution is
completely right. At the moment, I use a ResourceDecorator for my project with
these changes and this fixes my problem - but there might be a better way to
solve this.
> Content-type and InputStream are null when accessing nt:file resources with
> ";v="
> -
>
> Key: SLING-9417
> URL: https://issues.apache.org/jira/browse/SLING-9417
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Reporter: Matthias Herold
>Priority: Minor
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> When using the methods resource.getMetadata().getContentType() or
> resource.adaptTo(InputStream.class), both methods return null when:
> # the resource is a child of a versionable node,
> # the resource is of type nt:file, and
> # resource has been looked up with a version identifier in the URL (";v=").
> From my understanding,
[jira] [Created] (SLING-9417) Content-type and InputStream are null when accessing nt:file resources with ";v="
Matthias Herold created SLING-9417:
--
Summary: Content-type and InputStream are null when accessing
nt:file resources with ";v="
Key: SLING-9417
URL: https://issues.apache.org/jira/browse/SLING-9417
Project: Sling
Issue Type: Bug
Components: JCR
Reporter: Matthias Herold
When using the methods resource.getMetadata().getContentType() or
resource.adaptTo(InputStream.class), both methods return null when:
# the resource is a child of a versionable node,
# the resource is of type nt:file, and
# resource has been looked up with a version identifier in the URL (";v=").
>From my understanding, both methods should return the relevant values from the
>versioned node in this code. The error occurs because of line 185 in
>JcrNodeResource.java
{{ Node content = node.isNodeType(NT_FILE)}}
{{ ? node.getNode(JCR_CONTENT)}}
{{ : node.isNodeType(NT_LINKEDFILE) ? node.getProperty(JCR_CONTENT).getNode() :
node;}}
When the resource is looked up with the version modifier, the ode type will not
nt:file. Instead it is jcr:frozenNode with a property jcr:frozenPrimaryType set
to nt:file. Therefore, the above code fails and will not use the jcr:content
subnode, but the node itself. In my opinion, it would be right to change this
to:
{{Node content = (node.isNodeType(NodeType.NT_FILE) ||
(node.isNodeType("nt:frozenNode") && node.hasProperty("jcr:frozenPrimaryType")
}}
{{ && node.getProperty("jcr:frozenPrimaryType").getString().equals(NT_FILE)))}}
{{ ? node.getNode(Node.JCR_CONTENT)}}
{{ : node.isNodeType(JcrConstants.NT_LINKEDFILE) ?
node.getProperty(Node.JCR_CONTENT).getNode() : node;}}
JcrResourceMetadata has the same issue (line 65):
{{ if ( (!nodePromotionChecked) && node.isNodeType(NT_FILE)) {}}
This could be changed to:
{{ if ( (!nodePromotionChecked) && (node.isNodeType(NT_FILE) ||}}
{{ (node.isNodeType("nt:frozenNode") &&
node.hasProperty("jcr:frozenPrimaryType") }}
{{ && node.getProperty("jcr:frozenPrimaryType").getString().equals(NT_FILE
{}}
As I'm still a newbie in Sling, I'm not sure if the proposed solution is
completely right. At the moment, I use a ResourceDecorator for my project with
these changes and this fixes my problem - but there might be a better way to
solve this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[Jenkins] Sling » sling-org-apache-sling-launchpad-testing » master #769 is BROKEN
]
[INFO] Total time: 03:55 min
[INFO] Finished at: 2020-05-01T13:36:33Z
[INFO]
[INFO] [jenkins-event-spy] Generated
/home/jenkins/jenkins-slave/workspace/e-sling-launchpad-testing_master@tmp/withMaven9f0a4cb5/maven-spy-20200501-133237-775595622983541694581.log
[Pipeline] }
[withMaven] Publishers: Pipeline Graph Publisher: 8 ms, JGiven Publisher: 2 ms
[Pipeline] // withMaven
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (SonarCloud)
[Pipeline] withCredentials
Masking supported pattern matches of $SONAR_TOKEN
[Pipeline] {
[Pipeline] withMaven
[withMaven] Options: []
[withMaven] Available options:
[withMaven] using JDK installation JDK 1.8 (latest)
[withMaven] using Maven installation 'Maven (latest)'
[Pipeline] {
[Pipeline] sh
+ mvn -U clean verify sonar:sonar -Dsonar.host.url=https://sonarcloud.io
-Dsonar.organization=apache
-Dsonar.projectKey=apache_sling-org-apache-sling-launchpad-testing
-Pjacoco-report
-Dsonar.coverage.jacoco.xmlReportPaths=target/site/jacoco-merged/jacoco.xml
- withMaven Wrapper script -
Picked up JAVA_TOOL_OPTIONS:
-Dmaven.ext.class.path="/home/jenkins/jenkins-slave/workspace/e-sling-launchpad-testing_master@tmp/withMaven7e7dfc46/pipeline-maven-spy.jar"
-Dorg.jenkinsci.plugins.pipeline.maven.reportsFolder="/home/jenkins/jenkins-slave/workspace/e-sling-launchpad-testing_master@tmp/withMaven7e7dfc46"
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /home/jenkins/tools/maven/latest
Java version: 1.8.0_241, vendor: Oracle Corporation, runtime:
/usr/local/asfpackages/java/jdk1.8.0_241/jre
Default locale: en_US, platform encoding: ISO-8859-1
OS name: "linux", version: "4.15.0-76-generic", arch: "amd64", family: "unix"
[INFO] [jenkins-event-spy] Generate
/home/jenkins/jenkins-slave/workspace/e-sling-launchpad-testing_master@tmp/withMaven7e7dfc46/maven-spy-20200501-133641-756635134743762324248.log.tmp
...
[INFO] Scanning for projects...
[INFO] Downloading from Nexus:
http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.launchpad.test-bundles/12-SNAPSHOT/maven-metadata.xml
[INFO] Downloaded from Nexus:
http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.launchpad.test-bundles/12-SNAPSHOT/maven-metadata.xml
(1.0 kB at 2.1 kB/s)
[INFO] Downloading from Nexus:
http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.starter/12-SNAPSHOT/maven-metadata.xml
[INFO] Downloaded from Nexus:
http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.starter/12-SNAPSHOT/maven-metadata.xml
(1.4 kB at 4.5 kB/s)
[INFO] Extended Maven classpath (scope 'provided') by the dependencies
extracted from the Sling model.
[INFO] Downloading from Nexus:
http://repository.apache.org/snapshots/org/codehaus/mojo/maven-metadata.xml
[INFO] Downloading from Nexus:
http://repository.apache.org/snapshots/org/apache/maven/plugins/maven-metadata.xml
[INFO] Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-metadata.xml
[INFO] Downloading from central:
https://repo.maven.apache.org/maven2/org/codehaus/mojo/maven-metadata.xml
[INFO] Downloaded from Nexus:
http://repository.apache.org/snapshots/org/apache/maven/plugins/maven-metadata.xml
(9.3 kB at 30 kB/s)
[INFO] Downloaded from central:
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-metadata.xml
(14 kB at 35 kB/s)
[INFO] Downloaded from central:
https://repo.maven.apache.org/maven2/org/codehaus/mojo/maven-metadata.xml (20
kB at 52 kB/s)
[INFO] Downloading from central:
https://repo.maven.apache.org/maven2/org/codehaus/mojo/sonar-maven-plugin/maven-metadata.xml
[INFO] Downloading from Nexus:
http://repository.apache.org/snapshots/org/codehaus/mojo/sonar-maven-plugin/maven-metadata.xml
[INFO] Downloaded from central:
https://repo.maven.apache.org/maven2/org/codehaus/mojo/sonar-maven-plugin/maven-metadata.xml
(1.2 kB at 55 kB/s)
[INFO]
[INFO] < org.apache.sling:org.apache.sling.launchpad.testing >-
[INFO] Building Apache Sling Launchpad Testing 12-SNAPSHOT
[INFO] -[ slingstart ]-
[INFO] Downloading from Nexus:
http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.launchpad.integration-tests/12-SNAPSHOT/maven-metadata.xml
[INFO] Downloaded from Nexus:
http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.launchpad.integration-tests/12-SNAPSHOT/maven-metadata.xml
(1.0 kB at 3.3 kB/s)
[INFO] Downloading from Nexus:
http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.launchpad.test-services/12-SNAPSHOT/maven-metadata.xml
[INFO] Downloaded from Nexus:
http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.launchpad.test-services/12-SNAPSHOT/maven-metad
[jira] [Resolved] (SLING-9416) Use extension "far" for feature archives by default
[ https://issues.apache.org/jira/browse/SLING-9416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-9416. - Resolution: Fixed Fixed in rev https://github.com/apache/sling-slingfeature-maven-plugin/commit/9e61bd851a842beb63c4e3a6bc77cb89421928c3 > Use extension "far" for feature archives by default > --- > > Key: SLING-9416 > URL: https://issues.apache.org/jira/browse/SLING-9416 > Project: Sling > Issue Type: Improvement > Components: Feature Model, Maven Plugins and Archetypes >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: slingfeature-maven-plugin 1.2.6 > > > When a feature archive is created, it should use the extension/type "far" and > not "zip" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-9416) Use extension "far" for feature archives by default
Carsten Ziegeler created SLING-9416: --- Summary: Use extension "far" for feature archives by default Key: SLING-9416 URL: https://issues.apache.org/jira/browse/SLING-9416 Project: Sling Issue Type: Improvement Components: Feature Model, Maven Plugins and Archetypes Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: slingfeature-maven-plugin 1.2.6 When a feature archive is created, it should use the extension/type "far" and not "zip" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-9413) Provide the Ability for the Launcher to start with Feature Archive(s)
[ https://issues.apache.org/jira/browse/SLING-9413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-9413. - Resolution: Fixed > Provide the Ability for the Launcher to start with Feature Archive(s) > - > > Key: SLING-9413 > URL: https://issues.apache.org/jira/browse/SLING-9413 > Project: Sling > Issue Type: New Feature > Components: Feature Model >Affects Versions: Feature Model Launcher 1.1.2 >Reporter: Andreas Schaefer >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Feature Model Launcher 1.1.4, Feature Model 1.2.2 > > > The Feature Launcher should provide the ability to launch one or more Feature > Archives -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-9413) Provide the Ability for the Launcher to start with Feature Archive(s)
[ https://issues.apache.org/jira/browse/SLING-9413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17097344#comment-17097344 ] Carsten Ziegeler commented on SLING-9413: - Implemented initial support in [1] and [2]. A feature archive with the extension ".far" is first extracted into the local cache, and the features from that archive are added to the features being launched. In a later version we can probably improve this and avoid extracting artifacts to the file system and launch directly from the archive. [1] https://github.com/apache/sling-org-apache-sling-feature-launcher/commit/80ffa27a832989fbdf42cde2181cbdcde2826601 [2] https://github.com/apache/sling-org-apache-sling-feature/commit/2bd1ad90f5d89ac15698b385ebcab8c8be152f5f > Provide the Ability for the Launcher to start with Feature Archive(s) > - > > Key: SLING-9413 > URL: https://issues.apache.org/jira/browse/SLING-9413 > Project: Sling > Issue Type: New Feature > Components: Feature Model >Affects Versions: Feature Model Launcher 1.1.2 >Reporter: Andreas Schaefer >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Feature Model Launcher 1.1.4, Feature Model 1.2.2 > > > The Feature Launcher should provide the ability to launch one or more Feature > Archives -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SLING-9415) Mvn id instead of path used to store artifacts
[ https://issues.apache.org/jira/browse/SLING-9415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-9415. - Resolution: Fixed Fixed in https://github.com/apache/sling-org-apache-sling-installer-factory-feature/commit/a3fed5f4e956eae1502a952889c98c56f341237c > Mvn id instead of path used to store artifacts > -- > > Key: SLING-9415 > URL: https://issues.apache.org/jira/browse/SLING-9415 > Project: Sling > Issue Type: Bug > Components: Installer >Affects Versions: Installer Factory Feature Model 0.2.0 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Installer Factory Feature Model 0.3.0 > > > The artifacts are currently written to the local cache using the mvn id > instead of the mvn path -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-9415) Mvn id instead of path used to store artifacts
Carsten Ziegeler created SLING-9415: --- Summary: Mvn id instead of path used to store artifacts Key: SLING-9415 URL: https://issues.apache.org/jira/browse/SLING-9415 Project: Sling Issue Type: Bug Components: Installer Affects Versions: Installer Factory Feature Model 0.2.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Installer Factory Feature Model 0.3.0 The artifacts are currently written to the local cache using the mvn id instead of the mvn path -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-9413) Provide the Ability for the Launcher to start with Feature Archive(s)
[ https://issues.apache.org/jira/browse/SLING-9413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-9413: Fix Version/s: Feature Model 1.2.2 > Provide the Ability for the Launcher to start with Feature Archive(s) > - > > Key: SLING-9413 > URL: https://issues.apache.org/jira/browse/SLING-9413 > Project: Sling > Issue Type: New Feature > Components: Feature Model >Affects Versions: Feature Model Launcher 1.1.2 >Reporter: Andreas Schaefer >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Feature Model Launcher 1.1.4, Feature Model 1.2.2 > > > The Feature Launcher should provide the ability to launch one or more Feature > Archives -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (SLING-9413) Provide the Ability for the Launcher to start with Feature Archive(s)
[ https://issues.apache.org/jira/browse/SLING-9413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-9413: --- Assignee: Carsten Ziegeler > Provide the Ability for the Launcher to start with Feature Archive(s) > - > > Key: SLING-9413 > URL: https://issues.apache.org/jira/browse/SLING-9413 > Project: Sling > Issue Type: New Feature > Components: Feature Model >Affects Versions: Feature Model Launcher 1.1.2 >Reporter: Andreas Schaefer >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Feature Model Launcher 1.1.4 > > > The Feature Launcher should provide the ability to launch one or more Feature > Archives -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [sling-org-apache-sling-feature-apiregions] sonarcloud[bot] commented on pull request #8: SLING-9410 BSN to feature cache does not get udpated when new configuration arrives
sonarcloud[bot] commented on pull request #8: URL: https://github.com/apache/sling-org-apache-sling-feature-apiregions/pull/8#issuecomment-622348926 Kudos, SonarCloud Quality Gate passed! [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-apiregions=8=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-apiregions=8=false=BUG) [0 Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-apiregions=8=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-apiregions=8=false=VULNERABILITY) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-apiregions=8=false=VULNERABILITY) [0 Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-apiregions=8=false=VULNERABILITY) (and [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-apiregions=8=false=SECURITY_HOTSPOT) [0 Security Hotspots](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-apiregions=8=false=SECURITY_HOTSPOT) to review) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-apiregions=8=false=CODE_SMELL) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-apiregions=8=false=CODE_SMELL) [1 Code Smell](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-apiregions=8=false=CODE_SMELL) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-apiregions=8=new_coverage=list) [83.7% Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-apiregions=8=new_coverage=list) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-apiregions=8=new_duplicated_lines_density=list) [0.0% Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-apiregions=8=new_duplicated_lines_density=list) This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[GitHub] [sling-org-apache-sling-feature-apiregions] bosschaert opened a new pull request #8: SLING-9410 BSN to feature cache does not get udpated when new configuration arrives
bosschaert opened a new pull request #8: URL: https://github.com/apache/sling-org-apache-sling-feature-apiregions/pull/8 This is an alternative approach to #7 which is simpler because the location cache does not need to be pruned on a configuration update. Thanks to @cziegeler for the suggestion of implementing it this way. So we either merge #7 or this PR... This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[jira] [Closed] (SLING-9390) Refactor implementation to have a single configuration object
[ https://issues.apache.org/jira/browse/SLING-9390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. J. David Bosschaert closed SLING-9390. - > Refactor implementation to have a single configuration object > - > > Key: SLING-9390 > URL: https://issues.apache.org/jira/browse/SLING-9390 > Project: Sling > Issue Type: Improvement > Components: Feature Model >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Feature Model API Regions Runtime Fragment 1.1.0 > > > The implementation is currently passing 5 maps/sets around containing the > configuration. For easier managing the configuration we should refactor the > implementation to have a single configuration object holding all of this -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SLING-9395) Support bundle updates in api regions
[ https://issues.apache.org/jira/browse/SLING-9395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. J. David Bosschaert closed SLING-9395. - > Support bundle updates in api regions > - > > Key: SLING-9395 > URL: https://issues.apache.org/jira/browse/SLING-9395 > Project: Sling > Issue Type: Improvement > Components: Feature Model >Reporter: Carsten Ziegeler >Assignee: A. J. David Bosschaert >Priority: Major > Fix For: Feature Model API Regions Runtime Fragment 1.1.0 > > > API Regions don't support bundles being updated dynamically, which is > something that is sometimes needed to try out newly developed functionality > or bugfixes. > To address use cases in this area, we need to allow bundles being updated to > a different version than the one specified initially with the API Regions as > long as the bundle location stays the same. > The algorithm to find what feature a bundle belongs to at runtime will become > the following: > 1. Find the feature a bundle belongs to by looking up the bundle-location > association with the feature. > 2. If the bundle location is not associated to a feature yet, look up the > bsn+version from the initial, defined list, and associate the new bundle > location with the feature found there. > This approach is similar to how OSGi ConfigAdmin associates a bundle location > with a configuration. > This approach also needs to take into account that package imports and > exports of the bundle might change, like new imports for a newer version -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SLING-9180) Wrong regions reported when API Regions removes a candidate
[
https://issues.apache.org/jira/browse/SLING-9180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. J. David Bosschaert closed SLING-9180.
-
> Wrong regions reported when API Regions removes a candidate
> ---
>
> Key: SLING-9180
> URL: https://issues.apache.org/jira/browse/SLING-9180
> Project: Sling
> Issue Type: Bug
> Components: Feature Model
>Affects Versions: Feature Model API Regions Runtime Fragment 1.0.8
>Reporter: A. J. David Bosschaert
>Assignee: A. J. David Bosschaert
>Priority: Major
> Fix For: Feature Model API Regions Runtime Fragment 1.1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The API Regions runtime fragment reports a warning when a candidate is
> removed from the resolution set.
> This reporting incorrectly contains too many region names. Instead of just
> the region where the package is exported in, it could also be reporting other
> regions that the exporting feature is exporting into.
> It could be reporting something like this:
>
> {code:java}
> WARNING: API-Regions removed candidates some.bundle [Regions: [org.foo.bar,
> global], Feature: f2] for requirement some.other.bundle package
> org.sling.mypkg as the requirement is in the following regions:
> [org.foo.blah, global] and in feature: [f1]
> {code}
> When the exported package {{org.sling.mypkg}} is actually _only_ in the
> _org.foo.bar_ region, and not in the global region.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SLING-9391) Allow to provide additional region information via configuration
[ https://issues.apache.org/jira/browse/SLING-9391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. J. David Bosschaert closed SLING-9391. - > Allow to provide additional region information via configuration > > > Key: SLING-9391 > URL: https://issues.apache.org/jira/browse/SLING-9391 > Project: Sling > Issue Type: Improvement > Components: Feature Model >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Feature Model API Regions Runtime Fragment 1.1.0 > > > The region configuration is currently provided by resources defined through > framework properties. Therefore the configuration can't be changed at runtime. > We should allow for additional region configuration at runtime through OSGi > factory configurations -- This message was sent by Atlassian Jira (v8.3.4#803005)
[RESULT][VOTE] Sling Feature Model API Regions Runtime Fragment 1.1.0
Hi all, With 5 binding +1 votes this release is successful. I've promoted the artifacts. Kind regards, David On Tue, 28 Apr 2020 at 09:36, wrote: > Hi all, > > I would like to call the release on the Sling Feature Model API Regions > Runtime Fragment 1.1.0. > > Resolved issues: > https://issues.apache.org/jira/projects/SLING/versions/12346978 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-2249 > > You can use this UNIX script to download the release and verify the > signatures: > > https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD > > Usage: > sh check_staged_release.sh 2249 /tmp/sling-staging > > Please vote to approve this release: > >[ ] +1 Approve the release >[ ] -1 Don't release, because ... > > This majority vote is open for at least 72 hours. > > Best regards, > > David >
[GitHub] [sling-org-apache-sling-feature-apiregions] sonarcloud[bot] commented on pull request #7: SLING-9410 BSN to feature cache does not get udpated when new configuration arrives
sonarcloud[bot] commented on pull request #7: URL: https://github.com/apache/sling-org-apache-sling-feature-apiregions/pull/7#issuecomment-622280777 Kudos, SonarCloud Quality Gate passed! [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-apiregions=7=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-apiregions=7=false=BUG) [0 Bugs](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-apiregions=7=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-apiregions=7=false=VULNERABILITY) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-apiregions=7=false=VULNERABILITY) [0 Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-apiregions=7=false=VULNERABILITY) (and [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-apiregions=7=false=SECURITY_HOTSPOT) [0 Security Hotspots](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-apiregions=7=false=SECURITY_HOTSPOT) to review) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-apiregions=7=false=CODE_SMELL) [](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-apiregions=7=false=CODE_SMELL) [0 Code Smells](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-feature-apiregions=7=false=CODE_SMELL) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-apiregions=7=new_coverage=list) [91.2% Coverage](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-apiregions=7=new_coverage=list) [](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-apiregions=7=new_duplicated_lines_density=list) [0.0% Duplication](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-apiregions=7=new_duplicated_lines_density=list) This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[GitHub] [sling-org-apache-sling-feature-apiregions] bosschaert opened a new pull request #7: SLING-9410 BSN to feature cache does not get udpated when new configuration arrives
bosschaert opened a new pull request #7: URL: https://github.com/apache/sling-org-apache-sling-feature-apiregions/pull/7 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
