Hi Mathieu, On Wed, Nov 6, 2019 at 10:58 PM Mathieu Lirzin <[email protected]> wrote:
> 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. Agree, we need to define the way how we will manage the plugins lifecycle, Here we can create release branches each time when we create release for ofbiz-framework. > With 2 VCS repositories > (framework + plugins) things are already not ideal, but with ‘n’ VCS > repositories a committer would need to create ‘n’ commits I think here you don't need to clone unused repository, > and users > would need to run ‘git pull’ in ‘n’ repositories which is not > manageable. > This should be done with simple command in development mode. With user perspective its easy to manage, Like If I want to use only ecommerce, I can clone and use it, no need to keep unnecessary plugins all the time or worry about them > 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. > Agree, it will increase some additional work, but will have lots of flexibility with user perspective. I think here some confusion, I am not proposing to maintain custom package manger. > 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. > Agree, but I think while svntogit migration we can have all the previous commit history, > > Sorry for ruining the party. :-) > You are doing great Job Mathieu :) -- Deepak Dixit > -- > Mathieu Lirzin > GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37 >
