-
Improvement
-
Resolution: Unresolved
-
Major
-
None
Currently the following code fails with a cryptic error message:
package org.test.; import groovy.transform.ToString @ToString(includeNames=true) class X implements Serializable { def script def A, B Promotemodul(script, m) { this.script = script this.A = m.A this.B = m.B } }
It would be great if some common annotations (ToString, EqualsAndHashCode...) would be supported in Pipeline Shared Libraries.
- is duplicated by
-
JENKINS-40564 Groovy class annotations not supported
-
- Resolved
-
- is related to
-
-
- Open
-
[JENKINS-45901] Allow common groovy annotation in Pipeline Shared Library Classes
Philipp Moeller
created issue -
| Link |
New:
This issue is duplicated by |
The issue description looks to me like it is only for shared libraries, but I would like to just clarify that these transformations would be very useful for pipeline definitions as well.
kevin brandon
added a comment - Seems to me that in the CmpTransformer that all present annotations should just be simply added. Annotations are meant to be meta data. If they are not supported they are not supported... but the annotation themselves shouldn't disappear. I can appreciate and understand about not wanting to support functionality that those annotations are meant for; however, by not having the meta data continue with the class it cuts out the possibility that the code might want to do some reflection. For myself I was hoping to annotate methods for some AOP action that would simply the code and keep it very dry.
abayer it would rock to keep the meta! Please let me know if I am off my rocker... or if there is a way to get back to the original class to access the meta that I am trying to look for!
kevin brandon
added a comment - Seems to me that in the CmpTransformer that all present annotations should just be simply added. Annotations are meant to be meta data. If they are not supported they are not supported... but the annotation themselves shouldn't disappear. I can appreciate and understand about not wanting to support functionality that those annotations are meant for; however, by not having the meta data continue with the class it cuts out the possibility that the code might want to do some reflection. For myself I was hoping to annotate methods for some AOP action that would simply the code and keep it very dry.
abayer it would rock to keep the meta! Please let me know if I am off my rocker... or if there is a way to get back to the original class to access the meta that I am trying to look for! 
Allan BURDAJEWICZ
added a comment - Also an issue with @MapConstructor Allan BURDAJEWICZ
added a comment - Since the common groovy annotations are not supported by the Groovy DSL, could we at least add this to the documentation ? Otherwise users may spend time to debugging issues in vain.
Allan BURDAJEWICZ
added a comment - Since the common groovy annotations are not supported by the Groovy DSL, could we at least add this to the documentation ? Otherwise users may spend time to debugging issues in vain. Not sure if there is any particular place where Groovy language support (or lack thereof) is exhaustively documented, but at any rate I would not expect this issue or anything like it to be addressed. The focus going forward is allowing external process execution, not wasting any more time on the CPS engine except in cases of security vulnerabilities or serious regressions.
jglick it has been been 3 years since your last comment, may I inquire what were you referring to when you said "allowing external process execution, not wasting any more time on the CPS engine" and is this something available to use? Is there any documentation on that alternative mechanism?
Unless I am missing something, I see no real alternative at the moment after 3 years of waiting. I would imagine Groovy being chosen to be the engine for its high level abstractions, meta programming features and ease one could create their own DSL. But when so fundamental features such as commonly used annotations ToString, EqualsAndHashCode, Delegate as well as Groovy Traits are not available - it is kind of defeats the purpose, doesn't it? Sometimes it is so frustrating to work on complex libraries as you may never know if your code will actually work in the CPS or not.
If not fix it, why not extend NonCPS annotation to support classes or maybe even allow users to disable it altogether for a given libraries? In certain use cases - the library forcibly injected into the pipeline and it is only limited to generating the pipeline and is not used in runtime - meaning all of the library classes are trusted and they require no survivability as the actual generated pipeline will be executed separately - in which case CPS is nothing but trouble, introducing artificial limitations for no practical gain. In my pretty complex library I have 99% of my methods annotated with NonCPS (except for the ones that are exposed to be called from Jenkinsfile context), meaning - CPS is actually only 1% efficient for my use case.
I would argue this issue has to be revisited and acted on. Unless, of course, there is a viable alternative that I am not aware of.
Dee Kryvenko
added a comment - - edited jglick it has been been 3 years since your last comment, may I inquire what were you referring to when you said "allowing external process execution, not wasting any more time on the CPS engine" and is this something available to use? Is there any documentation on that alternative mechanism?
Unless I am missing something, I see no real alternative at the moment after 3 years of waiting. I would imagine Groovy being chosen to be the engine for its high level abstractions, meta programming features and ease one could create their own DSL. But when so fundamental features such as commonly used annotations ToString, EqualsAndHashCode, Delegate as well as Groovy Traits are not available - it is kind of defeats the purpose, doesn't it? Sometimes it is so frustrating to work on complex libraries as you may never know if your code will actually work in the CPS or not.
If not fix it, why not extend NonCPS annotation to support classes or maybe even allow users to disable it altogether for a given libraries? In certain use cases - the library forcibly injected into the pipeline and it is only limited to generating the pipeline and is not used in runtime - meaning all of the library classes are trusted and they require no survivability as the actual generated pipeline will be executed separately - in which case CPS is nothing but trouble, introducing artificial limitations for no practical gain. In my pretty complex library I have 99% of my methods annotated with NonCPS (except for the ones that are exposed to be called from Jenkinsfile context), meaning - CPS is actually only 1% efficient for my use case.
I would argue this issue has to be revisited and acted on. Unless, of course, there is a viable alternative that I am not aware of.
So I'm not gonna close this quite yet, but I wouldn't expect to get this at any time in the foreseeable future - figuring out the right order to apply AST transformations (i.e., the @ToString annotation and CPS transformation) is a challenge.