Re: [VOTE] Release Apache Sling Resource Resolver 1.6.8
+1 regards, Karl On Fri, Oct 19, 2018 at 4:39 PM Daniel Klco wrote: > > +1 > > On Fri, Oct 19, 2018 at 4:25 AM Radu Cotescu wrote: > > > +1 > > > > > On 18 Oct 2018, at 22:16, Karl Pauls wrote: > > > > > > Please vote to approve these releases: > > > > > > [ ] +1 Approve the releases > > > [ ] 0 Don't care > > > [ ] -1 Don't release, because ... > > > > -- Karl Pauls karlpa...@gmail.com
Re: [VOTE] Release Apache Sling 11
+1 regards, Karl On Fri, Oct 19, 2018 at 6:29 PM Robert Munteanu wrote: > > On Fri, 2018-10-19 at 18:03 +0200, Robert Munteanu wrote: > > > Please vote to approve this release: > > +1 > > Robert -- Karl Pauls karlpa...@gmail.com
[jira] [Commented] (SLING-7935) Consolidate all 'launchpad-testing' modules into a single git repository
[ https://issues.apache.org/jira/browse/SLING-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16657466#comment-16657466 ] Robert Munteanu commented on SLING-7935: Unified versions in > Consolidate all 'launchpad-testing' modules into a single git repository > > > Key: SLING-7935 > URL: https://issues.apache.org/jira/browse/SLING-7935 > Project: Sling > Issue Type: Task > Components: Launchpad >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Fix For: Starter 12 > > > We currently have seven testing-related modules in Git: > * org-apache-sling-launchpad-integration-tests > * org-apache-sling-launchpad-test-bundles > * org-apache-sling-launchpad-test-fragment > * org-apache-sling-launchpad-testing > * org-apache-sling-launchpad-testing-war > * org-apache-sling-launchpad-test-services > * org-apache-sling-launchpad-test-services-war > All of these are related to testing the starter application and typically we > only release them when the starter is also released. As such, it's a pain to > manually keep versions in sync and release the modules one by one. This is > one scenario where a single git repository would make sense. > Whether this should be the actual starter repository or a starter-testing one > is something that is not set in stone, but the current situation is not > optimal. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (SLING-7935) Consolidate all 'launchpad-testing' modules into a single git repository
[ https://issues.apache.org/jira/browse/SLING-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16657466#comment-16657466 ] Robert Munteanu edited comment on SLING-7935 at 10/19/18 9:29 PM: -- Unified versions in: * [sling-org-apache-sling-launchpad-test-services-war commit b1c3c05|https://github.com/apache/sling-org-apache-sling-launchpad-test-services-war/commit/b1c3c05] * [sling-org-apache-sling-launchpad-test-fragment commit 32aabef|https://github.com/apache/sling-org-apache-sling-launchpad-test-fragment/commit/32aabef] * [sling-org-apache-sling-launchpad-test-bundles commit 84b2007|https://github.com/apache/sling-org-apache-sling-launchpad-test-bundles/commit/84b2007] * [sling-org-apache-sling-launchpad-test-bundles commit 2236b41|https://github.com/apache/sling-org-apache-sling-launchpad-test-bundles/commit/2236b41] * [sling-org-apache-sling-launchpad-test-services commit dffb32e|https://github.com/apache/sling-org-apache-sling-launchpad-test-services/commit/dffb32e] * [sling-org-apache-sling-launchpad-integration-tests commit 02439fd|https://github.com/apache/sling-org-apache-sling-launchpad-integration-tests/commit/02439fd] * [sling-org-apache-sling-launchpad-testing commit 19f71e1|https://github.com/apache/sling-org-apache-sling-launchpad-testing/commit/19f71e1] * [sling-org-apache-sling-launchpad-testing commit 11a7575|https://github.com/apache/sling-org-apache-sling-launchpad-testing/commit/11a7575] * [sling-org-apache-sling-launchpad-testing-war commit 35e71a3|https://github.com/apache/sling-org-apache-sling-launchpad-testing-war/commit/35e71a3] * [sling-org-apache-sling-launchpad-testing-war commit cfa4517|https://github.com/apache/sling-org-apache-sling-launchpad-testing-war/commit/cfa4517] was (Author: rombert): Unified versions in > Consolidate all 'launchpad-testing' modules into a single git repository > > > Key: SLING-7935 > URL: https://issues.apache.org/jira/browse/SLING-7935 > Project: Sling > Issue Type: Task > Components: Launchpad >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Fix For: Starter 12 > > > We currently have seven testing-related modules in Git: > * org-apache-sling-launchpad-integration-tests > * org-apache-sling-launchpad-test-bundles > * org-apache-sling-launchpad-test-fragment > * org-apache-sling-launchpad-testing > * org-apache-sling-launchpad-testing-war > * org-apache-sling-launchpad-test-services > * org-apache-sling-launchpad-test-services-war > All of these are related to testing the starter application and typically we > only release them when the starter is also released. As such, it's a pain to > manually keep versions in sync and release the modules one by one. This is > one scenario where a single git repository would make sense. > Whether this should be the actual starter repository or a starter-testing one > is something that is not set in stone, but the current situation is not > optimal. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SLING-8042) The slingfeature-maven-plugin should be able to derive the name of a feature from the file name
[
https://issues.apache.org/jira/browse/SLING-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved SLING-8042.
-
Resolution: Fixed
Implemented this as explained above in rev 0a11d70
The special handling of a feature named "feature.json" is not needed as the
special handling has already been done by the AttachFeaturesMojo
> The slingfeature-maven-plugin should be able to derive the name of a feature
> from the file name
> ---
>
> Key: SLING-8042
> URL: https://issues.apache.org/jira/browse/SLING-8042
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Reporter: Radu Cotescu
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0
>
>
> The {{slingfeature-maven-plugin}} should be able to derive the name of a
> feature from the file name, if the name is missing from the feature
> definition.
> Assuming a file called {{my-feature.json}}, with the following contents:
> {noformat}
> {
> "id" :
> "${project.groupId}:${project.artifactId}:slingfeature:${project.version}",
> "bundles" :[
>...
> ]
> }
> {noformat}
> then the {{slingfeature-maven-plugin}} should infer that the feature it's
> building is called {{my-feature}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-8042) The slingfeature-maven-plugin should be able to derive the name of a feature from the file name
[
https://issues.apache.org/jira/browse/SLING-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-8042:
Fix Version/s: slingfeature-maven-plugin 1.0.0
> The slingfeature-maven-plugin should be able to derive the name of a feature
> from the file name
> ---
>
> Key: SLING-8042
> URL: https://issues.apache.org/jira/browse/SLING-8042
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Reporter: Radu Cotescu
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0
>
>
> The {{slingfeature-maven-plugin}} should be able to derive the name of a
> feature from the file name, if the name is missing from the feature
> definition.
> Assuming a file called {{my-feature.json}}, with the following contents:
> {noformat}
> {
> "id" :
> "${project.groupId}:${project.artifactId}:slingfeature:${project.version}",
> "bundles" :[
>...
> ]
> }
> {noformat}
> then the {{slingfeature-maven-plugin}} should infer that the feature it's
> building is called {{my-feature}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (SLING-8042) The slingfeature-maven-plugin should be able to derive the name of a feature from the file name
[
https://issues.apache.org/jira/browse/SLING-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler reassigned SLING-8042:
---
Assignee: Carsten Ziegeler (was: David Bosschaert)
> The slingfeature-maven-plugin should be able to derive the name of a feature
> from the file name
> ---
>
> Key: SLING-8042
> URL: https://issues.apache.org/jira/browse/SLING-8042
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Reporter: Radu Cotescu
>Assignee: Carsten Ziegeler
>Priority: Major
>
> The {{slingfeature-maven-plugin}} should be able to derive the name of a
> feature from the file name, if the name is missing from the feature
> definition.
> Assuming a file called {{my-feature.json}}, with the following contents:
> {noformat}
> {
> "id" :
> "${project.groupId}:${project.artifactId}:slingfeature:${project.version}",
> "bundles" :[
>...
> ]
> }
> {noformat}
> then the {{slingfeature-maven-plugin}} should infer that the feature it's
> building is called {{my-feature}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-7935) Consolidate all 'launchpad-testing' modules into a single git repository
[ https://issues.apache.org/jira/browse/SLING-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16657068#comment-16657068 ] Robert Munteanu commented on SLING-7935: As a first step I will change the projects to have the same version. It makes life much easier when releasing anyway and we only release them alongside the starter. > Consolidate all 'launchpad-testing' modules into a single git repository > > > Key: SLING-7935 > URL: https://issues.apache.org/jira/browse/SLING-7935 > Project: Sling > Issue Type: Task > Components: Launchpad >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Fix For: Starter 12 > > > We currently have seven testing-related modules in Git: > * org-apache-sling-launchpad-integration-tests > * org-apache-sling-launchpad-test-bundles > * org-apache-sling-launchpad-test-fragment > * org-apache-sling-launchpad-testing > * org-apache-sling-launchpad-testing-war > * org-apache-sling-launchpad-test-services > * org-apache-sling-launchpad-test-services-war > All of these are related to testing the starter application and typically we > only release them when the starter is also released. As such, it's a pain to > manually keep versions in sync and release the modules one by one. This is > one scenario where a single git repository would make sense. > Whether this should be the actual starter repository or a starter-testing one > is something that is not set in stone, but the current situation is not > optimal. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (SLING-7935) Consolidate all 'launchpad-testing' modules into a single git repository
[ https://issues.apache.org/jira/browse/SLING-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu reassigned SLING-7935: -- Assignee: Robert Munteanu > Consolidate all 'launchpad-testing' modules into a single git repository > > > Key: SLING-7935 > URL: https://issues.apache.org/jira/browse/SLING-7935 > Project: Sling > Issue Type: Task > Components: Launchpad >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Fix For: Starter 12 > > > We currently have seven testing-related modules in Git: > * org-apache-sling-launchpad-integration-tests > * org-apache-sling-launchpad-test-bundles > * org-apache-sling-launchpad-test-fragment > * org-apache-sling-launchpad-testing > * org-apache-sling-launchpad-testing-war > * org-apache-sling-launchpad-test-services > * org-apache-sling-launchpad-test-services-war > All of these are related to testing the starter application and typically we > only release them when the starter is also released. As such, it's a pain to > manually keep versions in sync and release the modules one by one. This is > one scenario where a single git repository would make sense. > Whether this should be the actual starter repository or a starter-testing one > is something that is not set in stone, but the current situation is not > optimal. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SLING-7907) Update local starter references to 11 or 12-SNAPSHOT
[ https://issues.apache.org/jira/browse/SLING-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu resolved SLING-7907. Resolution: Fixed * [sling-whiteboard commit 591ffdf|https://github.com/apache/sling-whiteboard/commit/591ffdf] * [sling-org-apache-sling-scripting-sightly-testing commit cd2a971|https://github.com/apache/sling-org-apache-sling-scripting-sightly-testing/commit/cd2a971] * [sling-org-apache-sling-launchpad-testing commit 138ff27|https://github.com/apache/sling-org-apache-sling-launchpad-testing/commit/138ff27] * [sling-org-apache-sling-launchpad-testing-war commit c66cfba|https://github.com/apache/sling-org-apache-sling-launchpad-testing-war/commit/c66cfba] > Update local starter references to 11 or 12-SNAPSHOT > > > Key: SLING-7907 > URL: https://issues.apache.org/jira/browse/SLING-7907 > Project: Sling > Issue Type: Sub-task >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [VOTE] Release Apache Sling 11
+1 On Fri, Oct 19, 2018 at 12:11 PM Carsten Ziegeler wrote: > +1 > > Am 19.10.2018 um 18:03 schrieb Robert Munteanu: > > Obviously, this is a [VOTE]... > > > > On Fri, 2018-10-19 at 18:02 +0200, Robert Munteanu wrote: > >> Hi, > >> > >> This is the vote for releasing Sling 11 and the associated > >> artifacts. > >> > >> More precisely: > >> > >> - org.apache.sling.starter-11 > >> - org.apache.sling.launchpad.test-services-2.0.16 > >> - org.apache.sling.junit.teleporter-1.0.18 > >> - org.apache.sling.launchpad.integration-tests-1.0.8 > >> - org.apache.sling.launchpad.test-fragment-2.0.16 > >> - org.apache.sling.launchpad.test-services-war-2.0.16 > >> - org.apache.sling.launchpad.test-bundles-0.0.6 > >> - org.apache.sling.launchpad.testing-11 > >> - org.apache.sling.launchpad.testing-war-11 > >> - sling-launchpad-archetype 1.0.8 > >> > >> Note that through a funny coincidence this Starter release got the > >> 2000 > >> staging repository, which I guess is a fitting, round, number. > >> > >> We solved 29 issues in these releases > >> > >> https://issues.apache.org/jira/projects/SLING/versions/12342436 > >> https://issues.apache.org/jira/projects/SLING/versions/12343904 > >> https://issues.apache.org/jira/projects/SLING/versions/12341682 > >> https://issues.apache.org/jira/projects/SLING/versions/12342714 > >> https://issues.apache.org/jira/projects/SLING/versions/12342749 > >> https://issues.apache.org/jira/projects/SLING/versions/12342575 > >> https://issues.apache.org/jira/projects/SLING/versions/12342642 > >> https://issues.apache.org/jira/projects/SLING/versions/12342720 > >> > >> Staging repository: > >> > > https://repository.apache.org/content/repositories/orgapachesling-2000 > >> > >> 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 2000 /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. > >> > >> Thanks, > >> > >> Robert > >> > > > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org >
Re: [VOTE] Release Apache Sling 11
+1 Am 19.10.2018 um 18:03 schrieb Robert Munteanu: Obviously, this is a [VOTE]... On Fri, 2018-10-19 at 18:02 +0200, Robert Munteanu wrote: Hi, This is the vote for releasing Sling 11 and the associated artifacts. More precisely: - org.apache.sling.starter-11 - org.apache.sling.launchpad.test-services-2.0.16 - org.apache.sling.junit.teleporter-1.0.18 - org.apache.sling.launchpad.integration-tests-1.0.8 - org.apache.sling.launchpad.test-fragment-2.0.16 - org.apache.sling.launchpad.test-services-war-2.0.16 - org.apache.sling.launchpad.test-bundles-0.0.6 - org.apache.sling.launchpad.testing-11 - org.apache.sling.launchpad.testing-war-11 - sling-launchpad-archetype 1.0.8 Note that through a funny coincidence this Starter release got the 2000 staging repository, which I guess is a fitting, round, number. We solved 29 issues in these releases https://issues.apache.org/jira/projects/SLING/versions/12342436 https://issues.apache.org/jira/projects/SLING/versions/12343904 https://issues.apache.org/jira/projects/SLING/versions/12341682 https://issues.apache.org/jira/projects/SLING/versions/12342714 https://issues.apache.org/jira/projects/SLING/versions/12342749 https://issues.apache.org/jira/projects/SLING/versions/12342575 https://issues.apache.org/jira/projects/SLING/versions/12342642 https://issues.apache.org/jira/projects/SLING/versions/12342720 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2000 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 2000 /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. Thanks, Robert -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Assigned] (SLING-7907) Update local starter references to 11 or 12-SNAPSHOT
[ https://issues.apache.org/jira/browse/SLING-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu reassigned SLING-7907: -- Assignee: Robert Munteanu > Update local starter references to 11 or 12-SNAPSHOT > > > Key: SLING-7907 > URL: https://issues.apache.org/jira/browse/SLING-7907 > Project: Sling > Issue Type: Sub-task >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-7906) Release Sling Starter 11 and associated artifacts
[ https://issues.apache.org/jira/browse/SLING-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16657000#comment-16657000 ] Robert Munteanu commented on SLING-7906: Vote started at https://lists.apache.org/thread.html/15ed36f8465b8da4fb9f3ee69651935bf91573c47d127d797967f9b7@%3Cdev.sling.apache.org%3E > Release Sling Starter 11 and associated artifacts > - > > Key: SLING-7906 > URL: https://issues.apache.org/jira/browse/SLING-7906 > Project: Sling > Issue Type: Sub-task >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > > - starter 11 > - launchpad.testing and associated projects > - Maven archetypes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[VOTE] Release Apache Sling 11
Obviously, this is a [VOTE]... On Fri, 2018-10-19 at 18:02 +0200, Robert Munteanu wrote: > Hi, > > This is the vote for releasing Sling 11 and the associated > artifacts. > > More precisely: > > - org.apache.sling.starter-11 > - org.apache.sling.launchpad.test-services-2.0.16 > - org.apache.sling.junit.teleporter-1.0.18 > - org.apache.sling.launchpad.integration-tests-1.0.8 > - org.apache.sling.launchpad.test-fragment-2.0.16 > - org.apache.sling.launchpad.test-services-war-2.0.16 > - org.apache.sling.launchpad.test-bundles-0.0.6 > - org.apache.sling.launchpad.testing-11 > - org.apache.sling.launchpad.testing-war-11 > - sling-launchpad-archetype 1.0.8 > > Note that through a funny coincidence this Starter release got the > 2000 > staging repository, which I guess is a fitting, round, number. > > We solved 29 issues in these releases > > https://issues.apache.org/jira/projects/SLING/versions/12342436 > https://issues.apache.org/jira/projects/SLING/versions/12343904 > https://issues.apache.org/jira/projects/SLING/versions/12341682 > https://issues.apache.org/jira/projects/SLING/versions/12342714 > https://issues.apache.org/jira/projects/SLING/versions/12342749 > https://issues.apache.org/jira/projects/SLING/versions/12342575 > https://issues.apache.org/jira/projects/SLING/versions/12342642 > https://issues.apache.org/jira/projects/SLING/versions/12342720 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-2000 > > 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 2000 /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. > > Thanks, > > Robert >
Release Sling 11
Hi, This is the vote for releasing Sling 11 and the associated artifacts. More precisely: - org.apache.sling.starter-11 - org.apache.sling.launchpad.test-services-2.0.16 - org.apache.sling.junit.teleporter-1.0.18 - org.apache.sling.launchpad.integration-tests-1.0.8 - org.apache.sling.launchpad.test-fragment-2.0.16 - org.apache.sling.launchpad.test-services-war-2.0.16 - org.apache.sling.launchpad.test-bundles-0.0.6 - org.apache.sling.launchpad.testing-11 - org.apache.sling.launchpad.testing-war-11 - sling-launchpad-archetype 1.0.8 Note that through a funny coincidence this Starter release got the 2000 staging repository, which I guess is a fitting, round, number. We solved 29 issues in these releases https://issues.apache.org/jira/projects/SLING/versions/12342436 https://issues.apache.org/jira/projects/SLING/versions/12343904 https://issues.apache.org/jira/projects/SLING/versions/12341682 https://issues.apache.org/jira/projects/SLING/versions/12342714 https://issues.apache.org/jira/projects/SLING/versions/12342749 https://issues.apache.org/jira/projects/SLING/versions/12342575 https://issues.apache.org/jira/projects/SLING/versions/12342642 https://issues.apache.org/jira/projects/SLING/versions/12342720 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2000 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 2000 /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. Thanks, Robert
[jira] [Updated] (SLING-7935) Consolidate all 'launchpad-testing' modules into a single git repository
[ https://issues.apache.org/jira/browse/SLING-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-7935: --- Fix Version/s: (was: Starter 11) Starter 12 > Consolidate all 'launchpad-testing' modules into a single git repository > > > Key: SLING-7935 > URL: https://issues.apache.org/jira/browse/SLING-7935 > Project: Sling > Issue Type: Task > Components: Launchpad >Reporter: Robert Munteanu >Priority: Major > Fix For: Starter 12 > > > We currently have seven testing-related modules in Git: > * org-apache-sling-launchpad-integration-tests > * org-apache-sling-launchpad-test-bundles > * org-apache-sling-launchpad-test-fragment > * org-apache-sling-launchpad-testing > * org-apache-sling-launchpad-testing-war > * org-apache-sling-launchpad-test-services > * org-apache-sling-launchpad-test-services-war > All of these are related to testing the starter application and typically we > only release them when the starter is also released. As such, it's a pain to > manually keep versions in sync and release the modules one by one. This is > one scenario where a single git repository would make sense. > Whether this should be the actual starter repository or a starter-testing one > is something that is not set in stone, but the current situation is not > optimal. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-7913) Ban snapshots in the Sling starter
[ https://issues.apache.org/jira/browse/SLING-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-7913: --- Fix Version/s: (was: Starter 11) Starter 12 > Ban snapshots in the Sling starter > -- > > Key: SLING-7913 > URL: https://issues.apache.org/jira/browse/SLING-7913 > Project: Sling > Issue Type: Bug > Components: Starter >Reporter: Robert Munteanu >Priority: Major > Fix For: Starter 12 > > > We have agreed to keep only releases in the Sling starter to make it easier > to release and to make builds reproducible. > We should enforce this policy to make it impossible to mistakenly add > SNAPSHOT versions to the project. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-7504) Sling File Installer Provider inactive in Sling Starter
[
https://issues.apache.org/jira/browse/SLING-7504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-7504:
---
Fix Version/s: (was: Starter 11)
Starter 12
> Sling File Installer Provider inactive in Sling Starter
> ---
>
> Key: SLING-7504
> URL: https://issues.apache.org/jira/browse/SLING-7504
> Project: Sling
> Issue Type: Improvement
> Components: Launchpad
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: Starter 12
>
>
> Even in the newest Starter 11 the framework property for the Sling File
> Installer is not set by default. This should be fixed. The relevant framework
> property is {{sling.fileinstall.dir}}. I propose to set this to
> {{${sling.home}/install}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (SLING-8045) The ExtensionRegistryService does not correctly manage references
[
https://issues.apache.org/jira/browse/SLING-8045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu resolved SLING-8045.
-
Resolution: Fixed
Fixed in [commit
e554fa4|https://github.com/apache/sling-org-apache-sling-scripting-sightly/commit/e554fa4].
> The ExtensionRegistryService does not correctly manage references
> -
>
> Key: SLING-8045
> URL: https://issues.apache.org/jira/browse/SLING-8045
> Project: Sling
> Issue Type: Bug
> Components: Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting HTL Engine 1.1.0-1.4.0
>
>
> The
> {{org.apache.sling.scripting.sightly.impl.engine.ExtensionRegistryService}}
> does not correctly handle the case when a
> {{org.apache.sling.scripting.sightly.extension.RuntimeExtension}} is
> unregistered:
> 1. the
> {{org.apache.sling.scripting.sightly.impl.engine.ExtensionRegistryService#unbindExtensionService}}
> method should not require a service object;
> 2. the service should fallback to using a lower priority
> {{org.apache.sling.scripting.sightly.extension.RuntimeExtension}} registered
> for the same operation as a higher priority one, if the extension with a
> higher priority gets unregistered.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-8042) The slingfeature-maven-plugin should be able to derive the name of a feature from the file name
[
https://issues.apache.org/jira/browse/SLING-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656906#comment-16656906
]
David Bosschaert commented on SLING-8042:
-
Thanks for clarifying, [~cziegeler]!
+1 from me :)
> The slingfeature-maven-plugin should be able to derive the name of a feature
> from the file name
> ---
>
> Key: SLING-8042
> URL: https://issues.apache.org/jira/browse/SLING-8042
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Reporter: Radu Cotescu
>Assignee: David Bosschaert
>Priority: Major
>
> The {{slingfeature-maven-plugin}} should be able to derive the name of a
> feature from the file name, if the name is missing from the feature
> definition.
> Assuming a file called {{my-feature.json}}, with the following contents:
> {noformat}
> {
> "id" :
> "${project.groupId}:${project.artifactId}:slingfeature:${project.version}",
> "bundles" :[
>...
> ]
> }
> {noformat}
> then the {{slingfeature-maven-plugin}} should infer that the feature it's
> building is called {{my-feature}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SLING-8045) The ExtensionRegistryService does not correctly manage references
Radu Cotescu created SLING-8045:
---
Summary: The ExtensionRegistryService does not correctly manage
references
Key: SLING-8045
URL: https://issues.apache.org/jira/browse/SLING-8045
Project: Sling
Issue Type: Bug
Components: Scripting
Reporter: Radu Cotescu
Assignee: Radu Cotescu
Fix For: Scripting HTL Engine 1.1.0-1.4.0
The {{org.apache.sling.scripting.sightly.impl.engine.ExtensionRegistryService}}
does not correctly handle the case when a
{{org.apache.sling.scripting.sightly.extension.RuntimeExtension}} is
unregistered:
1. the
{{org.apache.sling.scripting.sightly.impl.engine.ExtensionRegistryService#unbindExtensionService}}
method should not require a service object;
2. the service should fallback to using a lower priority
{{org.apache.sling.scripting.sightly.extension.RuntimeExtension}} registered
for the same operation as a higher priority one, if the extension with a higher
priority gets unregistered.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [VOTE] Release Apache Sling Models Impl version 1.4.10
My +1 On Fri, Oct 19, 2018 at 10:50 AM Daniel Klco wrote: > Hi, > > We solved 5 issues in this release: > https://issues.apache.org/jira/projects/SLING/versions/12342851 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-1999/ > > 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 1999 /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. >
[GitHub] klcodanr commented on issue #2: SLING-8029 Retrieve gpg key automatically if it is missing in keyring
klcodanr commented on issue #2: SLING-8029 Retrieve gpg key automatically if it is missing in keyring URL: https://github.com/apache/sling-tooling-release/pull/2#issuecomment-431391243 That scenario could happen now if someone lost control of their ASF account. It would just have a manual step to update the key. I would think though that the script should display a warning, display some explanation on how to update the key and have the user to perform the update. Ideally if it could display some sort of helpful information on whether the key is expired, revoked, etc that would be good to help determine if the key update can be trusted. 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] [Assigned] (SLING-7906) Release Sling Starter 11 and associated artifacts
[ https://issues.apache.org/jira/browse/SLING-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu reassigned SLING-7906: -- Assignee: Robert Munteanu > Release Sling Starter 11 and associated artifacts > - > > Key: SLING-7906 > URL: https://issues.apache.org/jira/browse/SLING-7906 > Project: Sling > Issue Type: Sub-task >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > > - starter 11 > - launchpad.testing and associated projects > - Maven archetypes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SLING-7922) Update to latest available releases for Sling 11
[ https://issues.apache.org/jira/browse/SLING-7922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu resolved SLING-7922. Resolution: Fixed All fixed, including the latest Felix release that were out. > Update to latest available releases for Sling 11 > > > Key: SLING-7922 > URL: https://issues.apache.org/jira/browse/SLING-7922 > Project: Sling > Issue Type: Sub-task > Components: Starter >Reporter: Robert Munteanu >Priority: Major > > Should look into: > - Sling modules that are released but not included > - Felix bundles > - Oak 1.8 > - Other misc dependencies -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-8042) The slingfeature-maven-plugin should be able to derive the name of a feature from the file name
[
https://issues.apache.org/jira/browse/SLING-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656872#comment-16656872
]
Carsten Ziegeler commented on SLING-8042:
-
[~bosschaert] Yes, deployed/installed features always have an id as well as the
maven properties are replaced (for 1+2)
> The slingfeature-maven-plugin should be able to derive the name of a feature
> from the file name
> ---
>
> Key: SLING-8042
> URL: https://issues.apache.org/jira/browse/SLING-8042
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Reporter: Radu Cotescu
>Assignee: David Bosschaert
>Priority: Major
>
> The {{slingfeature-maven-plugin}} should be able to derive the name of a
> feature from the file name, if the name is missing from the feature
> definition.
> Assuming a file called {{my-feature.json}}, with the following contents:
> {noformat}
> {
> "id" :
> "${project.groupId}:${project.artifactId}:slingfeature:${project.version}",
> "bundles" :[
>...
> ]
> }
> {noformat}
> then the {{slingfeature-maven-plugin}} should infer that the feature it's
> building is called {{my-feature}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-8042) The slingfeature-maven-plugin should be able to derive the name of a feature from the file name
[
https://issues.apache.org/jira/browse/SLING-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656869#comment-16656869
]
David Bosschaert commented on SLING-8042:
-
[~cziegeler] if you mean with with the 3rd and 4th option that the feature as
built and installed in the maven repo will contain the ID then I'm +1.
> The slingfeature-maven-plugin should be able to derive the name of a feature
> from the file name
> ---
>
> Key: SLING-8042
> URL: https://issues.apache.org/jira/browse/SLING-8042
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Reporter: Radu Cotescu
>Assignee: David Bosschaert
>Priority: Major
>
> The {{slingfeature-maven-plugin}} should be able to derive the name of a
> feature from the file name, if the name is missing from the feature
> definition.
> Assuming a file called {{my-feature.json}}, with the following contents:
> {noformat}
> {
> "id" :
> "${project.groupId}:${project.artifactId}:slingfeature:${project.version}",
> "bundles" :[
>...
> ]
> }
> {noformat}
> then the {{slingfeature-maven-plugin}} should infer that the feature it's
> building is called {{my-feature}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [VOTE] Release Apache Sling Resource Resolver 1.6.8
+1 On Fri, Oct 19, 2018 at 4:25 AM Radu Cotescu wrote: > +1 > > > On 18 Oct 2018, at 22:16, Karl Pauls wrote: > > > > Please vote to approve these releases: > > > > [ ] +1 Approve the releases > > [ ] 0 Don't care > > [ ] -1 Don't release, because ... > >
[jira] [Closed] (SLING-7414) WebConsole security provider 1.1.0 or newer do not work with the Sling Starter
[
https://issues.apache.org/jira/browse/SLING-7414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu closed SLING-7414.
--
> WebConsole security provider 1.1.0 or newer do not work with the Sling Starter
> --
>
> Key: SLING-7414
> URL: https://issues.apache.org/jira/browse/SLING-7414
> Project: Sling
> Issue Type: Bug
> Components: Authentication
>Affects Versions: Form Based Authentication 1.0.10
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Critical
> Fix For: Form Based Authentication 1.0.12
>
>
> When upgrading the webconsole security provider in the Sling starter to
> 1.2.0, the following problems occur:
> * the SmokeIT fails since accessing {{/system/console/bundles.json}}
> redirects to an HTML login form
> * accessing the OSGi console at {{/system/console}} presents a login form at
> http://localhost:8080/system/sling/form/login?resource=%2Fsystem%2Fconsole,
> but then redirects to http://localhost:8080/system/console/j_security_check .
> Re-accessing {{/system/console}} brings up the login form again.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (SLING-8018) Form login page styling broken when using a context path
[ https://issues.apache.org/jira/browse/SLING-8018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu closed SLING-8018. -- > Form login page styling broken when using a context path > > > Key: SLING-8018 > URL: https://issues.apache.org/jira/browse/SLING-8018 > Project: Sling > Issue Type: Bug > Components: Authentication >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Fix For: Form Based Authentication 1.0.12 > > > Similar to SLING-8016, just this time it's the login page. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (SLING-7938) Add an option to prefer sending the reason_code as a request parameter over the reason text when redirecting to the login page
[ https://issues.apache.org/jira/browse/SLING-7938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu closed SLING-7938. -- > Add an option to prefer sending the reason_code as a request parameter over > the reason text when redirecting to the login page > -- > > Key: SLING-7938 > URL: https://issues.apache.org/jira/browse/SLING-7938 > Project: Sling > Issue Type: Improvement > Components: Authentication >Affects Versions: Form Based Authentication 1.0.10 >Reporter: Eric Norman >Assignee: Eric Norman >Priority: Major > Fix For: Form Based Authentication 1.0.12 > > > Add a config option to the form authentication handler to prefer sending the > reason_code as a request parameter instead of the reason text when > redirecting to the login page. > Sending the reason code as a request parameter should be safer, especially if > your custom login page was echoing the reason text to the screen. The custom > login page script can then calculate the reason text to show in the UI by > matching the reason codes against the well-known failure reason codes and > fallback to some default reason text for anything invalid. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (SLING-8014) Switch auth form to use commons lang 3
[ https://issues.apache.org/jira/browse/SLING-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu closed SLING-8014. -- > Switch auth form to use commons lang 3 > -- > > Key: SLING-8014 > URL: https://issues.apache.org/jira/browse/SLING-8014 > Project: Sling > Issue Type: Sub-task > Components: Authentication >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Fix For: Form Based Authentication 1.0.12 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (SLING-8016) Sling Starter content links are broken when running under a context path
[
https://issues.apache.org/jira/browse/SLING-8016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu closed SLING-8016.
--
> Sling Starter content links are broken when running under a context path
>
>
> Key: SLING-8016
> URL: https://issues.apache.org/jira/browse/SLING-8016
> Project: Sling
> Issue Type: Bug
> Components: Starter
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Starter Content 1.0.2
>
>
> Most of the links on the front page ( Login, Browse Content, System Console )
> and also the links to the static assets are broken when running under a
> context path
> {{java -jar target/org.apache.sling.starter-11-SNAPSHOT.jar -r sling}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (SLING-8044) osgi-mock: Register services interfaces from OSGi metadata only when no explicit interface given
[ https://issues.apache.org/jira/browse/SLING-8044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-8044. --- Resolution: Fixed https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/commit/b04e06522379d32552353304746fbcdb09258460 > osgi-mock: Register services interfaces from OSGi metadata only when no > explicit interface given > > > Key: SLING-8044 > URL: https://issues.apache.org/jira/browse/SLING-8044 > Project: Sling > Issue Type: Bug > Components: Testing >Affects Versions: Testing OSGi Mock 2.4.2 >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Labels: mocks > Fix For: Testing OSGi Mock 2.4.4 > > > if an OSGi service is registered with BundleContext.registerService it should > only be registered to the given interface class, and not to additional > interface classes contained in the OSGi metadata of the service. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SLING-8043) create MissingElementsException only if there is at least one missing element
[ https://issues.apache.org/jira/browse/SLING-8043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Klco resolved SLING-8043. - Resolution: Fixed Fixed in https://github.com/apache/sling-org-apache-sling-models-impl/commit/92d2e5b38e8db3cef714a207ebd42f4fb5f896a0 > create MissingElementsException only if there is at least one missing element > - > > Key: SLING-8043 > URL: https://issues.apache.org/jira/browse/SLING-8043 > Project: Sling > Issue Type: Improvement >Affects Versions: Sling Models Impl 1.4.8 >Reporter: Dan Klco >Assignee: Dan Klco >Priority: Minor > Fix For: Sling Models Impl 1.4.10 > > > Tracking the PR here: > https://github.com/apache/sling-org-apache-sling-models-impl/pull/7 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-8043) create MissingElementsException only if there is at least one missing element
Dan Klco created SLING-8043: --- Summary: create MissingElementsException only if there is at least one missing element Key: SLING-8043 URL: https://issues.apache.org/jira/browse/SLING-8043 Project: Sling Issue Type: Improvement Affects Versions: Sling Models Impl 1.4.8 Reporter: Dan Klco Assignee: Dan Klco Fix For: Sling Models Impl 1.4.10 Tracking the PR here: https://github.com/apache/sling-org-apache-sling-models-impl/pull/7 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] kwin commented on issue #2: SLING-8029 Retrieve gpg key automatically if it is missing in keyring
kwin commented on issue #2: SLING-8029 Retrieve gpg key automatically if it is missing in keyring URL: https://github.com/apache/sling-tooling-release/pull/2#issuecomment-431374168 For exactly this reason we only trust keys within https://people.apache.org/keys/group/sling.asc, right? Can we just import those? 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-8044) osgi-mock: Register services interfaces from OSGi metadata only when no explicit interface given
Stefan Seifert created SLING-8044: - Summary: osgi-mock: Register services interfaces from OSGi metadata only when no explicit interface given Key: SLING-8044 URL: https://issues.apache.org/jira/browse/SLING-8044 Project: Sling Issue Type: Bug Components: Testing Affects Versions: Testing OSGi Mock 2.4.2 Reporter: Stefan Seifert Assignee: Stefan Seifert Fix For: Testing OSGi Mock 2.4.4 if an OSGi service is registered with BundleContext.registerService it should only be registered to the given interface class, and not to additional interface classes contained in the OSGi metadata of the service. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] rombert commented on issue #2: SLING-8029 Retrieve gpg key automatically if it is missing in keyring
rombert commented on issue #2: SLING-8029 Retrieve gpg key automatically if it is missing in keyring URL: https://github.com/apache/sling-tooling-release/pull/2#issuecomment-431372901 The worst-case scenario I'm thinking of is the following: 1. PMC member "Alice" goes on vacation. 2. Malicious actor "Charlie" creates a GPG key and pushes it to the keyserver, using Alice's email 3. Charlie breaks into Alice's Nexus account and uploads a malicious release 4. Charlie forges an email coming from Alice and starts a vote on the dev list with the malicious release 5. PMC members vote +1 on the release and the key is automatically accepted Granted, it's a pretty convoluted scenario but it only needs one weakness - the Nexus account credentials from a PMC member. Not automatically importing GPG keys would add a second layer. It might be that I'm overthinking this and that this is not a really big issue :-) But I fully agree that at least displaying the error message from GPG would be a great improvement. 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-8042) The slingfeature-maven-plugin should be able to derive the name of a feature from the file name
[
https://issues.apache.org/jira/browse/SLING-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656791#comment-16656791
]
Karl Pauls commented on SLING-8042:
---
+1
> The slingfeature-maven-plugin should be able to derive the name of a feature
> from the file name
> ---
>
> Key: SLING-8042
> URL: https://issues.apache.org/jira/browse/SLING-8042
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Reporter: Radu Cotescu
>Assignee: David Bosschaert
>Priority: Major
>
> The {{slingfeature-maven-plugin}} should be able to derive the name of a
> feature from the file name, if the name is missing from the feature
> definition.
> Assuming a file called {{my-feature.json}}, with the following contents:
> {noformat}
> {
> "id" :
> "${project.groupId}:${project.artifactId}:slingfeature:${project.version}",
> "bundles" :[
>...
> ]
> }
> {noformat}
> then the {{slingfeature-maven-plugin}} should infer that the feature it's
> building is called {{my-feature}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-8042) The slingfeature-maven-plugin should be able to derive the name of a feature from the file name
[
https://issues.apache.org/jira/browse/SLING-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656789#comment-16656789
]
Carsten Ziegeler commented on SLING-8042:
-
So my suggestion is:
* If an id is set in the feature file, group id, artifact id, version have to
match the project
* We still support the variable replacement
* If no id is set, it will be set to the group id, artifact id, version of the
project and the classifier is set to the name of the file
* if no id is set *and* the project is a slingosgifeature project *and* the
file is named "feature.json", then this becomes the main artifact
The first two are what is implemented now
> The slingfeature-maven-plugin should be able to derive the name of a feature
> from the file name
> ---
>
> Key: SLING-8042
> URL: https://issues.apache.org/jira/browse/SLING-8042
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Reporter: Radu Cotescu
>Assignee: David Bosschaert
>Priority: Major
>
> The {{slingfeature-maven-plugin}} should be able to derive the name of a
> feature from the file name, if the name is missing from the feature
> definition.
> Assuming a file called {{my-feature.json}}, with the following contents:
> {noformat}
> {
> "id" :
> "${project.groupId}:${project.artifactId}:slingfeature:${project.version}",
> "bundles" :[
>...
> ]
> }
> {noformat}
> then the {{slingfeature-maven-plugin}} should infer that the feature it's
> building is called {{my-feature}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-8042) The slingfeature-maven-plugin should be able to derive the name of a feature from the file name
[
https://issues.apache.org/jira/browse/SLING-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656780#comment-16656780
]
Karl Pauls commented on SLING-8042:
---
[~cziegeler] +1
> The slingfeature-maven-plugin should be able to derive the name of a feature
> from the file name
> ---
>
> Key: SLING-8042
> URL: https://issues.apache.org/jira/browse/SLING-8042
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Reporter: Radu Cotescu
>Assignee: David Bosschaert
>Priority: Major
>
> The {{slingfeature-maven-plugin}} should be able to derive the name of a
> feature from the file name, if the name is missing from the feature
> definition.
> Assuming a file called {{my-feature.json}}, with the following contents:
> {noformat}
> {
> "id" :
> "${project.groupId}:${project.artifactId}:slingfeature:${project.version}",
> "bundles" :[
>...
> ]
> }
> {noformat}
> then the {{slingfeature-maven-plugin}} should infer that the feature it's
> building is called {{my-feature}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-8042) The slingfeature-maven-plugin should be able to derive the name of a feature from the file name
[
https://issues.apache.org/jira/browse/SLING-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656776#comment-16656776
]
Carsten Ziegeler commented on SLING-8042:
-
[~karlpauls] That is exactly what I proposed two times now :)
A feature file must have an id - but we can relax it for maven projects. We're
already relaxing it by support variables in the id which are meaningless if
someone looks at that file out of context. So not having the id is more or less
the same but less verbose
> The slingfeature-maven-plugin should be able to derive the name of a feature
> from the file name
> ---
>
> Key: SLING-8042
> URL: https://issues.apache.org/jira/browse/SLING-8042
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Reporter: Radu Cotescu
>Assignee: David Bosschaert
>Priority: Major
>
> The {{slingfeature-maven-plugin}} should be able to derive the name of a
> feature from the file name, if the name is missing from the feature
> definition.
> Assuming a file called {{my-feature.json}}, with the following contents:
> {noformat}
> {
> "id" :
> "${project.groupId}:${project.artifactId}:slingfeature:${project.version}",
> "bundles" :[
>...
> ]
> }
> {noformat}
> then the {{slingfeature-maven-plugin}} should infer that the feature it's
> building is called {{my-feature}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-8042) The slingfeature-maven-plugin should be able to derive the name of a feature from the file name
[
https://issues.apache.org/jira/browse/SLING-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656775#comment-16656775
]
Karl Pauls commented on SLING-8042:
---
[~bosschaert], i think we are close in our thinking but why would you want to
template that at all? Why not just have the maven plugin set the id period?
> The slingfeature-maven-plugin should be able to derive the name of a feature
> from the file name
> ---
>
> Key: SLING-8042
> URL: https://issues.apache.org/jira/browse/SLING-8042
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Reporter: Radu Cotescu
>Assignee: David Bosschaert
>Priority: Major
>
> The {{slingfeature-maven-plugin}} should be able to derive the name of a
> feature from the file name, if the name is missing from the feature
> definition.
> Assuming a file called {{my-feature.json}}, with the following contents:
> {noformat}
> {
> "id" :
> "${project.groupId}:${project.artifactId}:slingfeature:${project.version}",
> "bundles" :[
>...
> ]
> }
> {noformat}
> then the {{slingfeature-maven-plugin}} should infer that the feature it's
> building is called {{my-feature}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-8042) The slingfeature-maven-plugin should be able to derive the name of a feature from the file name
[
https://issues.apache.org/jira/browse/SLING-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656759#comment-16656759
]
Karl Pauls commented on SLING-8042:
---
Well, I guess the argument was that you might want to be able to work with
features without requiring maven to build them - hence, the possibility to
specify an id. Furthermore, it is somewhat easy to see the context when you
look at the file in isolation. I personally think that is fine but it seems
like it is overkill in the cases where they are part of a maven build. Can't we
make it so that:
* features need an id
* features in a maven build don't have an id but get them set during the build
with their file name as classifier
In other words, when you look at a feature in a maven repo, it will have an id
but if you look at the src dir it will not and the maven plugin will always
just set the correct id based on the groupid/artifactid/version/classifier.
Wouldn't that be a reasonable compromise?
> The slingfeature-maven-plugin should be able to derive the name of a feature
> from the file name
> ---
>
> Key: SLING-8042
> URL: https://issues.apache.org/jira/browse/SLING-8042
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Reporter: Radu Cotescu
>Assignee: David Bosschaert
>Priority: Major
>
> The {{slingfeature-maven-plugin}} should be able to derive the name of a
> feature from the file name, if the name is missing from the feature
> definition.
> Assuming a file called {{my-feature.json}}, with the following contents:
> {noformat}
> {
> "id" :
> "${project.groupId}:${project.artifactId}:slingfeature:${project.version}",
> "bundles" :[
>...
> ]
> }
> {noformat}
> then the {{slingfeature-maven-plugin}} should infer that the feature it's
> building is called {{my-feature}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-8042) The slingfeature-maven-plugin should be able to derive the name of a feature from the file name
[
https://issues.apache.org/jira/browse/SLING-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656754#comment-16656754
]
David Bosschaert commented on SLING-8042:
-
I think that when you are looking at a feature then you should have the whole
feature, including its ID. The ID should be part of the feature declaration
IMHO.
Having said that, I have no objection to simple template style variable
substitution that is used when 'building' the feature file. As long as what is
deployed in maven as the feature has the ID in it.
Having a variable that is understood by the slingfeature-maven-plugin (e.g.
${file.name} or something like that) could be used as a placeholder. Then, once
the feature ends up in the Maven repo, all these variables are replaced with
real values and the feature there is fully defined.
> The slingfeature-maven-plugin should be able to derive the name of a feature
> from the file name
> ---
>
> Key: SLING-8042
> URL: https://issues.apache.org/jira/browse/SLING-8042
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Reporter: Radu Cotescu
>Assignee: David Bosschaert
>Priority: Major
>
> The {{slingfeature-maven-plugin}} should be able to derive the name of a
> feature from the file name, if the name is missing from the feature
> definition.
> Assuming a file called {{my-feature.json}}, with the following contents:
> {noformat}
> {
> "id" :
> "${project.groupId}:${project.artifactId}:slingfeature:${project.version}",
> "bundles" :[
>...
> ]
> }
> {noformat}
> then the {{slingfeature-maven-plugin}} should infer that the feature it's
> building is called {{my-feature}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-8042) The slingfeature-maven-plugin should be able to derive the name of a feature from the file name
[
https://issues.apache.org/jira/browse/SLING-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656753#comment-16656753
]
Carsten Ziegeler commented on SLING-8042:
-
The feature files in a project must use the coordinates of the project they are
contained in. Some things don't work if the coordinates would be different and
even if, that's more than confusion
> The slingfeature-maven-plugin should be able to derive the name of a feature
> from the file name
> ---
>
> Key: SLING-8042
> URL: https://issues.apache.org/jira/browse/SLING-8042
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Reporter: Radu Cotescu
>Assignee: David Bosschaert
>Priority: Major
>
> The {{slingfeature-maven-plugin}} should be able to derive the name of a
> feature from the file name, if the name is missing from the feature
> definition.
> Assuming a file called {{my-feature.json}}, with the following contents:
> {noformat}
> {
> "id" :
> "${project.groupId}:${project.artifactId}:slingfeature:${project.version}",
> "bundles" :[
>...
> ]
> }
> {noformat}
> then the {{slingfeature-maven-plugin}} should infer that the feature it's
> building is called {{my-feature}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-8042) The slingfeature-maven-plugin should be able to derive the name of a feature from the file name
[
https://issues.apache.org/jira/browse/SLING-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656741#comment-16656741
]
Robert Munteanu commented on SLING-8042:
I might be missing something, but declaring the id looks like it's not needed.
I assume we need the id only to reference a feature from other features.
Inferring from the file name is fine for me, and I guess the Maven plugin can
augment the feature with all the groupId/artifactId/version/etc information
automatically.
The only reason for manually setting the id is when this logic fails. I don't
see a good scenario right now. The only one I can think of is renaming the
feature or changing Maven coordinates and wanting to keep the same coordinates
for backwards compatibility. But I don't think this is really needed, even if
possible from a Maven POV.
> The slingfeature-maven-plugin should be able to derive the name of a feature
> from the file name
> ---
>
> Key: SLING-8042
> URL: https://issues.apache.org/jira/browse/SLING-8042
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Reporter: Radu Cotescu
>Assignee: David Bosschaert
>Priority: Major
>
> The {{slingfeature-maven-plugin}} should be able to derive the name of a
> feature from the file name, if the name is missing from the feature
> definition.
> Assuming a file called {{my-feature.json}}, with the following contents:
> {noformat}
> {
> "id" :
> "${project.groupId}:${project.artifactId}:slingfeature:${project.version}",
> "bundles" :[
>...
> ]
> }
> {noformat}
> then the {{slingfeature-maven-plugin}} should infer that the feature it's
> building is called {{my-feature}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-8042) The slingfeature-maven-plugin should be able to derive the name of a feature from the file name
[
https://issues.apache.org/jira/browse/SLING-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656729#comment-16656729
]
Carsten Ziegeler commented on SLING-8042:
-
We're going on circles on this one. In the past I've said several times that we
don't need the "id" at all in the feature file, but there was resistance
against this. So I stopped talking about it.
Having only half of the id in the file is even worse.
So either we leave it the way it is or we support not having the id in there at
all.
It still looks strange that I have to use maven variables just to put
information in there which is known already. These files belong to the maven
project.
> The slingfeature-maven-plugin should be able to derive the name of a feature
> from the file name
> ---
>
> Key: SLING-8042
> URL: https://issues.apache.org/jira/browse/SLING-8042
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Reporter: Radu Cotescu
>Assignee: David Bosschaert
>Priority: Major
>
> The {{slingfeature-maven-plugin}} should be able to derive the name of a
> feature from the file name, if the name is missing from the feature
> definition.
> Assuming a file called {{my-feature.json}}, with the following contents:
> {noformat}
> {
> "id" :
> "${project.groupId}:${project.artifactId}:slingfeature:${project.version}",
> "bundles" :[
>...
> ]
> }
> {noformat}
> then the {{slingfeature-maven-plugin}} should infer that the feature it's
> building is called {{my-feature}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (SLING-8042) The slingfeature-maven-plugin should be able to derive the name of a feature from the file name
[
https://issues.apache.org/jira/browse/SLING-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert reassigned SLING-8042:
---
Assignee: David Bosschaert
> The slingfeature-maven-plugin should be able to derive the name of a feature
> from the file name
> ---
>
> Key: SLING-8042
> URL: https://issues.apache.org/jira/browse/SLING-8042
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Reporter: Radu Cotescu
>Assignee: David Bosschaert
>Priority: Major
>
> The {{slingfeature-maven-plugin}} should be able to derive the name of a
> feature from the file name, if the name is missing from the feature
> definition.
> Assuming a file called {{my-feature.json}}, with the following contents:
> {noformat}
> {
> "id" :
> "${project.groupId}:${project.artifactId}:slingfeature:${project.version}",
> "bundles" :[
>...
> ]
> }
> {noformat}
> then the {{slingfeature-maven-plugin}} should infer that the feature it's
> building is called {{my-feature}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SLING-8042) The slingfeature-maven-plugin should be able to derive the name of a feature from the file name
Radu Cotescu created SLING-8042:
---
Summary: The slingfeature-maven-plugin should be able to derive
the name of a feature from the file name
Key: SLING-8042
URL: https://issues.apache.org/jira/browse/SLING-8042
Project: Sling
Issue Type: Improvement
Components: Feature Model
Reporter: Radu Cotescu
The {{slingfeature-maven-plugin}} should be able to derive the name of a
feature from the file name, if the name is missing from the feature definition.
Assuming a file called {{my-feature.json}}, with the following contents:
{noformat}
{
"id" :
"${project.groupId}:${project.artifactId}:slingfeature:${project.version}",
"bundles" :[
...
]
}
{noformat}
then the {{slingfeature-maven-plugin}} should infer that the feature it's
building is called {{my-feature}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [VOTE] Release Apache Sling Resource Resolver 1.6.8
+1 > On 18 Oct 2018, at 22:16, Karl Pauls wrote: > > Please vote to approve these releases: > > [ ] +1 Approve the releases > [ ] 0 Don't care > [ ] -1 Don't release, because ...
Re: [whiteboard] submodule deleted
Hi Radu, On Thu, Oct 18, 2018 at 10:36 PM Radu Cotescu wrote: > > On 18 Oct 2018, at 18:22, Bertrand Delacretaz > > wrote: > > I didn't know we were using submodules, why is that? > > In this context it’s because we don’t deploy the artifact from [1] anywhere, > since it’s still experimental. Hence why I decided > to make it a submodule of the scripting-resolver reactor [2]... Ok, I see, makes sense! Thanks for clarifying. -Bertrand
Re: [VOTE] Release Apache Sling Resource Resolver 1.6.8
On Thu, 2018-10-18 at 22:16 +0200, Karl Pauls wrote: > Please vote to approve these releases: +1 Robert signature.asc Description: This is a digitally signed message part
[jira] [Commented] (SLING-8038) Allow the Repository MOJO specify including features from CLI
[
https://issues.apache.org/jira/browse/SLING-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656360#comment-16656360
]
ASF GitHub Bot commented on SLING-8038:
---
cziegeler commented on issue #13: SLING-8038 - Allow the Repository MOJO
specify including features from CLI
URL:
https://github.com/apache/sling-slingfeature-maven-plugin/pull/13#issuecomment-431268901
It's a little bit hard to follow what exactly has changed. Maybe you could
redo the patch without moving code out of the existing class first. We can
later on then rename this class to AbstractXYZ
The new mojo should not be bound to any lifecycle phase, otherwise it's not
usable outside of a maven project.
In addition the only parameter it should get are mvn coordinates for the
feature, no includes, no directory etc.
The mvn coordinates can be parsed with the existing code in ArtifactId
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
> Allow the Repository MOJO specify including features from CLI
> -
>
> Key: SLING-8038
> URL: https://issues.apache.org/jira/browse/SLING-8038
> Project: Sling
> Issue Type: Improvement
>Reporter: Simone Tripodi
>Priority: Major
>
> The is a need of creating a standalone Repository, the {{RepositoryMojo}}
> does already that job, BUT requirement is having a tool which can be easily
> invoked from CLI (where the
> {{org.apache.sling.feature.maven.mojos.DependencyLifecycleParticipant}} is
> not invoked due to the fact that plugin extensions could not be enabled).
> PS is coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] cziegeler commented on issue #13: SLING-8038 - Allow the Repository MOJO specify including features from CLI
cziegeler commented on issue #13: SLING-8038 - Allow the Repository MOJO specify including features from CLI URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/13#issuecomment-431268901 It's a little bit hard to follow what exactly has changed. Maybe you could redo the patch without moving code out of the existing class first. We can later on then rename this class to AbstractXYZ The new mojo should not be bound to any lifecycle phase, otherwise it's not usable outside of a maven project. In addition the only parameter it should get are mvn coordinates for the feature, no includes, no directory etc. The mvn coordinates can be parsed with the existing code in ArtifactId 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
