rules vs. generated code

[aklemp]

Hi,

I've stumbled across an issue while testing. Some types are generated and are located in a different source folder. Some of these types are created by 3rd-party tools and I have no control over them. The constraints of jQAssistant are invoked on the complete graph including the generated types. Obviously, there are situations where the constraint is failing for those types (e.g. the cdi:BeansMustUseConstructorInjection) but I want them to run on my own code.

One possibility is of course to use none of the available plugin constraints if that problem arises and define new ones with appropriate exclusions. The available constraints could also be templates that can be spezialized with a package, folder or whatever to exclude. The complete analysis could exclude generated code (although I don't like this all-or-nothing approach).

Probably this is a quite common scenario to have hand-written and generated code and different rules apply to them. What would be the way to go?

Kind regards, aklemp

[aklemp]

Another idea: some custom (project-specific) concept could label the types as generated. But then the constraint has to be a parameterized template. A specific constraint depends on the concept and the template passing the label name to exclude. This way, one could also apply different constraints to different types of generated code (generated by different tools).

The only change in jQAssistant would be to convert the existing constraints to templates or add templates to the default constraints.

[aklemp]

This might also apply to test code in addition to generated code because different conventions apply.

[DirkMahler]

There's an annotation @javax.annotation.Generated which is used by lots of tools to indicate that code is generated. Would be easy to add a concept "Generated" to the jQA java plugin.

[aklemp]

That's true but how to distinguish generated code of different tools where different constraints might apply. Also, how to use predefined constraints and configure them to apply to generated code or not?

[DirkMahler]

If there are several tools generating code then the following approach could help:

[[generated:tool1]]
.Labels all classes generated by tool1 as 'Generated'
[source,cypher,role=concept]
----
MATCH (n:Type) WHERE ... SET n:Generated RETURN n
----

[[generated:tool2]]
.Labels all classes generated by tool2 as 'Generated'
[source,cypher,role=concept]
----
MATCH (n:Type) WHERE ... SET n:Generated RETURN n
----

[[generated]]
.Reports the numer of generated classes
[source,cypher,role=concept,requiresConcepts="generated:tool1,generated:tool2"]
----
MATCH (n:Generated:Type) RETURN count(n)
----

[[my-constraint]]
.A constraint that ignores generated classes
[source,cypher,role=constraint,requiresConcepts="generated"]
----
MATCH (n:Type) WHERE ... and not n:Generated RETURN n
----

The trick is to use a concept that just reports all generated classes but itself depends on the various concepts to identify generated code.

[aklemp]

I don't understand how this resolves the problem. I cannot distinguish generated classes of tool1 and tool2. Therefore, my-constraint is an all-or-nothing approach either asserting all classes or the non-generated classes. I cannot apply it to all manually crafted classes and the ones of tool1 but not tool2. I could use different labels for the tools. But then I cannot use the constraints of the default plugins anymore, because everything needs to be customized in each project.

[DirkMahler]

Sorry - I missed this aspect:

[[generated:tool1]]
.Labels all classes generated by tool1 as 'Generated' and 'Tool1'
[source,cypher,role=concept]
----
MATCH (n:Type) WHERE ... SET n:Generated:Tool1 RETURN n
----

[[generated:tool2]]
.Labels all classes generated by tool2 as 'Generated' and 'Tool2'
[source,cypher,role=concept]
----
MATCH (n:Type) WHERE ... SET n:Generated:Tool2 RETURN n
----

[[generated]]
.Reports the numer of generated classes
[source,cypher,role=concept,requiresConcepts="generated:tool1,generated:tool2"]
----
MATCH (n:Generated:Type) RETURN count(n)
----

[[my-constraint]]
.A constraint that ignores generated classes from Tool1
[source,cypher,role=constraint,requiresConcepts="generated"]
----
MATCH (n:Type) WHERE ... and not n:Generated:Tool1 RETURN n
----

[aklemp]

Right, it can be solved like this. But as I said, all predefined constraints in the plugins have to be copied locally and adapted depending on the used tools. I was looking for a reusable solution, maybe using the existing template rule mechanism (probably extending it somehow).

[DirkMahler]

Hm - if it's about generic constraints (i.e. the which come with the distribution) it would be possible to exclude everything which is labeled as "Generated". This would mean that they all need to depend on a non-existing concept "Generated" which must be provided by the user who knows about the concrete tools used in a project. The disadvantage is that such a concept must be present before any of these rules can be used. To solve this I could imagine to provide a default concept "Generated" in the distribution which then can be overriden by a user with a concrete concept "Generated" that depends on all the other concepts that are needed to set the labels. WDYT?

[aklemp]

I'm not sure, if this would be useful in all projects because all the generic constraints would not apply to generated code. Imagine the following use case in a project:

apply Java constraints to complete graph including generated classes apply CDI constraints to complete graph but ignore generated classes of tool1 apply JUnit constraints to complete graph but not generated classes of tool2

[DirkMahler]

Moving this issue to a later release - there's already some very basic support for templates, we need to see if this can be used/extended to fit that use case

[StephanPirnbaum]

Closing this as (this is a very old discussion and) we now have means to define custom concepts that provide another concept, i.e. java:GeneratedType. Constraints are then only required to depend on this concept. If this is missing in a specific plugin, please open a ticket there.