[jira] [Created] (SLING-8693) Additional support for Anonymous v/s loggedin user experiences

[Mayank Arora (Jira)]

Mayank Arora created SLING-8693:
---

 Summary: Additional support for Anonymous v/s loggedin user 
experiences
 Key: SLING-8693
 URL: https://issues.apache.org/jira/browse/SLING-8693
 Project: Sling
  Issue Type: Improvement
Reporter: Mayank Arora


I am using SDI heavily for my current project but unable to achieve a usecase.  
Not sure if this is currently a product gap or something not covered in 
documentation.

Usecase is that there is a dynamic component on a page for which content is 
personalized per logged-in user and returned from an API. So, I have specified 
no-cache for this component (resource type) in SDI config.

A variation of this usecase is if the User is not logged in, then all anonymous 
users see static/authored content for this component, which we want to cache. 
Traffic we are seeing is 50% anonymous v/s logged-in users, so there is a great 
benefit if we can cache static/authored content for this component for 
anonymous users. As per SDI configuration, I am unable to find a way where for 
this component (specific resourceType), using SSI, I can achieve no-cache for 
logged-in users v/s cache for anonymous users.

Logging this as a feature request / documentation update request. Is this . 
usecase currently possible in SDI?



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

Re: Release Validator Docker Image

[Carsten Ziegeler]

Sounds good to me, with the addition that it does not upload the md5 
files to SVN and only creates the sha256 (or sha512?) if the check of 
the files is successful


Carsten

Am 10.09.2019 um 23:33 schrieb Robert Munteanu:

On Tue, 2019-09-10 at 22:57 +0200, Carsten Ziegeler wrote:

I think the value is already there today, we push manually to dist
and
having the sha512 there and not the md5 is already a win.
It would be great to have this mirrored in the maven repository, but
that probably needs those bugs to be fixed.


So my proposal, echoing discussions at the hackathon would be to
implement a command that publishes a release to dist and that:

- downloads the release artifacts from Nexus (already covered by
existing command)
- computes SHA-256 checksums and adds them to the files to be deployed
- uses the Java API equivalent of `svn remove https://dist.apache.org/
...` to remove all old artifacts of a release
- uses the Java API equivalent of `svn import .
https://dist.apache.org/ ...` to import local set of artifacts to SVN

Would that cover everyone's needs for pushing to dist?

Robert



Carsten

Am 10.09.2019 um 13:16 schrieb Radu Cotescu:

Hi Carsten,


On 9 Sep 2019, at 19:29, Carsten Ziegeler 
wrote:

Can we maybe also remove the md5 files and create sha512 files,
when the checksum is correct?



The sha1 and md5 files seem to be generated by Nexus and not by our
Maven release process. I quickly checked how the sha512 files are
generated and this seems to be a config in the Apache parent pom
[4]. However, those are not attached [5] to the build, most
probably due to [6].

I guess we can create the sha512 files with this CLI tool, but the
value would come only when we’d be able to push the staged
artifacts to dist.

Cheers,
Radu

[4] -
https://github.com/apache/maven-apache-parent/blob/apache-21/pom.xml#L440
<
https://github.com/apache/maven-apache-parent/blob/apache-21/pom.xml#L440



[5] -
https://checksum-maven-plugin.nicoulaj.net/files-mojo.html#attachChecksums
<
https://checksum-maven-plugin.nicoulaj.net/files-mojo.html#attachChecksums>[6
] - https://issues.apache.org/jira/browse/INFRA-14923 <
https://issues.apache.org/jira/browse/INFRA-14923>





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

Re: Release Validator Docker Image

[Robert Munteanu]

On Tue, 2019-09-10 at 22:57 +0200, Carsten Ziegeler wrote:
> I think the value is already there today, we push manually to dist
> and 
> having the sha512 there and not the md5 is already a win.
> It would be great to have this mirrored in the maven repository, but 
> that probably needs those bugs to be fixed.

So my proposal, echoing discussions at the hackathon would be to
implement a command that publishes a release to dist and that:

- downloads the release artifacts from Nexus (already covered by
existing command)
- computes SHA-256 checksums and adds them to the files to be deployed
- uses the Java API equivalent of `svn remove https://dist.apache.org/
...` to remove all old artifacts of a release
- uses the Java API equivalent of `svn import . 
https://dist.apache.org/ ...` to import local set of artifacts to SVN

Would that cover everyone's needs for pushing to dist?

Robert

> 
> Carsten
> 
> Am 10.09.2019 um 13:16 schrieb Radu Cotescu:
> > Hi Carsten,
> > 
> > > On 9 Sep 2019, at 19:29, Carsten Ziegeler 
> > > wrote:
> > > 
> > > Can we maybe also remove the md5 files and create sha512 files,
> > > when the checksum is correct?
> > > 
> > 
> > The sha1 and md5 files seem to be generated by Nexus and not by our
> > Maven release process. I quickly checked how the sha512 files are
> > generated and this seems to be a config in the Apache parent pom
> > [4]. However, those are not attached [5] to the build, most
> > probably due to [6].
> > 
> > I guess we can create the sha512 files with this CLI tool, but the
> > value would come only when we’d be able to push the staged
> > artifacts to dist.
> > 
> > Cheers,
> > Radu
> > 
> > [4] - 
> > https://github.com/apache/maven-apache-parent/blob/apache-21/pom.xml#L440
> > <
> > https://github.com/apache/maven-apache-parent/blob/apache-21/pom.xml#L440
> > >
> > [5] - 
> > https://checksum-maven-plugin.nicoulaj.net/files-mojo.html#attachChecksums
> > <
> > https://checksum-maven-plugin.nicoulaj.net/files-mojo.html#attachChecksums>[6
> > ] - https://issues.apache.org/jira/browse/INFRA-14923 <
> > https://issues.apache.org/jira/browse/INFRA-14923>
> > 

Re: Release Validator Docker Image

[Carsten Ziegeler]

I think the value is already there today, we push manually to dist and 
having the sha512 there and not the md5 is already a win.
It would be great to have this mirrored in the maven repository, but 
that probably needs those bugs to be fixed.


Carsten

Am 10.09.2019 um 13:16 schrieb Radu Cotescu:

Hi Carsten,


On 9 Sep 2019, at 19:29, Carsten Ziegeler  wrote:

Can we maybe also remove the md5 files and create sha512 files, when the 
checksum is correct?



The sha1 and md5 files seem to be generated by Nexus and not by our Maven 
release process. I quickly checked how the sha512 files are generated and this 
seems to be a config in the Apache parent pom [4]. However, those are not 
attached [5] to the build, most probably due to [6].

I guess we can create the sha512 files with this CLI tool, but the value would 
come only when we’d be able to push the staged artifacts to dist.

Cheers,
Radu

[4] - https://github.com/apache/maven-apache-parent/blob/apache-21/pom.xml#L440 

[5] - https://checksum-maven-plugin.nicoulaj.net/files-mojo.html#attachChecksums 
[6] - 
https://issues.apache.org/jira/browse/INFRA-14923 




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

Re: Why get rid of the rewriter?

[Carsten Ziegeler]

Sounds good to me, now for the rewriter I would like to have something 
more special geared towards html thank a generic thing like SAX. So 
basically instead of getting the information that the element name is 
"a" and then you have to figure out that this is a link, you already get 
the information this is a "LINK" or a "SRC" or whatever.


Regards
Carsten

Am 10.09.2019 um 18:37 schrieb Stefan Seifert:

i try to write a first summary:

- we have good use cases for a rewriter in general, but are unhappy with the current 
implementation and it's way of configuration. the whole thing is a bit "alien" 
to the other parts of sling.

- a new rewriter implementation should be performant and with up-to-date 
support for modern HTML. ideally something like SAX for HTML (not XML/XHTML). 
this would not cover other use cases producing something other than HTML, 
though. perhaps there are libraries out there that can be built upon. should 
also provide modular support, e.g. rewriting only the output of a single 
component or text fragment. maybe someone can come up with a proposal.

- we have to keep the old rewriter for backward compatibility because it was 
used a lot in the past, but do not plan to maintain it further and probably 
will remove it from the sling starter as well. mark it as deprecated or contrib.

- we do no longer want to use the rewriter for link validation and 
externalization, but support this as aspect in another, more appropriate way 
(with some basic support or hooks/SPIs from Sling itself, the rest is more up 
to upstream layers). we have currently only very rough ideas here, a proposal 
needs to be draftet as well.

stefan


-Original Message-
From: Jason E Bailey [mailto:jason.bai...@24601.org]
Sent: Tuesday, September 10, 2019 6:09 PM
To: dev@sling.apache.org
Subject: Re: Why get rid of the rewriter?

I'm positive towards the concept of the rewriter, a utility that provides
centralized features that addresses cross-cutting concerns with user
generated content.

I'm not a fan of the current implementation of the rewriter.

1.  As Ruben pointed out, as of HTML5  html doesn't have anything to do
with XML. There is no concept of namespace in HTML now. There is no self
closing tag. There may not be an end tag. There is a concept of implied
parent tags.

2. TagSoup, which is currently used to parse the HTML, requires  fully
cached content and will attempt to validate the content and add to it,
where appropriate. Which isn't necessary.

3. The Rewriter requires the pipeline configuration to be in a specific
place with a specific name which is inflexible and contrary to other tools
we use.


The point being that I would prefer to have the rewriter implementation
deprecated in favor of a more up to date solution then having the concept
of the rewriter deprecated.



--
Jason

On Tue, Sep 10, 2019, at 8:56 AM, Ruben Reusser wrote:

As was pointed out before the rewriter is used in a lot of projects for
other things than rewriting links (in our case we use it a lot to inject
legal disclaimers or content fragment models)

The bigger problem however is that it assumes hml == xml and hence can

not

deal with attributes with no value

Ruben

On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz



wrote:


Hi,

On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey  wrote:

...Can anyone summarize why we are getting rid of it?...


I'm not sure if we need to "get rid" of that module, even if some
portion of Sling users stops using it.

The proposal at [1] says the rewriter should be "deprecated and no
longer used", which is apparently what was discussed at the adaptTo
round table or hackathon.

If people still find the module useful I think it''s fine to move it
to "contrib" status instead of deprecating. As long as there's a
reasonable expectation that the module will be maintained I think
that's a realistic status, but our guarantees are weak for contrib
modules so there's no pressure.

And if other modules provide better ways of doing similar things, link
to them from the rewriter's docs.

-Bertrand

[1]


https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3
f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E





--
thank you

Ruben Reusser
CTO, headwire.com, Inc






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

org-apache-sling-app-cms - start.sh & stop.sh

[Miroslav Beranič]

Hi all,

I've followed documentation to build Sling CMS APP
at org-apache-sling-app-cms/docs/building.md, where it says:

To run the Sling CMS, build the code and copy the files
builder/src/main/scripts/start.sh builder/src/main/scripts/stop.sh and
builder/target/org.apache.sling.cms-{VERSION].jar to a directory. Execute
the script ./start.sh to start Sling CMS.

Well, when I do this, I get error:
$ /bin/sh
 /path/to/workspace/org-apache-sling-app-cms/target/distro/start.sh ( copy
of a builder/src/main/scripts/start.sh ).
ls: cannot access '*cms*.jar': No such file or directory
Application started on port 8080!

Well, I run this from inside InteliJ IDEA, and I guess it is more of a
missing feature on iDEA to set home/working directory, but eather way, if
start.sh and stop.sh would be changed in a way, to set/switch to working
directory like this:

( start.sh:23 )
script="$0"
basename="$(dirname $script)"
cd $basename

With added check if JAR file was found like this:

JARFILE=`ls *cms*.jar | head -1`
if [ -z "$JARFILE" ]; then
  echo "No JAR file found."
  exit
fi
mkdir -p sling/logs


Now it works as expected:

Application started on port 8080!

Also, variable APP_PORT is set, if not defined. I guess it would make sense
to pre-set APP_DEBUG_PORT if missing, as I guess this is almost-always used
for debug/testing purposes and not in production environment.

Other than this, Sling CMS app works out-of-the box. Very, very nice.
Cheers to the authors.

Master git branch from GitHub.

Kind Regards,
Miroslav


-- 
Miroslav Beranič
MIBESIS
miroslav.bera...@mibesis.si
https://www.mibesis.si

Re: Why get rid of the rewriter?

[Jason E Bailey]

+1 for the summary

--
Jason

On Tue, Sep 10, 2019, at 12:37 PM, Stefan Seifert wrote:
> i try to write a first summary:
> 
> - we have good use cases for a rewriter in general, but are unhappy 
> with the current implementation and it's way of configuration. the 
> whole thing is a bit "alien" to the other parts of sling.
> 
> - a new rewriter implementation should be performant and with 
> up-to-date support for modern HTML. ideally something like SAX for HTML 
> (not XML/XHTML). this would not cover other use cases producing 
> something other than HTML, though. perhaps there are libraries out 
> there that can be built upon. should also provide modular support, e.g. 
> rewriting only the output of a single component or text fragment. maybe 
> someone can come up with a proposal.
> 
> - we have to keep the old rewriter for backward compatibility because 
> it was used a lot in the past, but do not plan to maintain it further 
> and probably will remove it from the sling starter as well. mark it as 
> deprecated or contrib.
> 
> - we do no longer want to use the rewriter for link validation and 
> externalization, but support this as aspect in another, more 
> appropriate way (with some basic support or hooks/SPIs from Sling 
> itself, the rest is more up to upstream layers). we have currently only 
> very rough ideas here, a proposal needs to be draftet as well.
> 
> stefan
> 
> >-Original Message-
> >From: Jason E Bailey [mailto:jason.bai...@24601.org]
> >Sent: Tuesday, September 10, 2019 6:09 PM
> >To: dev@sling.apache.org
> >Subject: Re: Why get rid of the rewriter?
> >
> >I'm positive towards the concept of the rewriter, a utility that provides
> >centralized features that addresses cross-cutting concerns with user
> >generated content.
> >
> >I'm not a fan of the current implementation of the rewriter.
> >
> >1.  As Ruben pointed out, as of HTML5  html doesn't have anything to do
> >with XML. There is no concept of namespace in HTML now. There is no self
> >closing tag. There may not be an end tag. There is a concept of implied
> >parent tags.
> >
> >2. TagSoup, which is currently used to parse the HTML, requires  fully
> >cached content and will attempt to validate the content and add to it,
> >where appropriate. Which isn't necessary.
> >
> >3. The Rewriter requires the pipeline configuration to be in a specific
> >place with a specific name which is inflexible and contrary to other tools
> >we use.
> >
> >
> >The point being that I would prefer to have the rewriter implementation
> >deprecated in favor of a more up to date solution then having the concept
> >of the rewriter deprecated.
> >
> >
> >
> >--
> >Jason
> >
> >On Tue, Sep 10, 2019, at 8:56 AM, Ruben Reusser wrote:
> >> As was pointed out before the rewriter is used in a lot of projects for
> >> other things than rewriting links (in our case we use it a lot to inject
> >> legal disclaimers or content fragment models)
> >>
> >> The bigger problem however is that it assumes hml == xml and hence can
> >not
> >> deal with attributes with no value
> >>
> >> Ruben
> >>
> >> On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz
> >
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey  wrote:
> >> > > ...Can anyone summarize why we are getting rid of it?...
> >> >
> >> > I'm not sure if we need to "get rid" of that module, even if some
> >> > portion of Sling users stops using it.
> >> >
> >> > The proposal at [1] says the rewriter should be "deprecated and no
> >> > longer used", which is apparently what was discussed at the adaptTo
> >> > round table or hackathon.
> >> >
> >> > If people still find the module useful I think it''s fine to move it
> >> > to "contrib" status instead of deprecating. As long as there's a
> >> > reasonable expectation that the module will be maintained I think
> >> > that's a realistic status, but our guarantees are weak for contrib
> >> > modules so there's no pressure.
> >> >
> >> > And if other modules provide better ways of doing similar things, link
> >> > to them from the rewriter's docs.
> >> >
> >> > -Bertrand
> >> >
> >> > [1]
> >> >
> >https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3
> >f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E
> >> >
> >>
> >>
> >> --
> >> thank you
> >>
> >> Ruben Reusser
> >> CTO, headwire.com, Inc
> >>
> 
> 
>

RE: Why get rid of the rewriter?

[Stefan Seifert]

i try to write a first summary:

- we have good use cases for a rewriter in general, but are unhappy with the 
current implementation and it's way of configuration. the whole thing is a bit 
"alien" to the other parts of sling.

- a new rewriter implementation should be performant and with up-to-date 
support for modern HTML. ideally something like SAX for HTML (not XML/XHTML). 
this would not cover other use cases producing something other than HTML, 
though. perhaps there are libraries out there that can be built upon. should 
also provide modular support, e.g. rewriting only the output of a single 
component or text fragment. maybe someone can come up with a proposal.

- we have to keep the old rewriter for backward compatibility because it was 
used a lot in the past, but do not plan to maintain it further and probably 
will remove it from the sling starter as well. mark it as deprecated or contrib.

- we do no longer want to use the rewriter for link validation and 
externalization, but support this as aspect in another, more appropriate way 
(with some basic support or hooks/SPIs from Sling itself, the rest is more up 
to upstream layers). we have currently only very rough ideas here, a proposal 
needs to be draftet as well.

stefan

>-Original Message-
>From: Jason E Bailey [mailto:jason.bai...@24601.org]
>Sent: Tuesday, September 10, 2019 6:09 PM
>To: dev@sling.apache.org
>Subject: Re: Why get rid of the rewriter?
>
>I'm positive towards the concept of the rewriter, a utility that provides
>centralized features that addresses cross-cutting concerns with user
>generated content.
>
>I'm not a fan of the current implementation of the rewriter.
>
>1.  As Ruben pointed out, as of HTML5  html doesn't have anything to do
>with XML. There is no concept of namespace in HTML now. There is no self
>closing tag. There may not be an end tag. There is a concept of implied
>parent tags.
>
>2. TagSoup, which is currently used to parse the HTML, requires  fully
>cached content and will attempt to validate the content and add to it,
>where appropriate. Which isn't necessary.
>
>3. The Rewriter requires the pipeline configuration to be in a specific
>place with a specific name which is inflexible and contrary to other tools
>we use.
>
>
>The point being that I would prefer to have the rewriter implementation
>deprecated in favor of a more up to date solution then having the concept
>of the rewriter deprecated.
>
>
>
>--
>Jason
>
>On Tue, Sep 10, 2019, at 8:56 AM, Ruben Reusser wrote:
>> As was pointed out before the rewriter is used in a lot of projects for
>> other things than rewriting links (in our case we use it a lot to inject
>> legal disclaimers or content fragment models)
>>
>> The bigger problem however is that it assumes hml == xml and hence can
>not
>> deal with attributes with no value
>>
>> Ruben
>>
>> On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz
>
>> wrote:
>>
>> > Hi,
>> >
>> > On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey  wrote:
>> > > ...Can anyone summarize why we are getting rid of it?...
>> >
>> > I'm not sure if we need to "get rid" of that module, even if some
>> > portion of Sling users stops using it.
>> >
>> > The proposal at [1] says the rewriter should be "deprecated and no
>> > longer used", which is apparently what was discussed at the adaptTo
>> > round table or hackathon.
>> >
>> > If people still find the module useful I think it''s fine to move it
>> > to "contrib" status instead of deprecating. As long as there's a
>> > reasonable expectation that the module will be maintained I think
>> > that's a realistic status, but our guarantees are weak for contrib
>> > modules so there's no pressure.
>> >
>> > And if other modules provide better ways of doing similar things, link
>> > to them from the rewriter's docs.
>> >
>> > -Bertrand
>> >
>> > [1]
>> >
>https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3
>f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E
>> >
>>
>>
>> --
>> thank you
>>
>> Ruben Reusser
>> CTO, headwire.com, Inc
>>

Re: Why get rid of the rewriter?

[Jason E Bailey]

I'm positive towards the concept of the rewriter, a utility that provides 
centralized features that addresses cross-cutting concerns with user generated 
content.

I'm not a fan of the current implementation of the rewriter.

1.  As Ruben pointed out, as of HTML5  html doesn't have anything to do with 
XML. There is no concept of namespace in HTML now. There is no self closing 
tag. There may not be an end tag. There is a concept of implied parent tags. 

2. TagSoup, which is currently used to parse the HTML, requires  fully cached 
content and will attempt to validate the content and add to it, where 
appropriate. Which isn't necessary.

3. The Rewriter requires the pipeline configuration to be in a specific place 
with a specific name which is inflexible and contrary to other tools we use.


The point being that I would prefer to have the rewriter implementation 
deprecated in favor of a more up to date solution then having the concept of 
the rewriter deprecated.



--
Jason

On Tue, Sep 10, 2019, at 8:56 AM, Ruben Reusser wrote:
> As was pointed out before the rewriter is used in a lot of projects for
> other things than rewriting links (in our case we use it a lot to inject
> legal disclaimers or content fragment models)
> 
> The bigger problem however is that it assumes hml == xml and hence can not
> deal with attributes with no value
> 
> Ruben
> 
> On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz 
> wrote:
> 
> > Hi,
> >
> > On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey  wrote:
> > > ...Can anyone summarize why we are getting rid of it?...
> >
> > I'm not sure if we need to "get rid" of that module, even if some
> > portion of Sling users stops using it.
> >
> > The proposal at [1] says the rewriter should be "deprecated and no
> > longer used", which is apparently what was discussed at the adaptTo
> > round table or hackathon.
> >
> > If people still find the module useful I think it''s fine to move it
> > to "contrib" status instead of deprecating. As long as there's a
> > reasonable expectation that the module will be maintained I think
> > that's a realistic status, but our guarantees are weak for contrib
> > modules so there's no pressure.
> >
> > And if other modules provide better ways of doing similar things, link
> > to them from the rewriter's docs.
> >
> > -Bertrand
> >
> > [1]
> > https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E
> >
> 
> 
> -- 
> thank you
> 
> Ruben Reusser
> CTO, headwire.com, Inc
>

Re: [VOTE] Release slingfeature-maven-plugin 1.1.2

[Andreas Schaefer]

+1 (non-binding)

- Andy

> On Sep 10, 2019, at 1:59 AM, dav...@apache.org wrote:
> 
> Hi all,
> 
> We solved 5 issues in this release:
> https://issues.apache.org/jira/projects/SLING/versions/12346050
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-2127
> 
> 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 2127 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ] -1 Don't release, because ...
> 
> This majority vote is open for at least 72 hours.
> 
> Best regards,
> 
> David Bosschaert

Re: Why get rid of the rewriter?

[Konrad Windszus]

Why can footnotes not be added as request attributes (either just as a numeric 
counter or a complex object depending on the use case)?

> On 10. Sep 2019, at 16:55, Julian Sedding  wrote:
> 
> Another real-world use-case that was nicely solved using the rewriter
> is footnotes. Footnotes are collected by a rewriter and consecutive
> numbers injected into the markup. At the end of a page all collected
> footnote's texts were then rendered.
> 
> Off the top of my head I cannot name another elegant solution for this 
> problem.
> 
> Granted there is extra processing due to serialising -> parsing ->
> serialising. However, I have yet to encounter a real world scenario
> where this performance cost becomes a performance problem.
> 
> HTL question: could HTL be (easily) modified to generate SAX events
> instead of rendering the markup directly? That should (for HTL) allow
> getting rid of the processing overhead. Just a thought on how to solve
> the underlying issue while keeping the rewriter (maybe by allowing it
> to be hooked in differently).
> 
> Regards
> Julian
> 
> 
> 
> 
> 
> 
> 
> On Tue, Sep 10, 2019 at 4:35 PM Konrad Windszus  wrote:
>> 
>> The new url rewriter SPI will be perfectly supporting AOP.
>> Konrad
>> 
>>> Am 10.09.2019 um 16:09 schrieb Justin Edelson :
>>> 
>>> I see that the same assumptions are being made here that were made a year
>>> ago when this was discussed. I would strongly caution against assuming that
>>> the "aspect developer" and the "script developer" are the same person or
>>> even work for the same organization. The value of AOP programming styles,
>>> such as that used by the rewriter, is that these roles do not need to be
>>> aware of each other.
>>> 
>>> Agree 100% that AEM should change how link rewriting is done. But that's
>>> not really Sling's concern per se with respect to the rewriter. Sling's
>>> concern should be (1) whether or not AOP has value in a component-based
>>> system (I think the answer here is a clear "yes") and (2) what the right
>>> programming model is to support AOP. To Reuben's point, it is certainly
>>> possible that SAX is the wrong programming model (I personally don't agree,
>>> but I have a very soft spot for SAX). But the answer to that IMO is to
>>> define a better programming model, not jump to the conclusion that AOP
>>> doesn't have value.
>>> 
>>> Cheers,
>>> Justin
>>> 
>>> On Tue, Sep 10, 2019 at 9:54 AM Carsten Ziegeler 
>>> wrote:
>>> 
 The rewriter is a generic solution (for xhtml) which works independent
 of the scripting engine used. However, with engines like HTL which knows
 about HTML and has all the contextual information about the html
 elements, it is way more efficient to do any transformation whether its
 link transformations or anything else already during that step.
 Reparsing with a rather expensive XML processing pipeline is flexible
 but also slows down the rendering unnecessary.
 
 Carsten
 
> Am 10.09.2019 um 14:56 schrieb Ruben Reusser:
> As was pointed out before the rewriter is used in a lot of projects for
> other things than rewriting links (in our case we use it a lot to inject
> legal disclaimers or content fragment models)
> 
> The bigger problem however is that it assumes hml == xml and hence can
 not
> deal with attributes with no value
> 
> Ruben
> 
> On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz <
 bdelacre...@apache.org>
> wrote:
> 
>> Hi,
>> 
>>> On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey  wrote:
>>> ...Can anyone summarize why we are getting rid of it?...
>> 
>> I'm not sure if we need to "get rid" of that module, even if some
>> portion of Sling users stops using it.
>> 
>> The proposal at [1] says the rewriter should be "deprecated and no
>> longer used", which is apparently what was discussed at the adaptTo
>> round table or hackathon.
>> 
>> If people still find the module useful I think it''s fine to move it
>> to "contrib" status instead of deprecating. As long as there's a
>> reasonable expectation that the module will be maintained I think
>> that's a realistic status, but our guarantees are weak for contrib
>> modules so there's no pressure.
>> 
>> And if other modules provide better ways of doing similar things, link
>> to them from the rewriter's docs.
>> 
>> -Bertrand
>> 
>> [1]
>> 
 https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E
>> 
> 
> 
 
 --
 --
 Carsten Ziegeler
 Adobe Research Switzerland
 cziege...@apache.org
 
>> 

Re: Why get rid of the rewriter?

[Julian Sedding]

Another real-world use-case that was nicely solved using the rewriter
is footnotes. Footnotes are collected by a rewriter and consecutive
numbers injected into the markup. At the end of a page all collected
footnote's texts were then rendered.

Off the top of my head I cannot name another elegant solution for this problem.

Granted there is extra processing due to serialising -> parsing ->
serialising. However, I have yet to encounter a real world scenario
where this performance cost becomes a performance problem.

HTL question: could HTL be (easily) modified to generate SAX events
instead of rendering the markup directly? That should (for HTL) allow
getting rid of the processing overhead. Just a thought on how to solve
the underlying issue while keeping the rewriter (maybe by allowing it
to be hooked in differently).

Regards
Julian







On Tue, Sep 10, 2019 at 4:35 PM Konrad Windszus  wrote:
>
> The new url rewriter SPI will be perfectly supporting AOP.
> Konrad
>
> > Am 10.09.2019 um 16:09 schrieb Justin Edelson :
> >
> > I see that the same assumptions are being made here that were made a year
> > ago when this was discussed. I would strongly caution against assuming that
> > the "aspect developer" and the "script developer" are the same person or
> > even work for the same organization. The value of AOP programming styles,
> > such as that used by the rewriter, is that these roles do not need to be
> > aware of each other.
> >
> > Agree 100% that AEM should change how link rewriting is done. But that's
> > not really Sling's concern per se with respect to the rewriter. Sling's
> > concern should be (1) whether or not AOP has value in a component-based
> > system (I think the answer here is a clear "yes") and (2) what the right
> > programming model is to support AOP. To Reuben's point, it is certainly
> > possible that SAX is the wrong programming model (I personally don't agree,
> > but I have a very soft spot for SAX). But the answer to that IMO is to
> > define a better programming model, not jump to the conclusion that AOP
> > doesn't have value.
> >
> > Cheers,
> > Justin
> >
> > On Tue, Sep 10, 2019 at 9:54 AM Carsten Ziegeler 
> > wrote:
> >
> >> The rewriter is a generic solution (for xhtml) which works independent
> >> of the scripting engine used. However, with engines like HTL which knows
> >> about HTML and has all the contextual information about the html
> >> elements, it is way more efficient to do any transformation whether its
> >> link transformations or anything else already during that step.
> >> Reparsing with a rather expensive XML processing pipeline is flexible
> >> but also slows down the rendering unnecessary.
> >>
> >> Carsten
> >>
> >>> Am 10.09.2019 um 14:56 schrieb Ruben Reusser:
> >>> As was pointed out before the rewriter is used in a lot of projects for
> >>> other things than rewriting links (in our case we use it a lot to inject
> >>> legal disclaimers or content fragment models)
> >>>
> >>> The bigger problem however is that it assumes hml == xml and hence can
> >> not
> >>> deal with attributes with no value
> >>>
> >>> Ruben
> >>>
> >>> On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz <
> >> bdelacre...@apache.org>
> >>> wrote:
> >>>
>  Hi,
> 
> > On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey  wrote:
> > ...Can anyone summarize why we are getting rid of it?...
> 
>  I'm not sure if we need to "get rid" of that module, even if some
>  portion of Sling users stops using it.
> 
>  The proposal at [1] says the rewriter should be "deprecated and no
>  longer used", which is apparently what was discussed at the adaptTo
>  round table or hackathon.
> 
>  If people still find the module useful I think it''s fine to move it
>  to "contrib" status instead of deprecating. As long as there's a
>  reasonable expectation that the module will be maintained I think
>  that's a realistic status, but our guarantees are weak for contrib
>  modules so there's no pressure.
> 
>  And if other modules provide better ways of doing similar things, link
>  to them from the rewriter's docs.
> 
>  -Bertrand
> 
>  [1]
> 
> >> https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E
> 
> >>>
> >>>
> >>
> >> --
> >> --
> >> Carsten Ziegeler
> >> Adobe Research Switzerland
> >> cziege...@apache.org
> >>
>

Re: Why get rid of the rewriter?

[Konrad Windszus]

The new url rewriter SPI will be perfectly supporting AOP.
Konrad

> Am 10.09.2019 um 16:09 schrieb Justin Edelson :
> 
> I see that the same assumptions are being made here that were made a year
> ago when this was discussed. I would strongly caution against assuming that
> the "aspect developer" and the "script developer" are the same person or
> even work for the same organization. The value of AOP programming styles,
> such as that used by the rewriter, is that these roles do not need to be
> aware of each other.
> 
> Agree 100% that AEM should change how link rewriting is done. But that's
> not really Sling's concern per se with respect to the rewriter. Sling's
> concern should be (1) whether or not AOP has value in a component-based
> system (I think the answer here is a clear "yes") and (2) what the right
> programming model is to support AOP. To Reuben's point, it is certainly
> possible that SAX is the wrong programming model (I personally don't agree,
> but I have a very soft spot for SAX). But the answer to that IMO is to
> define a better programming model, not jump to the conclusion that AOP
> doesn't have value.
> 
> Cheers,
> Justin
> 
> On Tue, Sep 10, 2019 at 9:54 AM Carsten Ziegeler 
> wrote:
> 
>> The rewriter is a generic solution (for xhtml) which works independent
>> of the scripting engine used. However, with engines like HTL which knows
>> about HTML and has all the contextual information about the html
>> elements, it is way more efficient to do any transformation whether its
>> link transformations or anything else already during that step.
>> Reparsing with a rather expensive XML processing pipeline is flexible
>> but also slows down the rendering unnecessary.
>> 
>> Carsten
>> 
>>> Am 10.09.2019 um 14:56 schrieb Ruben Reusser:
>>> As was pointed out before the rewriter is used in a lot of projects for
>>> other things than rewriting links (in our case we use it a lot to inject
>>> legal disclaimers or content fragment models)
>>> 
>>> The bigger problem however is that it assumes hml == xml and hence can
>> not
>>> deal with attributes with no value
>>> 
>>> Ruben
>>> 
>>> On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz <
>> bdelacre...@apache.org>
>>> wrote:
>>> 
 Hi,
 
> On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey  wrote:
> ...Can anyone summarize why we are getting rid of it?...
 
 I'm not sure if we need to "get rid" of that module, even if some
 portion of Sling users stops using it.
 
 The proposal at [1] says the rewriter should be "deprecated and no
 longer used", which is apparently what was discussed at the adaptTo
 round table or hackathon.
 
 If people still find the module useful I think it''s fine to move it
 to "contrib" status instead of deprecating. As long as there's a
 reasonable expectation that the module will be maintained I think
 that's a realistic status, but our guarantees are weak for contrib
 modules so there's no pressure.
 
 And if other modules provide better ways of doing similar things, link
 to them from the rewriter's docs.
 
 -Bertrand
 
 [1]
 
>> https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E
 
>>> 
>>> 
>> 
>> --
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>> 

Re: Why get rid of the rewriter?

[Justin Edelson]

I see that the same assumptions are being made here that were made a year
ago when this was discussed. I would strongly caution against assuming that
the "aspect developer" and the "script developer" are the same person or
even work for the same organization. The value of AOP programming styles,
such as that used by the rewriter, is that these roles do not need to be
aware of each other.

Agree 100% that AEM should change how link rewriting is done. But that's
not really Sling's concern per se with respect to the rewriter. Sling's
concern should be (1) whether or not AOP has value in a component-based
system (I think the answer here is a clear "yes") and (2) what the right
programming model is to support AOP. To Reuben's point, it is certainly
possible that SAX is the wrong programming model (I personally don't agree,
but I have a very soft spot for SAX). But the answer to that IMO is to
define a better programming model, not jump to the conclusion that AOP
doesn't have value.

Cheers,
Justin

On Tue, Sep 10, 2019 at 9:54 AM Carsten Ziegeler 
wrote:

> The rewriter is a generic solution (for xhtml) which works independent
> of the scripting engine used. However, with engines like HTL which knows
> about HTML and has all the contextual information about the html
> elements, it is way more efficient to do any transformation whether its
> link transformations or anything else already during that step.
> Reparsing with a rather expensive XML processing pipeline is flexible
> but also slows down the rendering unnecessary.
>
> Carsten
>
> Am 10.09.2019 um 14:56 schrieb Ruben Reusser:
> > As was pointed out before the rewriter is used in a lot of projects for
> > other things than rewriting links (in our case we use it a lot to inject
> > legal disclaimers or content fragment models)
> >
> > The bigger problem however is that it assumes hml == xml and hence can
> not
> > deal with attributes with no value
> >
> > Ruben
> >
> > On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz <
> bdelacre...@apache.org>
> > wrote:
> >
> >> Hi,
> >>
> >> On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey  wrote:
> >>> ...Can anyone summarize why we are getting rid of it?...
> >>
> >> I'm not sure if we need to "get rid" of that module, even if some
> >> portion of Sling users stops using it.
> >>
> >> The proposal at [1] says the rewriter should be "deprecated and no
> >> longer used", which is apparently what was discussed at the adaptTo
> >> round table or hackathon.
> >>
> >> If people still find the module useful I think it''s fine to move it
> >> to "contrib" status instead of deprecating. As long as there's a
> >> reasonable expectation that the module will be maintained I think
> >> that's a realistic status, but our guarantees are weak for contrib
> >> modules so there's no pressure.
> >>
> >> And if other modules provide better ways of doing similar things, link
> >> to them from the rewriter's docs.
> >>
> >> -Bertrand
> >>
> >> [1]
> >>
> https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E
> >>
> >
> >
>
> --
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

Re: Why get rid of the rewriter?

[Carsten Ziegeler]

The rewriter is a generic solution (for xhtml) which works independent 
of the scripting engine used. However, with engines like HTL which knows 
about HTML and has all the contextual information about the html 
elements, it is way more efficient to do any transformation whether its 
link transformations or anything else already during that step.
Reparsing with a rather expensive XML processing pipeline is flexible 
but also slows down the rendering unnecessary.


Carsten

Am 10.09.2019 um 14:56 schrieb Ruben Reusser:

As was pointed out before the rewriter is used in a lot of projects for
other things than rewriting links (in our case we use it a lot to inject
legal disclaimers or content fragment models)

The bigger problem however is that it assumes hml == xml and hence can not
deal with attributes with no value

Ruben

On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz 
wrote:


Hi,

On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey  wrote:

...Can anyone summarize why we are getting rid of it?...


I'm not sure if we need to "get rid" of that module, even if some
portion of Sling users stops using it.

The proposal at [1] says the rewriter should be "deprecated and no
longer used", which is apparently what was discussed at the adaptTo
round table or hackathon.

If people still find the module useful I think it''s fine to move it
to "contrib" status instead of deprecating. As long as there's a
reasonable expectation that the module will be maintained I think
that's a realistic status, but our guarantees are weak for contrib
modules so there's no pressure.

And if other modules provide better ways of doing similar things, link
to them from the rewriter's docs.

-Bertrand

[1]
https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E






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

Re: [VOTE] Release slingfeature-maven-plugin 1.1.2

[Carsten Ziegeler]

+1

Carsten

Am 10.09.2019 um 10:59 schrieb dav...@apache.org:

Hi all,

We solved 5 issues in this release:
https://issues.apache.org/jira/projects/SLING/versions/12346050

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-2127

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 2127 /tmp/sling-staging

Please vote to approve this release:

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

This majority vote is open for at least 72 hours.

Best regards,

David Bosschaert



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

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

[Apache Jenkins Server]

ion) @ 
org.apache.sling.launchpad.testing ---
[INFO] Loading execution data file 
/home/jenkins/jenkins-slave/workspace/e-sling-launchpad-testing_master/target/jacoco-it.exec
[INFO] Analyzed bundle 'Apache Sling Launchpad Testing' with 0 classes
[INFO] 
[INFO] --- jacoco-maven-plugin:0.7.9:report (report-merged) @ 
org.apache.sling.launchpad.testing ---
[INFO] Loading execution data file 
/home/jenkins/jenkins-slave/workspace/e-sling-launchpad-testing_master/target/jacoco-merged.exec
[INFO] Analyzed bundle 'Apache Sling Launchpad Testing' with 0 classes
[INFO] 
[INFO] --- maven-failsafe-plugin:2.21.0:verify (default) @ 
org.apache.sling.launchpad.testing ---
[INFO] 
[INFO] 
[INFO] Skipping Apache Sling Launchpad Testing
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  04:50 min
[INFO] Finished at: 2019-09-10T12:59:52Z
[INFO] 
[INFO] [jenkins-event-spy] Generated 
/home/jenkins/jenkins-slave/workspace/e-sling-launchpad-testing_master@tmp/withMavenbdcbeb84/maven-spy-20190910-125502-96642605128299413749.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] echo
Marking build unstable due to missing SonarCloud onboarding. See 
https://cwiki.apache.org/confluence/display/SLING/SonarCloud+analysis for steps 
to fix.
[Pipeline] }
[withMaven] Publishers: 
[Pipeline] // withMaven
[Pipeline] }
[Pipeline] // withCredentials
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // timeout
[Pipeline] stage
[Pipeline] { (Notifications)
[Pipeline] echo
Status change is BROKEN, notifications will be sent.
[Pipeline] emailext

Re: Why get rid of the rewriter?

[Ruben Reusser]

As was pointed out before the rewriter is used in a lot of projects for
other things than rewriting links (in our case we use it a lot to inject
legal disclaimers or content fragment models)

The bigger problem however is that it assumes hml == xml and hence can not
deal with attributes with no value

Ruben

On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz 
wrote:

> Hi,
>
> On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey  wrote:
> > ...Can anyone summarize why we are getting rid of it?...
>
> I'm not sure if we need to "get rid" of that module, even if some
> portion of Sling users stops using it.
>
> The proposal at [1] says the rewriter should be "deprecated and no
> longer used", which is apparently what was discussed at the adaptTo
> round table or hackathon.
>
> If people still find the module useful I think it''s fine to move it
> to "contrib" status instead of deprecating. As long as there's a
> reasonable expectation that the module will be maintained I think
> that's a realistic status, but our guarantees are weak for contrib
> modules so there's no pressure.
>
> And if other modules provide better ways of doing similar things, link
> to them from the rewriter's docs.
>
> -Bertrand
>
> [1]
> https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E
>


-- 
thank you

Ruben Reusser
CTO, headwire.com, Inc

Re: [VOTE] Release slingfeature-maven-plugin 1.1.2

[Daniel Klco]

+1

On Tue, Sep 10, 2019 at 7:28 AM Robert Munteanu  wrote:

> On Tue, 2019-09-10 at 09:59 +0100, dav...@apache.org wrote:
> > Please vote to approve this release:
>
> +1
>
> Robert
>

Re: Why get rid of the rewriter?

[Bertrand Delacretaz]

Hi,

On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey  wrote:
> ...Can anyone summarize why we are getting rid of it?...

I'm not sure if we need to "get rid" of that module, even if some
portion of Sling users stops using it.

The proposal at [1] says the rewriter should be "deprecated and no
longer used", which is apparently what was discussed at the adaptTo
round table or hackathon.

If people still find the module useful I think it''s fine to move it
to "contrib" status instead of deprecating. As long as there's a
reasonable expectation that the module will be maintained I think
that's a realistic status, but our guarantees are weak for contrib
modules so there's no pressure.

And if other modules provide better ways of doing similar things, link
to them from the rewriter's docs.

-Bertrand

[1] 
https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E

Re: [VOTE] Release slingfeature-maven-plugin 1.1.2

[Robert Munteanu]

On Tue, 2019-09-10 at 09:59 +0100, dav...@apache.org wrote:
> Please vote to approve this release:

+1

Robert


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

Re: Release Validator Docker Image

[Radu Cotescu]

Hi Carsten,

> On 9 Sep 2019, at 19:29, Carsten Ziegeler  wrote:
> 
> Can we maybe also remove the md5 files and create sha512 files, when the 
> checksum is correct?
> 

The sha1 and md5 files seem to be generated by Nexus and not by our Maven 
release process. I quickly checked how the sha512 files are generated and this 
seems to be a config in the Apache parent pom [4]. However, those are not 
attached [5] to the build, most probably due to [6].

I guess we can create the sha512 files with this CLI tool, but the value would 
come only when we’d be able to push the staged artifacts to dist.

Cheers,
Radu

[4] - https://github.com/apache/maven-apache-parent/blob/apache-21/pom.xml#L440 

[5] - 
https://checksum-maven-plugin.nicoulaj.net/files-mojo.html#attachChecksums 
[6] 
- https://issues.apache.org/jira/browse/INFRA-14923 

[jira] [Assigned] (SLING-8692) Slingfeature maven plugin: add option to decompress artifacts stored in the repository goal

[David Bosschaert (Jira)]

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

David Bosschaert reassigned SLING-8692:
---

Assignee: David Bosschaert

> Slingfeature maven plugin: add option to decompress artifacts stored in the 
> repository goal
> ---
>
> Key: SLING-8692
> URL: https://issues.apache.org/jira/browse/SLING-8692
> Project: Sling
>  Issue Type: Improvement
>  Components: Feature Model
>Affects Versions: slingfeature-maven-plugin 1.1.2
>Reporter: Karl Pauls
>Assignee: David Bosschaert
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.1.4
>
>
> It might be useful to have an option on the repository goal to have it store 
> the artifacts in the created repository decompressed (i.e., with a zip 
> compression of 0). Maybe even decompress embeded jars in case of bundles. 
> That would create a bigger repository but likely mean faster start-up.



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

[jira] [Created] (SLING-8692) Slingfeature maven plugin: add option to decompress artifacts stored in the repository goal

[Karl Pauls (Jira)]

Karl Pauls created SLING-8692:
-

 Summary: Slingfeature maven plugin: add option to decompress 
artifacts stored in the repository goal
 Key: SLING-8692
 URL: https://issues.apache.org/jira/browse/SLING-8692
 Project: Sling
  Issue Type: Improvement
  Components: Feature Model
Affects Versions: slingfeature-maven-plugin 1.1.2
Reporter: Karl Pauls
 Fix For: slingfeature-maven-plugin 1.1.4


It might be useful to have an option on the repository goal to have it store 
the artifacts in the created repository decompressed (i.e., with a zip 
compression of 0). Maybe even decompress embeded jars in case of bundles. 

That would create a bigger repository but likely mean faster start-up.



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

Re: [VOTE] Release slingfeature-maven-plugin 1.1.2

[Radu Cotescu]

+1

> On 10 Sep 2019, at 10:59, dav...@apache.org wrote:
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ] -1 Don't release, because ...
> 
> This majority vote is open for at least 72 hours.
> 
> Best regards,
> 
> David Bosschaert

Re: [VOTE] Release slingfeature-maven-plugin 1.1.2

[davidb]

+1

David

On Tue, 10 Sep 2019 at 09:59,  wrote:

> Hi all,
>
> We solved 5 issues in this release:
> https://issues.apache.org/jira/projects/SLING/versions/12346050
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-2127
>
> 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 2127 /tmp/sling-staging
>
> Please vote to approve this release:
>
>   [ ] +1 Approve the release
>   [ ] -1 Don't release, because ...
>
> This majority vote is open for at least 72 hours.
>
> Best regards,
>
> David Bosschaert
>

[VOTE] Release slingfeature-maven-plugin 1.1.2

[davidb]

Hi all,

We solved 5 issues in this release:
https://issues.apache.org/jira/projects/SLING/versions/12346050

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-2127

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 2127 /tmp/sling-staging

Please vote to approve this release:

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

This majority vote is open for at least 72 hours.

Best regards,

David Bosschaert

RE: Why get rid of the rewriter?

[Stefan Seifert]

>What is the solution for rewriting URLs contained within the output of a
>rich text editor? Similar to https://wcm.io/handler/richtext/? I hope that
>downstream implementers of Sling will provide a pathway for replacing the
>rewriter if it is removed. I would speculate this would result in a
>tremendous amount of work to fix / test on upgrade for many
>implementations.

yes, you still need solutions for rich text components, and there a post 
processing is valid - but only for the rich text this component outputs, with 
full awareness of the context and it's configuration.

stefan

Re: Why get rid of the rewriter?

[Roy Teeuwen]

I also used rewriting for various use cases ( for example creating disclaimer 
links at the bottom of the page based on whats on the page)

To be honest, its just a nice wrapper around a filter, if you would take it 
away, people would just create a filter on page level that captures the 
response and do all the stuff afterwards, so I dont see any difference / better 
way being proposed yet. But if there is a better way, wouldnt mind hearing it!



Van: Daniel Klco 
Verzonden: dinsdag, september 10, 2019 3:29 AM
Aan: dev@sling.apache.org
Onderwerp: Re: Why get rid of the rewriter?

What is the solution for rewriting URLs contained within the output of a
rich text editor? Similar to https://wcm.io/handler/richtext/? I hope that
downstream implementers of Sling will provide a pathway for replacing the
rewriter if it is removed. I would speculate this would result in a
tremendous amount of work to fix / test on upgrade for many
implementations.

I agree the AEM Link Checker is a bad idea, though I argue that has to do
more with the concept of removing links at runtime than the way it is
implemented.

While the rewriter is not the most efficient method, but it does give you
the ability to affect the entire page structure in one go vs. having to
handle it on a per-component, resource type or field basis. The problem I
see with most implementations of Sling using the rewriter is they do not
give enough control of how the rewriter operates. I've been using this with
the Sling CMS reference, for example to allow for whitelisting attributes
and elements on a per-site basis using Sling CA Configs:
https://github.com/apache/sling-org-apache-sling-app-cms/blob/master/docs/configure-site.md#rewrite-configuration


On Mon, Sep 9, 2019, 5:52 PM Stefan Seifert  wrote:

> yes, that's what we roughly outlined at [1]. of course that's still a lot
> of work to do to get rid of the rewriter, and when it's time it maybe still
> deprecated kept in in-place for more exotic use cases (like PDF generation).
>
> why / for what use cases do we want to get rid of it - my view:
>
> - the rewriter is currently (esp. in AEM) mainly used for checking
> validity of links in a post-processing step
> - that means AFTER the markup was generated by all the scripts, it is
> parsed again, link are identified by heuristics, and if a link seems to
> point to an internal page/resource, and this page/resource does not exist,
> the link is removed by the rewriter
> - this leads to several problems:
> - performance issue: why generating the markup and directly after parse
> it again to serialize it again?
> - responsibility/control issue: what should happen should if a link is
> invalid should rely in the control of the component/script that renders the
> link. sometimes only the anchor is unwrapped, but often more is happening,
> e.g. the whole teaser is hidden, the whole navigation entry is hidden etc.
> the rewriter cannot "know" these use cases.
> - link detection issue: because relying on heuristics it is never sure
> that the rewriter can detect all links. e.g. by default it cannot detect
> link in data attributes, link in javascript, link in JSON files etc.
> - that means the aspect of externalizing and validating links belongs into
> the business/framework logic, not in a post processing link rewriter.
>
> that's why we build the URL/link handler in wcm.io [2] - and i think in
> the long run sling should go in this direction as well (at least for the
> basic URL handling features). I known that lot's of sling-based application
> put all their complex link handling logic into customized rewriter
> pipelines, but imho this is the wrong place for it. see also [3] for some
> background information.
>
> stefan
>
> [1]
> https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E
> [2] https://wcm.io/handler/
> [3]
> https://adapt.to/2019/en/schedule/assets-and-links-in-aem-projects.html
>
>
> >-Original Message-
> >From: Jason E Bailey [mailto:j...@apache.org]
> >Sent: Monday, September 9, 2019 3:07 PM
> >To: dev@sling.apache.org
> >Subject: Why get rid of the rewriter?
> >
> >I obviously missed the chat at the adaptTo() meetup.
> >
> >Can anyone summarize why we are getting rid of it? And the thought process
> >on replacing it?
> >
> >- Jason
>
>
>

[jira] [Updated] (SLING-8683) Slingfeature maven plugin should be usable to wrap project artifacts in feature.

[Carsten Ziegeler (Jira)]

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

Carsten Ziegeler updated SLING-8683:

Fix Version/s: (was: slingfeature-maven-plugin 1.1.2)
   slingfeature-maven-plugin 1.1.4

> Slingfeature maven plugin should be usable to wrap project artifacts in 
> feature.
> 
>
> Key: SLING-8683
> URL: https://issues.apache.org/jira/browse/SLING-8683
> Project: Sling
>  Issue Type: Improvement
>  Components: Feature Model
>Affects Versions: slingfeature-maven-plugin 1.1.0
>Reporter: Karl Pauls
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.1.4
>
>
> It would be nice if there was an easy way to create a feature for the 
> artifact(s) of a maven project without manually creating the feature. The 
> idea was to maybe make it so that if the slingfeature-maven-plugin is added 
> to a project, it will generate and a attach a feature wrapping the 
> artifact(s) from the build automatically. 



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