[jira] [Commented] (SLING-5763) ClassFormatException when using java 8 lambda expressions

2016-06-07 Thread Robert Munteanu (JIRA) 

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

Robert Munteanu commented on SLING-5763:


It seems that there have been some API changes between version 2.0 and 2.1 of 
the `org.apache.sling.scripting.jsp` bundle, namely in how the wrapper classes 
from `org.apache.sling.scripting.jsp.jasper` are configured and used.

So a straight upgrade does not work and I am not sure after a first glance how 
to update the code.

Would you be interested in supplying a patch? To get started, just upgrade the 
dependency to `org.apache.sling.scripting.jsp` in the 
`maven-jspc-plugin/pom.xml` file and see what does not compile :-)

> ClassFormatException when using java 8 lambda expressions
> -
>
> Key: SLING-5763
> URL: https://issues.apache.org/jira/browse/SLING-5763
> Project: Sling
>  Issue Type: Bug
>  Components: Maven Plugins and Archetypes
>Affects Versions: Maven JSPC Plugin 2.0.8
>Reporter: Andrey Bardashevsky
>
> When i try to jsp:useBean with Java 8 lambda expression jspc plugin throws 
> following exception:
> {code}
> org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException
>   at 
> org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.(ClassFileReader.java:329)
>   at 
> org.apache.sling.scripting.jsp.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:204)
>   at 
> org.apache.sling.scripting.jsp.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:176)
>   at 
> org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:123)
>   at 
> org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:178)
>   at 
> org.eclipse.jdt.internal.compiler.lookup.Scope.getPackage(Scope.java:2046)
>   at 
> org.eclipse.jdt.internal.compiler.ast.QualifiedTypeReference.getTypeBinding(QualifiedTypeReference.java:69)
>   at 
> org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType(TypeReference.java:130)
>   at 
> org.eclipse.jdt.internal.compiler.ast.LocalDeclaration.resolve(LocalDeclaration.java:138)
>   at 
> org.eclipse.jdt.internal.compiler.ast.Block.resolveUsing(Block.java:115)
>   at 
> org.eclipse.jdt.internal.compiler.ast.TryStatement.resolve(TryStatement.java:751)
>   at 
> org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:432)
>   at 
> org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:190)
>   at 
> org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:403)
>   at 
> org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1047)
>   at 
> org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1094)
>   at 
> org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:353)
>   at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:596)
>   at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:411)
>   at 
> org.apache.sling.scripting.jsp.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:410)
>   at 
> org.apache.sling.scripting.jsp.jasper.compiler.Compiler.compile(Compiler.java:313)
>   at org.apache.sling.maven.jspc.JspcMojo.processFile(JspcMojo.java:367)
>   at 
> org.apache.sling.maven.jspc.JspcMojo.executeInternal(JspcMojo.java:321)
>   at org.apache.sling.maven.jspc.JspcMojo.execute(JspcMojo.java:240)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
>   at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
>

[jira] [Commented] (SLING-5763) ClassFormatException when using java 8 lambda expressions

2016-06-07 Thread Robert Munteanu (JIRA) 

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

Robert Munteanu commented on SLING-5763:


Ah, sorry, I completely misread your report. I though this was happening at 
runtime and mistook the component as 'it happened on a project generated using 
the Maven archetype'.

> ClassFormatException when using java 8 lambda expressions
> -
>
> Key: SLING-5763
> URL: https://issues.apache.org/jira/browse/SLING-5763
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting JSP 2.1.8
>Reporter: Andrey Bardashevsky
>
> When i try to jsp:useBean with Java 8 lambda expression jspc plugin throws 
> following exception:
> {code}
> org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException
>   at 
> org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.(ClassFileReader.java:329)
>   at 
> org.apache.sling.scripting.jsp.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:204)
>   at 
> org.apache.sling.scripting.jsp.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:176)
>   at 
> org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:123)
>   at 
> org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:178)
>   at 
> org.eclipse.jdt.internal.compiler.lookup.Scope.getPackage(Scope.java:2046)
>   at 
> org.eclipse.jdt.internal.compiler.ast.QualifiedTypeReference.getTypeBinding(QualifiedTypeReference.java:69)
>   at 
> org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType(TypeReference.java:130)
>   at 
> org.eclipse.jdt.internal.compiler.ast.LocalDeclaration.resolve(LocalDeclaration.java:138)
>   at 
> org.eclipse.jdt.internal.compiler.ast.Block.resolveUsing(Block.java:115)
>   at 
> org.eclipse.jdt.internal.compiler.ast.TryStatement.resolve(TryStatement.java:751)
>   at 
> org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:432)
>   at 
> org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:190)
>   at 
> org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:403)
>   at 
> org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1047)
>   at 
> org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1094)
>   at 
> org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:353)
>   at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:596)
>   at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:411)
>   at 
> org.apache.sling.scripting.jsp.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:410)
>   at 
> org.apache.sling.scripting.jsp.jasper.compiler.Compiler.compile(Compiler.java:313)
>   at org.apache.sling.maven.jspc.JspcMojo.processFile(JspcMojo.java:367)
>   at 
> org.apache.sling.maven.jspc.JspcMojo.executeInternal(JspcMojo.java:321)
>   at org.apache.sling.maven.jspc.JspcMojo.execute(JspcMojo.java:240)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
>   at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm

[jira] [Updated] (SLING-5763) ClassFormatException when using java 8 lambda expressions

2016-06-07 Thread Robert Munteanu (JIRA) 

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

Robert Munteanu updated SLING-5763:
---
Affects Version/s: (was: Scripting JSP 2.1.8)
   Maven JSPC Plugin 2.0.8

> ClassFormatException when using java 8 lambda expressions
> -
>
> Key: SLING-5763
> URL: https://issues.apache.org/jira/browse/SLING-5763
> Project: Sling
>  Issue Type: Bug
>  Components: Maven Plugins and Archetypes
>Affects Versions: Maven JSPC Plugin 2.0.8
>Reporter: Andrey Bardashevsky
>
> When i try to jsp:useBean with Java 8 lambda expression jspc plugin throws 
> following exception:
> {code}
> org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException
>   at 
> org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.(ClassFileReader.java:329)
>   at 
> org.apache.sling.scripting.jsp.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:204)
>   at 
> org.apache.sling.scripting.jsp.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:176)
>   at 
> org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:123)
>   at 
> org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:178)
>   at 
> org.eclipse.jdt.internal.compiler.lookup.Scope.getPackage(Scope.java:2046)
>   at 
> org.eclipse.jdt.internal.compiler.ast.QualifiedTypeReference.getTypeBinding(QualifiedTypeReference.java:69)
>   at 
> org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType(TypeReference.java:130)
>   at 
> org.eclipse.jdt.internal.compiler.ast.LocalDeclaration.resolve(LocalDeclaration.java:138)
>   at 
> org.eclipse.jdt.internal.compiler.ast.Block.resolveUsing(Block.java:115)
>   at 
> org.eclipse.jdt.internal.compiler.ast.TryStatement.resolve(TryStatement.java:751)
>   at 
> org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:432)
>   at 
> org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:190)
>   at 
> org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:403)
>   at 
> org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1047)
>   at 
> org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1094)
>   at 
> org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:353)
>   at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:596)
>   at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:411)
>   at 
> org.apache.sling.scripting.jsp.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:410)
>   at 
> org.apache.sling.scripting.jsp.jasper.compiler.Compiler.compile(Compiler.java:313)
>   at org.apache.sling.maven.jspc.JspcMojo.processFile(JspcMojo.java:367)
>   at 
> org.apache.sling.maven.jspc.JspcMojo.executeInternal(JspcMojo.java:321)
>   at org.apache.sling.maven.jspc.JspcMojo.execute(JspcMojo.java:240)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
>   at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.codehaus.plexus.classwo

[jira] [Updated] (SLING-5763) ClassFormatException when using java 8 lambda expressions

2016-06-07 Thread Robert Munteanu (JIRA) 

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

Robert Munteanu updated SLING-5763:
---
Component/s: (was: Scripting)
 Maven Plugins and Archetypes

> ClassFormatException when using java 8 lambda expressions
> -
>
> Key: SLING-5763
> URL: https://issues.apache.org/jira/browse/SLING-5763
> Project: Sling
>  Issue Type: Bug
>  Components: Maven Plugins and Archetypes
>Affects Versions: Maven JSPC Plugin 2.0.8
>Reporter: Andrey Bardashevsky
>
> When i try to jsp:useBean with Java 8 lambda expression jspc plugin throws 
> following exception:
> {code}
> org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException
>   at 
> org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.(ClassFileReader.java:329)
>   at 
> org.apache.sling.scripting.jsp.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:204)
>   at 
> org.apache.sling.scripting.jsp.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:176)
>   at 
> org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:123)
>   at 
> org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:178)
>   at 
> org.eclipse.jdt.internal.compiler.lookup.Scope.getPackage(Scope.java:2046)
>   at 
> org.eclipse.jdt.internal.compiler.ast.QualifiedTypeReference.getTypeBinding(QualifiedTypeReference.java:69)
>   at 
> org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType(TypeReference.java:130)
>   at 
> org.eclipse.jdt.internal.compiler.ast.LocalDeclaration.resolve(LocalDeclaration.java:138)
>   at 
> org.eclipse.jdt.internal.compiler.ast.Block.resolveUsing(Block.java:115)
>   at 
> org.eclipse.jdt.internal.compiler.ast.TryStatement.resolve(TryStatement.java:751)
>   at 
> org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:432)
>   at 
> org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:190)
>   at 
> org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:403)
>   at 
> org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1047)
>   at 
> org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1094)
>   at 
> org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:353)
>   at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:596)
>   at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:411)
>   at 
> org.apache.sling.scripting.jsp.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:410)
>   at 
> org.apache.sling.scripting.jsp.jasper.compiler.Compiler.compile(Compiler.java:313)
>   at org.apache.sling.maven.jspc.JspcMojo.processFile(JspcMojo.java:367)
>   at 
> org.apache.sling.maven.jspc.JspcMojo.executeInternal(JspcMojo.java:321)
>   at org.apache.sling.maven.jspc.JspcMojo.execute(JspcMojo.java:240)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
>   at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.codehaus.plexus.classworlds.launcher.Lau

Re: Dependency Management

2016-06-07 Thread Georg Henzler 

On 2016-05-26 14:36, Bertrand Delacretaz wrote:

My opinion, and I think this is what we've been doing in Sling forever
even if we didn't explicitly document it, is that if a bundle B
depends on another *for its API* then the dependency should list the
lowest possible version.


I agree to this.

... just tried to run the latest with hc-core [1] to test something 
completely else and obviously it does not work with AEM anymore unless 
you deploy commons lang3 elsewhere - IMHO there is no need to make 
everyone go through this hassle (for me it was easier to revert the 
commit to test what I was testing...)


Regards
Georg

[1]
https://github.com/apache/sling/commit/7203dc7ec1b7b85ecca93450179bbefa78f7bd02?diff=unified

Re: Dependency Management

2016-06-07 Thread Konrad Windszus 

> On 07 Jun 2016, at 10:32, Konrad Windszus  wrote:
> 
> Hi,
>> On 07 Jun 2016, at 10:12, Oliver Lietz  wrote:
>> 
>> On Monday 06 June 2016 14:57:16 Konrad Windszus wrote:
>>> I would like to wrap things up here:
>>> 
>>> So it seems the common agreement is:
>> 
>> Really?
>> 
>>> 1) Depend on the lowest possible version of a dependency (to let bnd
>>> generate import package ranges which are as broad as possible to support as
>>> many different systems as possible (even old ones)). A module should only
>>> be upgraded to a newer dependency in case this is really necessary (because
>>> of a feature being used which is not available in earlier version or if the
>>> newer version contains a bugfix from which the consumer bundle is
>>> affected).
>> 
>> I don't see all topics discussed and your definition is very vague. It can 
>> be 
>> taken as "never upgrade". This prevents modernization of our code base 
>> (example given).
> I agree that this is rather vague. We definitely need an official way of 
> upgrading dependencies. But in the cases of upgrading commons-lang and 
> commons-io I don't see any convincing reason to upgrade to the newest 
> dependency for the modules validation or health check (we don't actually 
> leverage new API there yet). Only if we do, we can and should discuss again.
> 
>> 
>>> 2) For ITs and the Maven Launchpad depend on the same version
>>> which is reasonably new (this is only possible if the IT is in a dedicated
>>> Maven bundle).
>> 
>> Pax Exam can pull in any version of a dependency even when running in the 
>> same 
>> module. The limitation to one version is only true for our current setup of 
>> unit tests with Maven 3.
> Not all ITs are based on Pax Exam. So the ones leveraging a real Sling 
> instance and being located in the same bundle as the code itself (Transporter 
> rule) are not that easy to decouple.
>> 
>>> 3) Since Maven does not completely separate compile and test
>>> classpath for the unit test we must depend on the lowest possible version
>>> as well.
>>> 
>>> If everyone is fine with that, I would ask Oliver Lietz to basically revert
>>> some changes being done in https://issues.apache.org/jira/browse/SLING-5603 
>>> 
>>> and https://issues.apache.org/jira/browse/SLING-5685 
>>> . Thanks for your
>>> input,
>> 
>> To make clear you are the driving force behind this approach please go ahead 
>> and revert yourself (and don't forget to adjust fixed versions).
> Ok, I will do so for Healthcheck Core in 
> https://issues.apache.org/jira/browse/SLING-5685 
> .
Actually it is unclear why the dependency to Commons IO was introduced at all 
for HC Core. Please also check 
https://issues.apache.org/jira/browse/SLING-5685?focusedCommentId=15318210&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15318210.
@Oli: Can you quickly comment on that? Thanks

>> 
>> Regards,
>> O.
>> 
>>> Konrad
>>> 
 On 03 Jun 2016, at 13:32, Oliver Lietz  wrote:
 
 On Friday 03 June 2016 20:13:29 Steven Walters wrote:
> On Fri, Jun 3, 2016 at 6:20 PM, Oliver Lietz  
>> wrote:
>> On Monday 30 May 2016 15:28:04 Robert Munteanu wrote:
>>> On Fri, 2016-05-27 at 11:14 +0200, Oliver Lietz wrote:
 I don't think there is support in Maven 3 for unit tests using a
 different
 version than for compile. Not sure if other build tools can handle
 different
 versions of dependencies for compile and test.
>>> 
>>> Maven 3 is unable to do that. I can't say anything for other build
>>> systems.
>> 
>> Looks like Gradle can do (but I haven't tested):
>> https://docs.gradle.org/current/userguide/java_plugin.html#sec:java_plug
>> in
>> _and_dependency_management
> 
> Yes, Gradle can do this.
> 'compile' and 'testRuntime' configurations are the standard
> configuration names that are relevant here and there is a natural
> inheritance chain (such that the default is that 'testRuntime'
> eventually inherits everything in 'compile'),
> but the versions used by 'testCompile/'testRuntime' can be overridden
> to be different (usually newer) ones than what is used by
> 'compile'/'runtime'
> 
> I've done this plenty in the past when working with AEM to use newer
> APIs/frameworks in the tests than what the code is compiled against.
> such as compiling for AEM 5.6, but due to using newer versions of the
> Sling mock frameworks in test cases, having newer Sling jars pulled in
> as a result for test case compilation + execution.
> Maven can't do this, so it makes writing tests for the same code more
> difficult when using Maven when compared to Gradle under these
> circumstances.
> 
> However, I don't particularly see this being enough reason alone to
> warrant

[jira] [Comment Edited] (SLING-5685) Upgrade Commons IO to 2.5

2016-06-07 Thread Konrad Windszus (JIRA) 

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

Konrad Windszus edited comment on SLING-5685 at 6/7/16 9:27 AM:


It is unclear why the dependency to Commons IO was added in HC Core in 
[r1741565|https://svn.apache.org/r1741565] at all. Commons IO is not necessary 
for HC core and before that commit was never referenced. Why was it introduced 
with that commit?


was (Author: kwin):
It is unclear why the dependency to Commons IO was added at all in HC Core in 
[r1741565|https://svn.apache.org/r1741565] at all. Commons IO is not necessary 
for HC core and before that commit was never referenced. Why was it introduced 
with that commit?

> Upgrade Commons IO to 2.5
> -
>
> Key: SLING-5685
> URL: https://issues.apache.org/jira/browse/SLING-5685
> Project: Sling
>  Issue Type: Task
>  Components: Launchpad, Scripting
>Reporter: Oliver Lietz
> Fix For: File System ClassLoader 1.0.4, Launchpad Karaf Features 
> 0.2.0, Scripting Thymeleaf 1.0.0, Health Check Core 1.2.6
>
> Attachments: commons-io.java.txt, commons-io.pom.txt
>
>




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

[jira] [Commented] (SLING-5685) Upgrade Commons IO to 2.5

2016-06-07 Thread Konrad Windszus (JIRA) 

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

Konrad Windszus commented on SLING-5685:


It is unclear why the dependency to Commons IO was added at all in HC Core in 
[r1741565|https://svn.apache.org/r1741565] at all. Commons IO is not necessary 
for HC core and before that commit was never referenced. Why was it introduced 
with that commit?

> Upgrade Commons IO to 2.5
> -
>
> Key: SLING-5685
> URL: https://issues.apache.org/jira/browse/SLING-5685
> Project: Sling
>  Issue Type: Task
>  Components: Launchpad, Scripting
>Reporter: Oliver Lietz
> Fix For: File System ClassLoader 1.0.4, Launchpad Karaf Features 
> 0.2.0, Scripting Thymeleaf 1.0.0, Health Check Core 1.2.6
>
> Attachments: commons-io.java.txt, commons-io.pom.txt
>
>




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

[jira] [Resolved] (SLING-5754) Sightly renders form attributes always in lowercase

2016-06-07 Thread Konrad Windszus (JIRA) 

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

Konrad Windszus resolved SLING-5754.

Resolution: Invalid

> Sightly renders form attributes always in lowercase
> ---
>
> Key: SLING-5754
> URL: https://issues.apache.org/jira/browse/SLING-5754
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.2
>Reporter: Erik Grijzen
>
> Sightly always renders all HTML attributes of a  element in lowercase:
> HTML source:
> {code}
> 
> {code}
> Actual output:
> {code}
> 
> {code}
> Expected output:
> {code}
> 
> {code}
> For other HTML tags like , , , etc. it works fine.



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

Re: Dependency Management

2016-06-07 Thread Konrad Windszus 
Hi,
> On 07 Jun 2016, at 10:12, Oliver Lietz  wrote:
> 
> On Monday 06 June 2016 14:57:16 Konrad Windszus wrote:
>> I would like to wrap things up here:
>> 
>> So it seems the common agreement is:
> 
> Really?
> 
>> 1) Depend on the lowest possible version of a dependency (to let bnd
>> generate import package ranges which are as broad as possible to support as
>> many different systems as possible (even old ones)). A module should only
>> be upgraded to a newer dependency in case this is really necessary (because
>> of a feature being used which is not available in earlier version or if the
>> newer version contains a bugfix from which the consumer bundle is
>> affected).
> 
> I don't see all topics discussed and your definition is very vague. It can be 
> taken as "never upgrade". This prevents modernization of our code base 
> (example given).
I agree that this is rather vague. We definitely need an official way of 
upgrading dependencies. But in the cases of upgrading commons-lang and 
commons-io I don't see any convincing reason to upgrade to the newest 
dependency for the modules validation or health check (we don't actually 
leverage new API there yet). Only if we do, we can and should discuss again.

> 
>> 2) For ITs and the Maven Launchpad depend on the same version
>> which is reasonably new (this is only possible if the IT is in a dedicated
>> Maven bundle).
> 
> Pax Exam can pull in any version of a dependency even when running in the 
> same 
> module. The limitation to one version is only true for our current setup of 
> unit tests with Maven 3.
Not all ITs are based on Pax Exam. So the ones leveraging a real Sling instance 
and being located in the same bundle as the code itself (Transporter rule) are 
not that easy to decouple.
> 
>> 3) Since Maven does not completely separate compile and test
>> classpath for the unit test we must depend on the lowest possible version
>> as well.
>> 
>> If everyone is fine with that, I would ask Oliver Lietz to basically revert
>> some changes being done in https://issues.apache.org/jira/browse/SLING-5603
>> and https://issues.apache.org/jira/browse/SLING-5685. Thanks for your
>> input,
> 
> To make clear you are the driving force behind this approach please go ahead 
> and revert yourself (and don't forget to adjust fixed versions).
Ok, I will do so for Healthcheck Core in 
https://issues.apache.org/jira/browse/SLING-5685.
> 
> Regards,
> O.
> 
>> Konrad
>> 
>>> On 03 Jun 2016, at 13:32, Oliver Lietz  wrote:
>>> 
>>> On Friday 03 June 2016 20:13:29 Steven Walters wrote:
 On Fri, Jun 3, 2016 at 6:20 PM, Oliver Lietz  
> wrote:
> On Monday 30 May 2016 15:28:04 Robert Munteanu wrote:
>> On Fri, 2016-05-27 at 11:14 +0200, Oliver Lietz wrote:
>>> I don't think there is support in Maven 3 for unit tests using a
>>> different
>>> version than for compile. Not sure if other build tools can handle
>>> different
>>> versions of dependencies for compile and test.
>> 
>> Maven 3 is unable to do that. I can't say anything for other build
>> systems.
> 
> Looks like Gradle can do (but I haven't tested):
> https://docs.gradle.org/current/userguide/java_plugin.html#sec:java_plug
> in
> _and_dependency_management
 
 Yes, Gradle can do this.
 'compile' and 'testRuntime' configurations are the standard
 configuration names that are relevant here and there is a natural
 inheritance chain (such that the default is that 'testRuntime'
 eventually inherits everything in 'compile'),
 but the versions used by 'testCompile/'testRuntime' can be overridden
 to be different (usually newer) ones than what is used by
 'compile'/'runtime'
 
 I've done this plenty in the past when working with AEM to use newer
 APIs/frameworks in the tests than what the code is compiled against.
 such as compiling for AEM 5.6, but due to using newer versions of the
 Sling mock frameworks in test cases, having newer Sling jars pulled in
 as a result for test case compilation + execution.
 Maven can't do this, so it makes writing tests for the same code more
 difficult when using Maven when compared to Gradle under these
 circumstances.
 
 However, I don't particularly see this being enough reason alone to
 warrant the effort of having Sling switching to Gradle.
 There are some other possible benefits to using Gradle, such as being
 able to merge separate IT modules back into modules they are testing,
 therefore reducing the number of modules/build complexity.
 But even so, I still don't see Sling leaving Maven.
>>> 
>>> Same here. That would be a lot of work and I don't think the project can
>>> perform such a big task right now.
>>> 
>>> O.
>

[jira] [Commented] (SLING-5754) Sightly renders form attributes always in lowercase

2016-06-07 Thread Georg Henzler (JIRA) 

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

Georg Henzler commented on SLING-5754:
--

As it turned out this is not a Sightly problem, but rather happens in 
com.day.cq.rewriter.htmlparser.TagTokenizer#attributeEnded(...) for all tags 
that are configured to be rewritten via includeTags configuration. The standard 
sling generator 
(org.apache.sling.rewriter.impl.components.HtmlGeneratorFactory) does not do 
this. 

[~kwin] Please close as invalid (as I don't have permissions to do so).  

> Sightly renders form attributes always in lowercase
> ---
>
> Key: SLING-5754
> URL: https://issues.apache.org/jira/browse/SLING-5754
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.2
>Reporter: Erik Grijzen
>
> Sightly always renders all HTML attributes of a  element in lowercase:
> HTML source:
> {code}
> 
> {code}
> Actual output:
> {code}
> 
> {code}
> Expected output:
> {code}
> 
> {code}
> For other HTML tags like , , , etc. it works fine.



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

Re: Dependency Management

2016-06-07 Thread Oliver Lietz 
On Monday 06 June 2016 14:57:16 Konrad Windszus wrote:
> I would like to wrap things up here:
> 
> So it seems the common agreement is:

Really?

> 1) Depend on the lowest possible version of a dependency (to let bnd
> generate import package ranges which are as broad as possible to support as
> many different systems as possible (even old ones)). A module should only
> be upgraded to a newer dependency in case this is really necessary (because
> of a feature being used which is not available in earlier version or if the
> newer version contains a bugfix from which the consumer bundle is
> affected).

I don't see all topics discussed and your definition is very vague. It can be 
taken as "never upgrade". This prevents modernization of our code base 
(example given).

> 2) For ITs and the Maven Launchpad depend on the same version
> which is reasonably new (this is only possible if the IT is in a dedicated
> Maven bundle).

Pax Exam can pull in any version of a dependency even when running in the same 
module. The limitation to one version is only true for our current setup of 
unit tests with Maven 3.

> 3) Since Maven does not completely separate compile and test
> classpath for the unit test we must depend on the lowest possible version
> as well.
> 
> If everyone is fine with that, I would ask Oliver Lietz to basically revert
> some changes being done in https://issues.apache.org/jira/browse/SLING-5603
> and https://issues.apache.org/jira/browse/SLING-5685. Thanks for your
> input,

To make clear you are the driving force behind this approach please go ahead 
and revert yourself (and don't forget to adjust fixed versions).

Regards,
O.

> Konrad
> 
> > On 03 Jun 2016, at 13:32, Oliver Lietz  wrote:
> > 
> > On Friday 03 June 2016 20:13:29 Steven Walters wrote:
> >> On Fri, Jun 3, 2016 at 6:20 PM, Oliver Lietz  
wrote:
> >>> On Monday 30 May 2016 15:28:04 Robert Munteanu wrote:
>  On Fri, 2016-05-27 at 11:14 +0200, Oliver Lietz wrote:
> > I don't think there is support in Maven 3 for unit tests using a
> > different
> > version than for compile. Not sure if other build tools can handle
> > different
> > versions of dependencies for compile and test.
>  
>  Maven 3 is unable to do that. I can't say anything for other build
>  systems.
> >>> 
> >>> Looks like Gradle can do (but I haven't tested):
> >>> https://docs.gradle.org/current/userguide/java_plugin.html#sec:java_plug
> >>> in
> >>> _and_dependency_management
> >> 
> >> Yes, Gradle can do this.
> >> 'compile' and 'testRuntime' configurations are the standard
> >> configuration names that are relevant here and there is a natural
> >> inheritance chain (such that the default is that 'testRuntime'
> >> eventually inherits everything in 'compile'),
> >> but the versions used by 'testCompile/'testRuntime' can be overridden
> >> to be different (usually newer) ones than what is used by
> >> 'compile'/'runtime'
> >> 
> >> I've done this plenty in the past when working with AEM to use newer
> >> APIs/frameworks in the tests than what the code is compiled against.
> >> such as compiling for AEM 5.6, but due to using newer versions of the
> >> Sling mock frameworks in test cases, having newer Sling jars pulled in
> >> as a result for test case compilation + execution.
> >> Maven can't do this, so it makes writing tests for the same code more
> >> difficult when using Maven when compared to Gradle under these
> >> circumstances.
> >> 
> >> However, I don't particularly see this being enough reason alone to
> >> warrant the effort of having Sling switching to Gradle.
> >> There are some other possible benefits to using Gradle, such as being
> >> able to merge separate IT modules back into modules they are testing,
> >> therefore reducing the number of modules/build complexity.
> >> But even so, I still don't see Sling leaving Maven.
> > 
> > Same here. That would be a lot of work and I don't think the project can
> > perform such a big task right now.
> > 
> > O.