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 > > >
RE: [VOTE] Release Apache Sling File Optimization version 0.9.4
+1 stefan p.s. please add the JIRA ticket numbers in your commit messages, that makes reviewing commit logs much easier.
RE: Why get rid of the rewriter?
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] [Commented] (SLING-6203) Create a Maven archetype for content packages
[ https://issues.apache.org/jira/browse/SLING-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16925994#comment-16925994 ] Robert Munteanu commented on SLING-6203: For the feature model I was thinking of setting up a Sling launcher similar to https://github.com/apache/sling-slingstart-archetype . I guess you were thinking about something similar to a content package, but IMO the content packages can stay as they are right now. Of course, if you think converting them to another model brings value feel free to do that. > Create a Maven archetype for content packages > - > > Key: SLING-6203 > URL: https://issues.apache.org/jira/browse/SLING-6203 > Project: Sling > Issue Type: Sub-task > Components: General >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.2#803003)
Re: Release Validator Docker Image
Can we maybe also remove the md5 files and create sha512 files, when the checksum is correct? Carsten Am 09.09.2019 um 19:25 schrieb Daniel Klco: Thanks Radu for doing the hard work. As predicted, once that was in place, the CI check was relatively straightforward. I added the code to check the CI status from GitHub, updated the GPG check to download the Sling key file and added a summary message letting the user know if all of the checks succeeded: https://github.com/apache/sling-org-apache-sling-committer-cli/commit/310b49d9d57ba97cc651468ab14143f15433b202 You should now be able to do the following: bash-3.2$ docker run --env-file=./docker-env apache/sling-cli release verify --repository=2126 org.apache.sling.fileoptim-0.9.4-source-release.zip GPG: signed by Dan Klco (CODE SIGNING KEY) with key (id=0xF0EAC1A44C6E4124; fingerprint=4D78347F4F4F868D8EC2CD13F0EAC1A44C6E4124) SHA-1: VALID (ea25bb7fb0cb0bff51f20eb4d21cb91d5262259d) MD-5: VALID (69c30bb2f5e117d1f4ba2d4278b15c0e) org.apache.sling.fileoptim-0.9.4.jar GPG: signed by Dan Klco (CODE SIGNING KEY) with key (id=0xF0EAC1A44C6E4124; fingerprint=4D78347F4F4F868D8EC2CD13F0EAC1A44C6E4124) SHA-1: VALID (5a5df233209b018420f4255a3a087aeff8bb0a01) MD-5: VALID (8be14fc95cb74e1d3ff23869dfe9afef) org.apache.sling.fileoptim-0.9.4.pom GPG: signed by Dan Klco (CODE SIGNING KEY) with key (id=0xF0EAC1A44C6E4124; fingerprint=4D78347F4F4F868D8EC2CD13F0EAC1A44C6E4124) SHA-1: VALID (e08d7a115313af4c10e7006022d730e07a1cfc42) MD-5: VALID (cfc07c2782b95a3c41e0b8b61fff54f2) CI Status: VALID: continuous-integration/jenkins/branch State: success Description: This commit looks good See: https://builds.apache.org/job/Sling/job/sling-org-apache-sling-file-optimization/job/master/37/display/redirect org.apache.sling.fileoptim-0.9.4-javadoc.jar GPG: signed by Dan Klco (CODE SIGNING KEY) with key (id=0xF0EAC1A44C6E4124; fingerprint=4D78347F4F4F868D8EC2CD13F0EAC1A44C6E4124) SHA-1: VALID (003ebb552c39c7df07613ed21e7d11d8cc51d27a) MD-5: VALID (f9b54cca8995a115b978716bb5ac9c14) org.apache.sling.fileoptim-0.9.4-sources.jar GPG: signed by Dan Klco (CODE SIGNING KEY) with key (id=0xF0EAC1A44C6E4124; fingerprint=4D78347F4F4F868D8EC2CD13F0EAC1A44C6E4124) SHA-1: VALID (ff94c1c349390cd6e9e4316c648ce6909757bef2) MD-5: VALID (746e62e2e70c006ad083ac76c18da798) Release Summary: VALID (16 checks executed) On Mon, Sep 9, 2019 at 9:16 AM Daniel Klco wrote: Nice! The approach using the Lucene search of the repo contents is much cleaner than what I was thinking. On Sun, Sep 8, 2019 at 1:00 PM Radu Cotescu wrote: Hi Daniel, On 6 Sep 2019, at 18:01, Daniel Klco wrote: Thanks Radu, I've been looking into this on and off over the last few days and I'm still struggling to see the value of re-implementing all of this in Java instead of relying on a simple series of scripts. Sure it's possible to do GPG key and Hash validation, but I'd still need to write a scraper to download the artifacts from Nexus and then all of the code around these other functions, each of which are hundreds of lines of Java code vs a single line in BASH. What would you think about flipping this the other way around? Instead of re-implementing in Java, make the docker image more flexible and use scripts to decide which function to invoke? I've put together a quick example of what I'm thinking here: https://github.com/apache/sling-org-apache-sling-committer-cli/tree/bash-validate I’ve managed to implement the missing pieces during last week’s hackathon and on Friday afternoon [3]. The fact that we ship a Docker image with that code is just convenience I guess. The functionality is implemented actually as an OSGi app using the Sling feature model, so we could pack it however we want. Cheers, Radu [3] - https://issues.apache.org/jira/browse/SLING-8684 < https://issues.apache.org/jira/browse/SLING-8684> -- -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Release Validator Docker Image
Thanks Radu for doing the hard work. As predicted, once that was in place, the CI check was relatively straightforward. I added the code to check the CI status from GitHub, updated the GPG check to download the Sling key file and added a summary message letting the user know if all of the checks succeeded: https://github.com/apache/sling-org-apache-sling-committer-cli/commit/310b49d9d57ba97cc651468ab14143f15433b202 You should now be able to do the following: bash-3.2$ docker run --env-file=./docker-env apache/sling-cli release verify --repository=2126 org.apache.sling.fileoptim-0.9.4-source-release.zip GPG: signed by Dan Klco (CODE SIGNING KEY) with key (id=0xF0EAC1A44C6E4124; fingerprint=4D78347F4F4F868D8EC2CD13F0EAC1A44C6E4124) SHA-1: VALID (ea25bb7fb0cb0bff51f20eb4d21cb91d5262259d) MD-5: VALID (69c30bb2f5e117d1f4ba2d4278b15c0e) org.apache.sling.fileoptim-0.9.4.jar GPG: signed by Dan Klco (CODE SIGNING KEY) with key (id=0xF0EAC1A44C6E4124; fingerprint=4D78347F4F4F868D8EC2CD13F0EAC1A44C6E4124) SHA-1: VALID (5a5df233209b018420f4255a3a087aeff8bb0a01) MD-5: VALID (8be14fc95cb74e1d3ff23869dfe9afef) org.apache.sling.fileoptim-0.9.4.pom GPG: signed by Dan Klco (CODE SIGNING KEY) with key (id=0xF0EAC1A44C6E4124; fingerprint=4D78347F4F4F868D8EC2CD13F0EAC1A44C6E4124) SHA-1: VALID (e08d7a115313af4c10e7006022d730e07a1cfc42) MD-5: VALID (cfc07c2782b95a3c41e0b8b61fff54f2) CI Status: VALID: continuous-integration/jenkins/branch State: success Description: This commit looks good See: https://builds.apache.org/job/Sling/job/sling-org-apache-sling-file-optimization/job/master/37/display/redirect org.apache.sling.fileoptim-0.9.4-javadoc.jar GPG: signed by Dan Klco (CODE SIGNING KEY) with key (id=0xF0EAC1A44C6E4124; fingerprint=4D78347F4F4F868D8EC2CD13F0EAC1A44C6E4124) SHA-1: VALID (003ebb552c39c7df07613ed21e7d11d8cc51d27a) MD-5: VALID (f9b54cca8995a115b978716bb5ac9c14) org.apache.sling.fileoptim-0.9.4-sources.jar GPG: signed by Dan Klco (CODE SIGNING KEY) with key (id=0xF0EAC1A44C6E4124; fingerprint=4D78347F4F4F868D8EC2CD13F0EAC1A44C6E4124) SHA-1: VALID (ff94c1c349390cd6e9e4316c648ce6909757bef2) MD-5: VALID (746e62e2e70c006ad083ac76c18da798) Release Summary: VALID (16 checks executed) On Mon, Sep 9, 2019 at 9:16 AM Daniel Klco wrote: > Nice! The approach using the Lucene search of the repo contents is much > cleaner than what I was thinking. > > On Sun, Sep 8, 2019 at 1:00 PM Radu Cotescu wrote: > >> Hi Daniel, >> >> > On 6 Sep 2019, at 18:01, Daniel Klco wrote: >> > >> > Thanks Radu, >> > >> > I've been looking into this on and off over the last few days and I'm >> still >> > struggling to see the value of re-implementing all of this in Java >> instead >> > of relying on a simple series of scripts. Sure it's possible to do GPG >> key >> > and Hash validation, but I'd still need to write a scraper to download >> the >> > artifacts from Nexus and then all of the code around these other >> functions, >> > each of which are hundreds of lines of Java code vs a single line in >> BASH. >> > >> > What would you think about flipping this the other way around? Instead >> of >> > re-implementing in Java, make the docker image more flexible and use >> > scripts to decide which function to invoke? >> > >> > I've put together a quick example of what I'm thinking here: >> > >> > >> https://github.com/apache/sling-org-apache-sling-committer-cli/tree/bash-validate >> > >> >> I’ve managed to implement the missing pieces during last week’s hackathon >> and on Friday afternoon [3]. The fact that we ship a Docker image with that >> code is just convenience I guess. The functionality is implemented actually >> as an OSGi app using the Sling feature model, so we could pack it however >> we want. >> >> Cheers, >> Radu >> >> [3] - https://issues.apache.org/jira/browse/SLING-8684 < >> https://issues.apache.org/jira/browse/SLING-8684> > >
[jira] [Resolved] (SLING-8691) Add Check for CI Build Status
[ https://issues.apache.org/jira/browse/SLING-8691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Klco resolved SLING-8691. - Resolution: Fixed Added in [https://github.com/apache/sling-org-apache-sling-committer-cli/commit/310b49d9d57ba97cc651468ab14143f15433b202] > Add Check for CI Build Status > - > > Key: SLING-8691 > URL: https://issues.apache.org/jira/browse/SLING-8691 > Project: Sling > Issue Type: Sub-task >Reporter: Dan Klco >Assignee: Dan Klco >Priority: Major > Fix For: Committer CLI 1.0.0 > > > In addition to validating the signatures, we should check the CI status for > the release commit. -- This message was sent by Atlassian Jira (v8.3.2#803003)
Re: [VOTE] Release Apache Sling File Optimization version 0.9.4
+1 > On 9 Sep 2019, at 15:18, Daniel Klco wrote: > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ...
Re: [DISCUSS] cutting the first cp2fm-0.0.2 release
+1 Headwire’s Peregrine CMS converts w/o any issues and deploys successfully into an FM Sling. - Andy > On Sep 9, 2019, at 9:47 AM, Simone Tripodi wrote: > > Hi all, > > I would like to start the process to release the first version of the > cp2fm tool - is there any blocker you know that would prevent it? > > TIA! > ~Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/
[jira] [Resolved] (SLING-8682) IT apis-jar-wrapped-flattened-classes fails
[ https://issues.apache.org/jira/browse/SLING-8682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-8682. - Assignee: Simone Tripodi Resolution: Fixed > IT apis-jar-wrapped-flattened-classes fails > --- > > Key: SLING-8682 > URL: https://issues.apache.org/jira/browse/SLING-8682 > Project: Sling > Issue Type: Bug > Components: Maven Plugins and Archetypes >Reporter: Carsten Ziegeler >Assignee: Simone Tripodi >Priority: Major > Fix For: slingfeature-maven-plugin 1.1.2 > > Time Spent: 20m > Remaining Estimate: 0h > > With the correction of subpackage handling in SLING-8681 the > apis-jar-wrapped-flattened-classes fails now. > This might be a bug in our api handling code as the javadoc command does not > get a source -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (SLING-8682) IT apis-jar-wrapped-flattened-classes fails
[ https://issues.apache.org/jira/browse/SLING-8682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16925919#comment-16925919 ] Krystian Nowak commented on SLING-8682: --- [~cziegeler]: PR is merge by [~simone.tripodi] - thanks! This ticket can be therefore mark as resolved and ready for 1.1.2 release. > IT apis-jar-wrapped-flattened-classes fails > --- > > Key: SLING-8682 > URL: https://issues.apache.org/jira/browse/SLING-8682 > Project: Sling > Issue Type: Bug > Components: Maven Plugins and Archetypes >Reporter: Carsten Ziegeler >Priority: Major > Fix For: slingfeature-maven-plugin 1.1.2 > > Time Spent: 20m > Remaining Estimate: 0h > > With the correction of subpackage handling in SLING-8681 the > apis-jar-wrapped-flattened-classes fails now. > This might be a bug in our api handling code as the javadoc command does not > get a source -- This message was sent by Atlassian Jira (v8.3.2#803003)
[DISCUSS] cutting the first cp2fm-0.0.2 release
Hi all, I would like to start the process to release the first version of the cp2fm tool - is there any blocker you know that would prevent it? TIA! ~Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/
[GitHub] [sling-slingfeature-maven-plugin] krystiannowak commented on issue #38: SLING-8682 - preventing javadoc jar generation when sources dir is empty
krystiannowak commented on issue #38: SLING-8682 - preventing javadoc jar generation when sources dir is empty URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/38#issuecomment-529567308 @simonetripodi you're welcome - any time & thanks for the merge! This is an automated message from the Apache Git Service. To respond to the message, please log on to 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-6203) Create a Maven archetype for content packages
[ https://issues.apache.org/jira/browse/SLING-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16925886#comment-16925886 ] Andreas Schaefer commented on SLING-6203: - Adding support for FM is not difficult but it gets difficult if you want to have both traditional and FM content packages supported in the same version. I would think that we use different version to separate the two (transitional and FM). I am looking forward to see how Sling Starter looks like in FM. More important I am looking forward to see how FMs are deployed. > Create a Maven archetype for content packages > - > > Key: SLING-6203 > URL: https://issues.apache.org/jira/browse/SLING-6203 > Project: Sling > Issue Type: Sub-task > Components: General >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.2#803003)
Re: [VOTE] Release Apache Sling File Optimization version 0.9.4
On Mon, 2019-09-09 at 09:18 -0400, Daniel Klco wrote: > Please vote to approve this release: +1 Robert signature.asc Description: This is a digitally signed message part
Re: [VOTE] Release Apache Sling File Optimization version 0.9.4
+1 On Mon, Sep 9, 2019 at 11:33 AM Andreas Schaefer wrote: > +1 (non-binding) > > - Andy > > > On Sep 9, 2019, at 6:18 AM, Daniel Klco wrote: > > > > Hi, > > > > We solved 1 issue in this release: > > https://issues.apache.org/jira/projects/SLING/versions/12346145 > > > > Staging repository: > > https://repository.apache.org/content/repositories/orgapachesling-2126 > > > > 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 2126 /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. > >
Re: [hackathon] switch to feature model
Hi I am not sure about this but my question was the other way around. Do we want in the future that Content Package are writing in a Feature Model way (Content ZIP file separate from Bundles connected though a FM configuration)? As far as I am concerned I do not see any issues where a traditional CP cannot be writing in an FM way but I might be wrong. - Andy > On Sep 9, 2019, at 2:33 AM, Robert Munteanu wrote: > > On Fri, 2019-09-06 at 14:57 -0700, Andreas Schaefer wrote: >> Hi >> >> We for sure can look into that but I am wondering if we keep CP as >> they are right now and then convert them or if we move CPs to be FM >> based? > > Can we convert them if they have content that is not manageable via > repoinit instructions? > > Thanks, > Robert >
Re: [VOTE] Release Apache Sling File Optimization version 0.9.4
+1 (non-binding) - Andy > On Sep 9, 2019, at 6:18 AM, Daniel Klco wrote: > > Hi, > > We solved 1 issue in this release: > https://issues.apache.org/jira/projects/SLING/versions/12346145 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-2126 > > 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 2126 /tmp/sling-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > This majority vote is open for at least 72 hours.
[GitHub] [sling-slingfeature-maven-plugin] simonetripodi merged pull request #38: SLING-8682 - preventing javadoc jar generation when sources dir is empty
simonetripodi merged pull request #38: SLING-8682 - preventing javadoc jar generation when sources dir is empty URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/38 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] [sling-slingfeature-maven-plugin] simonetripodi commented on issue #38: SLING-8682 - preventing javadoc jar generation when sources dir is empty
simonetripodi commented on issue #38: SLING-8682 - preventing javadoc jar generation when sources dir is empty URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/38#issuecomment-529515871 LGTM, thanks a lot @krystiannowak for your priceless contribution! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (SLING-8691) Add Check for CI Build Status
Dan Klco created SLING-8691: --- Summary: Add Check for CI Build Status Key: SLING-8691 URL: https://issues.apache.org/jira/browse/SLING-8691 Project: Sling Issue Type: Sub-task Reporter: Dan Klco Assignee: Dan Klco Fix For: Committer CLI 1.0.0 In addition to validating the signatures, we should check the CI status for the release commit. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[VOTE] Release Apache Sling File Optimization version 0.9.4
Hi, We solved 1 issue in this release: https://issues.apache.org/jira/projects/SLING/versions/12346145 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2126 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 2126 /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.
Re: Release Validator Docker Image
Nice! The approach using the Lucene search of the repo contents is much cleaner than what I was thinking. On Sun, Sep 8, 2019 at 1:00 PM Radu Cotescu wrote: > Hi Daniel, > > > On 6 Sep 2019, at 18:01, Daniel Klco wrote: > > > > Thanks Radu, > > > > I've been looking into this on and off over the last few days and I'm > still > > struggling to see the value of re-implementing all of this in Java > instead > > of relying on a simple series of scripts. Sure it's possible to do GPG > key > > and Hash validation, but I'd still need to write a scraper to download > the > > artifacts from Nexus and then all of the code around these other > functions, > > each of which are hundreds of lines of Java code vs a single line in > BASH. > > > > What would you think about flipping this the other way around? Instead of > > re-implementing in Java, make the docker image more flexible and use > > scripts to decide which function to invoke? > > > > I've put together a quick example of what I'm thinking here: > > > > > https://github.com/apache/sling-org-apache-sling-committer-cli/tree/bash-validate > > > > I’ve managed to implement the missing pieces during last week’s hackathon > and on Friday afternoon [3]. The fact that we ship a Docker image with that > code is just convenience I guess. The functionality is implemented actually > as an OSGi app using the Sling feature model, so we could pack it however > we want. > > Cheers, > Radu > > [3] - https://issues.apache.org/jira/browse/SLING-8684 < > https://issues.apache.org/jira/browse/SLING-8684>
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] [Commented] (SLING-8682) IT apis-jar-wrapped-flattened-classes fails
[ https://issues.apache.org/jira/browse/SLING-8682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16925635#comment-16925635 ] Krystian Nowak commented on SLING-8682: --- [~cziegeler], [~simone.tripodi] - it turned out that the Java package in apis-jar-wrapped-flattened-classes IT API region exports was in fact not existing in bundle's sources jar making the directory empty and exposing the edge case (which was explicitly visible in Java 9+, here Java 11, but not obviously visible in Java 8 without going into wrapped IT Maven subprojects). Please have a look at this PR for IT test config fix and protection against such edge case in MOJO: [https://github.com/apache/sling-slingfeature-maven-plugin/pull/38] > IT apis-jar-wrapped-flattened-classes fails > --- > > Key: SLING-8682 > URL: https://issues.apache.org/jira/browse/SLING-8682 > Project: Sling > Issue Type: Bug > Components: Maven Plugins and Archetypes >Reporter: Carsten Ziegeler >Priority: Major > Fix For: slingfeature-maven-plugin 1.1.2 > > Time Spent: 10m > Remaining Estimate: 0h > > With the correction of subpackage handling in SLING-8681 the > apis-jar-wrapped-flattened-classes fails now. > This might be a bug in our api handling code as the javadoc command does not > get a source -- This message was sent by Atlassian Jira (v8.3.2#803003)
[GitHub] [sling-slingfeature-maven-plugin] krystiannowak opened a new pull request #38: SLING-8682 - preventing javadoc jar generation when sources dir is empty
krystiannowak opened a new pull request #38: SLING-8682 - preventing javadoc jar generation when sources dir is empty URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/38 * preventing javadoc jar generation when sources dir is empty * using a correct Java package existing in bundle javadoc jar in IT This is an automated message from the Apache Git Service. To respond to the message, please log on to 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-8675) Update tooling support install bundle version to be compatible with Starter 11
[ https://issues.apache.org/jira/browse/SLING-8675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu resolved SLING-8675. Resolution: Fixed Fixed with [sling-ide-tooling commit 9a6308a|https://github.com/apache/sling-ide-tooling/commit/9a6308a] > Update tooling support install bundle version to be compatible with Starter 11 > -- > > Key: SLING-8675 > URL: https://issues.apache.org/jira/browse/SLING-8675 > Project: Sling > Issue Type: Task > Components: IDE >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > > We need a release that incorporates SLING-8674 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (SLING-8675) Update tooling support install bundle version to be compatible with Starter 11
[ https://issues.apache.org/jira/browse/SLING-8675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu reassigned SLING-8675: -- Assignee: Robert Munteanu > Update tooling support install bundle version to be compatible with Starter 11 > -- > > Key: SLING-8675 > URL: https://issues.apache.org/jira/browse/SLING-8675 > Project: Sling > Issue Type: Task > Components: IDE >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Fix For: Sling Eclipse IDE 1.2.4 > > > We need a release that incorporates SLING-8674 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[RESULT] [VOTE] Release Apache Sling Tooling Support Install 1.0.6
Hi, The vote has passed with the following result: +1 (binding): Robert Munteanu, Stefan Seifert, Konrad Windszus +1 (non-binding): Andreas Schaefer I will copy this release to the Sling dist directory and promote the artifacts to the central Maven repository. Regards, Robert Munteanu
[jira] [Commented] (SLING-8682) IT apis-jar-wrapped-flattened-classes fails
[ https://issues.apache.org/jira/browse/SLING-8682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16925559#comment-16925559 ] Simone Tripodi commented on SLING-8682: --- Theoretically, there shouldn't be cases where sources directories are empty - that means that: * the MOJO was not able to checkout sources, so please have a look at the WARNING messages in the build log; * or, worst case, a region does not export any APIs: that case IMHO should be prevented during the Analyzer phase. > IT apis-jar-wrapped-flattened-classes fails > --- > > Key: SLING-8682 > URL: https://issues.apache.org/jira/browse/SLING-8682 > Project: Sling > Issue Type: Bug > Components: Maven Plugins and Archetypes >Reporter: Carsten Ziegeler >Priority: Major > Fix For: slingfeature-maven-plugin 1.1.2 > > > With the correction of subpackage handling in SLING-8681 the > apis-jar-wrapped-flattened-classes fails now. > This might be a bug in our api handling code as the javadoc command does not > get a source -- This message was sent by Atlassian Jira (v8.3.2#803003)
Re: [VOTE] Release Apache Sling Tooling Support Install 1.0.6
+1 (checked signatures and build) Konrad > On 9. Sep 2019, at 11:04, Robert Munteanu wrote: > > On Thu, 2019-09-05 at 10:50 +, Robert Munteanu wrote: >> This majority vote is open for at least 72 hours. > > We are missing two binding votes, can anyone else please check+vote? > > Thanks, > Robert >
Re: [hackathon] switch to feature model
On Fri, 2019-09-06 at 14:57 -0700, Andreas Schaefer wrote: > Hi > > We for sure can look into that but I am wondering if we keep CP as > they are right now and then convert them or if we move CPs to be FM > based? Can we convert them if they have content that is not manageable via repoinit instructions? Thanks, Robert
[jira] [Commented] (SLING-8687) Enable integration tests with Docker
[ https://issues.apache.org/jira/browse/SLING-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16925513#comment-16925513 ] Oliver Lietz commented on SLING-8687: - Yes, it's described in the [README|https://github.com/apache/sling-org-apache-sling-commons-clam/blob/master/README.md]. Testcontainers is provided via Testing PaxExam 3.1.0 > Enable integration tests with Docker > > > Key: SLING-8687 > URL: https://issues.apache.org/jira/browse/SLING-8687 > Project: Sling > Issue Type: Task > Components: Commons >Reporter: Oliver Lietz >Assignee: Oliver Lietz >Priority: Major > Fix For: Commons Clam 2.0.2 > > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (SLING-8672) Missing Constraint: Require-Capability: osgi.service; filter="(objectClass=com.codahale.metrics.MetricRegistry)"
[ https://issues.apache.org/jira/browse/SLING-8672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16925510#comment-16925510 ] Oliver Lietz commented on SLING-8672: - [~lnthai2002], Have a look at the [sling-commons-scheduler|https://github.com/apache/sling-org-apache-sling-karaf-features/blob/master/src/main/feature/feature.xml#L116] – it lists all dependencies (no issue with Commons Scheduler). Maybe you can disable service requirements in Eclipse resolver. > Missing Constraint: Require-Capability: osgi.service; > filter="(objectClass=com.codahale.metrics.MetricRegistry)" > > > Key: SLING-8672 > URL: https://issues.apache.org/jira/browse/SLING-8672 > Project: Sling > Issue Type: Bug > Components: Commons >Affects Versions: Commons Scheduler 2.7.4 >Reporter: Nhut Thai Le >Priority: Major > Attachments: launchErr.PNG > > > Hello, > I'm using org.apache.commons.scheduler 2.7.4 and io.dropwizard.metrics.core > 3.2.6. When i launch the application from eclipse, o.a.c.scheduler complains > that: Missing Constraint: Require-Capability: osgi.service; > filter="(objectClass=com.codahale.metrics.MetricRegistry)". The > com.codahale.metrics.MetricRegistry class is defined and exported by > io.dropwizard.metrics.core but dropwizard.metrics.core never declare that it > provide this class as Capability (i checked a few versions of > io.dropwizard.metrics.core). Is it a bug that sling.commons.scheduler > requires such capability ? I havent seen this error when i was running on > eclipse oxygen but with recent upgrade to eclipse 201903, this shows up. > About our running env: > org.eclipse.osgi 3.14.0.v20190517-1309 > org.apache.felix.scr 2.1.14.v20190123-1619 > pax-web-extender-whiteboard 7.2.10 > jetty 9.4.18.v20190429 > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (SLING-8690) Servlet Helpers: MockSlingHttpServletRequest.getContextPath should return "" by default
[
https://issues.apache.org/jira/browse/SLING-8690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert resolved SLING-8690.
---
Resolution: Fixed
https://github.com/apache/sling-org-apache-sling-servlet-helpers/commit/9649aaca8d5e729bf7b6fb09c50827ce6aae4215
> Servlet Helpers: MockSlingHttpServletRequest.getContextPath should return ""
> by default
> ---
>
> Key: SLING-8690
> URL: https://issues.apache.org/jira/browse/SLING-8690
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Servlet Helpers 1.2.0
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: Servlet Helpers 1.2.2
>
>
> according to the JavaDocs of the {{HttpServletRequest.getContextPath}}
> method should return "" and not null for servlets registered to the root
> context path (which is the default for the mocks).
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (SLING-8690) Servlet Helpers: MockSlingHttpServletRequest.getContextPath should return "" by default
Stefan Seifert created SLING-8690:
-
Summary: Servlet Helpers:
MockSlingHttpServletRequest.getContextPath should return "" by default
Key: SLING-8690
URL: https://issues.apache.org/jira/browse/SLING-8690
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: Servlet Helpers 1.2.0
Reporter: Stefan Seifert
Assignee: Stefan Seifert
Fix For: Servlet Helpers 1.2.2
according to the JavaDocs of the {{HttpServletRequest.getContextPath}} method
should return "" and not null for servlets registered to the root context path
(which is the default for the mocks).
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
RE: [VOTE] Release Apache Sling Tooling Support Install 1.0.6
+1
[jira] [Comment Edited] (SLING-8682) IT apis-jar-wrapped-flattened-classes fails
[
https://issues.apache.org/jira/browse/SLING-8682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16925470#comment-16925470
]
Krystian Nowak edited comment on SLING-8682 at 9/9/19 9:05 AM:
---
[~cziegeler]: Isn't it the case that when sourcesDir is empty, no javadoc at
all should be generated anyway? I was checking what happens in IT
apis-jar-wrapped-flattened-classes in both Java 8 and Java 11 case.
Even though in Java 8 it seems fine from outside:
{noformat}
docker volume create --name maven-repo
{noformat}
{noformat}
docker run -it --rm --name my-maven-project -v maven-repo:/root/.m2 -v
"$(pwd)":/usr/src/mymaven -w /usr/src/mymaven maven:3.6.1-jdk-8 mvn clean
install
{noformat}
pretends to work OK:
{noformat}
[INFO] Building: apis-jar-wrapped-flattened-classes/pom.xml
[INFO] run post-build script verify.bsh
[INFO] apis-jar-wrapped-flattened-classes/pom.xml ... SUCCESS
(92.2 s)
{noformat}
(...)
{noformat}
[INFO] BUILD SUCCESS
{noformat}
*BUT* when changing the directory:
{noformat}
cd target/it/apis-jar-wrapped-flattened-classes
{noformat}
and running:
{noformat}
docker run -it --rm --name my-maven-project -v maven-repo:/root/.m2 -v
"$(pwd)":/usr/src/mymaven -w /usr/src/mymaven maven:3.6.1-jdk-8 mvn clean
install
{noformat}
we get:
{noformat}
[INFO] --- slingfeature-maven-plugin:1.1.1-SNAPSHOT:apis-jar (analyze) @
slingfeature-maven-plugin-test ---
[INFO] Building jar:
/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test-1.0.0-SNAPSHOT-base-apis.jar
[INFO] Building jar:
/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test-1.0.0-SNAPSHOT-base-sources.jar
[INFO] Executing javadoc tool: [/usr/local/openjdk-8/jre/../bin/javadoc,
@/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test/base/base-javadoc]
[INFO]
javadoc: error - No packages or classes specified.
{noformat}
(...)
{noformat}
1 error
[INFO] Building jar:
/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test-1.0.0-SNAPSHOT-base-javadoc.jar
{noformat}
(...)
{noformat}
[INFO] BUILD SUCCESS
{noformat}
In Java 11 instead:
{noformat}
docker run -it --rm --name my-maven-project -v maven-repo:/root/.m2 -v
"$(pwd)":/usr/src/mymaven -w /usr/src/mymaven maven:3.6.1-jdk-11 mvn clean
install
{noformat}
results in expliticly failed IT:
{noformat}
[INFO] Building: apis-jar-wrapped-flattened-classes/pom.xml
[INFO] run post-build script verify.bsh
[INFO] apis-jar-wrapped-flattened-classes/pom.xml ... FAILED
(88.2 s)
[INFO] The build exited with code 1. See
/usr/src/mymaven/target/it/apis-jar-wrapped-flattened-classes/build.log for
details.
{noformat}
resulting in:
{noformat}
[INFO] -
[INFO] Build Summary:
[INFO] Passed: 7, Failed: 1, Errors: 0, Skipped: 0
[INFO] -
[ERROR] The following builds failed:
[ERROR] * apis-jar-wrapped-flattened-classes/pom.xml
{noformat}
and
{noformat}
[INFO] BUILD FAILURE
{noformat}
Also diving into the specific directory:
{noformat}
cd target/it/apis-jar-wrapped-flattened-classes
{noformat}
and running:
{noformat}
docker run -it --rm --name my-maven-project -v maven-repo:/root/.m2 -v
"$(pwd)":/usr/src/mymaven -w /usr/src/mymaven maven:3.6.1-jdk-11 mvn clean
install
{noformat}
we get an explicit javadoc error (similar to the one in Java 8 case, but this
one fails the outer build, hence it was visible from outside):
{noformat}
[INFO] --- slingfeature-maven-plugin:1.1.1-SNAPSHOT:apis-jar (analyze) @
slingfeature-maven-plugin-test ---
[INFO] Building jar:
/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test-1.0.0-SNAPSHOT-base-apis.jar
[INFO] Building jar:
/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test-1.0.0-SNAPSHOT-base-sources.jar
[INFO] Executing javadoc tool: [/usr/local/openjdk-11/bin/javadoc,
@/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test/base/base-javadoc]
[INFO]
javadoc: error - No modules, packages or classes specified.
1 error
[INFO]
[INFO] BUILD FAILURE
[INFO]
{noformat}
So it seems in case when _sourcesDir_ list in
[https://github.com/apache/sling-slingfeature-maven-plugin/blob/master/src/main/java/org/apache/sling/feature/maven/mojos/ApisJarMojo.java#L258-L260]
is empty, both in Java 8 and Java 11 the _javadoc_ exec invocation fails, but
the failure is not propagated up in Java 8, only in Java 11 case, hence only
then it was visible from outside in SLING-8597 and the resulting
[https://github.com/apache/sling-slingfeature-maven-plugin/commit/23e848409876cfa35b0ec8669612d73351f4e2e3]
- possibly SLING-8681 could be extended into not calling _javadoc_ exec at all
if _sourcesDir_ list is empty. It would result in not having ja
Re: [VOTE] Release Apache Sling Tooling Support Install 1.0.6
On Thu, 2019-09-05 at 10:50 +, Robert Munteanu wrote: > This majority vote is open for at least 72 hours. We are missing two binding votes, can anyone else please check+vote? Thanks, Robert
Re: [VOTE] Release Apache Sling Tooling Support Install 1.0.6
On Thu, 2019-09-05 at 10:50 +, Robert Munteanu wrote: > Please vote to approve this release: +1 Robert signature.asc Description: This is a digitally signed message part
Re: htl-maven-plugin - default value for sourceDirectory
Hi,
The logic in the filevault-package-maven-plugin is as follows:
It looks for the first found directory below any of the following:
${project.basedir}/jcr_root,${project.basedir}/src/main/jcr_root,${project.basedir}/src/main/content/jcr_root,${project.basedir}/src/content/jcr_root,${project.build.outputDirectory}
(http://jackrabbit.apache.org/filevault-package-maven-plugin/package-mojo.html#jcrRootSourceDirectory)
This works pretty well and rarely forces anyone to reconfigure the plugin.
The list could be even extended to cater for other use cases like script in a
bundle...
Thanks,
Konrad
> On 9. Sep 2019, at 10:46, Radu Cotescu wrote:
>
> Hi Robert,
>
> On Fri, 6 Sep 2019 at 17:49, Robert Munteanu wrote:
>
>> Hi,
>>
>> I have added the htl-maven-plugin for validation to a content package
>> project. I noticed initially that the validation did process anything,
>> because of looking by default in ${project.build.sourceDirectory},
>> which is src/main/java.
>>
>> Would it make sense to change this default, so that it picks up expect
>> locations of htl scripts, e.g. jcr_root or src/main/content/jcr_root?
>>
>> Thanks,
>> Robert
>
>
> I guess such a change shouldn’t affect users, since we’ve always advised
> them to either change the source directory in the pom or configure the
> plugin. However, I’d stay away from JCR specific tooling and conventions as
> defaults.
>
> Cheers,
> Radu
>
>>
[jira] [Commented] (SLING-8672) Missing Constraint: Require-Capability: osgi.service; filter="(objectClass=com.codahale.metrics.MetricRegistry)"
[ https://issues.apache.org/jira/browse/SLING-8672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16925478#comment-16925478 ] Robert Munteanu commented on SLING-8672: [~lnthai2002] - we provide this capability out of our commons.metrics bundle - see SLING-7600 / [sling-org-apache-sling-commons-metrics commit 3ba0a61|https://github.com/apache/sling-org-apache-sling-commons-metrics/commit/3ba0a61] . Would using that bundle instead of the dropwizard one work for you? Alternatively, maybe [~olli] has an idea, as we worked on the issue I referenced. > Missing Constraint: Require-Capability: osgi.service; > filter="(objectClass=com.codahale.metrics.MetricRegistry)" > > > Key: SLING-8672 > URL: https://issues.apache.org/jira/browse/SLING-8672 > Project: Sling > Issue Type: Bug > Components: Commons >Affects Versions: Commons Scheduler 2.7.4 >Reporter: Nhut Thai Le >Priority: Major > Attachments: launchErr.PNG > > > Hello, > I'm using org.apache.commons.scheduler 2.7.4 and io.dropwizard.metrics.core > 3.2.6. When i launch the application from eclipse, o.a.c.scheduler complains > that: Missing Constraint: Require-Capability: osgi.service; > filter="(objectClass=com.codahale.metrics.MetricRegistry)". The > com.codahale.metrics.MetricRegistry class is defined and exported by > io.dropwizard.metrics.core but dropwizard.metrics.core never declare that it > provide this class as Capability (i checked a few versions of > io.dropwizard.metrics.core). Is it a bug that sling.commons.scheduler > requires such capability ? I havent seen this error when i was running on > eclipse oxygen but with recent upgrade to eclipse 201903, this shows up. > About our running env: > org.eclipse.osgi 3.14.0.v20190517-1309 > org.apache.felix.scr 2.1.14.v20190123-1619 > pax-web-extender-whiteboard 7.2.10 > jetty 9.4.18.v20190429 > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (SLING-8687) Enable integration tests with Docker
[ https://issues.apache.org/jira/browse/SLING-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16925477#comment-16925477 ] Bertrand Delacretaz commented on SLING-8687: Ok got it, it's the [https://www.testcontainers.org/] bits that interact with Docker that needs to be available when running the integration tests. Thanks for clarifying! > Enable integration tests with Docker > > > Key: SLING-8687 > URL: https://issues.apache.org/jira/browse/SLING-8687 > Project: Sling > Issue Type: Task > Components: Commons >Reporter: Oliver Lietz >Assignee: Oliver Lietz >Priority: Major > Fix For: Commons Clam 2.0.2 > > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (SLING-6203) Create a Maven archetype for content packages
[ https://issues.apache.org/jira/browse/SLING-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16925474#comment-16925474 ] Robert Munteanu commented on SLING-6203: [~schaefa] - your points make sense. I am wondering though why adding support for the feature model would be trickier? I think we can simply not add support for a provisioning model project, and look into the feature model once the Sling Starter itself is based on it. > Create a Maven archetype for content packages > - > > Key: SLING-6203 > URL: https://issues.apache.org/jira/browse/SLING-6203 > Project: Sling > Issue Type: Sub-task > Components: General >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.2#803003)
Re: htl-maven-plugin - default value for sourceDirectory
Hi Robert,
On Fri, 6 Sep 2019 at 17:49, Robert Munteanu wrote:
> Hi,
>
> I have added the htl-maven-plugin for validation to a content package
> project. I noticed initially that the validation did process anything,
> because of looking by default in ${project.build.sourceDirectory},
> which is src/main/java.
>
> Would it make sense to change this default, so that it picks up expect
> locations of htl scripts, e.g. jcr_root or src/main/content/jcr_root?
>
> Thanks,
> Robert
I guess such a change shouldn’t affect users, since we’ve always advised
them to either change the source directory in the pom or configure the
plugin. However, I’d stay away from JCR specific tooling and conventions as
defaults.
Cheers,
Radu
>
[jira] [Commented] (SLING-8615) Move to a resource-centric setup
[ https://issues.apache.org/jira/browse/SLING-8615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16925472#comment-16925472 ] Robert Munteanu commented on SLING-8615: [~olli] - I had not considered that the scripting HTL dependency would cause problems. Is it inconvenient because it brings in HTL or is that too many dependencies for a minimal Karaf feature and you would prefer just one scripting engine? > Move to a resource-centric setup > > > Key: SLING-8615 > URL: https://issues.apache.org/jira/browse/SLING-8615 > Project: Sling > Issue Type: Improvement > Components: Starter >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Fix For: Starter Content 1.0.6 > > > As proposed on > https://lists.apache.org/thread.html/847538afdb43d82c7c4a2d59464897168ea1302a69c5b0863eddc360@%3Cdev.sling.apache.org%3E > , we should use the Sling way and base the starter-content bundle on scripts > and resources. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (SLING-8682) IT apis-jar-wrapped-flattened-classes fails
[
https://issues.apache.org/jira/browse/SLING-8682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16925470#comment-16925470
]
Krystian Nowak commented on SLING-8682:
---
[~cziegeler]: Isn't it the case that when sourcesDir is empty, no javadoc at
all should be generated anyway? I was checking what happens in IT
apis-jar-wrapped-flattened-classes in both Java 8 and Java 11 case.
Even though in Java 8 it seems fine from outside:
{noformat}
docker volume create --name maven-repo
{noformat}
{noformat}
docker run -it --rm --name my-maven-project -v maven-repo:/root/.m2 -v
"$(pwd)":/usr/src/mymaven -w /usr/src/mymaven maven:3.6.1-jdk-8 mvn clean
install
{noformat}
pretends to work OK:
{noformat}
[INFO] Building: apis-jar-wrapped-flattened-classes/pom.xml
[INFO] run post-build script verify.bsh
[INFO] apis-jar-wrapped-flattened-classes/pom.xml ... SUCCESS
(92.2 s)
{noformat}
(...)
{noformat}
[INFO] BUILD SUCCESS
{noformat}
*BUT* when changing the directory:
{noformat}
cat target/it/apis-jar-wrapped-flattened-classes
{noformat}
and running:
{noformat}
docker run -it --rm --name my-maven-project -v maven-repo:/root/.m2 -v
"$(pwd)":/usr/src/mymaven -w /usr/src/mymaven maven:3.6.1-jdk-8 mvn clean
install
{noformat}
we get:
{noformat}
[INFO] --- slingfeature-maven-plugin:1.1.1-SNAPSHOT:apis-jar (analyze) @
slingfeature-maven-plugin-test ---
[INFO] Building jar:
/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test-1.0.0-SNAPSHOT-base-apis.jar
[INFO] Building jar:
/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test-1.0.0-SNAPSHOT-base-sources.jar
[INFO] Executing javadoc tool: [/usr/local/openjdk-8/jre/../bin/javadoc,
@/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test/base/base-javadoc]
[INFO]
javadoc: error - No packages or classes specified.
{noformat}
(...)
{noformat}
1 error
[INFO] Building jar:
/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test-1.0.0-SNAPSHOT-base-javadoc.jar
{noformat}
(...)
{noformat}
[INFO] BUILD SUCCESS
{noformat}
In Java 11 instead:
{noformat}
docker run -it --rm --name my-maven-project -v maven-repo:/root/.m2 -v
"$(pwd)":/usr/src/mymaven -w /usr/src/mymaven maven:3.6.1-jdk-11 mvn clean
install
{noformat}
results in expliticly failed IT:
{noformat}
[INFO] Building: apis-jar-wrapped-flattened-classes/pom.xml
[INFO] run post-build script verify.bsh
[INFO] apis-jar-wrapped-flattened-classes/pom.xml ... FAILED
(88.2 s)
[INFO] The build exited with code 1. See
/usr/src/mymaven/target/it/apis-jar-wrapped-flattened-classes/build.log for
details.
{noformat}
resulting in:
{noformat}
[INFO] -
[INFO] Build Summary:
[INFO] Passed: 7, Failed: 1, Errors: 0, Skipped: 0
[INFO] -
[ERROR] The following builds failed:
[ERROR] * apis-jar-wrapped-flattened-classes/pom.xml
{noformat}
and
{noformat}
[INFO] BUILD FAILURE
{noformat}
Also diving into the specific directory:
{noformat}
cat target/it/apis-jar-wrapped-flattened-classes
{noformat}
and running:
{noformat}
docker run -it --rm --name my-maven-project -v maven-repo:/root/.m2 -v
"$(pwd)":/usr/src/mymaven -w /usr/src/mymaven maven:3.6.1-jdk-11 mvn clean
install
{noformat}
we get an explicit javadoc error (similar to the one in Java 8 case, but this
one fails the outer build, hence it was visible from outside):
{noformat}
[INFO] --- slingfeature-maven-plugin:1.1.1-SNAPSHOT:apis-jar (analyze) @
slingfeature-maven-plugin-test ---
[INFO] Building jar:
/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test-1.0.0-SNAPSHOT-base-apis.jar
[INFO] Building jar:
/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test-1.0.0-SNAPSHOT-base-sources.jar
[INFO] Executing javadoc tool: [/usr/local/openjdk-11/bin/javadoc,
@/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test/base/base-javadoc]
[INFO]
javadoc: error - No modules, packages or classes specified.
1 error
[INFO]
[INFO] BUILD FAILURE
[INFO]
{noformat}
So it seems in case when _sourcesDir_ list in
https://github.com/apache/sling-slingfeature-maven-plugin/blob/master/src/main/java/org/apache/sling/feature/maven/mojos/ApisJarMojo.java#L258-L260
is empty, both in Java 8 and Java 11 the _javadoc_ exec invocation fails, but
the failure is not propagated up in Java 8, only in Java 11 case, hence only
then it was visible from outside in SLING-8597 and the resulting
[https://github.com/apache/sling-slingfeature-maven-plugin/commit/23e848409876cfa35b0ec8669612d73351f4e2e3]
- possibly SLING-8681 could be extended into not calling _javadoc_ exec at all
if _sourcesDir_ list is empty. It would result in not having javadocs jar
produced in this case, but
[jira] [Commented] (SLING-8686) Example code variable name wrong in Sling API CRUD, updating a property
[
https://issues.apache.org/jira/browse/SLING-8686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16925468#comment-16925468
]
Robert Munteanu commented on SLING-8686:
Good catch [~thomasmorf]. Can you send a PR so we can properly attribute the
fix to you? The file to modify is at
https://github.com/apache/sling-site/blob/master/src/main/jbake/content/documentation/the-sling-engine/sling-api-crud-support.md
.
> Example code variable name wrong in Sling API CRUD, updating a property
> ---
>
> Key: SLING-8686
> URL: https://issues.apache.org/jira/browse/SLING-8686
> Project: Sling
> Issue Type: Improvement
> Components: Documentation
>Reporter: Thomas Morf
>Priority: Trivial
>
> On the page:
> [https://sling.apache.org/documentation/the-sling-engine/sling-api-crud-support.html#updating-a-property]
>
> Paragraph:
> *Sling API CRUD*
>
> The variable name myNode in the code example should probably be "myResource",
> if I understand the intention of the code correctly.
>
> Resource myResource = resourceResolver.getResource("/myresource");
> ModifiableValueMap properties = **myNode**.adaptTo(ModifiableValueMap.class);
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (SLING-8688) Enable integration tests with Docker
[ https://issues.apache.org/jira/browse/SLING-8688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Lietz resolved SLING-8688. - Resolution: Done > Enable integration tests with Docker > > > Key: SLING-8688 > URL: https://issues.apache.org/jira/browse/SLING-8688 > Project: Sling > Issue Type: Task > Components: JCR, Oak >Reporter: Oliver Lietz >Assignee: Oliver Lietz >Priority: Major > Fix For: Clam 1.1.2 > > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (SLING-8685) Rename feature sling-scripting-sightly to sling-scripting-htl
[ https://issues.apache.org/jira/browse/SLING-8685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Lietz resolved SLING-8685. - Resolution: Done > Rename feature sling-scripting-sightly to sling-scripting-htl > - > > Key: SLING-8685 > URL: https://issues.apache.org/jira/browse/SLING-8685 > Project: Sling > Issue Type: Task > Components: Karaf >Reporter: Oliver Lietz >Assignee: Oliver Lietz >Priority: Major > Fix For: Karaf Features 0.2.0, Karaf Integration Tests 0.2.0, > Karaf Distribution 0.2.0, Karaf Configs 0.2.0, Karaf Launchpad Integration > Tests (Oak Tar) 0.0.2 > > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (SLING-8687) Enable integration tests with Docker
[
https://issues.apache.org/jira/browse/SLING-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16925463#comment-16925463
]
Oliver Lietz commented on SLING-8687:
-
I just moved the tests out of the profile {{it}} to default build. By default
the Sling builds are running on {{ubuntu}} hosts were Docker is already
installed.
> Enable integration tests with Docker
>
>
> Key: SLING-8687
> URL: https://issues.apache.org/jira/browse/SLING-8687
> Project: Sling
> Issue Type: Task
> Components: Commons
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Major
> Fix For: Commons Clam 2.0.2
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (SLING-8683) Slingfeature maven plugin should be usable to wrap project artifacts in feature.
[ https://issues.apache.org/jira/browse/SLING-8683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16925438#comment-16925438 ] Carsten Ziegeler commented on SLING-8683: - This needs a configuration of a mojo inside the project, there is no automatism we could use. The only trigger would be the packaging of the project, but I think in this case the packaging is either jar or bundle (not slingfeature). I guess we have two options: - create a new feature with just the bundle - add the bundle to an existing feature which is also part of the project > 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.2 > > > 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)
[jira] [Commented] (SLING-8687) Enable integration tests with Docker
[ https://issues.apache.org/jira/browse/SLING-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16925431#comment-16925431 ] Bertrand Delacretaz commented on SLING-8687: Could you provide a short summary of how you got this working, so we can reuse the "recipe" for other modules? > Enable integration tests with Docker > > > Key: SLING-8687 > URL: https://issues.apache.org/jira/browse/SLING-8687 > Project: Sling > Issue Type: Task > Components: Commons >Reporter: Oliver Lietz >Assignee: Oliver Lietz >Priority: Major > Fix For: Commons Clam 2.0.2 > > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (SLING-8687) Enable integration tests with Docker
[ https://issues.apache.org/jira/browse/SLING-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Lietz resolved SLING-8687. - Resolution: Done > Enable integration tests with Docker > > > Key: SLING-8687 > URL: https://issues.apache.org/jira/browse/SLING-8687 > Project: Sling > Issue Type: Task > Components: Commons >Reporter: Oliver Lietz >Assignee: Oliver Lietz >Priority: Major > Fix For: Commons Clam 2.0.2 > > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (SLING-8689) Improve version handling
[ https://issues.apache.org/jira/browse/SLING-8689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-8689. - Resolution: Fixed Updated in rev 1bdba86 It's now possible to define the versionScope as a separate parameter using ANY,MAJOR,MINOR,INCREMENTAL,SUBINCREMENTAL and to specify this per include using a slash as a separator. Updated the README as well > Improve version handling > > > Key: SLING-8689 > URL: https://issues.apache.org/jira/browse/SLING-8689 > Project: Sling > Issue Type: Improvement > Components: Maven Plugins and Archetypes >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: slingfeature-maven-plugin 1.1.2 > > > The update-feature-versions plugin currently only allows to update to the > latest version found, which in some cases might not be the right thing > We should allow to update to a specific version and to just the highest > version without changing the major version. For example if an artifact is on > 1.2.3 it should update to the highest 1.x version, but not to any 2.x version -- This message was sent by Atlassian Jira (v8.3.2#803003)
