[jira] [Commented] (SLING-8641) Onboard sling-feature-converter-maven-plugin to SonarCloud

[Fabrice Bellingard (Jira)]

[ 
https://issues.apache.org/jira/browse/SLING-8641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916972#comment-16916972
 ] 

Fabrice Bellingard commented on SLING-8641:
---

I can't find it, is it this one? => 
[https://github.com/apache/sling-feature-converter-maven-plugin]

> Onboard sling-feature-converter-maven-plugin to SonarCloud
> --
>
> Key: SLING-8641
> URL: https://issues.apache.org/jira/browse/SLING-8641
> Project: Sling
>  Issue Type: Task
>  Components: Feature Model
>Reporter: Andreas Schaefer
>Priority: Major
>
> [~bellingard] Can you onboard the new module 
> sling-maven-converter-maven-plugin?



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Re: [VOTE] Accept the donation of the Sling Packager tool, SLING-8584

[Karl Pauls]

+1

regards,

Karl

On Monday, August 26, 2019, Robert Munteanu  wrote:

> Hi,
>
> Please vote to accept the donation of the Sling Packager module
> described in SLING-8584 [1].
>
> This majority vote is open for at least 72 hours.
>
> Thanks,
>
> Robert
>
> [1]: https://issues.apache.org/jira/browse/SLING-8584
>
>

-- 
Karl Pauls
karlpa...@gmail.com

Re: [VOTE] Accept the donation of the Sling Packager tool, SLING-8584

[Dominik Süß]

Hi all ,

Being a fresh committee to Jackrabbit I certainly can’t speak for the rest
but historically we seperated out as much as possible concerning the http
communication.

Toby being the main developer behind vault also spent a significant time to
decouple the whole ‚frontend‘ & communication part from packagemanager &
the vault plugin when contributing.

Also the release scheme and cross dependencies wouldn’t be a good fit -
Sling is IMVHO the right home for this and if the contribution comes with
the commitment to maintain I see no real reasons to reject it.
Contributions in contrib are anyhow rather like in the incubator and time
will tell if it’s a useful tool with interest beyond the contributor or not.

Cheers
Dominik

Robert Munteanu  schrieb am Di. 27. Aug. 2019 um 17:00:

> Hi Konrad,
>
> On Tue, 2019-08-27 at 14:55 +0200, Konrad Windszus wrote:
> > For me the situation looks a bit slightly different: I raised a
> > concern in
> >
> https://lists.apache.org/thread.html/7699b02a090d0397d661721f47a6d70b72fb83ff372fafb7d45e6f5e@%3Cdev.sling.apache.org%3E
> >   > 0b72fb83ff372fafb7d45e6f5e@%3Cdev.sling.apache.org%3E> and Ruben
> > answered and I unfortunately never really followed-up on that one.
> > Still for me we haven't really reached consensus back then. I was
> > rather a bit surprised that Robert started the VOTE without
> > commenting on the mailing list thread first.
>
> I did not intend to move this quicker than people expected. I thought
> that the discussion settled down and there were no objections.
>
> The way I view this is that we cannot direct a contribution to another
> project. The contributors have received feedback that another project
> may be better suited, and decided to submit it to Sling nonetheless.
>
> Right now, as a project, we may either accept or reject the
> contribution. If we reject it, it is their choice on whether to go to
> Jackrabbit or not.
>
> My personal opinion is that there are arguments for both Sling and
> Jackrabbit hosting the contribution, but turning it down is not a good
> start :-) We have experience in migrating modules cross projects, so if
> it comes to that we should be well equipped for it.
>
> Thanks,
>
> Robert
>
>

[jira] [Resolved] (SLING-8662) Migrate the Apache Sling Scripting Bundle Tracker to sling-bundle-parent 35

[Radu Cotescu (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-8662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu resolved SLING-8662.
-
Resolution: Fixed

Fixed in [commit 
479ead9|https://github.com/apache/sling-org-apache-sling-scripting-bundle-tracker/commit/479ead9].

> Migrate the Apache Sling Scripting Bundle Tracker to sling-bundle-parent 35
> ---
>
> Key: SLING-8662
> URL: https://issues.apache.org/jira/browse/SLING-8662
> Project: Sling
>  Issue Type: Task
>  Components: Scripting
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Scripting Bundle Tracker 0.1.0
>
>
> The Apache Sling Scripting Bundle Tracker should be updated to use  
> {{sling-bundle-parent}} 35, in order to allow builds with Java 11 and beyond.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Created] (SLING-8662) Migrate the Apache Sling Scripting Bundle Tracker to sling-bundle-parent 35

[Radu Cotescu (Jira)]

Radu Cotescu created SLING-8662:
---

 Summary: Migrate the Apache Sling Scripting Bundle Tracker to 
sling-bundle-parent 35
 Key: SLING-8662
 URL: https://issues.apache.org/jira/browse/SLING-8662
 Project: Sling
  Issue Type: Task
  Components: Scripting
Reporter: Radu Cotescu
Assignee: Radu Cotescu
 Fix For: Scripting Bundle Tracker 0.1.0


The Apache Sling Scripting Bundle Tracker should be updated to use  
{{sling-bundle-parent}} 35, in order to allow builds with Java 11 and beyond.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Re: [VOTE] Accept the donation of the Sling Packager tool, SLING-8584

[Robert Munteanu]

Hi Konrad,

On Tue, 2019-08-27 at 14:55 +0200, Konrad Windszus wrote:
> For me the situation looks a bit slightly different: I raised a
> concern in 
> https://lists.apache.org/thread.html/7699b02a090d0397d661721f47a6d70b72fb83ff372fafb7d45e6f5e@%3Cdev.sling.apache.org%3E
>   0b72fb83ff372fafb7d45e6f5e@%3Cdev.sling.apache.org%3E> and Ruben
> answered and I unfortunately never really followed-up on that one.
> Still for me we haven't really reached consensus back then. I was
> rather a bit surprised that Robert started the VOTE without
> commenting on the mailing list thread first.

I did not intend to move this quicker than people expected. I thought
that the discussion settled down and there were no objections.

The way I view this is that we cannot direct a contribution to another
project. The contributors have received feedback that another project
may be better suited, and decided to submit it to Sling nonetheless.

Right now, as a project, we may either accept or reject the
contribution. If we reject it, it is their choice on whether to go to
Jackrabbit or not.

My personal opinion is that there are arguments for both Sling and
Jackrabbit hosting the contribution, but turning it down is not a good
start :-) We have experience in migrating modules cross projects, so if
it comes to that we should be well equipped for it.

Thanks,

Robert

[RESULT][VOTE] Release Apache Sling Health Check Core 2.0.0, Sling Health Check Web Console 2.0.0

[Georg Henzler]

Hi,

The vote has passed with the following result :

+1 (binding): Stefan Seifert, Radu Cotescu, Konrad Windszus, Georg 
Henzler

+1 (non binding): Andreas Schaefer

I will copy this release to the Sling dist directory and
promote the artifacts to the central Maven repository.

-Georg

On 2019-08-27 15:18, Georg Henzler wrote:

+1

On 2019-08-23 15:48, Andreas Schaefer wrote:

+1 (non-binding)

- Andy


On Aug 23, 2019, at 2:35 AM, Radu Cotescu  wrote:

+1


On 22 Aug 2019, at 19:34, Georg Henzler  wrote:

Please vote to approve this release:

[ ] +1 Approve the release
[ ]  0 Don't care
[ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Re: [VOTE] Release Apache Sling Health Check Core 2.0.0, Sling Health Check Web Console 2.0.0

[Konrad Windszus]

Makes sense. Thanks for the answer.
Here is  my +1.

> On 26. Aug 2019, at 18:12, Georg Henzler  wrote:
> 
> Interesting thought - I didn't think about using [1].
> 
> I think it is fine though, since those two bundles should
> never be referenced via maven directly - rather they are
> part of a runtime (as e.g. compiled by the provisioning
> model [2] or the feature model). For those non-pom
> references, I don't think the metadata from [1] would
> be picked up.
> 
> I included a different mechanism though: By explicitly
> referencing the new Felix HC API [3] the new bundles only
> start if the Felix API bundle is installed - so anybody
> blindly upgrading to apache-sling-hc-core|webconsole
> 2.0.0 will get unstarted bundles showing the missing
> Felix HC API package - that should be pointer enough to
> find the migration guide [4].
> 
> -Georg
> 
> 
> [1] https://maven.apache.org/guides/mini/guide-relocation.html
> 
> [2] 
> https://github.com/apache/sling-org-apache-sling-starter/blob/master/src/main/provisioning/healthcheck.txt
> 
> [3] 
> https://github.com/apache/sling-org-apache-sling-hc-core/blob/b0cfe3c8f7fdc1790f8c16bc075967f12ce33686/src/main/java/org/apache/sling/hc/core/impl/NoopHcCore.java#L33
> 
> [4] 
> https://sling.apache.org/documentation/bundles/sling-health-check-tool.html
> 
> On 2019-08-26 10:04, Konrad Windszus wrote:
>> Yes, Felix HC. This is a drop in replacement at least for these two
>> bundles IMHO (although the API package has changed).
>> Konrad
>>> On 26. Aug 2019, at 10:01, Stefan Seifert  wrote:
>>> relocate to what - felix HC?
>>> relocate makes only sense if the new target is a drop-in replacement - 
>>> which is not the case with sling HC -> felix HC?
>>> stefan
 -Original Message-
 From: Konrad Windszus [mailto:konra...@gmx.de]
 Sent: Monday, August 26, 2019 9:51 AM
 To: dev@sling.apache.org
 Subject: Re: [VOTE] Release Apache Sling Health Check Core 2.0.0, Sling
 Health Check Web Console 2.0.0
 Hi Georg,
 wouldn't it make sense to add a relocation section to this last release
 (https://maven.apache.org/guides/mini/guide-relocation.html
 )?
 That way it would be even more obvious on how to migrate...
 Konrad
> On 22. Aug 2019, at 19:34, Georg Henzler  wrote:
> Hi,
> We solved 1 issues in this release:
> https://issues.apache.org/jira/browse/SLING-8653
> There are no outstanding issues.
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-2117/
> 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 2117 /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.
> -Georg

Re: [VOTE] Release Apache Sling Health Check Core 2.0.0, Sling Health Check Web Console 2.0.0

[Georg Henzler]

+1

On 2019-08-23 15:48, Andreas Schaefer wrote:

+1 (non-binding)

- Andy


On Aug 23, 2019, at 2:35 AM, Radu Cotescu  wrote:

+1


On 22 Aug 2019, at 19:34, Georg Henzler  wrote:

Please vote to approve this release:

[ ] +1 Approve the release
[ ]  0 Don't care
[ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Re: [VOTE] Accept the donation of the Sling Packager tool, SLING-8584

[Georg Henzler]

(pressed the wrong button, sorry)

So I wanted to add that even that the discussion now is a bit late, 
looking rationally at where to put it, it just think it make sense to 
put it to Jackrabbit (@Ruben: both AEM and Composum are just UI Layers 
to the FileVault API, see e.g. [1]).


-Georg

[1] 
https://github.com/ist-dresden/composum/blob/a7ef648b3a0bd0ad1cd955f2f0c26e7c8bdaeebc/sling/core/pckginstall/src/main/java/com/composum/sling/core/pckginstall/PackageTransformer.java#L8


On 2019-08-27 15:06, Georg Henzler wrote:

Hi Carsten,

sorry for the late comment/bad timing (somehow the message in July
slipped). Also I think we all agree that the contribution itself is a
great addition.



On 2019-08-27 14:33, Carsten Ziegeler wrote:

TBH I find this conversation a little bit strange. We have a
contribution, this contribution has been made to us, the Apache Sling
project. The suggestion with contributing to Jackrabbit has been
discussed over a month ago and it seemed no one had an issue with
accepting this contribution in Sling after that.

Now, when it comes to a vote there is the suggestion to go with
Jackrabbit again.

I think this is not how we should handle contribution

Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [VOTE] Accept the donation of the Sling Packager tool, SLING-8584

[Bertrand Delacretaz]

On Tue, Aug 27, 2019 at 3:10 PM Carsten Ziegeler  wrote:
> ...I think the tool should land at the community that cares the most about
> it. Tbh, I think this is Sling at this point

+1 and that's also where it has been offered so makes sense to me.

-Bertrand

Re: [VOTE] Accept the donation of the Sling Packager tool, SLING-8584

[Carsten Ziegeler]

Thanks Konrad and Georg,

I somehow also didn't really realize that it was summer holiday at that 
time :)


I think the tool should land at the community that cares the most about 
it. Tbh, I think this is Sling at this point. And yes, we can move it to 
Jackrabbit later on if that turns out to be the better option.


Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [VOTE] Accept the donation of the Sling Packager tool, SLING-8584

[Georg Henzler]

Hi Carsten,

sorry for the late comment/bad timing (somehow the message in July 
slipped). Also I think we all agree that the contribution itself is a 
great addition.




On 2019-08-27 14:33, Carsten Ziegeler wrote:

TBH I find this conversation a little bit strange. We have a
contribution, this contribution has been made to us, the Apache Sling
project. The suggestion with contributing to Jackrabbit has been
discussed over a month ago and it seemed no one had an issue with
accepting this contribution in Sling after that.

Now, when it comes to a vote there is the suggestion to go with
Jackrabbit again.

I think this is not how we should handle contribution

Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [VOTE] Accept the donation of the Sling Packager tool, SLING-8584

[Konrad Windszus]

For me the situation looks a bit slightly different: I raised a concern in 
https://lists.apache.org/thread.html/7699b02a090d0397d661721f47a6d70b72fb83ff372fafb7d45e6f5e@%3Cdev.sling.apache.org%3E
 

 and Ruben answered and I unfortunately never really followed-up on that one. 
Still for me we haven't really reached consensus back then. I was rather a bit 
surprised that Robert started the VOTE without commenting on the mailing list 
thread first.

But I want to stress one point first:
This is a great tool and I really appreciate the contribution and won't vote 
-1. But I would still appreciate if the tool would instead be donated to 
Jackrabbit as I feel this project makes more sense as home for the plugin. But 
since Ruben does not seem to consider this as a valid option I am also fine 
with having that inside Sling for the moment.
Once Jackrabbit provides an HTTP endpoint we can think again about moving the 
project to Apache Jackrabbit.

Konrad

> On 27. Aug 2019, at 14:33, Carsten Ziegeler  wrote:
> 
> TBH I find this conversation a little bit strange. We have a contribution, 
> this contribution has been made to us, the Apache Sling project. The 
> suggestion with contributing to Jackrabbit has been discussed over a month 
> ago and it seemed no one had an issue with accepting this contribution in 
> Sling after that.
> 
> Now, when it comes to a vote there is the suggestion to go with Jackrabbit 
> again.
> 
> I think this is not how we should handle contribution
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

[Jenkins] Sling » sling-org-apache-sling-launchpad-testing » master #289 is FIXED

[Apache Jenkins Server]

Please see 
https://builds.apache.org/job/Sling/job/sling-org-apache-sling-launchpad-testing/job/master/289/
 for details.

No further emails will be sent until the status of the build is changed.

Re: [VOTE] Accept the donation of the Sling Packager tool, SLING-8584

[Carsten Ziegeler]

TBH I find this conversation a little bit strange. We have a 
contribution, this contribution has been made to us, the Apache Sling 
project. The suggestion with contributing to Jackrabbit has been 
discussed over a month ago and it seemed no one had an issue with 
accepting this contribution in Sling after that.


Now, when it comes to a vote there is the suggestion to go with 
Jackrabbit again.


I think this is not how we should handle contribution

Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[Jenkins] Sling » sling-org-apache-sling-launchpad-testing » master #290 is BROKEN

[Apache Jenkins Server]

 
- in 
org.apache.sling.launchpad.webapp.integrationtest.scripting.SlingJSPTaglibTest
[INFO] Running 
org.apache.sling.launchpad.webapp.integrationtest.NodetypeRenderingTest
[INFO] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.387 s 
- in org.apache.sling.launchpad.webapp.integrationtest.NodetypeRenderingTest
[INFO] Running org.apache.sling.launchpad.webapp.integrationtest.MkdirTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.112 s 
- in org.apache.sling.launchpad.webapp.integrationtest.MkdirTest
[INFO] 
[INFO] Results:
[INFO] 
[ERROR] Errors: 
[ERROR]   MappingEventsProxyTest.runWriteableResourcesTest:26 » JsonGeneration 
write(par...
[INFO] 
[ERROR] Tests run: 660, Failures: 0, Errors: 1, Skipped: 1
[INFO] 
[INFO] 
[INFO] --- slingstart-maven-plugin:1.7.16:stop (stop-container) @ 
org.apache.sling.launchpad.testing ---
[INFO] Stopping 1 Launchpad instances
[INFO] Stopping Launchpad '_-41000'
27.08.2019 12:26:30.851 *INFO * [Apache Sling Terminator] Java VM is shutting 
down
27.08.2019 12:26:30.851 *INFO * [Apache Sling Terminator] Stopping Apache Sling
27.08.2019 12:26:37.630 *INFO * [Sling Notifier] Apache Sling has been stopped
[INFO] 
[INFO] --- ianal-maven-plugin:1.0-alpha-1:verify-legal-files (default) @ 
org.apache.sling.launchpad.testing ---
[INFO] Checking legal files in: 
org.apache.sling.launchpad.testing-12-SNAPSHOT.jar
[INFO] Checking legal files in: 
org.apache.sling.launchpad.testing-12-SNAPSHOT-sources.jar
[INFO] 
[INFO] --- apache-rat-plugin:0.11:check (default) @ 
org.apache.sling.launchpad.testing ---
[INFO] 51 implicit excludes (use -debug for more details).
[INFO] Exclude: DEPENDENCIES
[INFO] Exclude: src/main/appended-resources/META-INF/*
[INFO] Exclude: velocity.log
[INFO] Exclude: target/*
[INFO] Exclude: README.md
[INFO] Exclude: maven-eclipse.xml
[INFO] Exclude: .*
[INFO] Exclude: .*/**
[INFO] Exclude: **/*.json
[INFO] Exclude: DEPENDENCIES
[INFO] Exclude: **/*.rej
[INFO] Exclude: hs_err_*.log
[INFO] Exclude: **/repository/index/*/index-details.txt
[INFO] Exclude: bnd.bnd
[INFO] 7 resources included (use -debug for more details)
[INFO] Rat check: Summary of files. Unapproved: 0 unknown: 0 generated: 0 
approved: 6 licence.
[INFO] 
[INFO] --- maven-failsafe-plugin:2.21.0:verify (default) @ 
org.apache.sling.launchpad.testing ---
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  03:32 min
[INFO] Finished at: 2019-08-27T12:26:38Z
[INFO] 
[INFO] [jenkins-event-spy] Generated 
/home/jenkins/jenkins-slave/workspace/e-sling-launchpad-testing_master@tmp/withMaven2255c05f/maven-spy-20190827-122306-291776247942159333258.log
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-failsafe-plugin:2.21.0:verify (default) on 
project org.apache.sling.launchpad.testing: There are test failures.
[ERROR] 
[ERROR] Please refer to 
/home/jenkins/jenkins-slave/workspace/e-sling-launchpad-testing_master/target/failsafe-reports
 for the individual test results.
[ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump, 
[date].dumpstream and [date]-jvmRun[N].dumpstream.
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[Pipeline] }
[withMaven] junitPublisher - Archive test results for Maven artifact 
org.apache.sling:org.apache.sling.launchpad.testing:slingstart:12-SNAPSHOT 
generated by maven-surefire-plugin:test (default-test): 
target/surefire-reports/*.xml
Recording test results
None of the test reports contained any result
[withMaven] junitPublisher - Archive test results for Maven artifact 
org.apache.sling:org.apache.sling.launchpad.testing:slingstart:12-SNAPSHOT 
generated by maven-failsafe-plugin:integration-test (default): 
target/failsafe-reports/*.xml
Recording test results
[withMaven] Publishers: Pipeline Graph Publisher: 6 ms, Generated Artifacts 
Publisher: 606 ms, Junit Publisher: 68107 ms, Dependencies Fingerprint 
Publisher: 2278 ms, JGiven Publisher: 1 ms, Open Task Scanner Publisher: 153 ms
[Pipeline] // withMaven
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // timeout
[Pipeline] stage
[Pipeline] { (Notifications)
[Pipeline] echo
Status change is BROKEN, notifications will be sent.
[Pipeline] emailext

Re: [VOTE] Accept the donation of the Sling Packager tool, SLING-8584

[Ruben Reusser]

the slingpackager is meant to work against content management systems 
built on sling. It currently supports package managers by


- Composum
- AEM

If there are other package managers in the future I'd love to add 
support for them as well.


We interact with sling to install packages, not with jackrabbit. My 
preference would still be to include this in sling :-) (who knows, 
maybe some day sling decides not to run on jackrabbit anymore - the 
sling packager could then be transformed to support the new 
format/other endpoints)


Ruben

On Tue, Aug 27, 2019 at 2:32 AM, Konrad Windszus  
wrote:

I fully agree with that statement.
Actually there is already a task at FileVault to have an installation 
endpoint (accompanied by a branch): 
 
<>


For all those reasons I would also rather like to see this addition 
to Apache Jackrabbit.

Konrad



 On 27. Aug 2019, at 11:25, Georg Henzler > wrote:


 Hi,

 I also have my doubts... reasoning to have it in Sling from [2]:

 since the tool packages and deploys it is dependent 
Jackrabbit-Vault for

 the package format and on Apache Sling and Composum for the
 upload/install/list/uninstall/delete endpoint. I'd honestly much 
prefer

 for it to be an Apache Sling module.


 Composum [3] is included in the sling starter but not actually 
maintained
 as part of Sling. I'm not aware of any dependency the packager 
would have
 to Sling, so I think the Jackrabbit project would make a lot more 
sense to
 host the Packager tool. For instance, people not using Sling but 
only
 Jackrabbit could use it, also maybe at some point somebody will 
eventually
 create an Open Source Package Manager there (to provide the simple 
endpoints
 for upload/install/list/uninstall/delete without UI would be 
actually really

 easy, maybe it's a good time to do this now :)

 -Georg

 [3] 

[jira] [Commented] (SLING-8655) Add an Annotation to Sling Model to mark a property to be Externalized

[Ruben Reusser (Jira)]

[ 
https://issues.apache.org/jira/browse/SLING-8655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916636#comment-16916636
 ] 

Ruben Reusser commented on SLING-8655:
--

[~vladb] [~sseifert] [~radu.cotescu] we are mostly looking to externalize for 
an SPA use case - it looks like [~vladb]'s suggestion would work well for that 
- Does it still make sense to add the suggested ExternalizedSerializer to Sling 
as this is probably a use case most client side rendered web apps/sites will 
face at one point?

> Add an Annotation to Sling Model to mark a property to be Externalized
> --
>
> Key: SLING-8655
> URL: https://issues.apache.org/jira/browse/SLING-8655
> Project: Sling
>  Issue Type: New Feature
>  Components: Sling Models
>Affects Versions: Sling Models API 1.3.8
>Reporter: Andreas Schaefer
>Assignee: Andreas Schaefer
>Priority: Major
> Fix For: Sling Models API 1.3.10
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> For Peregrine CMS we use Sling Models to obtain data in JSon format to be 
> rendered on the client side. This means that the returned content is not 
> externalized aka paths are not mapped to the external view.
> Sling Model should have an Annotation (@ExternalizedPath) that marks a 
> property to be externalized when loaded.
> In order to be flexible the Externalized Path Injector should be pluggable so 
> that customers can add their custom Externalized Path Providers if they 
> choose to do so. By default there is a provider that uses the Resource 
> Resolver's map() function.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Re: [VOTE] Accept the donation of the Sling Packager tool, SLING-8584

[Konrad Windszus]

I fully agree with that statement.
Actually there is already a task at FileVault to have an installation endpoint 
(accompanied by a branch): https://issues.apache.org/jira/browse/JCRVLT-151 


For all those reasons I would also rather like to see this addition to Apache 
Jackrabbit.
Konrad



> On 27. Aug 2019, at 11:25, Georg Henzler  wrote:
> 
> Hi,
> 
> I also have my doubts... reasoning to have it in Sling from [2]:
> 
>> since the tool packages and deploys it is dependent Jackrabbit-Vault for
>> the package format and on Apache Sling and Composum for the
>> upload/install/list/uninstall/delete endpoint. I'd honestly much prefer
>> for it to be an Apache Sling module.
> 
> Composum [3] is included in the sling starter but not actually maintained
> as part of Sling. I'm not aware of any dependency the packager would have
> to Sling, so I think the Jackrabbit project would make a lot more sense to
> host the Packager tool. For instance, people not using Sling but only
> Jackrabbit could use it, also maybe at some point somebody will eventually
> create an Open Source Package Manager there (to provide the simple endpoints
> for upload/install/list/uninstall/delete without UI would be actually really
> easy, maybe it's a good time to do this now :)
> 
> -Georg
> 
> [3] https://github.com/ist-dresden/composum
> 
> 
> On 2019-08-27 11:04, Robert Munteanu wrote:
>> Hi Stefan,
>> On Tue, 2019-08-27 at 08:49 +, Stefan Seifert wrote:
>>> i'm not against adding it to sling, but maybe the jackrabbit project
>>> would also be a good place for it? alongside with [1]?
>> This was (summarily) discussed at [2]. Don't have a strong opinion
>> either way, just relaying the answer :-)
>> Thanks,
>> Robert
>>> stefan
>>> [1] http://jackrabbit.apache.org/filevault-package-maven-plugin/
>> [2]:
>> https://lists.apache.org/thread.html/8e417968d0b4ecaa3eb3bd321b13629b86f59c5e2b20284f138119b0@%3Cdev.sling.apache.org%3E
>>> > -Original Message-
>>> > From: Robert Munteanu 
>>> > Sent: Monday, August 26, 2019 4:43 PM
>>> > To: dev@sling.apache.org
>>> > Subject: [VOTE] Accept the donation of the Sling Packager tool,
>>> > SLING-8584
>>> >
>>> > Hi,
>>> >
>>> > Please vote to accept the donation of the Sling Packager module
>>> > described in SLING-8584 [1].
>>> >
>>> > This majority vote is open for at least 72 hours.
>>> >
>>> > Thanks,
>>> >
>>> > Robert
>>> >
>>> > [1]: https://issues.apache.org/jira/browse/SLING-8584
>>> >

Re: [VOTE] Accept the donation of the Sling Packager tool, SLING-8584

[Georg Henzler]

Hi,

I also have my doubts... reasoning to have it in Sling from [2]:

since the tool packages and deploys it is dependent Jackrabbit-Vault 
for

the package format and on Apache Sling and Composum for the
upload/install/list/uninstall/delete endpoint. I'd honestly much prefer
for it to be an Apache Sling module.


Composum [3] is included in the sling starter but not actually 
maintained
as part of Sling. I'm not aware of any dependency the packager would 
have
to Sling, so I think the Jackrabbit project would make a lot more sense 
to

host the Packager tool. For instance, people not using Sling but only
Jackrabbit could use it, also maybe at some point somebody will 
eventually
create an Open Source Package Manager there (to provide the simple 
endpoints
for upload/install/list/uninstall/delete without UI would be actually 
really

easy, maybe it's a good time to do this now :)

-Georg

[3] https://github.com/ist-dresden/composum


On 2019-08-27 11:04, Robert Munteanu wrote:

Hi Stefan,

On Tue, 2019-08-27 at 08:49 +, Stefan Seifert wrote:

i'm not against adding it to sling, but maybe the jackrabbit project
would also be a good place for it? alongside with [1]?


This was (summarily) discussed at [2]. Don't have a strong opinion
either way, just relaying the answer :-)

Thanks,

Robert



stefan

[1] http://jackrabbit.apache.org/filevault-package-maven-plugin/


[2]:
https://lists.apache.org/thread.html/8e417968d0b4ecaa3eb3bd321b13629b86f59c5e2b20284f138119b0@%3Cdev.sling.apache.org%3E



> -Original Message-
> From: Robert Munteanu 
> Sent: Monday, August 26, 2019 4:43 PM
> To: dev@sling.apache.org
> Subject: [VOTE] Accept the donation of the Sling Packager tool,
> SLING-8584
>
> Hi,
>
> Please vote to accept the donation of the Sling Packager module
> described in SLING-8584 [1].
>
> This majority vote is open for at least 72 hours.
>
> Thanks,
>
> Robert
>
> [1]: https://issues.apache.org/jira/browse/SLING-8584
>

RE: [VOTE] Accept the donation of the Sling Packager tool, SLING-8584

[Stefan Seifert]

ah, ok - then +1

stean

>-Original Message-
>From: Robert Munteanu 
>Sent: Tuesday, August 27, 2019 11:05 AM
>To: dev@sling.apache.org
>Subject: Re: [VOTE] Accept the donation of the Sling Packager tool, SLING-
>8584
>
>Hi Stefan,
>
>On Tue, 2019-08-27 at 08:49 +, Stefan Seifert wrote:
>> i'm not against adding it to sling, but maybe the jackrabbit project
>> would also be a good place for it? alongside with [1]?
>
>This was (summarily) discussed at [2]. Don't have a strong opinion
>either way, just relaying the answer :-)
>
>Thanks,
>
>Robert
>
>>
>> stefan
>>
>> [1] http://jackrabbit.apache.org/filevault-package-maven-plugin/
>
>[2]:
>https://lists.apache.org/thread.html/8e417968d0b4ecaa3eb3bd321b13629b86f59c5e
>2b20284f138119b0@%3Cdev.sling.apache.org%3E
>>
>>
>> > -Original Message-
>> > From: Robert Munteanu 
>> > Sent: Monday, August 26, 2019 4:43 PM
>> > To: dev@sling.apache.org
>> > Subject: [VOTE] Accept the donation of the Sling Packager tool,
>> > SLING-8584
>> >
>> > Hi,
>> >
>> > Please vote to accept the donation of the Sling Packager module
>> > described in SLING-8584 [1].
>> >
>> > This majority vote is open for at least 72 hours.
>> >
>> > Thanks,
>> >
>> > Robert
>> >
>> > [1]: https://issues.apache.org/jira/browse/SLING-8584
>> >
>

Re: [VOTE] Accept the donation of the Sling Packager tool, SLING-8584

[Robert Munteanu]

Hi Stefan,

On Tue, 2019-08-27 at 08:49 +, Stefan Seifert wrote:
> i'm not against adding it to sling, but maybe the jackrabbit project
> would also be a good place for it? alongside with [1]?

This was (summarily) discussed at [2]. Don't have a strong opinion
either way, just relaying the answer :-)

Thanks,

Robert

> 
> stefan
> 
> [1] http://jackrabbit.apache.org/filevault-package-maven-plugin/

[2]: 
https://lists.apache.org/thread.html/8e417968d0b4ecaa3eb3bd321b13629b86f59c5e2b20284f138119b0@%3Cdev.sling.apache.org%3E
> 
> 
> > -Original Message-
> > From: Robert Munteanu 
> > Sent: Monday, August 26, 2019 4:43 PM
> > To: dev@sling.apache.org
> > Subject: [VOTE] Accept the donation of the Sling Packager tool,
> > SLING-8584
> > 
> > Hi,
> > 
> > Please vote to accept the donation of the Sling Packager module
> > described in SLING-8584 [1].
> > 
> > This majority vote is open for at least 72 hours.
> > 
> > Thanks,
> > 
> > Robert
> > 
> > [1]: https://issues.apache.org/jira/browse/SLING-8584
> > 

RE: [VOTE] Accept the donation of the Sling Packager tool, SLING-8584

[Stefan Seifert]

i'm not against adding it to sling, but maybe the jackrabbit project would also 
be a good place for it? alongside with [1]?

stefan

[1] http://jackrabbit.apache.org/filevault-package-maven-plugin/


>-Original Message-
>From: Robert Munteanu 
>Sent: Monday, August 26, 2019 4:43 PM
>To: dev@sling.apache.org
>Subject: [VOTE] Accept the donation of the Sling Packager tool, SLING-8584
>
>Hi,
>
>Please vote to accept the donation of the Sling Packager module
>described in SLING-8584 [1].
>
>This majority vote is open for at least 72 hours.
>
>Thanks,
>
>Robert
>
>[1]: https://issues.apache.org/jira/browse/SLING-8584
>

[jira] [Commented] (SLING-8655) Add an Annotation to Sling Model to mark a property to be Externalized

[Stefan Seifert (Jira)]

[ 
https://issues.apache.org/jira/browse/SLING-8655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916523#comment-16916523
 ] 

Stefan Seifert commented on SLING-8655:
---

yes, i'm also unsure if a PR like this does not fall too short once hitting 
real life link resolving and externalization needs - multi tenancy aware etc. 
it can be much more than just adding a hostname and a ".html" suffix.

we usually do it in the model code - calling a central piece of logic that does 
the resolving, validation, externalization stuff. what is required in detail 
may differ from use case to use case - internal, external links, asset links, 
resources, with selectors etc.

> Add an Annotation to Sling Model to mark a property to be Externalized
> --
>
> Key: SLING-8655
> URL: https://issues.apache.org/jira/browse/SLING-8655
> Project: Sling
>  Issue Type: New Feature
>  Components: Sling Models
>Affects Versions: Sling Models API 1.3.8
>Reporter: Andreas Schaefer
>Assignee: Andreas Schaefer
>Priority: Major
> Fix For: Sling Models API 1.3.10
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> For Peregrine CMS we use Sling Models to obtain data in JSon format to be 
> rendered on the client side. This means that the returned content is not 
> externalized aka paths are not mapped to the external view.
> Sling Model should have an Annotation (@ExternalizedPath) that marks a 
> property to be externalized when loaded.
> In order to be flexible the Externalized Path Injector should be pluggable so 
> that customers can add their custom Externalized Path Providers if they 
> choose to do so. By default there is a provider that uses the Resource 
> Resolver's map() function.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Re: [VOTE] Release Apache Sling Starter Content 1.0.6, Apache Sling Dynamic Include 3.1.6, Apache Sling Form Based Authentication 1.0.16

[Robert Munteanu]

On Mon, 2019-08-26 at 15:24 +, Robert Munteanu wrote:
> Please vote to approve this release:

+1

Robert


signature.asc
Description: This is a digitally signed message part

Re: [VOTE] Accept the donation of the Sling Packager tool, SLING-8584

[Robert Munteanu]

On Mon, 2019-08-26 at 16:42 +0200, Robert Munteanu wrote:
> Please vote to accept the donation of the Sling Packager module
> described in SLING-8584 [1].

+1

Robert


signature.asc
Description: This is a digitally signed message part

[jira] [Commented] (SLING-8655) Add an Annotation to Sling Model to mark a property to be Externalized

[Vlad Bailescu (Jira)]

[ 
https://issues.apache.org/jira/browse/SLING-8655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916506#comment-16916506
 ] 

Vlad Bailescu commented on SLING-8655:
--

Since externalization is mostly related to the view part (of the MVC), I would 
rather we don't introduce this injector. The raw path can then be used, as 
usual, to get a hold of the resource it points to, while externalization is 
done when rendering the model:

* for HTML, using HTL: something like {code}${model.pagePath @ externalized} 
{code}
* for JSON, using a dedicated serializer: {code}@JsonSerialize(using = 
ExternalizedSerializer.class){code}

> Add an Annotation to Sling Model to mark a property to be Externalized
> --
>
> Key: SLING-8655
> URL: https://issues.apache.org/jira/browse/SLING-8655
> Project: Sling
>  Issue Type: New Feature
>  Components: Sling Models
>Affects Versions: Sling Models API 1.3.8
>Reporter: Andreas Schaefer
>Assignee: Andreas Schaefer
>Priority: Major
> Fix For: Sling Models API 1.3.10
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> For Peregrine CMS we use Sling Models to obtain data in JSon format to be 
> rendered on the client side. This means that the returned content is not 
> externalized aka paths are not mapped to the external view.
> Sling Model should have an Annotation (@ExternalizedPath) that marks a 
> property to be externalized when loaded.
> In order to be flexible the Externalized Path Injector should be pluggable so 
> that customers can add their custom Externalized Path Providers if they 
> choose to do so. By default there is a provider that uses the Resource 
> Resolver's map() function.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Comment Edited] (SLING-8655) Add an Annotation to Sling Model to mark a property to be Externalized

[Radu Cotescu (Jira)]

[ 
https://issues.apache.org/jira/browse/SLING-8655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916503#comment-16916503
 ] 

Radu Cotescu edited comment on SLING-8655 at 8/27/19 8:10 AM:
--

[~schaefa], I quickly reviewed the PRs and I'm not really convinced we need an 
injector + a new API for this use-case. IMO link externalization cannot be 
solved with a one-bullet solution. It's a personal opinion, but I really like 
what Provision has done at [1] and I think that externalization is a 
site-specific task (contrary to instance-specific). Continuing this reasoning, 
I'd suggest to handle externalization directly in the application code. (cc 
[~sseifert])

For JSON you could build your own JSON serializer and mark the path properties 
as being serialized with it.

[1] - [https://wcm.io/handler/url/general-concepts.html]


was (Author: radu.cotescu):
[~schaefa], I quickly reviewed the PRs and I'm not really convinced we need an 
injector + a new API for this use-case. IMO link externalization cannot be 
solved with a one-bullet solution. It's a personal opinion, but I really like 
what Provision has done at [1] and I think that externalization is a 
site-specific task (contrary to instance-specific). Continuing this reasoning, 
I'd suggest to handle externalization directly in the application code.

For JSON you could build your own JSON serializer and mark the path properties 
as being serialized with it.

[1] - [https://wcm.io/handler/url/general-concepts.html]

> Add an Annotation to Sling Model to mark a property to be Externalized
> --
>
> Key: SLING-8655
> URL: https://issues.apache.org/jira/browse/SLING-8655
> Project: Sling
>  Issue Type: New Feature
>  Components: Sling Models
>Affects Versions: Sling Models API 1.3.8
>Reporter: Andreas Schaefer
>Assignee: Andreas Schaefer
>Priority: Major
> Fix For: Sling Models API 1.3.10
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> For Peregrine CMS we use Sling Models to obtain data in JSon format to be 
> rendered on the client side. This means that the returned content is not 
> externalized aka paths are not mapped to the external view.
> Sling Model should have an Annotation (@ExternalizedPath) that marks a 
> property to be externalized when loaded.
> In order to be flexible the Externalized Path Injector should be pluggable so 
> that customers can add their custom Externalized Path Providers if they 
> choose to do so. By default there is a provider that uses the Resource 
> Resolver's map() function.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Commented] (SLING-8655) Add an Annotation to Sling Model to mark a property to be Externalized

[Radu Cotescu (Jira)]

[ 
https://issues.apache.org/jira/browse/SLING-8655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916503#comment-16916503
 ] 

Radu Cotescu commented on SLING-8655:
-

[~schaefa], I quickly reviewed the PRs and I'm not really convinced we need an 
injector + a new API for this use-case. IMO link externalization cannot be 
solved with a one-bullet solution. It's a personal opinion, but I really like 
what Provision has done at [1] and I think that externalization is a 
site-specific task (contrary to instance-specific). Continuing this reasoning, 
I'd suggest to handle externalization directly in the application code.

For JSON you could build your own JSON serializer and mark the path properties 
as being serialized with it.

[1] - [https://wcm.io/handler/url/general-concepts.html]

> Add an Annotation to Sling Model to mark a property to be Externalized
> --
>
> Key: SLING-8655
> URL: https://issues.apache.org/jira/browse/SLING-8655
> Project: Sling
>  Issue Type: New Feature
>  Components: Sling Models
>Affects Versions: Sling Models API 1.3.8
>Reporter: Andreas Schaefer
>Assignee: Andreas Schaefer
>Priority: Major
> Fix For: Sling Models API 1.3.10
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> For Peregrine CMS we use Sling Models to obtain data in JSon format to be 
> rendered on the client side. This means that the returned content is not 
> externalized aka paths are not mapped to the external view.
> Sling Model should have an Annotation (@ExternalizedPath) that marks a 
> property to be externalized when loaded.
> In order to be flexible the Externalized Path Injector should be pluggable so 
> that customers can add their custom Externalized Path Providers if they 
> choose to do so. By default there is a provider that uses the Resource 
> Resolver's map() function.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Re: [VOTE] Release Apache Sling Starter Content 1.0.6, Apache Sling Dynamic Include 3.1.6, Apache Sling Form Based Authentication 1.0.16

[Radu Cotescu]

+1

> On 26 Aug 2019, at 17:24, Robert Munteanu  wrote:
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This majority vote is open for at least 72 hours.

Re: [VOTE] Accept the donation of the Sling Packager tool, SLING-8584

[Radu Cotescu]

+1

> On 26 Aug 2019, at 16:42, Robert Munteanu  wrote:
> 
> Please vote to accept the donation of the Sling Packager module
> described in SLING-8584 [1].

Re: Release Validator Docker Image

[Radu Cotescu]

Hi Daniel,

> On 23 Aug 2019, at 14:59, Daniel Klco  wrote:
> 
> I'm just not convinced of the
> value re-implementing in Java brings vs a few simple bash commands.

Sure, it’s more work to do, but you’d benefit from a nice command line menu and 
we would unify the tooling. Here are a few examples:

$ docker run -it --env-file=./docker-env apache/sling-cli
Usage: docker run -it --env-file=./docker-env apache/sling-cli [COMMAND]
Apache Sling Committers CLI
Commands:
  help Displays help information about the specified command
  release  Performs release-related operations



$ docker run -it --env-file=./docker-env apache/sling-cli release help
Usage: docker run -it --env-file=./docker-env apache/sling-cli release [COMMAND]
Performs release-related operations
Commands:
  create-new-jira-version  Creates a new Jira version, if needed, and 
transitions any unresolved issues from the version being released to
 the next one
  list Lists all open releases
  prepare-emailPrepares an email vote for the releases found in the 
Nexus staged repository
  tally-votes  Counts votes cast for a release and generates the 
result email
  update-local-siteUpdates the Sling website with the new release 
information, based on a local checkout
  update-reporter  Updates the Apache Reporter System with the new 
release information
  help Displays help information about the specified command



$ docker run -it --env-file=./docker-env apache/sling-cli release prepare-email 
help
Usage: docker run -it --env-file=./docker-env apache/sling-cli release 
prepare-email -r= [-x=] [COMMAND]
Prepares an email vote for the releases found in the Nexus staged repository
  -r, --repository=
 Nexus repository id
  -x, --execution-mode=
 execution mode: DRY_RUN, INTERACTIVE, AUTO; default: DRY_RUN
Commands:
  help  Displays help information about the specified command



To help with this I’ve already pushed some code for verifying release 
signatures in a branch [2], which could easily be integrated with the rest. 
Checking build status is trivial by comparison.

Regards,
Radu

[2] - 
https://github.com/apache/sling-org-apache-sling-committer-cli/commit/1c6ea560ddd03947c0fd0b4e14104a1db13b55d6