Hello Mathieu, If you study the plugin system implementation, you will notice that it is based on maven for dependency resolution, which already takes care of many of the details you mentioned, especially with respect to dependency management. The way it is designed avoids reinventing the wheel by using something that already solves the problem. Now granted it is incomplete, that doesn't mean it's a bad idea, It's just incomplete. And part of the complexity by the way, is deficiencies in the architecture of OFBiz itself. The concept of a "component" needs to improve and better utilization of the subproject architecture would greatly improve this.
I don't have a problem with removing whatever you feel like removing. I only propose a more thorough assessment before shrugging it off as "too complex" or "poor". Dependency management by design is complex. And using Jar libraries or any other solution will not make it easier, quite the opposite. It does not matter whether it lives in the build system or somewhere else (although I personally prefer the build system). The important thing is how to architect it to solve your problems. Anyway, I have no further input on this, please feel free to discuss this with the rest of the folks and reach whatever decision you feel like heading to. On Tue, Nov 12, 2019 at 1:26 PM Mathieu Lirzin <[email protected]> wrote: > > 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
