Hello Deepak, Deepak Dixit <[email protected]> writes:
> As we moved to from svn to git, so I think now its time to create new git > repository for each and indiviaual plugins instead of maintaing single > ofbiz-plugins.git > > It will help to manage the plugin life cycle properly, > if anyone want to use single or set of plugins they can easiliy setup with > the proposed way. > > If we create git repo for each plugins definately we have to manage the > dependencies and release properly, I am confident that as a community we > can manage this thing :) > > If this looks good, I'll initiate further process for the same. > > Please share your thoughts on this. I sympathise with the intent of having better modularity. However I think OFBiz plugin API is still in its infancy and should become more mature before considering moving in the direction of splitting every plugin we are maintaining into its own Version Control System (VCS) repository. Let me give you a concrete example demonstrating the kind of problems that splitting plugins into multiple VCS repositories will bring. One major limitation of the current OFBiz plugin API is that you cannot use Gradle plugins that depends on the java plugin (like the scala plugin for example) inside your local ‘build.gradle’ file without breaking the global build. Fixing that bug will likely mean introducing breaking changes to the OFBiz plugin API that would then need to be propagated in every plugin we maintain. With 2 VCS repositories (framework + plugins) things are already not ideal, but with ‘n’ VCS repositories a committer would need to create ‘n’ commits and users would need to run ‘git pull’ in ‘n’ repositories which is not manageable. Basically to mitigate this maintenance nightmare we would then need a custom meta VCS that would be reponsible of managing our set of VCS repositories to pull, commit, push... But do we really want that? Do we have the shoulders to build and maintain our custom package manager? I would say no. As a side note, one major reason for using a VCS is the ability to reproduce the state of a specific version when dealing with bugs (‘git bisect’ is meant to help in that regard). However when splitting a code base into multiple VCS repositories without having a versioned dependency manifest we simply loose such capability. Sorry for ruining the party. :-) -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
