Re: [Metrics] Naming convention for MBeans registered by Sling Metrics

[Ian Boston]

Hi,
Could those generating the metrics use the full name, rather than expecting
them to be automatically namespaced.?
Rather like the way the Logger classes make no assumptions.
That would be simpler, but perhaps more work for the developer.
Best Regards
Ian

On 21 January 2016 at 05:28, Chetan Mehrotra 
wrote:

> Hi Team,
>
> Per current setup all Metrics MBeans are registered under
> "org.apache.sling" domain. Even metrics registered by non Sling bundle
> which can lead to confusion.
>
> So we would need to come up with a way to make JMX domain name a
> function of bundle which is registering the metric. For that I was
> thinking of following approach
>
> 1. Expose the MetricService as a ServiceFactory
>
> 2. Have an OSGi config which provides a mapping between
> Bundle-SymbolicName and JMX Domain name to use. It
> would be a regex expression. The metric though MUST be
> unique across all metrics (irrespective of which bundle was used)
>
> --
> com.foo = com.foo.*
> org.apache.sling=org.apache.sling.*
> --
>
> Where 'com.foo' is the JMX domain name used for all bundle having
> there Bundle-Symbolicname confirming to pattern 'com.foo.*'
>
> Thoughts and suggestion welcome!
>
> Chetan Mehrotra
>

[jira] [Created] (SLING-5444) Display nameHints in webConsole for distribution factories

[Marius Petria (JIRA)]

Marius Petria created SLING-5444:


 Summary: Display nameHints in webConsole for distribution factories
 Key: SLING-5444
 URL: https://issues.apache.org/jira/browse/SLING-5444
 Project: Sling
  Issue Type: Improvement
Reporter: Marius Petria
Assignee: Marius Petria
 Fix For: Content Distribution Core 0.1.14






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-5444) Display nameHints in webConsole for distribution factories

[Marius Petria (JIRA)]

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

Marius Petria resolved SLING-5444.
--
Resolution: Fixed

> Display nameHints in webConsole for distribution factories
> --
>
> Key: SLING-5444
> URL: https://issues.apache.org/jira/browse/SLING-5444
> Project: Sling
>  Issue Type: Improvement
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.14
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5444) Display nameHints in webConsole for distribution factories

[Marius Petria (JIRA)]

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

Marius Petria commented on SLING-5444:
--

Committed revision 1725880.


> Display nameHints in webConsole for distribution factories
> --
>
> Key: SLING-5444
> URL: https://issues.apache.org/jira/browse/SLING-5444
> Project: Sling
>  Issue Type: Improvement
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.14
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-5446) DefaultSharedDistributionPackageBuilder should not be tight to the VLT builder

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili resolved SLING-5446.

Resolution: Fixed

fixed in r1725986

> DefaultSharedDistributionPackageBuilder should not be tight to the VLT builder
> --
>
> Key: SLING-5446
> URL: https://issues.apache.org/jira/browse/SLING-5446
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.1.14
>
>
> {{DefaultSharedDistributionPackageBuilder}} is used for fetching 
> {{SharedDistributionPackages}} only in the 
> {{VaultDistributionPackageBuilderFactory}} while it'd be good to make this 
> used by default by all the {{DistributionPackageBuilders}} (e.g. the Kryo and 
> Avro ones in _extensions_) without having to manually instantiate it (and 
> thus expose the API).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-5446) DefaultSharedDistributionPackageBuilder should not be tight to the VLT builder

[Tommaso Teofili (JIRA)]

Tommaso Teofili created SLING-5446:
--

 Summary: DefaultSharedDistributionPackageBuilder should not be 
tight to the VLT builder
 Key: SLING-5446
 URL: https://issues.apache.org/jira/browse/SLING-5446
 Project: Sling
  Issue Type: Bug
  Components: Distribution
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
 Fix For: Content Distribution Core 0.1.14


{{DefaultSharedDistributionPackageBuilder}} is used for fetching 
{{SharedDistributionPackage}}s only in the 
{{VaultDistributionPackageBuilderFactory}} while it'd be good to make this used 
by default by all the {{DistributionPackageBuilder}}s (e.g. the Kryo and Avro 
ones in _extensions_) without having to manually instantiate it (and thus 
expose the API).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5446) DefaultSharedDistributionPackageBuilder should not be tight to the VLT builder

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili updated SLING-5446:
---
Issue Type: Improvement  (was: Bug)

> DefaultSharedDistributionPackageBuilder should not be tight to the VLT builder
> --
>
> Key: SLING-5446
> URL: https://issues.apache.org/jira/browse/SLING-5446
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.1.14
>
>
> {{DefaultSharedDistributionPackageBuilder}} is used for fetching 
> {{SharedDistributionPackages}} only in the 
> {{VaultDistributionPackageBuilderFactory}} while it'd be good to make this 
> used by default by all the {{DistributionPackageBuilders}} (e.g. the Kryo and 
> Avro ones in _extensions_) without having to manually instantiate it (and 
> thus expose the API).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [Metrics] Naming convention for MBeans registered by Sling Metrics

[Chetan Mehrotra]

> Could those generating the metrics use the full name, rather than expecting
them to be automatically namespaced.?

Note that this proposal is not for namespacing the metric name. Rather
its for the JMX Domain name under which the MBean is registered.

As for actual Metrics name currently its open to developer and if two
different component try to use the same name then first one would win
and for other an exception would be thrown.
Chetan Mehrotra


On Thu, Jan 21, 2016 at 7:28 PM, Ian Boston  wrote:
> Hi,
> Could those generating the metrics use the full name, rather than expecting
> them to be automatically namespaced.?
> Rather like the way the Logger classes make no assumptions.
> That would be simpler, but perhaps more work for the developer.
> Best Regards
> Ian
>
> On 21 January 2016 at 05:28, Chetan Mehrotra 
> wrote:
>
>> Hi Team,
>>
>> Per current setup all Metrics MBeans are registered under
>> "org.apache.sling" domain. Even metrics registered by non Sling bundle
>> which can lead to confusion.
>>
>> So we would need to come up with a way to make JMX domain name a
>> function of bundle which is registering the metric. For that I was
>> thinking of following approach
>>
>> 1. Expose the MetricService as a ServiceFactory
>>
>> 2. Have an OSGi config which provides a mapping between
>> Bundle-SymbolicName and JMX Domain name to use. It
>> would be a regex expression. The metric though MUST be
>> unique across all metrics (irrespective of which bundle was used)
>>
>> --
>> com.foo = com.foo.*
>> org.apache.sling=org.apache.sling.*
>> --
>>
>> Where 'com.foo' is the JMX domain name used for all bundle having
>> there Bundle-Symbolicname confirming to pattern 'com.foo.*'
>>
>> Thoughts and suggestion welcome!
>>
>> Chetan Mehrotra
>>

[jira] [Updated] (SLING-5446) DefaultSharedDistributionPackageBuilder should not be tight to the VLT builder

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili updated SLING-5446:
---
Description: {{DefaultSharedDistributionPackageBuilder}} is used for 
fetching {{SharedDistributionPackages}} only in the 
{{VaultDistributionPackageBuilderFactory}} while it'd be good to make this used 
by default by all the {{DistributionPackageBuilders}} (e.g. the Kryo and Avro 
ones in _extensions_) without having to manually instantiate it (and thus 
expose the API).  (was: {{DefaultSharedDistributionPackageBuilder}} is used for 
fetching {{SharedDistributionPackage}}s only in the 
{{VaultDistributionPackageBuilderFactory}} while it'd be good to make this used 
by default by all the {{DistributionPackageBuilder}}s (e.g. the Kryo and Avro 
ones in _extensions_) without having to manually instantiate it (and thus 
expose the API).)

> DefaultSharedDistributionPackageBuilder should not be tight to the VLT builder
> --
>
> Key: SLING-5446
> URL: https://issues.apache.org/jira/browse/SLING-5446
> Project: Sling
>  Issue Type: Bug
>  Components: Distribution
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Content Distribution Core 0.1.14
>
>
> {{DefaultSharedDistributionPackageBuilder}} is used for fetching 
> {{SharedDistributionPackages}} only in the 
> {{VaultDistributionPackageBuilderFactory}} while it'd be good to make this 
> used by default by all the {{DistributionPackageBuilders}} (e.g. the Kryo and 
> Avro ones in _extensions_) without having to manually instantiate it (and 
> thus expose the API).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-5445) XSSAPI#encodeForJSString is too restrictive

[Radu Cotescu (JIRA)]

Radu Cotescu created SLING-5445:
---

 Summary: XSSAPI#encodeForJSString is too restrictive
 Key: SLING-5445
 URL: https://issues.apache.org/jira/browse/SLING-5445
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: XSS Protection API 1.0.6
Reporter: Radu Cotescu
Assignee: Radu Cotescu
 Fix For: XSS Protection API 1.0.8


For the cases when somebody tries to sanitise JSON strings the 
{{XSSAPI#encodeForJSString}} current implementation is too restrictive. 

Assuming one would want to sanitize {{2016-01-21T15:40:30}}, the output of the 
{{XSSAPI#encodeForJSString}} would be 

{noformat}
2016\-01\-21T15:40:30
{noformat}

which although is a valid String for JavaScript code is not a valid one for 
JSON.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Worthwhile to create a Sling CMS?

[Sandro Boehme]

I recognized I accidently answered privately to Ondrej by hitting 
'reply'. So here is my answer to him from two days ago:


Hi Ondrej,

Am 19.01.16 um 15:49 schrieb Ondrej Florian:

Having yet another CMS for 'normal' people like Wix may not be worthwhile.
I think it is not like Wix as it is Open Source. But of course this is 
more important for developers than for users as long as Wix can provide 
enough reusable elements for the users.



HOWEVER, going into verticals may be much more interesting.

I absolutely agree.


I personally think the Sling could be great data integration platform.
- imagine modeling SAP or SF data as resources...
- being able to 'mix' those resources into a web pages or reports
- build forms / workflows
Yes, that should certainly not be too hard to do. In the Sitebuilder poc 
demo [1] I moved simple text fields to the page, gave them an HTML name 
and the Sling POST servlet created the according node property. This way 
the page editor didn't have to do much.
I also agree that it would integrate well into Java (-affine) 
architectures as it fits skill wise.



...this also takes you very close to document/knowledge management :-)

Yes, this is probably right.

Thanks,

Sandro

[1] - https://vimeo.com/140369433

[jira] [Resolved] (SLING-5447) Enable FindBugs for the Sightly Scripting Engine

[Radu Cotescu (JIRA)]

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

Radu Cotescu resolved SLING-5447.
-
Resolution: Fixed

Fixed in [r1726029|https://svn.apache.org/r1726029].

> Enable FindBugs for the Sightly Scripting Engine
> 
>
> Key: SLING-5447
> URL: https://issues.apache.org/jira/browse/SLING-5447
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.10
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting Sightly Engine 1.0.12
>
>
> FindBugs should run as part of the normal build process for the Sightly 
> Scripting Engine.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[RESULT][VOTE] Release Apache Sling Testing Utilities 2.0.24

[Robert Munteanu]

Hi,

The vote has passsed with the following result :

+1 (binding) Robert Munteanu, Stefan Seifert, Dan Klco

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

Thanks,

Robert

[jira] [Created] (SLING-5447) Enable FindBugs for the Sightly Scripting Engine

[Radu Cotescu (JIRA)]

Radu Cotescu created SLING-5447:
---

 Summary: Enable FindBugs for the Sightly Scripting Engine
 Key: SLING-5447
 URL: https://issues.apache.org/jira/browse/SLING-5447
 Project: Sling
  Issue Type: Improvement
  Components: Scripting
Affects Versions: Scripting Sightly Engine 1.0.10
Reporter: Radu Cotescu
Assignee: Radu Cotescu
 Fix For: Scripting Sightly Engine 1.0.12


FindBugs should run as part of the normal build process for the Sightly 
Scripting Engine.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-5445) XSSAPI#encodeForJSString is too restrictive

[Radu Cotescu (JIRA)]

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

Radu Cotescu resolved SLING-5445.
-
Resolution: Fixed

Fixed in [r1726027|https://svn.apache.org/r1726027].

> XSSAPI#encodeForJSString is too restrictive
> ---
>
> Key: SLING-5445
> URL: https://issues.apache.org/jira/browse/SLING-5445
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: XSS Protection API 1.0.6
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: XSS Protection API 1.0.8
>
>
> For the cases when somebody tries to sanitise JSON strings the 
> {{XSSAPI#encodeForJSString}} current implementation is too restrictive. 
> Assuming one would want to sanitize {{2016-01-21T15:40:30}}, the output of 
> the {{XSSAPI#encodeForJSString}} would be 
> {noformat}
> 2016\-01\-21T15:40:30
> {noformat}
> which although is a valid String for JavaScript code is not a valid one for 
> JSON.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5448) AuthenticationInfoPostProcessor javadoc misleading

[Alexander Klimetschek (JIRA)]

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

Alexander Klimetschek updated SLING-5448:
-
Description: 
Currently, the [AuthenticationInfoPostProcessor javadoc 
says|https://github.com/apache/sling/blob/4bc090c5f8cb8ec8d6b1674176978e9a5feff503/bundles/auth/core/src/main/java/org/apache/sling/auth/core/spi/AuthenticationInfoPostProcessor.java#L25-L29]:

{quote}
Service interface which allows bundles to modify the AuthenticationInfo object 
after authentication has been performed.
{quote}

But that's pretty misleading, as "after authentication" actually means "one 
AuthenticationHandler has returned an AuthenticationInfo" object, but does not 
include the resource provider creations (e.g. JCR repository login), which are 
often understood as part of authentication too.

I suggest this instead:
{quote}
Service interface which allows bundles to modify the AuthenticationInfo object 
right after one authentication handler has returned it from 
extractCredentials() or for an anonymous AuthenticationInfo. It is called 
before the resource resolver is created and any authentication in the resource 
providers (such as JCR repository login) happens.

As such it is useful to intercept responses from other AuthenticationHandlers 
and access or modify the AuthenticationInfo before they are actually used to 
create the resource resolver.
{quote}

  was:
Currently, the [AuthenticationInfoPostProcessor javadoc 
says|https://github.com/apache/sling/blob/4bc090c5f8cb8ec8d6b1674176978e9a5feff503/bundles/auth/core/src/main/java/org/apache/sling/auth/core/spi/AuthenticationInfoPostProcessor.java#L25-L29]:

{quote}
Service interface which allows bundles to modify the AuthenticationInfo object 
after authentication has been performed.
{quote}

But that's pretty misleading, as "after authentication" actually means "one 
AuthenticationHandler has returned an AuthenticationInfo" object, but does not 
include the resource provider creations (e.g. JCR repository login).

I suggest this instead:
{quote}
Service interface which allows bundles to modify the AuthenticationInfo object 
right after one authentication handler has returned it from 
extractCredentials() or for an anonymous AuthenticationInfo. It is called 
before the resource resolver is created and any authentication in the resource 
providers (such as JCR repository login) happens.

As such it is useful to intercept responses from other AuthenticationHandlers 
and access or modify the AuthenticationInfo before they are actually used to 
create the resource resolver.
{quote}


> AuthenticationInfoPostProcessor javadoc misleading
> --
>
> Key: SLING-5448
> URL: https://issues.apache.org/jira/browse/SLING-5448
> Project: Sling
>  Issue Type: Bug
>  Components: Authentication
>Affects Versions: Auth Core 1.3.12
>Reporter: Alexander Klimetschek
>
> Currently, the [AuthenticationInfoPostProcessor javadoc 
> says|https://github.com/apache/sling/blob/4bc090c5f8cb8ec8d6b1674176978e9a5feff503/bundles/auth/core/src/main/java/org/apache/sling/auth/core/spi/AuthenticationInfoPostProcessor.java#L25-L29]:
> {quote}
> Service interface which allows bundles to modify the AuthenticationInfo 
> object after authentication has been performed.
> {quote}
> But that's pretty misleading, as "after authentication" actually means "one 
> AuthenticationHandler has returned an AuthenticationInfo" object, but does 
> not include the resource provider creations (e.g. JCR repository login), 
> which are often understood as part of authentication too.
> I suggest this instead:
> {quote}
> Service interface which allows bundles to modify the AuthenticationInfo 
> object right after one authentication handler has returned it from 
> extractCredentials() or for an anonymous AuthenticationInfo. It is called 
> before the resource resolver is created and any authentication in the 
> resource providers (such as JCR repository login) happens.
> As such it is useful to intercept responses from other AuthenticationHandlers 
> and access or modify the AuthenticationInfo before they are actually used to 
> create the resource resolver.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-5448) AuthenticationInfoPostProcessor javadoc misleading

[Alexander Klimetschek (JIRA)]

Alexander Klimetschek created SLING-5448:


 Summary: AuthenticationInfoPostProcessor javadoc misleading
 Key: SLING-5448
 URL: https://issues.apache.org/jira/browse/SLING-5448
 Project: Sling
  Issue Type: Bug
  Components: Authentication
Affects Versions: Auth Core 1.3.12
Reporter: Alexander Klimetschek


Currently, the [AuthenticationInfoPostProcessor javadoc 
says|https://github.com/apache/sling/blob/4bc090c5f8cb8ec8d6b1674176978e9a5feff503/bundles/auth/core/src/main/java/org/apache/sling/auth/core/spi/AuthenticationInfoPostProcessor.java#L25-L29]:

{quote}
Service interface which allows bundles to modify the AuthenticationInfo object 
after authentication has been performed.
{quote}

But that's pretty misleading, as "after authentication" actually means "one 
AuthenticationHandler has returned an AuthenticationInfo" object, but does not 
include the resource provider creations (e.g. JCR repository login).

I suggest this instead:
{quote}
Service interface which allows bundles to modify the AuthenticationInfo object 
right after one authentication handler has returned it from 
extractCredentials() or for an anonymous AuthenticationInfo. It is called 
before the resource resolver is created and any authentication in the resource 
providers (such as JCR repository login) happens.

As such it is useful to intercept responses from other AuthenticationHandlers 
and access or modify the AuthenticationInfo before they are actually used to 
create the resource resolver.
{quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: svn commit: r1726029 - in /sling/trunk/bundles/scripting/sightly/engine: ./ src/main/java/org/apache/sling/scripting/sightly/impl/compiler/ src/main/java/org/apache/sling/scripting/sightly/impl/co

[Radu Cotescu]

Hi Robert,

Thanks for the heads up! How often is the analysis run? I see issues that
have been fixed by the commit for SLING-5447.

Cheers,
Radu

On Fri, 22 Jan 2016 at 07:38 Robert Munteanu  wrote:

> Hi Radu,
>
> On Thu, 2016-01-21 at 17:20 +, r...@apache.org wrote:
> > SLING-5447 - Enable FindBugs for the Sightly Scripting Engine
> >
> > * enabled FindBugs for the build process
>
> For the record you can also see the findbugs analysis results on the
> ASF Sonar instance:
>
>   https://analysis.apache.org/dashboard/index?id=org.apache.sling%3Asli
> ng-builder
> 
>
>
> For your use case, the Sightly Scripting Engine analysis results are
> available at
>
>   https://analysis.apache.org/dashboard/index?id=org.apache.sling%3Aorg
> .apache.sling.scripting.sightly
>
> Robert
>

Re: svn commit: r1726029 - in /sling/trunk/bundles/scripting/sightly/engine: ./ src/main/java/org/apache/sling/scripting/sightly/impl/compiler/ src/main/java/org/apache/sling/scripting/sightly/impl/co

[Robert Munteanu]

On Fri, 2016-01-22 at 07:50 +, Radu Cotescu wrote:
> Hi Robert,
> 
> Thanks for the heads up! How often is the analysis run? I see issues
> that
> have been fixed by the commit for SLING-5447.

It polls daily for SCM changes, see build record at 

  https://analysis.apache.org/jenkins/job/sling/

Robert

> 
> Cheers,
> Radu
> 
> On Fri, 22 Jan 2016 at 07:38 Robert Munteanu 
> wrote:
> 
> > Hi Radu,
> > 
> > On Thu, 2016-01-21 at 17:20 +, r...@apache.org wrote:
> > > SLING-5447 - Enable FindBugs for the Sightly Scripting Engine
> > > 
> > > * enabled FindBugs for the build process
> > 
> > For the record you can also see the findbugs analysis results on
> > the
> > ASF Sonar instance:
> > 
> >   https://analysis.apache.org/dashboard/index?id=org.apache.sling%3
> > Asli
> > ng-builder
> >  > sling-builder>
> > 
> > 
> > For your use case, the Sightly Scripting Engine analysis results
> > are
> > available at
> > 
> >   https://analysis.apache.org/dashboard/index?id=org.apache.sling%3
> > Aorg
> > .apache.sling.scripting.sightly
> > 
> > Robert
> > 

Re: svn commit: r1726029 - in /sling/trunk/bundles/scripting/sightly/engine: ./ src/main/java/org/apache/sling/scripting/sightly/impl/compiler/ src/main/java/org/apache/sling/scripting/sightly/impl/co

[Robert Munteanu]

Hi Radu,

On Thu, 2016-01-21 at 17:20 +, r...@apache.org wrote:
> SLING-5447 - Enable FindBugs for the Sightly Scripting Engine
> 
> * enabled FindBugs for the build process

For the record you can also see the findbugs analysis results on the
ASF Sonar instance:

  https://analysis.apache.org/dashboard/index?id=org.apache.sling%3Asli
ng-builder


For your use case, the Sightly Scripting Engine analysis results are
available at

  https://analysis.apache.org/dashboard/index?id=org.apache.sling%3Aorg
.apache.sling.scripting.sightly

Robert