Git repo for each ofbiz plugin

[Mathieu Lirzin]

Hello Michael,

Michael Brohl <[hidden email]> writes:

> why using strong words and disrespect other community people's work
> like this? This does not help in any way making things better.

If I showed disrespect to people in that community I am sorry about
that, that was not intended. I was just trying to tell that we might be
better off providing those package management commands that are lacking
important features, are troublesome to maintain.

> Having said this, to the topic: users often have difficulties even to
> get OFBiz running while it seams easiest for us developers. Just read
> the users list for reference.
>
> Having everything available and be done automatically helps people to
> get things running easier. By removing these features we would make
> things more complicated for them.

This is true when things works reliably. But when things fails (which is
expected with tinkered tools) it is worse for users who are then
helpless because of the added complexity, when instead we could have
just expect them to know how to download a repository and place it in
particular directory which is not a hard requirement IMO.

> More advanced people who are familiar with the mentioned techniques
> can use them anyway.

In the case of plugin management, I claim that we can make things easier
for everyone (developpers, users) by adopting well known Jar
distribution mechanism to manage both the framework and the plugins
installation (but that is ongoing work [1]).

[1] https://issues.apache.org/jira/browse/OFBIZ-11161

>
> Regards,
>
> Michael
>
> Am 11.11.19 um 20:37 schrieb Mathieu Lirzin:
>> Hello,
>>
>> Jacques Le Roux <[hidden email]> 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]

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 <[hidden email]> 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
> <[hidden email]> wrote:
>>
>> Taher Alkhateeb <[hidden email]> 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
>> > <[hidden email]> wrote:
>> >>
>> >> Hello,
>> >>
>> >> Jacques Le Roux <[hidden email]> 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

[Deepak Dixit-4]

On Sun, Nov 10, 2019 at 4:12 PM Jacques Le Roux <
[hidden email]> wrote:

> Le 07/11/2019 à 11:50, Deepak Dixit a écrit :
> > As per current git repo, How user can only checkout and use ecommerce or
> bi
> > or any single component?
> >
> > It was possible in with svn, but in git we need separate repository
>
> Hi Deepak,
>
> A Github feature[1] allows that. You can do it by checking out from
> Github. Simply try
>
> svn co https://github.com/apache/ofbiz-plugins/trunk/ecommerce
>
> If you then Svn commit, the Github repo will be the ending container and
> will sync to ASF Gitbox
>
> I have used the same in build.Gradle: OFBIZ-11276
>
> I don't say it's a definitive solution. At least it allows to think more
> about the best solution...
>
> [1]
> https://help.github.com/en/github/importing-your-projects-to-github/working-with-subversion-on-github

Thanks Jacques for sharing, I am not aware of this feature, I'll explore
this.

Kind Regards,
Deepak Dixit




>
>
> Jacques
>
>

[Jacques Le Roux]

Le 06/11/2019 à 19:21, Jacques Le Roux a écrit :
> BTW does someone knows if it's possible to have the same relationship between Fisheye and Jira that we had when using Svn?
I created https://issues.apache.org/jira/browse/INFRA-19471 for that

Jacques

[Pierre Smits-3]

I fully support any endeavour to get to individual repos in Github for each
component in the application and plugin stack. It will increase more choice
for potential adopters and hopefully lead to more contributors.

Our CI tooling is capable enough to inject the code from these repos into
the right places for building and testing purposes.

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer


On Fri, Nov 22, 2019 at 2:14 PM Jacques Le Roux <
[hidden email]> wrote:

> Le 06/11/2019 à 19:21, Jacques Le Roux a écrit :
> > BTW does someone knows if it's possible to have the same relationship
> between Fisheye and Jira that we had when using Svn?
> I created https://issues.apache.org/jira/browse/INFRA-19471 for that
>
> Jacques
>
>