Hello Jacques, Taher and Michael, I am realizing that I have overreacted to Jacques question by turning it into a vague (not that constructive) debate about extension mechanism for providing plugins.
I think the question of removing push/pull/removePlugin* commands should be post-poned when (1) a viable alternative is ready to use and adapted to non-technical savy users, or (2) nobody want to devote time to fixing issues related to those commands. Since neither (1) or (2) is currently the case I retract my suggestion and +1 for Jacques solution. Sorry for letting my frustration regarding OFBiz extensibility influenced my initial answer. Kind regards, Taher Alkhateeb <slidingfilame...@gmail.com> writes: > 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 > <mathieu.lir...@nereide.fr> wrote: >> >> Taher Alkhateeb <slidingfilame...@gmail.com> 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 >> > <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 >> >> -- >> 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
