I'm not sure I see this issue with the same perspective. Having the build system automatically download (and run some code) for a certain component is a convenience especially for the community components. Things are even easier when using git as there are many plugins to support that. I'm also not sure what is "poor" about that
On Mon, Nov 11, 2019 at 10:37 PM Mathieu Lirzin <mathieu.lir...@nereide.fr> wrote: > > Hello, > > Jacques Le Roux <jacques.le.r...@les7arts.com> writes: > > > I propose that waiting for plugins Maven repos we simply continue to > > use Svn through Github as I explained elsewhere > > No need to wait for Maven plugins before acting responsibly. :-) > > A preferable solution would be to simply remove the > ‘push/pull/removePlugin*’ stuff from our build system which is the > reason why we are discussing keeping this “Github SVN” hack initially. > > IMO people can manage their plugins more conveniently by directly > running the “installation” command of their choice ‘git clone’, ‘svn > checkout’, ‘ln -s’, ... in their plugins directory without needing OFBiz > build system to do it poorly for them. > > > Le 07/11/2019 à 14:00, Gil Portenseigne a écrit : > >> Hello Deepak, all, > >> > >> I do not have a strong opinion about separating plugins into independent > >> git repositories but here are my thought : > >> > >> Plugins integration in OFBiz is intended to be used with a maven > >> repository that hosts the plugin releases for the users. See as a > >> reference the ‘OFBiz Plugins tasks’ or README.adoc about ‘OFBiz plugin > >> system’. > >> > >> We did not implemented an official maven repository for plugin releases, > >> so there is no simple way to install a plugin without using VCS. There > >> might be tasks to be done to have an nice answer to how an user can > >> install a sole plugin from a downloaded release archive. > >> > > -- > Mathieu Lirzin > GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
