Git repo for each ofbiz plugin

[Deepak Dixit-5]

Hi All,

As we moved to from svn to git, so I think now its time to create new git
repository for each and indiviaual plugins instead of maintaing single
ofbiz-plugins.git

It will help to manage the plugin life cycle properly,
if anyone want to use single or set of plugins they can easiliy setup with
the proposed way.

If we create git repo for each plugins definately we have to manage the
dependencies and release properly, I am confident that as a community we
can manage this thing :)

If this looks good, I'll initiate further process for the same.

Please share your thoughts on this.

Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org

[Swapnil M Mane]

Hi Deepak,
Thanks for bringing this topic.
The idea looks reasonability good to me.
Various Apache projects [1] are following this approach of maintaining the
plugins in separate repository.
Cordova [2] and Maven [3] are good examples of this.

[1] https://github.com/apache?utf8=%E2%9C%93&q=plugins
[2] https://github.com/apache?utf8=%E2%9C%93&q=cordova+plugins
[3] https://github.com/apache?utf8=%E2%9C%93&q=maven+plugins

On Wed, Nov 6, 2019 at 2:31 PM Deepak Dixit <[hidden email]> wrote:

> Hi All,
>
> As we moved to from svn to git, so I think now its time to create new git
> repository for each and indiviaual plugins instead of maintaing single
> ofbiz-plugins.git
>
> It will help to manage the plugin life cycle properly,
> if anyone want to use single or set of plugins they can easiliy setup with
> the proposed way.
>

+1


> If we create git repo for each plugins definately we have to manage the
> dependencies and release properly, I am confident that as a community we
> can manage this thing :)
>

Indeed, it will be some work but like you I am also confident our vibrant
community will manage :)


>
> If this looks good, I'll initiate further process for the same.
>
> Please share your thoughts on this.
>
> Thanks & Regards
> --
> Deepak Dixit
> ofbiz.apache.org

[Jacques Le Roux]

Le 06/11/2019 à 10:01, Deepak Dixit a écrit :
> If we create git repo for each plugins definately we have to manage the
> dependencies and release properly, I am confident that as a community we
> can manage this thing:)

Hi Deepak,

I'm not sure what you mean by that. For instance, some features in applications are dependent on ecommerce (maybe some other plugins). And a lot of
data used by applications are in ecommerce, and maybe even other plugins.

BTW while working on the RAT build. I used a Github specific feature which allows to export a file from an automated mirrored svn repo there. I have
just used this feature to temporary fix the pull plugins source tasks which were still relying on the now read-only ASF svn repo.

I'll create a Jira for that before committing. I need also to fix the trunk demo...

I guess we should later use https://github.com/ajoberstar/gradle-git

Jacques

[Mathieu Lirzin]

Hello Deepak,

Deepak Dixit <[hidden email]> writes:

> As we moved to from svn to git, so I think now its time to create new git
> repository for each and indiviaual plugins instead of maintaing single
> ofbiz-plugins.git
>
> It will help to manage the plugin life cycle properly,
> if anyone want to use single or set of plugins they can easiliy setup with
> the proposed way.
>
> If we create git repo for each plugins definately we have to manage the
> dependencies and release properly, I am confident that as a community we
> can manage this thing :)
>
> If this looks good, I'll initiate further process for the same.
>
> Please share your thoughts on this.

I sympathise with the intent of having better modularity.  However I
think OFBiz plugin API is still in its infancy and should become more
mature before considering moving in the direction of splitting every
plugin we are maintaining into its own Version Control System (VCS)
repository.  Let me give you a concrete example demonstrating the kind
of problems that splitting plugins into multiple VCS repositories will
bring.

One major limitation of the current OFBiz plugin API is that you cannot
use Gradle plugins that depends on the java plugin (like the scala
plugin for example) inside your local ‘build.gradle’ file without
breaking the global build.  Fixing that bug will likely mean introducing
breaking changes to the OFBiz plugin API that would then need to be
propagated in every plugin we maintain. With 2 VCS repositories
(framework + plugins) things are already not ideal, but with ‘n’ VCS
repositories a committer would need to create ‘n’ commits and users
would need to run ‘git pull’ in ‘n’ repositories which is not
manageable.

Basically to mitigate this maintenance nightmare we would then need a
custom meta VCS that would be reponsible of managing our set of VCS
repositories to pull, commit, push... But do we really want that? Do we
have the shoulders to build and maintain our custom package manager? I
would say no.

As a side note, one major reason for using a VCS is the ability to
reproduce the state of a specific version when dealing with bugs (‘git
bisect’ is meant to help in that regard).  However when splitting a code
base into multiple VCS repositories without having a versioned
dependency manifest we simply loose such capability.

Sorry for ruining the party. :-)

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

[Jacques Le Roux]

Le 06/11/2019 à 17:08, Jacques Le Roux a écrit :

> Le 06/11/2019 à 10:01, Deepak Dixit a écrit :
>> If we create git repo for each plugins definately we have to manage the
>> dependencies and release properly, I am confident that as a community we
>> can manage this thing:)
>
> Hi Deepak,
>
> I'm not sure what you mean by that. For instance, some features in applications are dependent on ecommerce (maybe some other plugins). And a lot of
> data used by applications are in ecommerce, and maybe even other plugins.
>
> BTW while working on the RAT build. I used a Github specific feature which allows to export a file from an automated mirrored svn repo there. I have
> just used this feature to temporary fix the pull plugins source tasks which were still relying on the now read-only ASF svn repo.
>
> I'll create a Jira for that before committing. I need also to fix the trunk demo...
>
> I guess we should later use https://github.com/ajoberstar/gradle-git
>
> Jacques
>
>

Done with OFBIZ-11276

BTW does someone knows if it's possible to have the same relationship between Fisheye and Jira that we had when using Svn?

Thanks

Jacques

[Deepak Dixit-5]

Hi Jacques,



On Wed, Nov 6, 2019 at 9:38 PM Jacques Le Roux <[hidden email]>
wrote:

> Le 06/11/2019 à 10:01, Deepak Dixit a écrit :
> > If we create git repo for each plugins definately we have to manage the
> > dependencies and release properly, I am confident that as a community we
> > can manage this thing:)
>
> Hi Deepak,
>
> I'm not sure what you mean by that.


Here I am proposing to have independent git repository for all the plugin,
currently we are managing one repository (ofbiz-plugins.git)
As per the current way we can't use the independent plugins, we need to
clone whole ofbiz-plugins



> For instance, some features in applications are dependent on ecommerce
> (maybe some other plugins). And a lot of
> data used by applications are in ecommerce, and maybe even other plugins.
>


I think we already had an effort to remove plugin dependencies from
framework/applications.

--
Deepak Dixit

>
> BTW while working on the RAT build. I used a Github specific feature which
> allows to export a file from an automated mirrored svn repo there. I have
> just used this feature to temporary fix the pull plugins source tasks
> which were still relying on the now read-only ASF svn repo.
>
> I'll create a Jira for that before committing. I need also to fix the
> trunk demo...
>
> I guess we should later use https://github.com/ajoberstar/gradle-git
>
> Jacques
>
>

[Deepak Dixit-5]

Hi Mathieu,

On Wed, Nov 6, 2019 at 10:58 PM Mathieu Lirzin <[hidden email]>
wrote:

> Hello Deepak,
>
> Deepak Dixit <[hidden email]> writes:
>
> > As we moved to from svn to git, so I think now its time to create new git
> > repository for each and indiviaual plugins instead of maintaing single
> > ofbiz-plugins.git
> >
> > It will help to manage the plugin life cycle properly,
> > if anyone want to use single or set of plugins they can easiliy setup
> with
> > the proposed way.
> >
> > If we create git repo for each plugins definately we have to manage the
> > dependencies and release properly, I am confident that as a community we
> > can manage this thing :)
> >
> > If this looks good, I'll initiate further process for the same.
> >
> > Please share your thoughts on this.
>
> I sympathise with the intent of having better modularity.  However I
> think OFBiz plugin API is still in its infancy and should become more
> mature before considering moving in the direction of splitting every
> plugin we are maintaining into its own Version Control System (VCS)
> repository.  Let me give you a concrete example demonstrating the kind
> of problems that splitting plugins into multiple VCS repositories will
> bring.
>
> One major limitation of the current OFBiz plugin API is that you cannot
> use Gradle plugins that depends on the java plugin (like the scala
> plugin for example) inside your local ‘build.gradle’ file without
> breaking the global build.  Fixing that bug will likely mean introducing
> breaking changes to the OFBiz plugin API that would then need to be
> propagated in every plugin we maintain.

Agree, we need to define the way how we will manage the plugins lifecycle,
Here we can create release branches each time when we
create release for ofbiz-framework.



> With 2 VCS repositories
> (framework + plugins) things are already not ideal, but with ‘n’ VCS
> repositories a committer would need to create ‘n’ commits


I think here you don't need to clone unused repository,



> and users
> would need to run ‘git pull’ in ‘n’ repositories which is not
> manageable.
>

This should be done with simple command in development mode. With user
perspective its easy to manage,
Like If I want to use only ecommerce, I can clone and use it, no need to
keep unnecessary plugins all the time or worry about them



> Basically to mitigate this maintenance nightmare we would then need a
> custom meta VCS that would be reponsible of managing our set of VCS
> repositories to pull, commit, push... But do we really want that? Do we
> have the shoulders to build and maintain our custom package manager? I
> would say no.
>

Agree, it will increase some additional work, but will have lots of
flexibility with user perspective.
I think here some confusion, I am not proposing to maintain custom package
manger.



> As a side note, one major reason for using a VCS is the ability to
> reproduce the state of a specific version when dealing with bugs (‘git
> bisect’ is meant to help in that regard).  However when splitting a code
> base into multiple VCS repositories without having a versioned
> dependency manifest we simply loose such capability.
>

Agree, but I think while svntogit migration we can have all the previous
commit history,



>
> Sorry for ruining the party. :-)
>

You are doing great Job Mathieu :)


--
Deepak Dixit


> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
>

[Jacques Le Roux]

Le 07/11/2019 à 08:16, Deepak Dixit a écrit :
>> For instance, some features in applications are dependent on ecommerce
>> (maybe some other plugins). And a lot of
>> data used by applications are in ecommerce, and maybe even other plugins.
>>
> I think we already had an effort to remove plugin dependencies from
> framework/applications.
>
> --
> Deepak Dixit
Sincerely I don't see much efforts put in this issue. And IMO it needs to be resolved before thinking about splitting the plugins. I expect some
issues else...

Jacques

[Deepak Dixit-5]

Agree we may some issues, we need to find out and fix if found.

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 :)

Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org


On Thu, Nov 7, 2019 at 1:16 PM Jacques Le Roux <[hidden email]>
wrote:

> Le 07/11/2019 à 08:16, Deepak Dixit a écrit :
> >> For instance, some features in applications are dependent on ecommerce
> >> (maybe some other plugins). And a lot of
> >> data used by applications are in ecommerce, and maybe even other
> plugins.
> >>
> > I think we already had an effort to remove plugin dependencies from
> > framework/applications.
> >
> > --
> > Deepak Dixit
> Sincerely I don't see much efforts put in this issue. And IMO it needs to
> be resolved before thinking about splitting the plugins. I expect some
> issues else...
>
> Jacques
>
>

[Jacques Le Roux]

Le 07/11/2019 à 11:50, Deepak Dixit a écrit :
> Agree we may some issues, we need to find out and fix if found.

We have already found several, most are in:

https://issues.apache.org/jira/browse/OFBIZ-3500

https://issues.apache.org/jira/browse/OFBIZ-9322

>
> 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 :)

How a great deal is that? I mean compared to what we already know about "framework" dependencies on plugins and related issues. And we certainly miss
some others...

Jacques

>
> Thanks & Regards
> --
> Deepak Dixit
> ofbiz.apache.org
>
>
> On Thu, Nov 7, 2019 at 1:16 PM Jacques Le Roux <[hidden email]>
> wrote:
>
>> Le 07/11/2019 à 08:16, Deepak Dixit a écrit :
>>>> For instance, some features in applications are dependent on ecommerce
>>>> (maybe some other plugins). And a lot of
>>>> data used by applications are in ecommerce, and maybe even other
>> plugins.
>>> I think we already had an effort to remove plugin dependencies from
>>> framework/applications.
>>>
>>> --
>>> Deepak Dixit
>> Sincerely I don't see much efforts put in this issue. And IMO it needs to
>> be resolved before thinking about splitting the plugins. I expect some
>> issues else...
>>
>> Jacques
>>
>>

[Gil Portenseigne]

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.

Having separated repositories can offer the ability to clone one plugin
easily, but at the cost of separating history from other plugins and
framework, and increasing maintenance effort. In that case, some
scripting could be done, to automate update on all plugins in your
repos. Also we might consider using git submodules [1] into framework to
ease plugins management, but i'm not familiar enough with that feature.

Without maven i tend to lean toward separate repository, but like i
said, no strong opinion.

By the way, thanks for your work regarding git migration.

Regards,

Gil

[1] https://git-scm.com/docs/git-submodule



Le 16:20 - jeudi 07 nov., Deepak Dixit a écrit :

> Agree we may some issues, we need to find out and fix if found.
>
> 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 :)
>
> Thanks & Regards
> --
> Deepak Dixit
> ofbiz.apache.org
>
>
> On Thu, Nov 7, 2019 at 1:16 PM Jacques Le Roux <[hidden email]>
> wrote:
>
> > Le 07/11/2019 à 08:16, Deepak Dixit a écrit :
> > >> For instance, some features in applications are dependent on ecommerce
> > >> (maybe some other plugins). And a lot of
> > >> data used by applications are in ecommerce, and maybe even other
> > plugins.
> > >>
> > > I think we already had an effort to remove plugin dependencies from
> > > framework/applications.
> > >
> > > --
> > > Deepak Dixit
> > Sincerely I don't see much efforts put in this issue. And IMO it needs to
> > be resolved before thinking about splitting the plugins. I expect some
> > issues else...
> >
> > Jacques
> >
> >

[Deepak Dixit-5]

>>How a great deal is that? I mean compared to what we already know about
"framework" dependencies on plugins and related issues. And we certainly
miss
some others...

I am not comparing, we already discussed this at the time of cutting
plugins from framework.
To achieve this right way is to have different git repository for each
plugins.


Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org


On Thu, Nov 7, 2019 at 6:18 PM Jacques Le Roux <[hidden email]>
wrote:

> Le 07/11/2019 à 11:50, Deepak Dixit a écrit :
> > Agree we may some issues, we need to find out and fix if found.
>
> We have already found several, most are in:
>
> https://issues.apache.org/jira/browse/OFBIZ-3500
>
> https://issues.apache.org/jira/browse/OFBIZ-9322
>
> >
> > 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 :)
>
> How a great deal is that? I mean compared to what we already know about
> "framework" dependencies on plugins and related issues. And we certainly
> miss
> some others...
>
> Jacques
>
> >
> > Thanks & Regards
> > --
> > Deepak Dixit
> > ofbiz.apache.org
> >
> >
> > On Thu, Nov 7, 2019 at 1:16 PM Jacques Le Roux <
> [hidden email]>
> > wrote:
> >
> >> Le 07/11/2019 à 08:16, Deepak Dixit a écrit :
> >>>> For instance, some features in applications are dependent on ecommerce
> >>>> (maybe some other plugins). And a lot of
> >>>> data used by applications are in ecommerce, and maybe even other
> >> plugins.
> >>> I think we already had an effort to remove plugin dependencies from
> >>> framework/applications.
> >>>
> >>> --
> >>> Deepak Dixit
> >> Sincerely I don't see much efforts put in this issue. And IMO it needs
> to
> >> be resolved before thinking about splitting the plugins. I expect some
> >> issues else...
> >>
> >> Jacques
> >>
> >>
>

[Jacques Le Roux]

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

Jacques

[Jacques Le Roux]

Hi Gil, Deepak, Mathieu, All,

I propose that waiting for plugins Maven repos we simply continue to use Svn through Github as I explained elsewhere

Jacques

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.
>
> Having separated repositories can offer the ability to clone one plugin
> easily, but at the cost of separating history from other plugins and
> framework, and increasing maintenance effort. In that case, some
> scripting could be done, to automate update on all plugins in your
> repos. Also we might consider using git submodules [1] into framework to
> ease plugins management, but i'm not familiar enough with that feature.
>
> Without maven i tend to lean toward separate repository, but like i
> said, no strong opinion.
>
> By the way, thanks for your work regarding git migration.
>
> Regards,
>
> Gil
>
> [1]https://git-scm.com/docs/git-submodule
>
>
>
> Le 16:20 - jeudi 07 nov., Deepak Dixit a écrit :
>> Agree we may some issues, we need to find out and fix if found.
>>
>> 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 :)
>>
>> Thanks & Regards
>> --
>> Deepak Dixit
>> ofbiz.apache.org
>>
>>
>> On Thu, Nov 7, 2019 at 1:16 PM Jacques Le Roux<[hidden email]>
>> wrote:
>>
>>> Le 07/11/2019 à 08:16, Deepak Dixit a écrit :
>>>>> For instance, some features in applications are dependent on ecommerce
>>>>> (maybe some other plugins). And a lot of
>>>>> data used by applications are in ecommerce, and maybe even other
>>> plugins.
>>>> I think we already had an effort to remove plugin dependencies from
>>>> framework/applications.
>>>>
>>>> --
>>>> Deepak Dixit
>>> Sincerely I don't see much efforts put in this issue. And IMO it needs to
>>> be resolved before thinking about splitting the plugins. I expect some
>>> issues else...
>>>
>>> Jacques
>>>
>>>

[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

[taher]

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
<[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

[Michael Brohl-3]

Mathieu,

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

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.

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

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.
>>>

[Jacques Le Roux]

Hi Taher, All,

I then propose that waiting for another Git solution based, we simply continue to use Svn through Github :)

Jacques

Le 11/11/2019 à 22:47, Taher Alkhateeb a écrit :

> 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
> <[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]

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

[taher]

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
<[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