You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by GitBox <gi...@apache.org> on 2020/11/21 09:38:15 UTC

[GitHub] [camel-k] lburgazzoli commented on issue #1821: Support for POJO, bring it back!

lburgazzoli commented on issue #1821:
URL: https://github.com/apache/camel-k/issues/1821#issuecomment-731554705


   I am the one to be blamed for have introduced and then removed this feature. 
   
   When this feature was first introduced, Camel was in its 2.x ages and features like properties binding and configuration over properties was not powerful as it is today, so having a way to easily configure components or other aspect of Camel was really needed and that's why I added it but it was never been intended to let people adding arbitrary code. As today the Camel engine is much more powerful and the reasons for which this has been introduced do not longer exists. 
   
   Unfortunately people as start abusing of this feature and I had to deal with lot of issues, some have been solved but some won't as **camel-k is not a generic build system and it will never be**.
   
   So what issues do we have by letting people adding any arbitrary code through camel-k ?
   
   1. each class is compiled in its own class-loader which make the resulting classes not visible from other classes (this has partially been solved but I don't want to bring yet another modular class-loader which greatly complicates things)
   2. dependencies between classes is not taken into account and it will never be so the compilation may fail at runtime if any of your class depend on another class you have added (maybe you are lucky and the order do not unveil the problem but still, it is unpredictable)
   3. size of the resulting CR may exceed the limit resources have (bear in mind that all your sources are stored inside etcd)
   4. consistency with other languages: should we support adding arbitrary js/groovy/kotlin code ?
   5. code is compiled at runtime, so every time the application starts, it will spend some time compiling your code which is not exactly what you want in case you want your integration to quickly scale up
   6. you may miss the option to use native compilation 
   
   That said I can evaluate to re introduce this feature but certainly not in its previous incarnation and you need to help me to shape an UX that do not encourage users to abuse of this capability and does not introduce yet another unmaintainable feature. 
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org