Taher Alkhateeb <[email protected]> writes: > 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
I agree that having the “build system” downloading things automatically is convenient and desirable. But IMO what we should mean by a build system is Gradle (or Maven, SBT, Leinigen, ...) not “OFBiz pretending to be a build system ontop of Gradle”. Let me clarify what I mean by “OFBiz build system doing things poorly”. There are a lot a important features that people would expect from a tool downloading/installing plugins (a.k.a package manager) that are missing like for example: - having a manifest listing the installed plugins with their version - removing unneeded dependencies when uninstalling a plugin, - having a way to upgrade an install plugin (automatically upgrading its dependencies if needed). - Ensuring that the plugin is compatible with the framework version - Resolve plugin version mismatchs consistently (A depends on B-0.1 and C depends on B-0.2 => use B-0.2) - Having a shared cache for already downloaded dependencies. One could then say “we just need to implement those features” to do things properly. But having some experience with in the domain of package managers, I know that things are too *complex* for us OFBiz developpers to mess with that. This is why I am proposing to remove the push/pull/remove commands and advocate towards working on the adoption of existing distribution interfaces like Jar libraries (See work done in OFBIZ-11161 [1]). [1] https://issues.apache.org/jira/browse/OFBIZ-11161 > On Mon, Nov 11, 2019 at 10:37 PM Mathieu Lirzin > <[email protected]> wrote: >> >> Hello, >> >> Jacques Le Roux <[email protected]> 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 -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
