Re: [VOTE] Release Apache Sling Feature 1.0.0 and Feature IO 1.0.0
+1 Davidb wrote Hi all, I would like to call the 1.0.0 release of the following components: org.apache.sling.feature 1.0.0 fixed issues: https://issues.apache.org/jira/projects/SLING/versions/12344550 org.apache.sling.feature.io 1.0.0 fixed issues: https://issues.apache.org/jira/projects/SLING/versions/12344551 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2044/ 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 2044 /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. Best regards, David Bosschaert -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Commented] (SLING-7245) Validate pull requests using Jenkins
[
https://issues.apache.org/jira/browse/SLING-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755434#comment-16755434
]
Robert Munteanu commented on SLING-7245:
I've migrated more modules - 98 now live under
https://builds.apache.org/job/Sling%20(pipeline%20jobs)/ . Pending any major
issues, the plan is to:
* switch all jobs to the Jenkinsfile approach
* disable seed job
* delete old views
* rename pipeline job folder to "Sling"
* validate that nothing was lost in the meantime
* tweak notifications (some starter and the launchpad its should notify
dev@sling on failure)
* decide what to do with sling-site and sling-ide-tooling - can we at least
reuse the common parts of the current {{slingOsgiBundleBuild}}?
* merge changes to master
Follow-up improvements ( will fine separate issues later):
* {{slingOsgiModuleBuild}} should check that the current SNAPSHOT deploys in
the starter successfully and passes all ITs (if already present in the starter)
* create a new {{slingMavenModuleBuild}} build type for Maven mojos and
archetypes since they should not be deployed in the starter
* the "Sling" org folder should be created by the seed job _or_ we should find
another way to store the folder definition in git
* create another "Sling-Dashboard" or equivalent view to help spotting problems
> Validate pull requests using Jenkins
>
>
> Key: SLING-7245
> URL: https://issues.apache.org/jira/browse/SLING-7245
> Project: Sling
> Issue Type: Improvement
> Components: Build and Source Control
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We should refine the work done in SLING-7163 and validate PRs using Jenkins.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-7245) Validate pull requests using Jenkins
[ https://issues.apache.org/jira/browse/SLING-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755430#comment-16755430 ] Robert Munteanu commented on SLING-7245: [~henzlerg] - right now I'm leaning to not add the special groovy handling, let's see if we need it. I would hope that the declarative approach leads to simpler and more understandable job definitions > Validate pull requests using Jenkins > > > Key: SLING-7245 > URL: https://issues.apache.org/jira/browse/SLING-7245 > Project: Sling > Issue Type: Improvement > Components: Build and Source Control >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > We should refine the work done in SLING-7163 and validate PRs using Jenkins. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [VOTE] Release Apache Sling Feature 1.0.0 and Feature IO 1.0.0
On Tue, 2019-01-29 at 15:27 +, dav...@apache.org wrote: > Please vote to approve this release: +1 Robert signature.asc Description: This is a digitally signed message part
[jira] [Commented] (SLING-8251) Support checking dependencies for content packages
[ https://issues.apache.org/jira/browse/SLING-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755388#comment-16755388 ] Robert Munteanu commented on SLING-8251: [~bosschaert] - I guess for me the first step is to support what metadata is actually provided by the content packages, since it's out there in the wild. Supporting new formats depends on getting the tooling in the VLT tooling and also in releasing those packages with updated tooling, which might be slow. For the vlt part I think [~tripod] is the best to discuss this (and probably [~dsuess] knows a lot ). (Also [~cziegeler] and [~kpauls] are probably interested as well) > Support checking dependencies for content packages > -- > > Key: SLING-8251 > URL: https://issues.apache.org/jira/browse/SLING-8251 > Project: Sling > Issue Type: New Feature > Components: Feature Model >Reporter: Robert Munteanu >Assignee: David Bosschaert >Priority: Major > > When including content packages in a feature model there are some > dependencies that would be great to check at build time. Both of these are > defined as manifest headers: > # dependencies to other content pacakges - Content-Package-Dependencies > # dependencies to java packages - Import-Package (with the same syntax as the > OSGi bundle Import-Package header ). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-8251) Support checking dependencies for content packages
[ https://issues.apache.org/jira/browse/SLING-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755211#comment-16755211 ] Konrad Windszus commented on SLING-8251: The initial support for import-packages in FileVault was added in https://issues.apache.org/jira/browse/JCRVLT-32 > Support checking dependencies for content packages > -- > > Key: SLING-8251 > URL: https://issues.apache.org/jira/browse/SLING-8251 > Project: Sling > Issue Type: New Feature > Components: Feature Model >Reporter: Robert Munteanu >Assignee: David Bosschaert >Priority: Major > > When including content packages in a feature model there are some > dependencies that would be great to check at build time. Both of these are > defined as manifest headers: > # dependencies to other content pacakges - Content-Package-Dependencies > # dependencies to java packages - Import-Package (with the same syntax as the > OSGi bundle Import-Package header ). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (SLING-8251) Support checking dependencies for content packages
[
https://issues.apache.org/jira/browse/SLING-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754918#comment-16754918
]
David Bosschaert edited comment on SLING-8251 at 1/29/19 4:07 PM:
--
Hi [~rombert], all,
I'm trying to understand the requirements of this issue a little bit better.
I think to work across the other entities in the feature model it would be best
to express these dependencies in terms of OSGi Requirements/Capabilities.
For dependencies on Java Packages this is easy, as there exists already an OSGi
namespace for this. So the Import-Package would translate, just as with OSGi
bundles, into something like this:
{{Require-Capability:
osgi.wiring.package;filter:="(&(osgi.wiring.package=org.apache.sling.somepackage)(version>=1.2.0)(!(version>=2.0.0)))"}}
For dependencies on other content packages, I see that this is currently
typically expressed in terms of the content package name/version. In the
OSGi-world this is considered an anti-pattern (the Require-Bundle model).
However, if this is the model that exists today, then we need to be able to
model that.
Do content packages also support a dependency model based on actual content?
Maybe the script resolver that [~radu.cotescu] worked on in the Sling
whiteboard already has something like this?
In any case, it seems to me that we need to create a new Capability Namespace
for content packages and possibly another one for content resources. Maybe we
can call it {{org.apache.sling.content.package}}. Then it could have different
attributes depending on what you want to express, something like:
||attribute||description||
|group|reference content package by groupID |
|name|reference content package by artifactID |
|version|reference content package by version |
Then a content package could be represented by something like this, for
providing a capability based on name/version:
{code:java}
Provide-Capability:
org.apache.sling.content.package;name=foo;version=1.2.0
{code}
or provide a capability with resources:
{code:java}
Provide-Capability:
org.apache.sling.content.resource;path=/content/foo-path,
org.apache.sling.content.resource;path=/content/bar-path/bar.jsp
{code}
Any further thoughts?
was (Author: bosschaert):
Hi [~rombert], all,
I'm trying to understand the requirements of this issue a little bit better.
I think to work across the other entities in the feature model it would be best
to express these dependencies in terms of OSGi Requirements/Capabilities.
For dependencies on Java Packages this is easy, as there exists already an OSGi
namespace for this. So the Import-Package would translate, just as with OSGi
bundles, into something like this:
{{Require-Capability:
osgi.wiring.package;filter:="(&(osgi.wiring.package=org.apache.sling.somepackage)(version>=1.2.0)(!(version>=2.0.0)))"}}
For dependencies on other content packages, I see that this is currently
typically expressed in terms of the content package name/version. In the
OSGi-world this is considered an anti-pattern (the Require-Bundle model).
However, if this is the model that exists today, then we need to be able to
model that.
Do content packages also support a dependency model based on actual content?
Maybe the script resolver that [~radu.cotescu] worked on in the Sling
whiteboard already has something like this?
In any case, it seems to me that we need to create a new Capability Namespace
for content packages and possibly another one for content resources. Maybe we
can call it {{org.apache.sling.content.package}}. Then it could have different
attributes depending on what you want to express, something like:
||attribute||description||
|group|reference content package by groupID |
|name|reference content package by artifactID |
|version|reference content package by version |
Then a content package could be represented by something like this, for
providing a capability based on name/version:
{code:java}
Provide-Capability:
org.apache.sling.content.package;name=foo,
org.apache.sling.content.package;version=1.2.0
{code}
or provide a capability with resources:
{code:java}
Provide-Capability:
org.apache.sling.content.resource;path=/content/foo-path,
org.apache.sling.content.resource;path=/content/bar-path/bar.jsp
{code}
Any further thoughts?
> Support checking dependencies for content packages
> --
>
> Key: SLING-8251
> URL: https://issues.apache.org/jira/browse/SLING-8251
> Project: Sling
> Issue Type: New Feature
> Components: Feature Model
>Reporter: Robert Munteanu
>Assignee: David Bosschaert
>Priority: Major
>
> When including content packages in a feature model there are some
> dependencies that would be great to check at build time. Both of these are
> defined as manifest headers:
[VOTE] Release Apache Sling Feature 1.0.0 and Feature IO 1.0.0
Hi all, I would like to call the 1.0.0 release of the following components: org.apache.sling.feature 1.0.0 fixed issues: https://issues.apache.org/jira/projects/SLING/versions/12344550 org.apache.sling.feature.io 1.0.0 fixed issues: https://issues.apache.org/jira/projects/SLING/versions/12344551 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2044/ 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 2044 /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. Best regards, David Bosschaert
[jira] [Comment Edited] (SLING-8251) Support checking dependencies for content packages
[
https://issues.apache.org/jira/browse/SLING-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754918#comment-16754918
]
David Bosschaert edited comment on SLING-8251 at 1/29/19 2:42 PM:
--
Hi [~rombert], all,
I'm trying to understand the requirements of this issue a little bit better.
I think to work across the other entities in the feature model it would be best
to express these dependencies in terms of OSGi Requirements/Capabilities.
For dependencies on Java Packages this is easy, as there exists already an OSGi
namespace for this. So the Import-Package would translate, just as with OSGi
bundles, into something like this:
{{Require-Capability:
osgi.wiring.package;filter:="(&(osgi.wiring.package=org.apache.sling.somepackage)(version>=1.2.0)(!(version>=2.0.0)))"}}
For dependencies on other content packages, I see that this is currently
typically expressed in terms of the content package name/version. In the
OSGi-world this is considered an anti-pattern (the Require-Bundle model).
However, if this is the model that exists today, then we need to be able to
model that.
Do content packages also support a dependency model based on actual content?
Maybe the script resolver that [~radu.cotescu] worked on in the Sling
whiteboard already has something like this?
In any case, it seems to me that we need to create a new Capability Namespace
for content packages and possibly another one for content resources. Maybe we
can call it {{org.apache.sling.content.package}}. Then it could have different
attributes depending on what you want to express, something like:
||attribute||description||
|group|reference content package by groupID |
|name|reference content package by artifactID |
|version|reference content package by version |
Then a content package could be represented by something like this, for
providing a capability based on name/version:
{code:java}
Provide-Capability:
org.apache.sling.content.package;name=foo,
org.apache.sling.content.package;version=1.2.0
{code}
or provide a capability with resources:
{code:java}
Provide-Capability:
org.apache.sling.content.resource;path=/content/foo-path,
org.apache.sling.content.resource;path=/content/bar-path/bar.jsp
{code}
Any further thoughts?
was (Author: bosschaert):
Hi [~rombert], all,
I'm trying to understand the requirements of this issue a little bit better.
I think to work across the other entities in the feature model it would be best
to express these dependencies in terms of OSGi Requirements/Capabilities.
For dependencies on Java Packages this is easy, as there exists already an OSGi
namespace for this. So the Import-Package would translate, just as with OSGi
bundles, into something like this:
{{Require-Capability:
osgi.wiring.package;filter:="(&(osgi.wiring.package=org.apache.sling.somepackage)(version>=1.2.0)(!(version>=2.0.0)))"}}
For dependencies on other content packages, I see that this is currently
typically expressed in terms of the content package name/version. In the
OSGi-world this is considered an anti-pattern (the Require-Bundle model).
However, if this is the model that exists today, then we need to be able to
model that.
Do content packages also support a dependency model based on actual content?
Maybe the script resolver that [~radu.cotescu] worked on in the Sling
whiteboard already has something like this?
In any case, it seems to me that we need to create a new Capability Namespace
for content (or possibly multiple namespaces). Maybe we can call it
{{org.apache.sling.content}}. Then it could have different attributes depending
on what you want to express, something like:
||attribute||description||
|name|reference content package by name |
|version|reference content package by version |
|path|reference content resources inside the content package|
Then a content package could be represented by something like this, for
providing a capability based on name/version:
{code:java}
Provide-Capability:
org.apache.sling.content;name=foo,org.apache.sling.content:version=1.2.0
{code}
or provide a capability with resources:
{code:java}
Provide-Capability:
org.apache.sling.content;path=/content/foo-path,
org.apache.sling.content;path=/content/bar-path/bar.jsp
{code}
Any further thoughts?
> Support checking dependencies for content packages
> --
>
> Key: SLING-8251
> URL: https://issues.apache.org/jira/browse/SLING-8251
> Project: Sling
> Issue Type: New Feature
> Components: Feature Model
>Reporter: Robert Munteanu
>Assignee: David Bosschaert
>Priority: Major
>
> When including content packages in a feature model there are some
> dependencies that would be great to check at build time. Both of these are
> defined as manifest headers:
> # dependencies to
[RESULT][VOTE] Release Apache Sling XSS Protection API 2.1.0
Hi, The release was successful with 3 binding +1 votes from Karl Pauls, Robert Munteanu and Daniel Klco and 1 non-binding +1 vote from Jason E Bailey. I’ll start promoting the release ASAP. Thanks, Radu
[jira] [Closed] (SLING-8235) Stop copying the AntiSamy configuration to the repository
[
https://issues.apache.org/jira/browse/SLING-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu closed SLING-8235.
---
> Stop copying the AntiSamy configuration to the repository
> -
>
> Key: SLING-8235
> URL: https://issues.apache.org/jira/browse/SLING-8235
> Project: Sling
> Issue Type: Improvement
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: XSS Protection API 2.1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently the {{org.apache.sling.xss}} bundle copies the default AntiSamy
> configuration to the repository, with the help of the
> {{org.apache.sling.jcr.contentloader}}. However, the whole operation is
> redundant, since the bundle would anyways use this embedded file if the
> {{org.apache.sling.xss.impl.XSSFilterImpl}} is not configured to use another
> {{Resource}}.
> The {{org.apache.sling.xss}} bundle should therefore stop providing the
> {{Sling-Initial-Content}} header, allowing the bundle to also work when the
> resource tree is not provided by a JCR repository, and provide an optional
> Felix web console plugin, to allow developers / users to inspect the embedded
> AntiSamy config, if they need to adapt it to a customised one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-8251) Support checking dependencies for content packages
[
https://issues.apache.org/jira/browse/SLING-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754918#comment-16754918
]
David Bosschaert commented on SLING-8251:
-
Hi [~rombert], all,
I'm trying to understand the requirements of this issue a little bit better.
I think to work across the other entities in the feature model it would be best
to express these dependencies in terms of OSGi Requirements/Capabilities.
For dependencies on Java Packages this is easy, as there exists already an OSGi
namespace for this. So the Import-Package would translate, just as with OSGi
bundles, into something like this:
{{Require-Capability:
osgi.wiring.package;filter:="(&(osgi.wiring.package=org.apache.sling.somepackage)(version>=1.2.0)(!(version>=2.0.0)))"}}
For dependencies on other content packages, I see that this is currently
typically expressed in terms of the content package name/version. In the
OSGi-world this is considered an anti-pattern (the Require-Bundle model).
However, if this is the model that exists today, then we need to be able to
model that.
Do content packages also support a dependency model based on actual content?
Maybe the script resolver that [~radu.cotescu] worked on in the Sling
whiteboard already has something like this?
In any case, it seems to me that we need to create a new Capability Namespace
for content (or possibly multiple namespaces). Maybe we can call it
{{org.apache.sling.content}}. Then it could have different attributes depending
on what you want to express, something like:
||attribute||description||
|name|reference content package by name |
|version|reference content package by version |
|path|reference content resources inside the content package|
Then a content package could be represented by something like this, for
providing a capability based on name/version:
{code:java}
Provide-Capability:
org.apache.sling.content;name=foo,org.apache.sling.content:version=1.2.0
{code}
or provide a capability with resources:
{code:java}
Provide-Capability:
org.apache.sling.content;path=/content/foo-path,
org.apache.sling.content;path=/content/bar-path/bar.jsp
{code}
Any further thoughts?
> Support checking dependencies for content packages
> --
>
> Key: SLING-8251
> URL: https://issues.apache.org/jira/browse/SLING-8251
> Project: Sling
> Issue Type: New Feature
> Components: Feature Model
>Reporter: Robert Munteanu
>Assignee: David Bosschaert
>Priority: Major
>
> When including content packages in a feature model there are some
> dependencies that would be great to check at build time. Both of these are
> defined as manifest headers:
> # dependencies to other content pacakges - Content-Package-Dependencies
> # dependencies to java packages - Import-Package (with the same syntax as the
> OSGi bundle Import-Package header ).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (SLING-8213) Not possible to specify wildcard handler property in Maven plugin
[
https://issues.apache.org/jira/browse/SLING-8213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert resolved SLING-8213.
-
Resolution: Fixed
Fixed with:
*
https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-feature.git;a=commitdiff;h=ad9fb1970b98ba5d1b20d33829d6f5d9df8454ef
*
https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-feature-analyser.git;a=commitdiff;h=70274a1a15cfe1308add630ea3334c49cf01d7f6
*
https://gitbox.apache.org/repos/asf?p=sling-slingfeature-maven-plugin.git;a=commitdiff;h=3082ba25eaf2488571ee37911bb1f5353edd4369
> Not possible to specify wildcard handler property in Maven plugin
> -
>
> Key: SLING-8213
> URL: https://issues.apache.org/jira/browse/SLING-8213
> Project: Sling
> Issue Type: Bug
> Components: Feature Model
>Affects Versions: slingfeature-maven-plugin 0.8.0
>Reporter: David Bosschaert
>Assignee: David Bosschaert
>Priority: Major
> Fix For: Feature Model 0.8.2, Feature Model Analyser 0.8.2,
> slingfeature-maven-plugin 0.8.2
>
>
> The custom merge handlers executed during aggregation can be configured using
> {{handlerConfiguration}} tags in the slingfeature-maven-plugin configuration.
> They can be configured on a per-plugin basis (plugin-name needs to be
> specified) or with a wildcard.
> Currently the way to specify configuration that needs to be passed to all
> plugins is by specifying {{*}} as the name, in the case of the maven plugin,
> the name is specify as an XML tag.
> However {code}<*>{code} is not a valid XML tag and the pom will not parse
> with such a tag, so using {{*}} as the wildcard is an unfortunate choice.
> We need to fix this so that wildcards can be specified in the pom.xml
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-8213) Not possible to specify wildcard handler property in Maven plugin
[
https://issues.apache.org/jira/browse/SLING-8213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert updated SLING-8213:
Fix Version/s: Feature Model Analyser 0.8.2
Feature Model 0.8.2
> Not possible to specify wildcard handler property in Maven plugin
> -
>
> Key: SLING-8213
> URL: https://issues.apache.org/jira/browse/SLING-8213
> Project: Sling
> Issue Type: Bug
> Components: Feature Model
>Affects Versions: slingfeature-maven-plugin 0.8.0
>Reporter: David Bosschaert
>Assignee: David Bosschaert
>Priority: Major
> Fix For: Feature Model 0.8.2, Feature Model Analyser 0.8.2,
> slingfeature-maven-plugin 0.8.2
>
>
> The custom merge handlers executed during aggregation can be configured using
> {{handlerConfiguration}} tags in the slingfeature-maven-plugin configuration.
> They can be configured on a per-plugin basis (plugin-name needs to be
> specified) or with a wildcard.
> Currently the way to specify configuration that needs to be passed to all
> plugins is by specifying {{*}} as the name, in the case of the maven plugin,
> the name is specify as an XML tag.
> However {code}<*>{code} is not a valid XML tag and the pom will not parse
> with such a tag, so using {{*}} as the wildcard is an unfortunate choice.
> We need to fix this so that wildcards can be specified in the pom.xml
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (SLING-8213) Not possible to specify wildcard handler property in Maven plugin
[
https://issues.apache.org/jira/browse/SLING-8213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert reassigned SLING-8213:
---
Assignee: David Bosschaert
> Not possible to specify wildcard handler property in Maven plugin
> -
>
> Key: SLING-8213
> URL: https://issues.apache.org/jira/browse/SLING-8213
> Project: Sling
> Issue Type: Bug
> Components: Feature Model
>Affects Versions: slingfeature-maven-plugin 0.8.0
>Reporter: David Bosschaert
>Assignee: David Bosschaert
>Priority: Major
> Fix For: slingfeature-maven-plugin 0.8.2
>
>
> The custom merge handlers executed during aggregation can be configured using
> {{handlerConfiguration}} tags in the slingfeature-maven-plugin configuration.
> They can be configured on a per-plugin basis (plugin-name needs to be
> specified) or with a wildcard.
> Currently the way to specify configuration that needs to be passed to all
> plugins is by specifying {{*}} as the name, in the case of the maven plugin,
> the name is specify as an XML tag.
> However {code}<*>{code} is not a valid XML tag and the pom will not parse
> with such a tag, so using {{*}} as the wildcard is an unfortunate choice.
> We need to fix this so that wildcards can be specified in the pom.xml
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
