{"action":"created","issue":{"url":"https://api.github.com/repos/dekorateio/dekorate/issues/286","repository_url":"https://api.github.com/repos/dekorateio/dekorate","labels_url":"https://api.github.com/repos/dekorateio/dekorate/issues/286/labels{/name}","comments_url":"https://api.github.com/repos/dekorateio/dekorate/issues/286/comments","events_url":"https://api.github.com/repos/dekorateio/dekorate/issues/286/events","html_url":"https://github.com/dekorateio/dekorate/issues/286","id":471309277,"node_id":"MDU6SXNzdWU0NzEzMDkyNzc=","number":286,"title":"Better Extensibility Model For Frameworks","user":{"login":"ryanjbaxter","id":524254,"node_id":"MDQ6VXNlcjUyNDI1NA==","avatar_url":"https://avatars1.githubusercontent.com/u/524254?v=4","gravatar_id":"","url":"https://api.github.com/users/ryanjbaxter","html_url":"https://github.com/ryanjbaxter","followers_url":"https://api.github.com/users/ryanjbaxter/followers","following_url":"https://api.github.com/users/ryanjbaxter/following{/other_user}","gists_url":"https://api.github.com/users/ryanjbaxter/gists{/gist_id}","starred_url":"https://api.github.com/users/ryanjbaxter/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ryanjbaxter/subscriptions","organizations_url":"https://api.github.com/users/ryanjbaxter/orgs","repos_url":"https://api.github.com/users/ryanjbaxter/repos","events_url":"https://api.github.com/users/ryanjbaxter/events{/privacy}","received_events_url":"https://api.github.com/users/ryanjbaxter/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2019-07-22T20:26:06Z","updated_at":"2019-07-24T20:23:51Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"This might be applicable to other frameworks, but my only experience is with Spring.\r\n\r\nWhat we do now is add some logic in `SpringBootApplicationProcessor` to add certain properties to the manifest we generate based on whether certain starters are on the classpath (for example Spring Cloud Kubernetes, Spring Actuator).  There are many many Spring starters in the wild and it would be nice if we didn't have to add everything to this one class and also if the code could live outside of Dekorate itself.  The ideal situation in my opinion would be if we could have the Dekorate Spring starter on the classpath and then any number of other starters that allow us to further \"decorate\" the manifest based on their needs.  @iocanel @geoand thoughts?"},"comment":{"url":"https://api.github.com/repos/dekorateio/dekorate/issues/comments/514785952","html_url":"https://github.com/dekorateio/dekorate/issues/286#issuecomment-514785952","issue_url":"https://api.github.com/repos/dekorateio/dekorate/issues/286","id":514785952,"node_id":"MDEyOklzc3VlQ29tbWVudDUxNDc4NTk1Mg==","user":{"login":"ryanjbaxter","id":524254,"node_id":"MDQ6VXNlcjUyNDI1NA==","avatar_url":"https://avatars1.githubusercontent.com/u/524254?v=4","gravatar_id":"","url":"https://api.github.com/users/ryanjbaxter","html_url":"https://github.com/ryanjbaxter","followers_url":"https://api.github.com/users/ryanjbaxter/followers","following_url":"https://api.github.com/users/ryanjbaxter/following{/other_user}","gists_url":"https://api.github.com/users/ryanjbaxter/gists{/gist_id}","starred_url":"https://api.github.com/users/ryanjbaxter/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ryanjbaxter/subscriptions","organizations_url":"https://api.github.com/users/ryanjbaxter/orgs","repos_url":"https://api.github.com/users/ryanjbaxter/repos","events_url":"https://api.github.com/users/ryanjbaxter/events{/privacy}","received_events_url":"https://api.github.com/users/ryanjbaxter/received_events","type":"User","site_admin":false},"created_at":"2019-07-24T20:23:51Z","updated_at":"2019-07-24T20:23:51Z","author_association":"CONTRIBUTOR","body":"Quoting @iocanel from #288\r\n\r\n> Currently, using the java.util.ServiceLoader anyone can provide a custom BeanListener which can dekorate the manifests as sees fit. We can extend this concept to classes too (as mentioned in #286).\r\n> \r\n> We may also need to find a way to override a bean or a class listener to change the behavior of a known listener (not 100% sure about it, needs some more thought).\r\n> \r\n> The big question is what's the ideal place for these listeners. Are we to bundle them inside the dekorate spring module, or we should push them to each project individuallly (e.g. move the sck integration in sck itself and so on), or even somewhere else?\r\n> \r\n\r\nOriginally I was thinking of having a Spring Dekorate project that we (the Spring team) own.  \r\n\r\n> Personally, as long as there is concensus on what is best for the majority of users, I'd rather keep most of listeners in the existing spring module. The main reason is that dekorate is a small project and at this stage it has quite a fast release cycle so it can help us move faster. An other reason is that it easier to maintain (less modules, less things to depend on dekorate), which also means easier for the user to get started (nothing can beat the drop a single jar to your classspath experience).\r\n \r\nI agree that Dekorate has been fine as far as contributing code and evolving quickly.  My only thought it that Spring has a such a big feature set (not that everything is going to have integration with Dekorate) that it might be a bit much.\r\n\r\n> So what I propose is the following, let's design together clear extension points. Let's provide a set of sensible defaults as part of the dekorate spring module. And from there if need be anyone can create specialized modules.\r\n> \r\n> wdyt?\r\n\r\nMaybe this makes sense to start with.  If we need to we can then separate that out into its own project if it evolves in a way that makes sense.\r\n\r\n@spencergibb wondering if you have any opinion one way or the other here\r\n"}}
{"actor":{"display_login":"ryanjbaxter"}}