Re: Removing “base/config/component-load.xml”

[Mathieu Lirzin]

Hello Jacques,

Jacques Le Roux  writes:

> You were the most visible proponents of this. After 5 days w/o
> exchanges should we consider the idea is abandoned or should we start
> a vote?
>
> Without answers I'll consider the idea abandoned, which is a pity IMO.

The idea is not abandonned yet, it is just that I need to take some time
off to accept that my strategy consisting in trying to bring important
changes within OFBiz might actually be quixotic.

After re-reading [1] I am not sure to understand how a vote can help
resolving this issue because any -1 for code modification is considered
a veto (if it is “accompanied by a technical justification”).  So unless
the question that we vote on corresponds to Michael minimal
requirements, it will not enable us to move forward.

Am I overlooking something?

What question have you in mind for the vote?

Thanks for trying to make things move forward.

[1] https://www.apache.org/foundation/voting.html#Veto

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

Re: OFBiz Jersey Swagger plug in

[Girish Vasmatkar]

I have attached necessary details in JIRA.  Please review and let me know
if I need to provide more details.

Best Regards,
Girish

On Mon, Jan 27, 2020 at 10:20 AM Akash Jain 
wrote:

> Hi Girish,
>
> It's a nice feature. Please let me know if you need any help.
>
> Thanks and Regards
> --
> Akash Jain
>
> On Sun, Jan 26, 2020 at 3:27 PM Girish Vasmatkar <
> girish.vasmat...@hotwaxsystems.com> wrote:
>
> > Hi All
> >
> > Just wanted to gauge the community's interest in having a JAX-RS
> component
> > with swagger capabilities. I am fully aware of the fact that there are
> > efforts undergoing on implementing a REST servlet.
> >
> > This can come handy for anyone comfortable with implementing JAX-RS or
> > having experience with JAX-RS. You can fully take advantage of Jersey in
> > implementing services that are truly RESTful in nature leveraging
> HATEOAS.
> >
> > I have been using this plug in for one of our work and would like to
> > contribute the same to the community.
> >
> > Please let me know your thoughts and I can then open a JIRA maybe and
> > proceed further.
> >
> > Best,
> > Girish
> >
>

Re: Removing “base/config/component-load.xml”

[Jacques Le Roux]

Thanks James,

Maybe better to continue there indeed, less confusion, just focused on what's 
important.

Jacques

Le 29/01/2020 à 16:52, James Yong a écrit :

Added my comments on the technical aspects of the proposal at
https://issues.apache.org/jira/browse/OFBIZ-11296

On 2020/01/29 08:26:00, Jacques Le Roux  wrote:

Hi Mathieu, Samuel,

You were the most visible proponents of this. After 5 days w/o exchanges should 
we consider the idea is abandoned or should we start a vote?

Without answers I'll consider the idea abandoned, which is a pity IMO.

Thanks

Jacques

Le 24/01/2020 à 14:12, Michael Brohl a écrit :

Hi Jacques,

yes, my objection is targeted to the removal of the component-load.xml 
mechanism for applications and plugins.

I don't think it will be a problem to remove it from framework/base/config/ and 
hard code the four existing components framework, themes,
applications and plugins.

Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 24.01.20 um 08:03 schrieb Jacques Le Roux:

Le 24/01/2020 à 07:02, Jacques Le Roux a écrit :

Hi All,

Since it's impossible to have both features (ie “base/config/component-load.xml” and 
 present) and we don't reach a consensus I'll
start a vote about it.

Thanks

Jacques

Before I start a vote, here is a last try to get a consensus. Michael in his 
last email, answering to Pierre, made clear that he would not oppose
to <>. His concern is more for 
application and plugins component-load.xml.

Could we not reach a consensus with this option? Mathieu, Samuel?

Then we could discuss more about details for application and plugins 
component-load.xml...

Jacques

Re: Removing “base/config/component-load.xml”

[James Yong]

Added my comments on the technical aspects of the proposal at 
https://issues.apache.org/jira/browse/OFBIZ-11296

On 2020/01/29 08:26:00, Jacques Le Roux  wrote: 
> Hi Mathieu, Samuel,
> 
> You were the most visible proponents of this. After 5 days w/o exchanges 
> should we consider the idea is abandoned or should we start a vote?
> 
> Without answers I'll consider the idea abandoned, which is a pity IMO.
> 
> Thanks
> 
> Jacques
> 
> Le 24/01/2020 à 14:12, Michael Brohl a écrit :
> > Hi Jacques,
> >
> > yes, my objection is targeted to the removal of the component-load.xml 
> > mechanism for applications and plugins.
> >
> > I don't think it will be a problem to remove it from framework/base/config/ 
> > and hard code the four existing components framework, themes, 
> > applications and plugins.
> >
> > Thanks,
> >
> > Michael Brohl
> >
> > ecomify GmbH - www.ecomify.de
> >
> >
> > Am 24.01.20 um 08:03 schrieb Jacques Le Roux:
> >> Le 24/01/2020 à 07:02, Jacques Le Roux a écrit :
> >>> Hi All,
> >>>
> >>> Since it's impossible to have both features (ie 
> >>> “base/config/component-load.xml” and  present) and we don't 
> >>> reach a consensus I'll 
> >>> start a vote about it.
> >>>
> >>> Thanks
> >>>
> >>> Jacques
> >>
> >> Before I start a vote, here is a last try to get a consensus. Michael in 
> >> his last email, answering to Pierre, made clear that he would not oppose 
> >> to <>. His concern is more for 
> >> application and plugins component-load.xml.
> >>
> >> Could we not reach a consensus with this option? Mathieu, Samuel?
> >>
> >> Then we could discuss more about details for application and plugins 
> >> component-load.xml...
> >>
> >> Jacques
> >>
> >
> 

Re: [ofbiz-framework] branch trunk updated (6f39741 -> 6d194cf)

[Jacques Le Roux]

Thank you very much Pierre for this clarification,

It remembers me when the checkbox for the same in Jira was removed.

Jacques

Le 29/01/2020 à 10:59, Pierre Smits a écrit :

According to the ASF there is no legal issue with the status of the
contribution provided by a contributor without an ICLA.

In the license [1] it is stated that:

Unless You explicitly state otherwise, any Contribution intentionally
submitted for inclusion in the Work by You to the Licensor shall be under
the terms and conditions of this License, without any additional terms or
conditions.


Furthermore, in LEGAL-156 it is stated that PRs of non-privileged
contributors can be accepted, see [2]

Even one of the founders of the ASF has stated (see [3]):

that opinion comes from me speaking as a board member and
author of the Apache License, and has previously been cleared with Apache's
legal team for a long ago discussion with Incubator. We don't need a CLA on
file to accept contributions from non-committers. We just need a clear
intent by the author to contribute under our normal terms.


Though we desire our non-privileged contributors to submit an ICLA, it is
not a requirement (see [4]). When we started the discussion on that subject
the intent was:

1.  enable non-privileged contributors to express that they were willing
to do more, and
2. for the project to be able to recognise those contributors more easy,
and facilitate the onboarding process



[1] https://www.apache.org/licenses/LICENSE-2.0
[2]
https://issues.apache.org/jira/browse/LEGAL-156?focusedCommentId=13554864&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13554864
[3]
https://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/201112.mbox/%3ca603ffce-623b-43e9-87f8-39baa51c7...@gbiv.com%3E
[4]
https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Contributors


Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer


On Wed, Jan 29, 2020 at 9:44 AM Nicolas Malin 
wrote:


Hello

On 29/01/2020 07:58, Michael Brohl wrote:

Not sure if we necessarily have to deprecate the patch based
contributions. It could be a simpler way for contributors to provide a
change, especially if they are not developers and/or familiar with the
pull request mechanisms. Maybe the patch based way becomes obsolete
naturally but I would not force it.

We should work out a simple, documented way how to do it with PR's and
encourage contributors to use it, including using proper commit
statements following our template to prevent doing correctional work
on the committers site.

I have no strong opinion for path or PR, all seem good for me. But for
PR if the author is the contributer and not the commiter, I have a doubt
about the legal status and the ICLA [1].

   >  The purpose of this agreement is to clearly define the terms
under which intellectual property
   >  has been contributed to the ASF and thereby allow us to defend the
project should there be a
   >  legal dispute regarding the software at some future time. A signed
ICLA is required to be on file
   >  before an individual is given commit rights to any ASF project.

Personally I have a preference to cherry-pick all commits and squash
them and unique commit  with proper commit message

Nicolas

[1] http://www.apache.org/licenses/contributor-agreements.html#clas

Re: [ofbiz-framework] branch trunk updated (6f39741 -> 6d194cf)

[Pierre Smits]

According to the ASF there is no legal issue with the status of the
contribution provided by a contributor without an ICLA.

In the license [1] it is stated that:

Unless You explicitly state otherwise, any Contribution intentionally
submitted for inclusion in the Work by You to the Licensor shall be under
the terms and conditions of this License, without any additional terms or
conditions.


Furthermore, in LEGAL-156 it is stated that PRs of non-privileged
contributors can be accepted, see [2]

Even one of the founders of the ASF has stated (see [3]):

that opinion comes from me speaking as a board member and
author of the Apache License, and has previously been cleared with Apache's
legal team for a long ago discussion with Incubator. We don't need a CLA on
file to accept contributions from non-committers. We just need a clear
intent by the author to contribute under our normal terms.


Though we desire our non-privileged contributors to submit an ICLA, it is
not a requirement (see [4]). When we started the discussion on that subject
the intent was:

   1.  enable non-privileged contributors to express that they were willing
   to do more, and
   2. for the project to be able to recognise those contributors more easy,
   and facilitate the onboarding process



[1] https://www.apache.org/licenses/LICENSE-2.0
[2]
https://issues.apache.org/jira/browse/LEGAL-156?focusedCommentId=13554864&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13554864
[3]
https://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/201112.mbox/%3ca603ffce-623b-43e9-87f8-39baa51c7...@gbiv.com%3E
[4]
https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Contributors


Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer


On Wed, Jan 29, 2020 at 9:44 AM Nicolas Malin 
wrote:

> Hello
>
> On 29/01/2020 07:58, Michael Brohl wrote:
> >
> > Not sure if we necessarily have to deprecate the patch based
> > contributions. It could be a simpler way for contributors to provide a
> > change, especially if they are not developers and/or familiar with the
> > pull request mechanisms. Maybe the patch based way becomes obsolete
> > naturally but I would not force it.
> >
> > We should work out a simple, documented way how to do it with PR's and
> > encourage contributors to use it, including using proper commit
> > statements following our template to prevent doing correctional work
> > on the committers site.
>
> I have no strong opinion for path or PR, all seem good for me. But for
> PR if the author is the contributer and not the commiter, I have a doubt
> about the legal status and the ICLA [1].
>
>   >  The purpose of this agreement is to clearly define the terms
> under which intellectual property
>   >  has been contributed to the ASF and thereby allow us to defend the
> project should there be a
>   >  legal dispute regarding the software at some future time. A signed
> ICLA is required to be on file
>   >  before an individual is given commit rights to any ASF project.
>
> Personally I have a preference to cherry-pick all commits and squash
> them and unique commit  with proper commit message
>
> Nicolas
>
> [1] http://www.apache.org/licenses/contributor-agreements.html#clas
>
>

Re: [ofbiz-framework] branch trunk updated (6f39741 -> 6d194cf)

[Nicolas Malin]

Hello

On 29/01/2020 07:58, Michael Brohl wrote:
>
> Not sure if we necessarily have to deprecate the patch based
> contributions. It could be a simpler way for contributors to provide a
> change, especially if they are not developers and/or familiar with the
> pull request mechanisms. Maybe the patch based way becomes obsolete
> naturally but I would not force it.
>
> We should work out a simple, documented way how to do it with PR's and
> encourage contributors to use it, including using proper commit
> statements following our template to prevent doing correctional work
> on the committers site.

I have no strong opinion for path or PR, all seem good for me. But for
PR if the author is the contributer and not the commiter, I have a doubt
about the legal status and the ICLA [1].

  >  The purpose of this agreement is to clearly define the terms
under which intellectual property
  >  has been contributed to the ASF and thereby allow us to defend the
project should there be a
  >  legal dispute regarding the software at some future time. A signed
ICLA is required to be on file
  >  before an individual is given commit rights to any ASF project.

Personally I have a preference to cherry-pick all commits and squash
them and unique commit  with proper commit message

Nicolas

[1] http://www.apache.org/licenses/contributor-agreements.html#clas



pEpkey.asc
Description: application/pgp-keys

Re: [ofbiz-framework] branch trunk updated (6f39741 -> 6d194cf)

[Jacques Le Roux]

Hi Pierre,

I don't want to put more burden on the committer size either. From my experience, if we want to continue to use our commit template using PR merge is 
not an option.


Jacques

Le 29/01/2020 à 09:05, Pierre Smits a écrit :

I agree with Micheal here that the project should not impose restrictions
on how non-privileged provide their enhancements.

Indeed, those helping non-privileged contributors should be helped to do
their part as easy as possible.

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer


On Wed, Jan 29, 2020 at 8:02 AM Michael Brohl 
wrote:


Hi Jacques,

inline...

Am 28.01.20 um 19:05 schrieb jler...@apache.org:

This is in relation with "Github PRs and Jira" thread
(https://markmail.org/message/s422zuivbmzglph4)

Below is my 1st experience of GitHub PR merge in the context of ASF
dual hosting with GitBox. So I somehow made a jump in the void...

After reviewing the change I picked "squash and merge PR" among the 3
GitHub PR merge options. Because I did not want to break the linear
Git flow, it seemed the best option. But despite "squashing" we got  3
commits; 2 from Daniel Watford and one from I. I don't know if it's
possible to do otherwise with the 2 other options. Maybe it's good to
know that Daniel contributed...

Also I expected that my comment in GitHub would be used as the final
commit comment. So I then tried to amend the commit by modifying ONLY
the comment, and then push comment after a pull. But I got a
fast-forward issue and after trying several pull and push tricks I
understood I'll never pass over this issue:

"[remote rejected]   trunk -> trunk (pre-receive hook declined)"

Because it's related to having "receive.denynonfastforwards" set to
true on GitBox server[1] and I don't want to annoy Infra to temporary
set it true for a such change.

But I really wanted to change the commit comment to follow our
template. So I decided to pull rebase, slightly change the
ComponentContainerTest class, commit and push. Hence I created a new
commit, somehow a duplicate of the PR merge, at least with a correctly
formatted comment.

This was an awkward experience, I don't know if i could have done it
better, ideas, advices?
Maybe advising contributors to use our template in commit comments
used by GitHub PRs?
Also we can ask our contributors to use in the PRs title the format of
our commit template. For instance in[2] instead of

I would go so far to make the proper use of the templates a restriction
to get the PR into the codebase. We should make the committer's work as
easy as possible.

...


Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de

Re: [ofbiz-framework] branch trunk updated (6f39741 -> 6d194cf)

[Jacques Le Roux]

Le 29/01/2020 à 08:02, Michael Brohl a écrit :

Hi Jacques,

inline...

Am 28.01.20 um 19:05 schrieb jler...@apache.org:

This was an awkward experience, I don't know if i could have done it better, 
ideas, advices?
Maybe advising contributors to use our template in commit comments used by 
GitHub PRs?
Also we can ask our contributors to use in the PRs title the format of our 
commit template. For instance in[2] instead of


I would go so far to make the proper use of the templates a restriction to get the PR into the codebase. We should make the committer's work as easy 
as possible.


Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Hi Michael,

For me the current way is the easiest. The burden should not be on the 
committer. I'll never try again to merge a PR for sure!

Jacques

Re: [ofbiz-framework] branch trunk updated (6f39741 -> 6d194cf)

[Jacques Le Roux]

Hi Mathieu,

Inline...

Le 28/01/2020 à 20:31, Mathieu Lirzin a écrit :

Hello Jacques,

"jler...@apache.org"  writes:


But I got a
fast-forward issue and after trying several pull and push tricks I
understood I'll never pass over this issue:

"[remote rejected]   trunk -> trunk (pre-receive hook declined)"

Because it's related to having "receive.denynonfastforwards" set to
true on GitBox server[1] and I don't want to annoy Infra to temporary
set it true for a such change.

One must never, never, never rewrite history of the trunk branch. :-)


Yes I know and I did not :)





This was an awkward experience, I don't know if i could have done it better, 
ideas, advices?
Maybe advising contributors to use our template in commit comments used by 
GitHub PRs?

The best option I think is to clone the branch locally, amend the
necessary commits, push on the PR branch ask for validation from the
original author, and then from your terminal rebase on trunk and
fast-forward merge the commits (meaning without a merge commit).


Obviously too much work at the expense of committers, at least for me.



Basically the better option to use Github Web interface only for
discussion/review.


+1





Also we can ask our contributors to use in the PRs title the format of
our commit template. For instance in[2] instead of

OFBIZ-11331: Allow ComponentContainerTest to run on windows
rather
Fixed: Allow ComponentContainerTest to run on windows (OFBIZ-11331)

Then the commit/s would contain the explanations.

I just fear we will have sometimes to explain, and ask contributors to edit 
their comments or titles...

I'll sleep on it and wait for comments before doing any additions or
changes in our documentation about that, in relation with the "Github
PRs and Jira" thread

I think it would be better to not use the PR feature as long as there is
not a community consensus that this is an acceptable contribution
channel.  As stated previously I am not against adopting Github PR *if
and only if* we have a plan to move out of Jira.


The problem is that if you use one of the PR merge option you don't get your commit comment following the template. Actually the commit comment is not 
yours, it's the contributor's.




Given the pile of existing policies, I don't think this is a good idea
to simply provide more contribution options/policies, I think it is
important to review existing ones and consider replacing some of them.


Yes we have OFBIZ-11301 and OFBIZ-11271 pending for that



For example we could deprecate patch based contribution, or at least
adopt the ‘git format-patch’ conventions.


As an Eclipse user I don't really see how it would help me, at least; rather the contrary. I could of course change that and instead of C/P  a patch 
safe as a file but it's again more work.


Thanks

Jacques

Re: Removing “base/config/component-load.xml”

[Jacques Le Roux]

Hi Mathieu, Samuel,

You were the most visible proponents of this. After 5 days w/o exchanges should 
we consider the idea is abandoned or should we start a vote?

Without answers I'll consider the idea abandoned, which is a pity IMO.

Thanks

Jacques

Le 24/01/2020 à 14:12, Michael Brohl a écrit :

Hi Jacques,

yes, my objection is targeted to the removal of the component-load.xml 
mechanism for applications and plugins.

I don't think it will be a problem to remove it from framework/base/config/ and hard code the four existing components framework, themes, 
applications and plugins.


Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 24.01.20 um 08:03 schrieb Jacques Le Roux:

Le 24/01/2020 à 07:02, Jacques Le Roux a écrit :

Hi All,

Since it's impossible to have both features (ie “base/config/component-load.xml” and  present) and we don't reach a consensus I'll 
start a vote about it.


Thanks

Jacques


Before I start a vote, here is a last try to get a consensus. Michael in his last email, answering to Pierre, made clear that he would not oppose 
to <>. His concern is more for application and plugins component-load.xml.


Could we not reach a consensus with this option? Mathieu, Samuel?

Then we could discuss more about details for application and plugins 
component-load.xml...

Jacques

Re: [ofbiz-framework] branch trunk updated (6f39741 -> 6d194cf)

[Pierre Smits]

I agree with Micheal here that the project should not impose restrictions
on how non-privileged provide their enhancements.

Indeed, those helping non-privileged contributors should be helped to do
their part as easy as possible.

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer


On Wed, Jan 29, 2020 at 8:02 AM Michael Brohl 
wrote:

> Hi Jacques,
>
> inline...
>
> Am 28.01.20 um 19:05 schrieb jler...@apache.org:
> > This is in relation with "Github PRs and Jira" thread
> > (https://markmail.org/message/s422zuivbmzglph4)
> >
> > Below is my 1st experience of GitHub PR merge in the context of ASF
> > dual hosting with GitBox. So I somehow made a jump in the void...
> >
> > After reviewing the change I picked "squash and merge PR" among the 3
> > GitHub PR merge options. Because I did not want to break the linear
> > Git flow, it seemed the best option. But despite "squashing" we got  3
> > commits; 2 from Daniel Watford and one from I. I don't know if it's
> > possible to do otherwise with the 2 other options. Maybe it's good to
> > know that Daniel contributed...
> >
> > Also I expected that my comment in GitHub would be used as the final
> > commit comment. So I then tried to amend the commit by modifying ONLY
> > the comment, and then push comment after a pull. But I got a
> > fast-forward issue and after trying several pull and push tricks I
> > understood I'll never pass over this issue:
> >
> >"[remote rejected]   trunk -> trunk (pre-receive hook declined)"
> >
> > Because it's related to having "receive.denynonfastforwards" set to
> > true on GitBox server[1] and I don't want to annoy Infra to temporary
> > set it true for a such change.
> >
> > But I really wanted to change the commit comment to follow our
> > template. So I decided to pull rebase, slightly change the
> > ComponentContainerTest class, commit and push. Hence I created a new
> > commit, somehow a duplicate of the PR merge, at least with a correctly
> > formatted comment.
> >
> > This was an awkward experience, I don't know if i could have done it
> > better, ideas, advices?
> > Maybe advising contributors to use our template in commit comments
> > used by GitHub PRs?
> > Also we can ask our contributors to use in the PRs title the format of
> > our commit template. For instance in[2] instead of
>
> I would go so far to make the proper use of the templates a restriction
> to get the PR into the codebase. We should make the committer's work as
> easy as possible.
>
> ...
>
>
> Thanks,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
>