Sculptor 3.1: Dropping support for Java 6?

[Torsten Juergeleit]

How about dropping support for Java 6 (Oracle has stopped public support of Java 6 as of Feb 2013) and requiring at least Java 7 for Sculptor?

This gives us the ability to use dependencies compiled with Java 7, e.g. recent versions of Google App Engine.

WDYT?

/Torsten

[pavel.tavoda]

Yes, definitely, what about Spring 4?

[Torsten Juergeleit]

Yes, definitely,

Ok, here we go #149.

what about Spring 4?

This is tracked in #120. The develop branch is already on Spring 4.Here we have to update the Maven archetypes yet.

/Torsten

[pavel.tavoda]

Torsten just side question. I'm updating our internal projects to latest release 3.0.6 (from 3.0.0-SNAPSHOT).

I'm not able to override some basic methods like:

@ChainOverride

class PropertiesOverride extends Properties {

override String getResourceDir(Application application, String name) {

application.name.toLowerCase() + "/" + next.getResourceDir(application, name)

}

override String getResourceDirModule(Module module, String name) {

module.application.name.toLowerCase() + "/" + next.getResourceDirModule(module, name)

}

}

It has something to do with infered (implicit return type) of methods and active annotations in Xtend?

Wasn't this already solved in Xtend?

TNX

[Torsten Juergeleit]

Yes, this is due to our workaround "skipping methods with inferred return type" introduced in #96.

The inferred return type issue isn't solved in Xtend yet. With 2.7 we get an additional validation phase where the read-only AST provides all fully-resolved types.

/Torsten

[pavel.tavoda]

Great, that looks promising. Can we switch to 2.7?

I can extract return types from java compiled classes and explicitly set return values for xtend methods if necessary.

[Torsten Juergeleit]

Im already working on the modifications necessary for updating to 2.7.2 for #150. Xtend 2.7 introduces behaviour changes in the Xtend Compiler which are breaking our active annotations and the corresponding tests.

/Torsten

[pavel.tavoda]

I will wait for you, if it's not possible (for whatever reason) deduce return types I will do this text magic.

I can't compile cartridges (on master branch), bellow you see errors. I guess it's some simple problem with Logger however how it's possible that it's working on Travis :-O?

Also we can create -generator archetype with all possible classes and methods which can be overridden, what do you think?

TNX Torsten

[INFO] --- xtend-maven-plugin:2.6.2:compile (default) @ sculptor-cartridge-builder ---

[ERROR] 

ERROR: RootTmplExtension.xtend - 

26: Problem while loading annotation processor: org/slf4j/LoggerFactory

[ERROR] 

ERROR: RootTmplExtension.xtend - 

26: Problem while loading annotation processor: org/slf4j/LoggerFactory

[ERROR] 

ERROR: RootTmplExtension.xtend - 

27: No default constructor in super type RootTmpl.RootTmplExtension must define an explicit constructor.

[ERROR] 

ERROR: BuilderHelper.xtend - 

31: Problem while loading annotation processor: org/slf4j/LoggerFactory

[ERROR] 

ERROR: BuilderHelper.xtend - 

31: Problem while loading annotation processor: Could not initialize class org.sculptor.generator.chain.ChainOverridableProcessor

[ERROR] 

ERROR: BuilderTmpl.xtend - 

34: Problem while loading annotation processor: Could not initialize class org.sculptor.generator.chain.ChainOverridableProcessor

[ERROR] 

ERROR: BuilderTmpl.xtend - 

34: Problem while loading annotation processor: org/slf4j/LoggerFactory

[ERROR] 

ERROR: BuilderProperties.xtend - 

25: Problem while loading annotation processor: Could not initialize class org.sculptor.generator.chain.ChainOverridableProcessor

[ERROR] 

ERROR: BuilderProperties.xtend - 

25: Problem while loading annotation processor: Could not initialize class org.sculptor.generator.chain.ChainOverridableProcessor

[Torsten Juergeleit]

After closing #150 Sculptors develop branch is running with Xtext / Xtend 2.7.2 now.

Regarding your issues during compiling the cartridges is a result of missing compile-time dependencies in Sculptors generator library. This should be fixed with the latest commits.

/Torsten 

[pavel.tavoda]

I will check this, thank you.

/Pavel

[pavel.tavoda]

OK, now cartridges compiles fine.

Do you have some idea how to use validation phase for inferring return types? This AST is read-only. Possibilities:

1) Generate code in another project which is compiled AFTER generator-core

2) Use another override mechanism

3) Provide explicit return types

Some other idea? Can we 'cache' MutableClassDeclartion and change return type in validation phase?

Pavel

[pavel.tavoda]

Got it working. Now getReturnType() doesn't return error for inferred methods. You can use this reference in your generated methods and once it get's resolved it's 'filled' on all places.

Preparing patch with test case.

/Pavel