Type checks not functional any more (since first CobiGen release)

[maybeec]

Due to the migration of the APPS-Generator's single application design to a more modularized architecture, the type checking template methods of the java plug-in have been destroyed.

The problem is, that the whole model will be converted to a DOM model to enable xPath expressions on the model within the template. As of the modularization, the type checking template methods are now part of the model itself and not part of the global variables of FreeMarker. Therefore, the needed ability to integrate a BeanModel for the util implementation in a generic way has been eliminated.

Thus we have to find a new approach to handle this. My current proposal would be to add another method for InputReaders to be called beside the createModel() method. This method then might provide multiple function extensions for the template. I would also suggest to use the right extension point of FreeMarker for functions.

• Let plug-ins provide specialized FreeMarker template methods #45 Implement cobigen-core extension interface
• implement extension interface for the two methods
  • instanceOf instead of the previously called isSubtypeOf
  • isAbstract
• update documentation

[maybeec]

Please also document potential changes in the dependencies done during development in the licence tracker: https://github.com/oasp/tools-cobigen/wiki/mgmt_dependency-and-license-tracking
Just add a new table for the new version of the java plugin at the bottom. Document the final target version here (without snapshot).

[fkreis]

I think I didn't change the dependencies. I only used the TemplateMethodModelEx interface which belongs to Freemarker and so already is documented.

[maybeec]

But you have changed the dependency of cobigen-core from v1.0.0 to v1.1.0, haven't you? ;)

[fkreis]

ok added it.
What do you mean with: "Document the final target version here (without snapshot)."

[maybeec]

I only indicated that you do not state v1.1.0-SNAPSHOT as the new dependency :) But you have done it intuitively right :)

[fkreis]

ahhh :)
so if you are satisfied with the results we can close this issue.
(Maybe we shoud remove the old class FreemarkerUtils and update the tests using that class)

[fkreis]

oh... The new testcases test only the freemarkerutil methods but not JavaInputReader.getTemplateMethods(Object). I will add that one...

[maybeec]

I think the old FreeMarkerUtil can be removed completely as it is not used any more. Same for the tests of it. You will have your own tests testing the new templates methods.
I will have a look at the results tomorrow morning. If you at the university, we can talk about open issues or I will close the issues otherwise.

[maybeec]

During your code cleanup you killed test JavaInputReaderTest.provideParsingAndReflectionModelFeatures :)
Unfortunately we currently do not have any continuous integration with running nightly builds. Nevertheless, you might want to run all tests by running the mvn clean install command. This will run all tests and fail if there are some tests failing.

Can you correct the failing test?

[fkreis]

yes sure ; )

[maybeec]

Unfortunately I found another issue during integration test. Maybe we should also introduce integration tests as you proposed.

I refactored the test organisation a little bit to distinct unit test from integration tests. I also added a test suite in the integrationtest package, which includes integration tests for the two methods implemented, which are currently not valid. Please can you have a look at them and green the test runner again? :) I added the integrationtest by myself to give you an example how to do such integration tests for plug-ins in future.

You may want to have a look at the isValidInput(Object) method to get to know all possible input types handled by the JavaInputReader.

[fkreis]

Now the two integration tests are valid, so I think the template methods should work for inputs of type class now. It also should work for valid Object[] with length = 2.

PackageFolder has a method getClassLoader but potentially it returns null because its initialized in the constructor. There is one Constructor PackageFolder(URI location, String packageName, ClassLoader classLoader) but the parameter classLoader is never used!

There is no solution for input of JavaClass until now.

[maybeec]

So if the classLoader field of PackageFolder is null, just use the current classLoader your application is running with. This field might not be used anymore because you removed the FreeMarkerUtil already :)

[fkreis]

how should we deal now with instances of JavaClass?

[maybeec]

I had a short look at JavaParserUtil#getFirstJavaClass, where the classLoader is appended while building a sourceLibrary and parsing the Java source files. But I think after lossing the reference to the ClassLibraryBuilder, we also loose the classLoader reference.
You might want to have also a look at it, but if there is no way to get the original ClassLoader reference anymore for parsed content, we should go for the default classLoader.

[maybeec]

• see comment in 2017649
• fix constructor of PackageFolder

[maybeec]

Due to some more integration testing, I found further issues.
See the latest committed test. Please fix, if possible. Otherwise, just note me, that I have to do it before releasing.

[fkreis]

the problem is, that the implemented methods expect an arg which is a list of Strings, but e.g. variables.abstractCollection in the template isAbstract.ftl provides an ElementModel and not the String "java.util.AbstractCollection" as intened by the context.xml, what I do not understand at the moment.

[maybeec]

I think this is FreeMarker internal stuff we have to fight with.
So in general, you should check the type of the input when you are casting. There is no type check performed by FreeMarker, so we have to do that. Furthermore, if input parameter does not match the expected types, you might want to throw an exception with an appropriate message.
Currently, the user gets a ClassCastException, which is most likely interpreted as a bug.

As far as I got the idea of the FreeMarker types, a SimpleScalar is something like string, int, long, ...
An ElementModel then is some expression including FreeMarker stuff. As far as I got it during a short debug, we should get the evaluated value from the ElementModel expression by some getter. So the only thing to do is to handle such new input types. I provided different expressions as parameters for the template methods in the test. I think that are the most commonly used ones. If you might imagine further ones, try them in the test.

[fkreis]

the failing test testCorrectClassLoaderForMethods resulted from an fault caused by me, sry 4 that : )
the other 2 (testIsAbstractMethod() and testIsSubtypeOfMethod()) resulted from type problems as described before. Therefore added type checks and casts to NodeModel/String if possible. Otherwise an exception is thrown now.