On 12/6/12 6:31 PM, "Jesse Glick" <jgl...@cloudbees.com> wrote:
>On 12/06/2012 08:03 PM, Dean Yu wrote: >> I'm not a big fan of the shared plugin model. As a user, I've gotten >> bitten way to many times by compatibility problems this causes. > >Then report those problems and drive them to get fixed please! We should >be moving in the direction of more modularization and a slimmer core. This is not a technical problem, but a usability problem. As a user, I may not be aware of the interrelationships between plugins. I could upgrade a leaf plugin, which requires a newer version of a base plugin, which breaks compatibility with another leaf plugin. As a developer, I have the ability to track this down and drive to get this fixed. As a user, all I know is that I upgraded a plugin and things blew up. As a developer, I don't care to create another instance of this experience if I am not in control of all the leaf plugins. As for "slimmer core", is there even agreement on what that means? You could define core to mean: - Remoting - Scheduling - Basic execution lifecycle - Security - UI which implies that everything makes makes Jenkins a "CI Server" (test result parsing, SCM support, etc.) should be factored out. If core is what makes Jenkins a CI server, then I would take the position that core should include more models of concept that are part of building software. Lack of a central model for certain things leads to redundant code in plugins or inconsistent behaviors. For example, Jenkins has a deep concept of test results. It's easy to write a plugin to interpret test report formats and to the end user, they are very consistent in their behavior and features: historical trends, drill downs, and so forth. Jenkins does not have a concept of code coverage, and you can see the disparate behaviors of various code coverage report plugins because of this. The same is true of SCM plugins and the types of functionality they support, although this is complicated by the varying version control models that are out there. In summary, I think it's important to have proper conceptual models available for a problem domain, that specific implementations can take advantage of. That the model should be provided by a "core." But I'd love to see a formal definition of what that core is. -- Dean
