[GitHub] cziegeler closed pull request #1: Fixed Spelling.
cziegeler closed pull request #1: Fixed Spelling. URL: https://github.com/apache/sling-org-apache-sling-commons-classloader/pull/1 This is a PR merged from a forked repository. As GitHub hides the original diff on merge, it is displayed below for the sake of provenance: As this is a foreign pull request (from a fork), the diff is supplied below (as it won't show otherwise due to GitHub magic): diff --git a/src/main/java/org/apache/sling/commons/classloader/DynamicClassLoaderManager.java b/src/main/java/org/apache/sling/commons/classloader/DynamicClassLoaderManager.java index 60cec58..8d247c6 100644 --- a/src/main/java/org/apache/sling/commons/classloader/DynamicClassLoaderManager.java +++ b/src/main/java/org/apache/sling/commons/classloader/DynamicClassLoaderManager.java @@ -24,7 +24,7 @@ * The dynamic class loader manager is a central * service managing all dynamic class loaders. * It provides a class loader that can be used by - * bundles requiring access to all publically available + * bundles requiring access to all publicly available * classes. * * The default implementation uses the package admin 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] jimmycasey opened a new pull request #1: Fixed Spelling.
jimmycasey opened a new pull request #1: Fixed Spelling. URL: https://github.com/apache/sling-org-apache-sling-commons-classloader/pull/1 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-7497) Update Pax Exam to 4.12.0
[ https://issues.apache.org/jira/browse/SLING-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Lietz resolved SLING-7497. - Resolution: Done > Update Pax Exam to 4.12.0 > - > > Key: SLING-7497 > URL: https://issues.apache.org/jira/browse/SLING-7497 > Project: Sling > Issue Type: Task > Components: Testing >Reporter: Oliver Lietz >Assignee: Oliver Lietz >Priority: Major > Fix For: Testing PaxExam 2.0.2 > > > Tika Parsers requires Apache Commons Logging 1.2 API which is not provided by > Pax Logging 1.8.4 (used by Pax Exam 4.11, see > [PAXEXAM-914|https://ops4j1.jira.com/browse/PAXEXAM-914]). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SLING-7497) Update Pax Exam to 4.12.0
[ https://issues.apache.org/jira/browse/SLING-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Lietz updated SLING-7497: Summary: Update Pax Exam to 4.12.0 (was: Update Pax Exam to 4.12) > Update Pax Exam to 4.12.0 > - > > Key: SLING-7497 > URL: https://issues.apache.org/jira/browse/SLING-7497 > Project: Sling > Issue Type: Task > Components: Testing >Reporter: Oliver Lietz >Assignee: Oliver Lietz >Priority: Major > Fix For: Testing PaxExam 2.0.2 > > > Tika Parsers requires Apache Commons Logging 1.2 API which is not provided by > Pax Logging 1.8.4 (used by Pax Exam 4.11, see > [PAXEXAM-914|https://ops4j1.jira.com/browse/PAXEXAM-914]). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-7665) Use bnd Maven plugins
[
https://issues.apache.org/jira/browse/SLING-7665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16561182#comment-16561182
]
Carsten Ziegeler commented on SLING-7665:
-
[~olli] I think the worst option is to not use DS for this component anymore. I
personally neither like a separate bnd file nor do I like the magic of its
existence triggering different plugins. But I guess that's more my personal
taste.
It's more important that we can move on, so let's go with the separate bnd file
> Use bnd Maven plugins
> -
>
> Key: SLING-7665
> URL: https://issues.apache.org/jira/browse/SLING-7665
> Project: Sling
> Issue Type: Improvement
> Components: ResourceResolver
>Reporter: Oliver Lietz
>Priority: Major
> Fix For: Resource Resolver 1.6.2
>
> Attachments: SLING-7665.patch
>
>
> Additionally patch overrides {{Require-Capability}} for
> {{OsgiObservationBridge}}, see also [bnd #2429 Provide a way to override
> (required) capabilities generated from DS
> annotations|https://github.com/bndtools/bnd/issues/2429]:
> {noformat}
> Require-Capability:\
>
> osgi.service;filter:="(objectClass=org.osgi.service.event.EventHandler)";effective:=active;resolution:=optional
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [VOTE] Release Apache Sling API 2.18.2
Anyone else please? Thanks Carsten Carsten Ziegeler wrote > Hi, > > We solved 3 issues in this release: > https://issues.apache.org/jira/projects/SLING/versions/12342941 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-1924 > > You can use this UNIX script to download the release and verify the > signatures: > http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh > > Usage: > sh check_staged_release.sh 1924 /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. > > Carsten > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Commented] (SLING-7665) Use bnd Maven plugins
[
https://issues.apache.org/jira/browse/SLING-7665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16561133#comment-16561133
]
Oliver Lietz commented on SLING-7665:
-
[~cziegeler], yes – we should decide which way to go. See options from my
previous comment (or leave as is) and implement accordingly.
> Use bnd Maven plugins
> -
>
> Key: SLING-7665
> URL: https://issues.apache.org/jira/browse/SLING-7665
> Project: Sling
> Issue Type: Improvement
> Components: ResourceResolver
>Reporter: Oliver Lietz
>Priority: Major
> Fix For: Resource Resolver 1.6.2
>
> Attachments: SLING-7665.patch
>
>
> Additionally patch overrides {{Require-Capability}} for
> {{OsgiObservationBridge}}, see also [bnd #2429 Provide a way to override
> (required) capabilities generated from DS
> annotations|https://github.com/bndtools/bnd/issues/2429]:
> {noformat}
> Require-Capability:\
>
> osgi.service;filter:="(objectClass=org.osgi.service.event.EventHandler)";effective:=active;resolution:=optional
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: Markdown resource provider
on a more serious note, this would be possibly great for dita as well (for example better process for the xmladdon for AEM) Ruben On 7/29/2018 6:30 AM, Jason E Bailey wrote: Eugen - I didn't realize that it was a thing. So I'm good with it. However I now have a strong desire to make an HTML resource provider that will define resources trees with HTML, which you can then use to generate HTML. A meta-HTML :) - Jason On Sun, Jul 29, 2018, at 1:52 AM, Ioan Eugen Stan wrote: Hi, Nice work Robert. @Jason: I do believe there is value in yaml frontmatter. A lot of existing tools support markdown + frontmatter and people using them are familiar with that. Adding something Sling specific is going to make interoerability harder. It is going to be non portable as well. I'm in favor of using front matter. It will help port markdown apps to sling and promote interoperability between such apps. Regards, Eugen Stan Netdava International Mesaj original De la: jason.bai...@24601.org Trimis: 28 iulie 2018 20:28 Către: dev@sling.apache.org Răsp. la: dev@sling.apache.org Subiect: Re: Markdown resource provider I believe there's a difference between what the two end goals are. There is a the rendering of a Markdown resource into HTML and then there is using a Markdown file to generate a resource. A couple of thoughts on this. # For a Markdown Resource providing attributes, I don't see a reason to use YAML for this. Markdown support integrated HTML and HTML supports custom tags. You could create some thing along the lines of this wouldn't be displayed when viewing a rendered version of the file but be accessible when parsing. # We have a module for taking different file types and creating a Resource Object out of them, that's the ContentParser. If the goal was to import the md file into an existing resource we'd use the ContentLoader. If we wanted the ability to read and write the file then I see a ResourceProvider and since we have a FSResourceProvider I still think it makes sense to allow that to be expandable. -- Jason On Fri, Jul 27, 2018, at 10:31 AM, Carsten Ziegeler wrote: Daniel Klco wrote My first thought after reading the last paragraph was - Wouldn't it be cool if the FsResourceProvider was extensible so that specific files could be rendered in a specific manner, then you could add a MarkDown Handler and it would make it easier for other people to add custom handlers or to extend existing one for specific requirements. Agreed! This mechanism could be useful for XML or JSON files as well. Imagine if one could register an XSLT handler and just have Sling serve the rendered HTML for a dump of XML files. That's why I mentioned the resource decorator approach - it allows you to do this, and then you're even independent of the resource provider serving the resource. The decorator approach might not be the most obvious one, but I think it does the trick and doesn't require us to add another overlapping concept. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Markdown resource provider
Eugen - I didn't realize that it was a thing. So I'm good with it. However I now have a strong desire to make an HTML resource provider that will define resources trees with HTML, which you can then use to generate HTML. A meta-HTML :) - Jason On Sun, Jul 29, 2018, at 1:52 AM, Ioan Eugen Stan wrote: > Hi, > > Nice work Robert. > > @Jason: I do believe there is value in yaml frontmatter. A lot of > existing tools support markdown + frontmatter and people using them are > familiar with that. Adding something Sling specific is going to make > interoerability harder. It is going to be non portable as well. > > I'm in favor of using front matter. It will help port markdown apps to > sling and promote interoperability between such apps. > > Regards, > > Eugen Stan > Netdava International > > Mesaj original > De la: jason.bai...@24601.org > Trimis: 28 iulie 2018 20:28 > Către: dev@sling.apache.org > Răsp. la: dev@sling.apache.org > Subiect: Re: Markdown resource provider > > I believe there's a difference between what the two end goals are. There > is a the rendering of a Markdown resource into HTML and then there is > using a Markdown file to generate a resource. > > A couple of thoughts on this. > # For a Markdown Resource providing attributes, I don't see a reason to > use YAML for this. Markdown support integrated HTML and HTML supports > custom tags. You could create some thing along the lines of props data-sling-resourceType="foo"> this wouldn't be displayed when > viewing a rendered version of the file but be accessible when parsing. > > # We have a module for taking different file types and creating a > Resource Object out of them, that's the ContentParser. If the goal was > to import the md file into an existing resource we'd use the > ContentLoader. If we wanted the ability to read and write the file then > I see a ResourceProvider and since we have a FSResourceProvider I still > think it makes sense to allow that to be expandable. > > > > -- > Jason > > On Fri, Jul 27, 2018, at 10:31 AM, Carsten Ziegeler wrote: > > > > > > > > > Daniel Klco wrote > > >> My first thought after reading the last paragraph was - Wouldn't it be > > >> cool if the FsResourceProvider was extensible so that specific files > > >> could > > >> be rendered in a specific manner, then you could add a MarkDown Handler > > >> and > > >> it would make it easier for other people to add custom handlers or to > > >> extend existing one for specific requirements. > > >> > > > > > > Agreed! This mechanism could be useful for XML or JSON files as well. > > > Imagine if one could register an XSLT handler and just have Sling serve > > > the > > > rendered HTML for a dump of XML files. > > > > > > > That's why I mentioned the resource decorator approach - it allows you > > to do this, and then you're even independent of the resource provider > > serving the resource. > > The decorator approach might not be the most obvious one, but I think it > > does the trick and doesn't require us to add another overlapping concept. > > > > Regards > > Carsten > > -- > > Carsten Ziegeler > > Adobe Research Switzerland > > cziege...@apache.org
