[jira] [Commented] (SLING-8038) Allow the Repository MOJO specify including features from CLI
[
https://issues.apache.org/jira/browse/SLING-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16660086#comment-16660086
]
ASF GitHub Bot commented on SLING-8038:
---
cziegeler commented on issue #13: SLING-8038 - Allow the Repository MOJO
specify including features from CLI
URL:
https://github.com/apache/sling-slingfeature-maven-plugin/pull/13#issuecomment-432091301
This branch has conflicts and I suggest to also update the PR based on my
feedback
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Allow the Repository MOJO specify including features from CLI
> -
>
> Key: SLING-8038
> URL: https://issues.apache.org/jira/browse/SLING-8038
> Project: Sling
> Issue Type: Improvement
> Components: Maven Plugins and Archetypes
>Reporter: Simone Tripodi
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0
>
>
> The is a need of creating a standalone Repository, the {{RepositoryMojo}}
> does already that job, BUT requirement is having a tool which can be easily
> invoked from CLI (where the
> {{org.apache.sling.feature.maven.mojos.DependencyLifecycleParticipant}} is
> not invoked due to the fact that plugin extensions could not be enabled).
> PS is coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] cziegeler commented on issue #13: SLING-8038 - Allow the Repository MOJO specify including features from CLI
cziegeler commented on issue #13: SLING-8038 - Allow the Repository MOJO specify including features from CLI URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/13#issuecomment-432091301 This branch has conflicts and I suggest to also update the PR based on my feedback This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Resolved] (SLING-8001) CMS - Core - Add Insights API
[ https://issues.apache.org/jira/browse/SLING-8001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Klco resolved SLING-8001. - Resolution: Fixed Added in: https://github.com/apache/sling-org-apache-sling-app-cms/commit/dc5efa6959912c59783a24b351abd1dd59d9a93d > CMS - Core - Add Insights API > - > > Key: SLING-8001 > URL: https://issues.apache.org/jira/browse/SLING-8001 > Project: Sling > Issue Type: New Feature >Affects Versions: App CMS 0.10.0 >Reporter: Dan Klco >Assignee: Dan Klco >Priority: Minor > Fix For: App CMS 0.10.2 > > > It would be a nice feature to have a library for executing content insights. > This could include things such as SEO checks, readability analysis, > autotagging, etc. The API should allow for pluggable insight providers and > the ability to configure insights at the site level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SLING-8048) CMS - UI - Switch RTE to Wysihtml
[ https://issues.apache.org/jira/browse/SLING-8048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Klco resolved SLING-8048. - Resolution: Fixed Done in https://github.com/apache/sling-org-apache-sling-app-cms/commit/7328849b66921803b2f3a3757141800242326798 > CMS - UI - Switch RTE to Wysihtml > - > > Key: SLING-8048 > URL: https://issues.apache.org/jira/browse/SLING-8048 > Project: Sling > Issue Type: Improvement >Affects Versions: App CMS 0.10.0 >Reporter: Dan Klco >Assignee: Dan Klco >Priority: Minor > Fix For: App CMS 0.10.2 > > > Currently the CMS uses Summernote, however this requires jQuery and is not > easily configurable via resources. By switching to Wysihtml instead, we could > remove the dependency on jQuery and both integrate the RTE look and feel and > configure it at a granular level from the resource structure. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-8048) CMS - UI - Switch RTE to Wysihtml
Dan Klco created SLING-8048: --- Summary: CMS - UI - Switch RTE to Wysihtml Key: SLING-8048 URL: https://issues.apache.org/jira/browse/SLING-8048 Project: Sling Issue Type: Improvement Affects Versions: App CMS 0.10.0 Reporter: Dan Klco Assignee: Dan Klco Fix For: App CMS 0.10.2 Currently the CMS uses Summernote, however this requires jQuery and is not easily configurable via resources. By switching to Wysihtml instead, we could remove the dependency on jQuery and both integrate the RTE look and feel and configure it at a granular level from the resource structure. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [VOTE] Move health checks to Felix
+1 David Bosschaert On Mon, 22 Oct 2018 at 15:10, Georg Henzler wrote: > Hi all, > > to follow up on this conversation I would like to start a vote from > Sling side to give green light for the move of Health Checks to Felix > [1]. The Felix project has expressed interest [2]. > > Please vote to approve the move: > >[ ] +1 Approve the move >[ ] 0 Don't care >[ ] -1 I have concerns, in particular... > > This majority vote is open for at least 72 hours. > > -Georg > > [1] > https://issues.apache.org/jira/browse/SLING-7980 > https://issues.apache.org/jira/browse/FELIX-5952 > > [2] > https://www.mail-archive.com/dev@felix.apache.org/msg46780.html > > > On 2018-10-11 16:17, Georg Henzler wrote: > > Hi Bertrand, > > > >> Maybe I missed something but I do not see agreement on a concrete plan > >> here so IMO the move is premature. > > > > I had the feeling that there was an agreement that it is definitely > > good to move the health checks to felix to make them available to a > > larger audience, maybe there wasn't a clear agreement on how to do > > this exactly yet, but I think we get closer to this. > > > >> 1) How do we keep compatibility so that Sling users can use the Felix > >> HCs in the future... > > > > There is a clear path on how to migrate (replace api dependency and > > search and replace over java import statements replacing sling.hc.api > > with felix.hc.api). The version as attached to FELIX-5952 fully > > supports the HC API as well without having it as dependency (see [1] > > for details) - this means that all health checks that exist out there > > work without change. However the next release of sling.hc.api should > > deprecate it so everyone that upgrades gets the messages to use the > > Felix API instead of the Sling API (I created [2] for it). > > > >> ... without ending up with two distinct projects each > >> with their own smaller fractured community > > > > Deprecation of the Sling HC API and a clear migration path will not > > fracture the community I believe... rather having the HC API in Felix > > will allow all users/projects on the Felix platform to use it (e.g. > > ServiceMix projects) > > > >> 2) How can Sling committers maintain the module once it moves to > >> Felix, is the Felix PMC open to give us write access to it? > > > > I think the Felix community is open to invite people for it [3] > > > >> 3) What's the plan w.rt. merging with the systemready module > > > > I agree with Christian here [4] that systemready can be implemented as > > health check (once some minor improvements have been made to the > > current API) > > > >> Before this is defined and agreed upon, I think a move is premature > >> and likely to end up with two distinct modules and communities. > > > > I really want to avoid this as well! > > > > -Georg > > > > > > [1] > > > https://issues.apache.org/jira/browse/FELIX-5952?focusedCommentId=16643281=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16643281 > > [2] https://issues.apache.org/jira/browse/SLING-7980 > > [3] > > > https://lists.apache.org/thread.html/974b95a91e3d4f2e5ba3aec1f04a85eb2adf65d80e24ea78287284af@%3Cdev.felix.apache.org%3E > > > > [4] > > From > > > https://lists.apache.org/thread.html/2a10823b9e8304c175cd1c8724d8903b04d4a5640e3e5e85e97a2fc7@%3Cdev.felix.apache.org%3E > > > >> As sling hc is a lot more mature and battle proven I can imagine to > >> move to > >> this basic framework and change the system ready checks to this API. >
Re: [VOTE] Release Apache Sling 11
On Friday 19 October 2018 18:03:53 Robert Munteanu wrote: > Obviously, this is a [VOTE]... > > On Fri, 2018-10-19 at 18:02 +0200, Robert Munteanu wrote: > > Hi, > > > > This is the vote for releasing Sling 11 and the associated > > artifacts. > > > > More precisely: > > > > - org.apache.sling.starter-11 > > - org.apache.sling.launchpad.test-services-2.0.16 > > - org.apache.sling.junit.teleporter-1.0.18 > > - org.apache.sling.launchpad.integration-tests-1.0.8 > > - org.apache.sling.launchpad.test-fragment-2.0.16 > > - org.apache.sling.launchpad.test-services-war-2.0.16 > > - org.apache.sling.launchpad.test-bundles-0.0.6 > > - org.apache.sling.launchpad.testing-11 > > - org.apache.sling.launchpad.testing-war-11 > > - sling-launchpad-archetype 1.0.8 should be sling-starter-archetype > > > > Note that through a funny coincidence this Starter release got the > > 2000 > > staging repository, which I guess is a fitting, round, number. > > > > We solved 29 issues in these releases > > > > https://issues.apache.org/jira/projects/SLING/versions/12342436 > > https://issues.apache.org/jira/projects/SLING/versions/12343904 > > https://issues.apache.org/jira/projects/SLING/versions/12341682 > > https://issues.apache.org/jira/projects/SLING/versions/12342714 > > https://issues.apache.org/jira/projects/SLING/versions/12342749 > > https://issues.apache.org/jira/projects/SLING/versions/12342575 > > https://issues.apache.org/jira/projects/SLING/versions/12342642 > > https://issues.apache.org/jira/projects/SLING/versions/12342720 > > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-2000 +1 O.
[jira] [Commented] (SLING-8038) Allow the Repository MOJO specify including features from CLI
[
https://issues.apache.org/jira/browse/SLING-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16659329#comment-16659329
]
ASF GitHub Bot commented on SLING-8038:
---
DominikSuess commented on issue #13: SLING-8038 - Allow the Repository MOJO
specify including features from CLI
URL:
https://github.com/apache/sling-slingfeature-maven-plugin/pull/13#issuecomment-431816759
@simonetripodi @cziegeler - added patches in
https://github.com/apache/sling-slingfeature-maven-plugin/pull/14
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Allow the Repository MOJO specify including features from CLI
> -
>
> Key: SLING-8038
> URL: https://issues.apache.org/jira/browse/SLING-8038
> Project: Sling
> Issue Type: Improvement
> Components: Maven Plugins and Archetypes
>Reporter: Simone Tripodi
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0
>
>
> The is a need of creating a standalone Repository, the {{RepositoryMojo}}
> does already that job, BUT requirement is having a tool which can be easily
> invoked from CLI (where the
> {{org.apache.sling.feature.maven.mojos.DependencyLifecycleParticipant}} is
> not invoked due to the fact that plugin extensions could not be enabled).
> PS is coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] DominikSuess commented on issue #13: SLING-8038 - Allow the Repository MOJO specify including features from CLI
DominikSuess commented on issue #13: SLING-8038 - Allow the Repository MOJO specify including features from CLI URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/13#issuecomment-431816759 @simonetripodi @cziegeler - added patches in https://github.com/apache/sling-slingfeature-maven-plugin/pull/14 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] ghenzler commented on issue #2: SLING-8029 Retrieve gpg key automatically if it is missing in keyring
ghenzler commented on issue #2: SLING-8029 Retrieve gpg key automatically if it is missing in keyring URL: https://github.com/apache/sling-tooling-release/pull/2#issuecomment-431813721 If we do not use `--auto-key-retrieve` people will have to use `--recv-keys`, but I'm not sure that really everyone would cross-check with the fingerprint in [1]... we could automate that by going back to a solution similar to 2a986a96eeda5c08 (without `--auto-key-retrieve`), but with automatically cross-checking the fingerprint of the received key with [1] (using curl to get [1] and find the downloaded key's fingerprint in that result and then only running `gpg --verify` if valid) [1] https://people.apache.org/keys/group/sling.asc This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] DominikSuess opened a new pull request #14: Issue/sling 8038
DominikSuess opened a new pull request #14: Issue/sling 8038 URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/14 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (SLING-8002) DistributedEventReceiver utilizes long-running session
[
https://issues.apache.org/jira/browse/SLING-8002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16659068#comment-16659068
]
Jörg Hoh commented on SLING-8002:
-
Removing the warning does not fix the underlying issue, which is here a
long-running JCR session without any refresh. This is an anti-pattern for quite
some time.
> DistributedEventReceiver utilizes long-running session
> --
>
> Key: SLING-8002
> URL: https://issues.apache.org/jira/browse/SLING-8002
> Project: Sling
> Issue Type: Improvement
> Components: Event
>Affects Versions: Distributed Event Admin 1.1.2
>Reporter: Jörg Hoh
>Priority: Major
> Attachments: SLING-8002.patch
>
>
> We recently came across this warning in our logs. Looks like the
> DistributedEventReceiver uses a long-running session, thus causing warnings
> from Oak.
> {noformat}
> 10.10.2018 10:02:37.620 *WARN* [Thread-51]
> org.apache.jackrabbit.oak.jcr.session.RefreshStrategy This session has been
> idle for 5 minutes and might be out of date. Consider using a fresh session
> or explicitly refresh the session.
> java.lang.Exception: The session was created here:
> at
> org.apache.jackrabbit.oak.jcr.session.RefreshStrategy$LogOnce.(RefreshStrategy.java:170)
>
> at
> org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:285)
>
> at
> com.adobe.granite.repository.impl.CRX3RepositoryImpl.login(CRX3RepositoryImpl.java:150)
>
> at
> com.adobe.granite.repository.impl.CRX3RepositoryImpl.login(CRX3RepositoryImpl.java:241)
>
> at
> com.adobe.granite.repository.impl.SlingRepositoryImpl$4.run(SlingRepositoryImpl.java:177)
>
> at
> com.adobe.granite.repository.impl.SlingRepositoryImpl$4.run(SlingRepositoryImpl.java:174)
>
> at
> java.security.AccessController.doPrivileged(AccessController.java:686)
> at javax.security.auth.Subject.doAsPrivileged(Subject.java:729)
> at
> com.adobe.granite.repository.impl.SlingRepositoryImpl.createServiceSession(SlingRepositoryImpl.java:174)
>
> at
> org.apache.sling.jcr.base.AbstractSlingRepository2.createServiceSession(AbstractSlingRepository2.java:166)
>
> at
> org.apache.sling.jcr.base.AbstractSlingRepository2.loginService(AbstractSlingRepository2.java:381)
>
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrProviderStateFactory.createProviderState(JcrProviderStateFactory.java:116)
>
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.authenticate(JcrResourceProvider.java:304)
>
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.authenticate(JcrResourceProvider.java:76)
>
> at
> org.apache.sling.resourceresolver.impl.providers.stateful.ProviderManager.authenticate(ProviderManager.java:161)
>
> at
> org.apache.sling.resourceresolver.impl.providers.stateful.ProviderManager.getOrCreateProvider(ProviderManager.java:87)
>
> at
> org.apache.sling.resourceresolver.impl.providers.stateful.ProviderManager.authenticateAll(ProviderManager.java:129)
>
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.createControl(ResourceResolverImpl.java:138)
>
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.(ResourceResolverImpl.java:100)
>
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.(ResourceResolverImpl.java:94)
>
> at
> org.apache.sling.resourceresolver.impl.CommonResourceResolverFactoryImpl.getResourceResolverInternal(CommonResourceResolverFactoryImpl.java:263)
>
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverFactoryImpl.getServiceResourceResolver(ResourceResolverFactoryImpl.java:96)
>
> at
> org.apache.sling.event.dea.impl.DistributedEventReceiver$1.run(DistributedEventReceiver.java:139)
>
> at java.lang.Thread.run(Thread.java:785)
> {noformat}
> Either the scope of the session should be reduced, or the session should be
> refreshed before writing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-8002) DistributedEventReceiver utilizes long-running session
[
https://issues.apache.org/jira/browse/SLING-8002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16659041#comment-16659041
]
Robert Munteanu commented on SLING-8002:
[~joerghoh] - I see that this particular warnings has been removed with
OAK-6402 , which to me signals that we should approach these on a case-by-case
basis instead. I would suggest to leave the code as is. WDYT?
> DistributedEventReceiver utilizes long-running session
> --
>
> Key: SLING-8002
> URL: https://issues.apache.org/jira/browse/SLING-8002
> Project: Sling
> Issue Type: Improvement
> Components: Event
>Affects Versions: Distributed Event Admin 1.1.2
>Reporter: Jörg Hoh
>Priority: Major
> Attachments: SLING-8002.patch
>
>
> We recently came across this warning in our logs. Looks like the
> DistributedEventReceiver uses a long-running session, thus causing warnings
> from Oak.
> {noformat}
> 10.10.2018 10:02:37.620 *WARN* [Thread-51]
> org.apache.jackrabbit.oak.jcr.session.RefreshStrategy This session has been
> idle for 5 minutes and might be out of date. Consider using a fresh session
> or explicitly refresh the session.
> java.lang.Exception: The session was created here:
> at
> org.apache.jackrabbit.oak.jcr.session.RefreshStrategy$LogOnce.(RefreshStrategy.java:170)
>
> at
> org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:285)
>
> at
> com.adobe.granite.repository.impl.CRX3RepositoryImpl.login(CRX3RepositoryImpl.java:150)
>
> at
> com.adobe.granite.repository.impl.CRX3RepositoryImpl.login(CRX3RepositoryImpl.java:241)
>
> at
> com.adobe.granite.repository.impl.SlingRepositoryImpl$4.run(SlingRepositoryImpl.java:177)
>
> at
> com.adobe.granite.repository.impl.SlingRepositoryImpl$4.run(SlingRepositoryImpl.java:174)
>
> at
> java.security.AccessController.doPrivileged(AccessController.java:686)
> at javax.security.auth.Subject.doAsPrivileged(Subject.java:729)
> at
> com.adobe.granite.repository.impl.SlingRepositoryImpl.createServiceSession(SlingRepositoryImpl.java:174)
>
> at
> org.apache.sling.jcr.base.AbstractSlingRepository2.createServiceSession(AbstractSlingRepository2.java:166)
>
> at
> org.apache.sling.jcr.base.AbstractSlingRepository2.loginService(AbstractSlingRepository2.java:381)
>
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrProviderStateFactory.createProviderState(JcrProviderStateFactory.java:116)
>
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.authenticate(JcrResourceProvider.java:304)
>
> at
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.authenticate(JcrResourceProvider.java:76)
>
> at
> org.apache.sling.resourceresolver.impl.providers.stateful.ProviderManager.authenticate(ProviderManager.java:161)
>
> at
> org.apache.sling.resourceresolver.impl.providers.stateful.ProviderManager.getOrCreateProvider(ProviderManager.java:87)
>
> at
> org.apache.sling.resourceresolver.impl.providers.stateful.ProviderManager.authenticateAll(ProviderManager.java:129)
>
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.createControl(ResourceResolverImpl.java:138)
>
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.(ResourceResolverImpl.java:100)
>
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverImpl.(ResourceResolverImpl.java:94)
>
> at
> org.apache.sling.resourceresolver.impl.CommonResourceResolverFactoryImpl.getResourceResolverInternal(CommonResourceResolverFactoryImpl.java:263)
>
> at
> org.apache.sling.resourceresolver.impl.ResourceResolverFactoryImpl.getServiceResourceResolver(ResourceResolverFactoryImpl.java:96)
>
> at
> org.apache.sling.event.dea.impl.DistributedEventReceiver$1.run(DistributedEventReceiver.java:139)
>
> at java.lang.Thread.run(Thread.java:785)
> {noformat}
> Either the scope of the session should be reduced, or the session should be
> refreshed before writing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-8047) Rendered/exported JSON requested via SlingRequestProcessor is not written to output stream
[
https://issues.apache.org/jira/browse/SLING-8047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Mundt updated SLING-8047:
Description:
While trying to facilitate the {{SlingRequestProcessor}} to get a rendered or
exported JSON representation of a resource, we ran into the problem of the
response always being empty. The HTML rendering worked without any issue.
(See example code of [Get the rendered HTML for an AEM resource, component or
page|http://www.nateyolles.com/blog/2015/10/get-rendered-html-for-an-aem-resource-or-component]
or [https://stackoverflow.com/a/34218708])
Main, observed difference seem to be the method calls to print writer:
h4. JsonRenderer
{{org.apache.sling.servlets.get.impl.helpers.JsonRenderer#render}} uses
{{#write}} method of response's print writer.
h4. ExportServlet (via JacksonExporter)
{{org.apache.sling.models.impl.ExportServlet#doGet}} uses {{#write}} method of
response's print writer.
h4. HTMLRenderer
{{org.apache.sling.servlets.get.impl.helpers.HtmlRenderer#render}} uses
{{#print}} and {{#println}} methods of response's print writer.
h3. Further observations
When the print writer's {{autoFlush}} property is set to true and one uses the
{{#println}} method instead of {{#write}}, the {{JsonRenderer}} will flush the
print writer's buffer to the output stream. Due to wrapping the response in
{{org.apache.sling.scripting.core.impl.helper.OnDemandWriterResponse}} (where
{{autoFlush=false}}) this does not work for the {{ExportServlet}}.
When adding implicit {{#flush()}} calls to both classes, both request scenarios
will work. According to the servlet specification, it should not be necessary
to flush the print writer, as the container must immediately flush all
remaining content to the client upon "termination of the service method of the
servlet".
Please find two test cases for (where implicit {{#flush()}} calls were added):
* JsonRenderer ({{sling-org-apache-sling-servlets-get}}):
[^SLING-8047-DefaultGetServlet-does-not-write-to-output-stream.patch]
* ExportServlet ({{sling-org-apache-sling-models-impl}}):
[^SLING-8047-ExportServlet-does-not-write-to-output-stream.patch]
was:
While trying to facilitate the {{SlingRequestProcessor}} to get a rendered or
exported JSON representation of a resource, we ran into the problem of the
response always being empty. The HTML rendering worked without any issue.
(See example code of [Get the rendered HTML for an AEM resource, component or
page|http://www.nateyolles.com/blog/2015/10/get-rendered-html-for-an-aem-resource-or-component]
or [https://stackoverflow.com/a/34218708])
Main, observed difference seem to be the method calls to print writer:
h4. JsonRenderer
{{org.apache.sling.servlets.get.impl.helpers.JsonRenderer#render}} uses
{{#write}} method of response's print writer.
h4. ExportServlet (via JacksonExporter)
{{org.apache.sling.models.impl.ExportServlet#doGet}} uses {{#write}} method of
response's print writer.
h4. HTMLRenderer
{{org.apache.sling.servlets.get.impl.helpers.HtmlRenderer#render}} uses
{{#print}} and {{#println}} methods of response's print writer.
h3. Further observations
When the print writer's {{autoFlush}} property is set to true and one uses the
{{#println}} method instead of {{#write}}, the {{JsonRenderer}} will flush the
print writer's buffer to the output stream. Due to wrapping the response in
{{org.apache.sling.scripting.core.impl.helper.OnDemandWriterResponse}} (where
{{autoFlush=false}}) this does not work for the {{ExportServlet}}.
When adding implicit {{#flush()}} calls to both classes, both request scenarios
will work. According to the servlet specification, it should not be necessary
to flush the print writer, as the container must immediately flush all
remaining content to the client upon "termination of the service method of the
servlet".
Please find two test cases for (where implicit {{#flush()}} calls were added):
* JsonRenderer:
[^SLING-8047-DefaultGetServlet-does-not-write-to-output-stream.patch]
* ExportServlet:
[^SLING-8047-ExportServlet-does-not-write-to-output-stream.patch]
> Rendered/exported JSON requested via SlingRequestProcessor is not written to
> output stream
> --
>
> Key: SLING-8047
> URL: https://issues.apache.org/jira/browse/SLING-8047
> Project: Sling
> Issue Type: Bug
> Components: Feature Model, Servlets
>Reporter: Philip Mundt
>Priority: Major
> Attachments:
> SLING-8047-DefaultGetServlet-does-not-write-to-output-stream.patch,
> SLING-8047-ExportServlet-does-not-write-to-output-stream.patch
>
>
> While trying to facilitate the {{SlingRequestProcessor}} to get a rendered or
> exported JSON representation of a resource, we ran into the problem of the
> response
[jira] [Updated] (SLING-8047) Rendered/exported JSON requested via SlingRequestProcessor is not written to output stream
[
https://issues.apache.org/jira/browse/SLING-8047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Mundt updated SLING-8047:
Description:
While trying to facilitate the {{SlingRequestProcessor}} to get a rendered or
exported JSON representation of a resource, we ran into the problem of the
response always being empty. The HTML rendering worked without any issue.
(See example code of [Get the rendered HTML for an AEM resource, component or
page|http://www.nateyolles.com/blog/2015/10/get-rendered-html-for-an-aem-resource-or-component]
or [https://stackoverflow.com/a/34218708])
Main, observed difference seem to be the method calls to print writer:
h4. JsonRenderer
{{org.apache.sling.servlets.get.impl.helpers.JsonRenderer#render}} uses
{{#write}} method of response's print writer.
h4. ExportServlet (via JacksonExporter)
{{org.apache.sling.models.impl.ExportServlet#doGet}} uses {{#write}} method of
response's print writer.
h4. HTMLRenderer
{{org.apache.sling.servlets.get.impl.helpers.HtmlRenderer#render}} uses
{{#print}} and {{#println}} methods of response's print writer.
h3. Further observations
When the print writer's {{autoFlush}} property is set to true and one uses the
{{#println}} method instead of {{#write}}, the {{JsonRenderer}} will flush the
print writer's buffer to the output stream. Due to wrapping the response in
{{org.apache.sling.scripting.core.impl.helper.OnDemandWriterResponse}} (where
{{autoFlush=false}}) this does not work for the {{ExportServlet}}.
When adding implicit {{#flush()}} calls to both classes, both request scenarios
will work. According to the servlet specification, it should not be necessary
to flush the print writer, as the container must immediately flush all
remaining content to the client upon "termination of the service method of the
servlet".
Please find two test cases for (where implicit {{#flush()}} calls were added):
* JsonRenderer:
[^SLING-8047-DefaultGetServlet-does-not-write-to-output-stream.patch]
* ExportServlet:
[^SLING-8047-ExportServlet-does-not-write-to-output-stream.patch]
was:
While trying to facilitate the {{SlingRequestProcessor}} to get a rendered or
exported JSON representation of a resource, we ran into the problem of the
response always being empty. The HTML rendering worked without any issue.
(See example code of [Get the rendered HTML for an AEM resource, component or
page|http://www.nateyolles.com/blog/2015/10/get-rendered-html-for-an-aem-resource-or-component]
or [https://stackoverflow.com/a/34218708])
Main, observed difference seem to be the method calls to print writer:
h4. JsonRenderer
{{org.apache.sling.servlets.get.impl.helpers.JsonRenderer#render}} uses
{{#write}} method of response's print writer.
h4. ExportServlet (via JacksonExporter)
{{org.apache.sling.models.impl.ExportServlet#doGet}} uses {{#write}} method of
response's print writer.
h4. HTMLRenderer
{{org.apache.sling.servlets.get.impl.helpers.HtmlRenderer#render}} uses
{{#print}} and {{#println}} methods of response's print writer.
h3. Further observations
When the print writer's {{autoFlush}} property is set to true and one uses the
{{#println}} method instead of {{#write}}, the {{JsonRenderer}} will flush the
print writer's buffer to the output stream. Due to wrapping the response in
{{org.apache.sling.scripting.core.impl.helper.OnDemandWriterResponse}} (where
{{autoFlush=false}}) this does not work for the {{ExportServlet}}.
When adding implicit {{#flush()}} calls to both classes, both request scenarios
will work. According to the servlet specification, it should not be necessary
to flush the print writer, as the container must immediately flush all
remaining content to the client upon "termination of the service method of the
servlet".
Please find two test cases for (where implicit {{#flush()}} calls were added):
* JsonRenderer (tbd)
* ExportServlet (tbd)
> Rendered/exported JSON requested via SlingRequestProcessor is not written to
> output stream
> --
>
> Key: SLING-8047
> URL: https://issues.apache.org/jira/browse/SLING-8047
> Project: Sling
> Issue Type: Bug
> Components: Feature Model, Servlets
>Reporter: Philip Mundt
>Priority: Major
> Attachments:
> SLING-8047-DefaultGetServlet-does-not-write-to-output-stream.patch,
> SLING-8047-ExportServlet-does-not-write-to-output-stream.patch
>
>
> While trying to facilitate the {{SlingRequestProcessor}} to get a rendered or
> exported JSON representation of a resource, we ran into the problem of the
> response always being empty. The HTML rendering worked without any issue.
> (See example code of [Get the rendered HTML for an AEM resource, component or
>
[jira] [Updated] (SLING-8047) Rendered/exported JSON requested via SlingRequestProcessor is not written to output stream
[
https://issues.apache.org/jira/browse/SLING-8047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Mundt updated SLING-8047:
Attachment:
SLING-8047-DefaultGetServlet-does-not-write-to-output-stream.patch
SLING-8047-ExportServlet-does-not-write-to-output-stream.patch
> Rendered/exported JSON requested via SlingRequestProcessor is not written to
> output stream
> --
>
> Key: SLING-8047
> URL: https://issues.apache.org/jira/browse/SLING-8047
> Project: Sling
> Issue Type: Bug
> Components: Feature Model, Servlets
>Reporter: Philip Mundt
>Priority: Major
> Attachments:
> SLING-8047-DefaultGetServlet-does-not-write-to-output-stream.patch,
> SLING-8047-ExportServlet-does-not-write-to-output-stream.patch
>
>
> While trying to facilitate the {{SlingRequestProcessor}} to get a rendered or
> exported JSON representation of a resource, we ran into the problem of the
> response always being empty. The HTML rendering worked without any issue.
> (See example code of [Get the rendered HTML for an AEM resource, component or
> page|http://www.nateyolles.com/blog/2015/10/get-rendered-html-for-an-aem-resource-or-component]
> or [https://stackoverflow.com/a/34218708])
> Main, observed difference seem to be the method calls to print writer:
> h4. JsonRenderer
> {{org.apache.sling.servlets.get.impl.helpers.JsonRenderer#render}} uses
> {{#write}} method of response's print writer.
> h4. ExportServlet (via JacksonExporter)
> {{org.apache.sling.models.impl.ExportServlet#doGet}} uses {{#write}} method
> of response's print writer.
> h4. HTMLRenderer
> {{org.apache.sling.servlets.get.impl.helpers.HtmlRenderer#render}} uses
> {{#print}} and {{#println}} methods of response's print writer.
> h3. Further observations
> When the print writer's {{autoFlush}} property is set to true and one uses
> the {{#println}} method instead of {{#write}}, the {{JsonRenderer}} will
> flush the print writer's buffer to the output stream. Due to wrapping the
> response in
> {{org.apache.sling.scripting.core.impl.helper.OnDemandWriterResponse}} (where
> {{autoFlush=false}}) this does not work for the {{ExportServlet}}.
> When adding implicit {{#flush()}} calls to both classes, both request
> scenarios will work. According to the servlet specification, it should not be
> necessary to flush the print writer, as the container must immediately flush
> all remaining content to the client upon "termination of the service method
> of the servlet".
> Please find two test cases for (where implicit {{#flush()}} calls were added):
> * JsonRenderer (tbd)
> * ExportServlet (tbd)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [VOTE] Release Apache Sling 11
+1 On 2018-10-19 18:03, Robert Munteanu wrote: Obviously, this is a [VOTE]... On Fri, 2018-10-19 at 18:02 +0200, Robert Munteanu wrote: Hi, This is the vote for releasing Sling 11 and the associated artifacts. More precisely: - org.apache.sling.starter-11 - org.apache.sling.launchpad.test-services-2.0.16 - org.apache.sling.junit.teleporter-1.0.18 - org.apache.sling.launchpad.integration-tests-1.0.8 - org.apache.sling.launchpad.test-fragment-2.0.16 - org.apache.sling.launchpad.test-services-war-2.0.16 - org.apache.sling.launchpad.test-bundles-0.0.6 - org.apache.sling.launchpad.testing-11 - org.apache.sling.launchpad.testing-war-11 - sling-launchpad-archetype 1.0.8 Note that through a funny coincidence this Starter release got the 2000 staging repository, which I guess is a fitting, round, number. We solved 29 issues in these releases https://issues.apache.org/jira/projects/SLING/versions/12342436 https://issues.apache.org/jira/projects/SLING/versions/12343904 https://issues.apache.org/jira/projects/SLING/versions/12341682 https://issues.apache.org/jira/projects/SLING/versions/12342714 https://issues.apache.org/jira/projects/SLING/versions/12342749 https://issues.apache.org/jira/projects/SLING/versions/12342575 https://issues.apache.org/jira/projects/SLING/versions/12342642 https://issues.apache.org/jira/projects/SLING/versions/12342720 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2000 You can use this UNIX script to download the release and verify the signatures: https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD Usage: sh check_staged_release.sh 2000 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Thanks, Robert
Re: [VOTE] Move health checks to Felix
+1 On 2018-10-22 15:10, Georg Henzler wrote: Hi all, to follow up on this conversation I would like to start a vote from Sling side to give green light for the move of Health Checks to Felix [1]. The Felix project has expressed interest [2]. Please vote to approve the move: [ ] +1 Approve the move [ ] 0 Don't care [ ] -1 I have concerns, in particular... This majority vote is open for at least 72 hours. -Georg [1] https://issues.apache.org/jira/browse/SLING-7980 https://issues.apache.org/jira/browse/FELIX-5952 [2] https://www.mail-archive.com/dev@felix.apache.org/msg46780.html On 2018-10-11 16:17, Georg Henzler wrote: Hi Bertrand, Maybe I missed something but I do not see agreement on a concrete plan here so IMO the move is premature. I had the feeling that there was an agreement that it is definitely good to move the health checks to felix to make them available to a larger audience, maybe there wasn't a clear agreement on how to do this exactly yet, but I think we get closer to this. 1) How do we keep compatibility so that Sling users can use the Felix HCs in the future... There is a clear path on how to migrate (replace api dependency and search and replace over java import statements replacing sling.hc.api with felix.hc.api). The version as attached to FELIX-5952 fully supports the HC API as well without having it as dependency (see [1] for details) - this means that all health checks that exist out there work without change. However the next release of sling.hc.api should deprecate it so everyone that upgrades gets the messages to use the Felix API instead of the Sling API (I created [2] for it). ... without ending up with two distinct projects each with their own smaller fractured community Deprecation of the Sling HC API and a clear migration path will not fracture the community I believe... rather having the HC API in Felix will allow all users/projects on the Felix platform to use it (e.g. ServiceMix projects) 2) How can Sling committers maintain the module once it moves to Felix, is the Felix PMC open to give us write access to it? I think the Felix community is open to invite people for it [3] 3) What's the plan w.rt. merging with the systemready module I agree with Christian here [4] that systemready can be implemented as health check (once some minor improvements have been made to the current API) Before this is defined and agreed upon, I think a move is premature and likely to end up with two distinct modules and communities. I really want to avoid this as well! -Georg [1] https://issues.apache.org/jira/browse/FELIX-5952?focusedCommentId=16643281=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16643281 [2] https://issues.apache.org/jira/browse/SLING-7980 [3] https://lists.apache.org/thread.html/974b95a91e3d4f2e5ba3aec1f04a85eb2adf65d80e24ea78287284af@%3Cdev.felix.apache.org%3E [4] From https://lists.apache.org/thread.html/2a10823b9e8304c175cd1c8724d8903b04d4a5640e3e5e85e97a2fc7@%3Cdev.felix.apache.org%3E As sling hc is a lot more mature and battle proven I can imagine to move to this basic framework and change the system ready checks to this API.
[jira] [Created] (SLING-8047) Rendered/exported JSON requested via SlingRequestProcessor is not written to output stream
Philip Mundt created SLING-8047:
---
Summary: Rendered/exported JSON requested via
SlingRequestProcessor is not written to output stream
Key: SLING-8047
URL: https://issues.apache.org/jira/browse/SLING-8047
Project: Sling
Issue Type: Bug
Components: Feature Model, Servlets
Reporter: Philip Mundt
While trying to facilitate the {{SlingRequestProcessor}} to get a rendered or
exported JSON representation of a resource, we ran into the problem of the
response always being empty. The HTML rendering worked without any issue.
(See example code of [Get the rendered HTML for an AEM resource, component or
page|http://www.nateyolles.com/blog/2015/10/get-rendered-html-for-an-aem-resource-or-component]
or [https://stackoverflow.com/a/34218708])
Main, observed difference seem to be the method calls to print writer:
h4. JsonRenderer
{{org.apache.sling.servlets.get.impl.helpers.JsonRenderer#render}} uses
{{#write}} method of response's print writer.
h4. ExportServlet (via JacksonExporter)
{{org.apache.sling.models.impl.ExportServlet#doGet}} uses {{#write}} method of
response's print writer.
h4. HTMLRenderer
{{org.apache.sling.servlets.get.impl.helpers.HtmlRenderer#render}} uses
{{#print}} and {{#println}} methods of response's print writer.
h3. Further observations
When the print writer's {{autoFlush}} property is set to true and one uses the
{{#println}} method instead of {{#write}}, the {{JsonRenderer}} will flush the
print writer's buffer to the output stream. Due to wrapping the response in
{{org.apache.sling.scripting.core.impl.helper.OnDemandWriterResponse}} (where
{{autoFlush=false}}) this does not work for the {{ExportServlet}}.
When adding implicit {{#flush()}} calls to both classes, both request scenarios
will work. According to the servlet specification, it should not be necessary
to flush the print writer, as the container must immediately flush all
remaining content to the client upon "termination of the service method of the
servlet".
Please find two test cases for (where implicit {{#flush()}} calls were added):
* JsonRenderer (tbd)
* ExportServlet (tbd)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [VOTE] Move health checks to Felix
+1 Konrad > On 22. Oct 2018, at 15:10, Georg Henzler wrote: > > Hi all, > > to follow up on this conversation I would like to start a vote from Sling > side to give green light for the move of Health Checks to Felix [1]. The > Felix project has expressed interest [2]. > > Please vote to approve the move: > > [ ] +1 Approve the move > [ ] 0 Don't care > [ ] -1 I have concerns, in particular... > > This majority vote is open for at least 72 hours. > > -Georg > > [1] > https://issues.apache.org/jira/browse/SLING-7980 > https://issues.apache.org/jira/browse/FELIX-5952 > > [2] > https://www.mail-archive.com/dev@felix.apache.org/msg46780.html > > > On 2018-10-11 16:17, Georg Henzler wrote: >> Hi Bertrand, >>> Maybe I missed something but I do not see agreement on a concrete plan >>> here so IMO the move is premature. >> I had the feeling that there was an agreement that it is definitely >> good to move the health checks to felix to make them available to a >> larger audience, maybe there wasn't a clear agreement on how to do >> this exactly yet, but I think we get closer to this. >>> 1) How do we keep compatibility so that Sling users can use the Felix >>> HCs in the future... >> There is a clear path on how to migrate (replace api dependency and >> search and replace over java import statements replacing sling.hc.api >> with felix.hc.api). The version as attached to FELIX-5952 fully >> supports the HC API as well without having it as dependency (see [1] >> for details) - this means that all health checks that exist out there >> work without change. However the next release of sling.hc.api should >> deprecate it so everyone that upgrades gets the messages to use the >> Felix API instead of the Sling API (I created [2] for it). >>> ... without ending up with two distinct projects each >>> with their own smaller fractured community >> Deprecation of the Sling HC API and a clear migration path will not >> fracture the community I believe... rather having the HC API in Felix >> will allow all users/projects on the Felix platform to use it (e.g. >> ServiceMix projects) >>> 2) How can Sling committers maintain the module once it moves to >>> Felix, is the Felix PMC open to give us write access to it? >> I think the Felix community is open to invite people for it [3] >>> 3) What's the plan w.rt. merging with the systemready module >> I agree with Christian here [4] that systemready can be implemented as >> health check (once some minor improvements have been made to the >> current API) >>> Before this is defined and agreed upon, I think a move is premature >>> and likely to end up with two distinct modules and communities. >> I really want to avoid this as well! >> -Georg >> [1] >> https://issues.apache.org/jira/browse/FELIX-5952?focusedCommentId=16643281=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16643281 >> [2] https://issues.apache.org/jira/browse/SLING-7980 >> [3] >> https://lists.apache.org/thread.html/974b95a91e3d4f2e5ba3aec1f04a85eb2adf65d80e24ea78287284af@%3Cdev.felix.apache.org%3E >> [4] >> From >> https://lists.apache.org/thread.html/2a10823b9e8304c175cd1c8724d8903b04d4a5640e3e5e85e97a2fc7@%3Cdev.felix.apache.org%3E >>> As sling hc is a lot more mature and battle proven I can imagine to move to >>> this basic framework and change the system ready checks to this API.
[VOTE] Move health checks to Felix
Hi all, to follow up on this conversation I would like to start a vote from Sling side to give green light for the move of Health Checks to Felix [1]. The Felix project has expressed interest [2]. Please vote to approve the move: [ ] +1 Approve the move [ ] 0 Don't care [ ] -1 I have concerns, in particular... This majority vote is open for at least 72 hours. -Georg [1] https://issues.apache.org/jira/browse/SLING-7980 https://issues.apache.org/jira/browse/FELIX-5952 [2] https://www.mail-archive.com/dev@felix.apache.org/msg46780.html On 2018-10-11 16:17, Georg Henzler wrote: Hi Bertrand, Maybe I missed something but I do not see agreement on a concrete plan here so IMO the move is premature. I had the feeling that there was an agreement that it is definitely good to move the health checks to felix to make them available to a larger audience, maybe there wasn't a clear agreement on how to do this exactly yet, but I think we get closer to this. 1) How do we keep compatibility so that Sling users can use the Felix HCs in the future... There is a clear path on how to migrate (replace api dependency and search and replace over java import statements replacing sling.hc.api with felix.hc.api). The version as attached to FELIX-5952 fully supports the HC API as well without having it as dependency (see [1] for details) - this means that all health checks that exist out there work without change. However the next release of sling.hc.api should deprecate it so everyone that upgrades gets the messages to use the Felix API instead of the Sling API (I created [2] for it). ... without ending up with two distinct projects each with their own smaller fractured community Deprecation of the Sling HC API and a clear migration path will not fracture the community I believe... rather having the HC API in Felix will allow all users/projects on the Felix platform to use it (e.g. ServiceMix projects) 2) How can Sling committers maintain the module once it moves to Felix, is the Felix PMC open to give us write access to it? I think the Felix community is open to invite people for it [3] 3) What's the plan w.rt. merging with the systemready module I agree with Christian here [4] that systemready can be implemented as health check (once some minor improvements have been made to the current API) Before this is defined and agreed upon, I think a move is premature and likely to end up with two distinct modules and communities. I really want to avoid this as well! -Georg [1] https://issues.apache.org/jira/browse/FELIX-5952?focusedCommentId=16643281=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16643281 [2] https://issues.apache.org/jira/browse/SLING-7980 [3] https://lists.apache.org/thread.html/974b95a91e3d4f2e5ba3aec1f04a85eb2adf65d80e24ea78287284af@%3Cdev.felix.apache.org%3E [4] From https://lists.apache.org/thread.html/2a10823b9e8304c175cd1c8724d8903b04d4a5640e3e5e85e97a2fc7@%3Cdev.felix.apache.org%3E As sling hc is a lot more mature and battle proven I can imagine to move to this basic framework and change the system ready checks to this API.
[jira] [Closed] (SLING-8026) Sling Oak Restrictions not compatible with oak 1.8.x
[ https://issues.apache.org/jira/browse/SLING-8026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Georg Henzler closed SLING-8026. > Sling Oak Restrictions not compatible with oak 1.8.x > > > Key: SLING-8026 > URL: https://issues.apache.org/jira/browse/SLING-8026 > Project: Sling > Issue Type: Task > Components: Oak >Reporter: Georg Henzler >Assignee: Georg Henzler >Priority: Major > Fix For: Oak Restrictions 1.0.2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The Sling oak restrictions [1] are not compatible to oak 1.8.x since it > imports TreeUtil [2] that is not part of the SPI (and the location has > changed). To maintain compatibility to older oak versions, it would be best > to get rid of the TreeUtil.getString(treeToCheck, SLING_RESOURCE_TYPE) call > altogether (TreeUtils provides a simple type conversion and null check that > can be directly part of ResourceTypePattern to minimise package dependencies). > [1] https://sling.apache.org/documentation/bundles/sling-oak-restrictions.html > [2] > https://github.com/apache/sling-org-apache-sling-oak-restrictions/blob/master/src/main/java/org/apache/sling/oak/restrictions/impl/ResourceTypePattern.java#L28 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Failed Pipeline: sling-ide-tooling » master #52
See https://builds.apache.org/job/sling-ide-tooling/job/master/52/
Re: [VOTE] Release Apache Sling 11
+1 > On 19 Oct 2018, at 18:03, 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.
[jira] [Updated] (SLING-8038) Allow the Repository MOJO specify including features from CLI
[
https://issues.apache.org/jira/browse/SLING-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-8038:
Fix Version/s: slingfeature-maven-plugin 1.0.0
> Allow the Repository MOJO specify including features from CLI
> -
>
> Key: SLING-8038
> URL: https://issues.apache.org/jira/browse/SLING-8038
> Project: Sling
> Issue Type: Improvement
> Components: Maven Plugins and Archetypes
>Reporter: Simone Tripodi
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0
>
>
> The is a need of creating a standalone Repository, the {{RepositoryMojo}}
> does already that job, BUT requirement is having a tool which can be easily
> invoked from CLI (where the
> {{org.apache.sling.feature.maven.mojos.DependencyLifecycleParticipant}} is
> not invoked due to the fact that plugin extensions could not be enabled).
> PS is coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-8038) Allow the Repository MOJO specify including features from CLI
[
https://issues.apache.org/jira/browse/SLING-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-8038:
Component/s: Maven Plugins and Archetypes
> Allow the Repository MOJO specify including features from CLI
> -
>
> Key: SLING-8038
> URL: https://issues.apache.org/jira/browse/SLING-8038
> Project: Sling
> Issue Type: Improvement
> Components: Maven Plugins and Archetypes
>Reporter: Simone Tripodi
>Priority: Major
>
> The is a need of creating a standalone Repository, the {{RepositoryMojo}}
> does already that job, BUT requirement is having a tool which can be easily
> invoked from CLI (where the
> {{org.apache.sling.feature.maven.mojos.DependencyLifecycleParticipant}} is
> not invoked due to the fact that plugin extensions could not be enabled).
> PS is coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-8003) Interpolate Maven variables using the Maven Filtering APIs rather that iterate string replacing operations
[
https://issues.apache.org/jira/browse/SLING-8003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-8003:
Fix Version/s: slingfeature-maven-plugin 1.0.0
> Interpolate Maven variables using the Maven Filtering APIs rather that
> iterate string replacing operations
> --
>
> Key: SLING-8003
> URL: https://issues.apache.org/jira/browse/SLING-8003
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model, Maven Plugins and Archetypes
>Reporter: Simone Tripodi
>Assignee: David Bosschaert
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0
>
>
> Currently, the {{Substitution}} class iterates over all variables and replace
> them one by one in the whole input string.
> We can improve performances - and avoid writing custom variables interpolator
> - by replacing its use with the {{MavenReaderFilter}} API.
> It will helpful also to avoid reading the Feature file and storing it in a
> String, but keep working with {{Reader}} APIs.
> PR is coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (SLING-7961) Adjust feature file reading to latest state
[ https://issues.apache.org/jira/browse/SLING-7961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-7961. - Resolution: Fixed > Adjust feature file reading to latest state > --- > > Key: SLING-7961 > URL: https://issues.apache.org/jira/browse/SLING-7961 > Project: Sling > Issue Type: Improvement > Components: Maven Plugins and Archetypes >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: slingfeature-maven-plugin 1.0.0 > > > The slingfeature plugin uses different logic in the Lifecycleparticipant than > in the mojos to read features. The LP is still using the term of an > application which we droped. These parts need to be aligned. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SLING-8020) AttachFeaturesMojo should allow user to set title, description, vendor and license fields to the attached Feature, taking data from the POM
[
https://issues.apache.org/jira/browse/SLING-8020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved SLING-8020.
-
Resolution: Fixed
> AttachFeaturesMojo should allow user to set title, description, vendor and
> license fields to the attached Feature, taking data from the POM
> ---
>
> Key: SLING-8020
> URL: https://issues.apache.org/jira/browse/SLING-8020
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model, Maven Plugins and Archetypes
>Reporter: Simone Tripodi
>Assignee: David Bosschaert
>Priority: Minor
> Fix For: slingfeature-maven-plugin 1.0.0
>
>
> As per subject, it would be useful if the {{AttachFeaturesMojo}} could expose
> a flag that, if enabled, ({{false}} by default) would set {{title}},
> {{description}}, {{vendor}} and {{license}} fields taking related values from
> the POM.
> PR is coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-8020) AttachFeaturesMojo should allow user to set title, description, vendor and license fields to the attached Feature, taking data from the POM
[
https://issues.apache.org/jira/browse/SLING-8020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-8020:
Fix Version/s: slingfeature-maven-plugin 1.0.0
> AttachFeaturesMojo should allow user to set title, description, vendor and
> license fields to the attached Feature, taking data from the POM
> ---
>
> Key: SLING-8020
> URL: https://issues.apache.org/jira/browse/SLING-8020
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model, Maven Plugins and Archetypes
>Reporter: Simone Tripodi
>Assignee: David Bosschaert
>Priority: Minor
> Fix For: slingfeature-maven-plugin 1.0.0
>
>
> As per subject, it would be useful if the {{AttachFeaturesMojo}} could expose
> a flag that, if enabled, ({{false}} by default) would set {{title}},
> {{description}}, {{vendor}} and {{license}} fields taking related values from
> the POM.
> PR is coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-8034) SlingStart-m-p and SlingFeature-m-p packagetype clash
[
https://issues.apache.org/jira/browse/SLING-8034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-8034:
Fix Version/s: slingfeature-maven-plugin 1.0.0
> SlingStart-m-p and SlingFeature-m-p packagetype clash
> -
>
> Key: SLING-8034
> URL: https://issues.apache.org/jira/browse/SLING-8034
> Project: Sling
> Issue Type: Improvement
> Components: Maven Plugins and Archetypes
>Reporter: Simone Tripodi
>Assignee: David Bosschaert
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0
>
>
> Both MOJOs use the same _slingfeature_ package type - SlingStart-m-p should
> keep the defined package type while SlingFeature-m-p's should be changed,
> i.e. {{slingosgifeature}}.
> PR is coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-8032) Add a MOJO which is able to validate JSON Feature file against the JSON Schema
[
https://issues.apache.org/jira/browse/SLING-8032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-8032:
Fix Version/s: slingfeature-maven-plugin 1.0.0
> Add a MOJO which is able to validate JSON Feature file against the JSON Schema
> --
>
> Key: SLING-8032
> URL: https://issues.apache.org/jira/browse/SLING-8032
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model, Maven Plugins and Archetypes
>Reporter: Simone Tripodi
>Assignee: David Bosschaert
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.0
>
>
> While SLING-7990 contributed the Schema definition, I would like to
> contribute a simple MOJO which is able to validate Feature files against the
> Schema.
> JSON Schema validation does not fit as an {{AnalyserTask}} implementation,
> since {{Feature}} instances are parsed already here, anyway the {{Analyser}}
> takes in charge semantic analysis, while JSON Schema validation is is strict
> about syntax and structure, this is why I would have a separated MOJO which
> can be optionally enabled.
> PR is coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
