if it is bad for the project to have 2 years between two
releases, 16 => 18 => 20
WDYT ?
Gil
On Fri, Jan 24, 2020 at 05:31:14PM +0100, Jacques Le Roux wrote:
Le 24/01/2020 à 15:09, Nicolas Malin a écrit :
On 24/01/2020 14:57, Jacques Le Roux wrote:
I must say I'm mostly against b
Forgot: sorry for the resentment, it's not specially against you, most of us
are not backporting since we turned to Git.
I don't think it's a coincidence, but maybe there are other reasons?
Le 24/01/2020 à 17:35, Jacques Le Roux a écrit :
Hi Taher,
Are you backporting much? Since we
ipping a branch.
On Fri, Jan 24, 2020, 4:19 PM Gil Portenseigne
wrote:
+1
On Fri, Jan 24, 2020 at 11:27:15AM +0100, Jacques Le Roux wrote:
Hi,
R16 is now an old distribution and has almost reached its end of
support. We
can soon expect a last release but we need to think about the next to be
re
Le 24/01/2020 à 15:09, Nicolas Malin a écrit :
On 24/01/2020 14:57, Jacques Le Roux wrote:
I must say I'm mostly against because of the surplus of effort
necessary to backport to both R17 and R18
About R20, as Pierre Smits mentioned in Slack should we not create a
R19 before ;)
If we follow
and correction, present on R18 and
not R17 that are stable and fully functionnal
Nicolas
On 9/28/19 1:29 PM, Jacques Le Roux wrote:
Hi,
As reported by Rashi Dhagat in OFBIZ-11215 "Email password is not
working" in R16, and actually nor in R17.
It has been fixed in trunk and R18 with
crit :
+1
On 24/01/2020 08:11, Jacques Le Roux wrote:
Hi,
R16 is now an old distribution and has almost reached its end of
support. We can soon expect a last release but we need to think about
the next.
Some would prefer to release R17 before releasing R18, some would
prefer to bypass R
Hi,
R16 is now an old distribution and has almost reached its end of support. We can soon expect a last release but we need to think about the next to be
released package
Some would prefer to release R17 before releasing R18, some would prefer to
bypass R17 release and directly publish R18
This officially invalidates the vote because the subject was confusing
Jacques
Le 24/01/2020 à 08:11, Jacques Le Roux a écrit :
Hi,
R16 is now an old distribution and has almost reached its end of support. We
can soon expect a last release but we need to think about the next.
Some would
o "release R17..."; thus if the vote
will be successful we will NOT bypassR17
On Fri, Jan 24, 2020 at 8:12 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
Hi,
R16 is now an old distribution and has almost reached its end of support.
We can soon expect a last release
Hi,
R16 is now an old distribution and has almost reached its end of support. We
can soon expect a last release but we need to think about the next.
Some would prefer to release R17 before releasing R18, some would prefer to
bypass R17 release and directly publish R18 instead.
So the
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
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
Le 08/12/2019 à 02:34, Mathieu Lirzin a écrit :
Hello,
We have in OFBiz two redundant ways to define the order
release R17 as current release (once we
officially
released it), start working on R18 to make it ready for release.
Kind Regards,
Deepak Dixit
On Wed, Oct 9, 2019 at 1:01 PM Jacques Le Roux
wrote:
Hi Deepak,
I have no problems with that. For demo R16 would stay our stable or we
could hav
Thanks Pierre,
I second that, I would not write it better!
Jacques
Le 21/01/2020 à 15:56, Pierre Smits a écrit :
Hi all,
The mission of the project is, in line with the ASF, to provide software
for the greater good and offering (potential) adopters a choice. In the
projects case this is done
Le 21/01/2020 à 00:36, Mathieu Lirzin a écrit :
Hello,
Taher Alkhateeb writes:
While working on all the above, I never faced major obstacles. But the
reason that I did not is I always made a complete, well written
argument about what I'm trying to implement. I always ask for a pair
of eyes
Great Message Taher!
Jacques
Le 20/01/2020 à 11:50, Taher Alkhateeb a écrit :
Hello Mathieu and all,
Thank you for this interesting and engaging thread. Before I make my
input, I would like to note that Apache OFBiz and its community from
my experience is welcoming of change and improvements.
Hi,
As I'm sure not everybody noticed the change introduced by OFBIZ-11161
regarding Cache maintenance and labels refreshing here is a notice.
As mentioned Mathieu:
<>
HTH
Jacques
Welcome aboard Olivier
Jacques
Le 16/01/2020 à 16:13, Gavin Mabie a écrit :
Congrats Olivier
On Thu, Jan 16, 2020 at 4:23 PM Taher Alkhateeb wrote:
The OFBiz PMC has invited Olivier Heintz to become a new committer and
we are happy to announce that he has accepted this role.
Some of the
Le 16/01/2020 à 12:37, Pawan Verma a écrit :
I've checked this on local, everything is fine. It has nothing to do with
e52860356fe2b6fe55348021fa7ef488c9f82501.
I was wondering and with multi-changes locally could not really check, thanks
Pawan!
Jacques
,
James
On 2020/01/11 12:56:24, James Yong wrote:
Hi Jacques,
Points taken.
Thanks,
James
On 2020/01/11 10:46:03, Jacques Le Roux wrote:
Also jquery.x is not much maintained, last changes are from June 2015...
Le 11/01/2020 à 11:44, Jacques Le Roux a écrit :
Just noticed it needs Bower
Le 11/01/2020 à 15:16, Bright Efuet a écrit :
Hello everone My name is EFUET BRIGHT. i am new to open source but love the
Groovy Language. so i decided to join the APACHE OFBIZ project to widen my
knowledge as far as open source is concern. I would also love to participate to
Gsoc 2020.
Erratum inline...
Le 26/11/2019 à 21:02, Jacques Le Roux a écrit :
I created OFBIZ-11268 for that
Actually it's OFBIZ-11297
Le 26/11/2019 à 11:54, Jacques Le Roux a écrit :
Yesterday we had a small conversation with Pawan on Slack. He wondered why I did not backport to R16 since we
Le 14/01/2020 à 12:40, Pierre Smits a écrit :
Hi all,
How are we moving forward getting to release something? Some time has
passed since latest one (r16.11.06).
Is there still value to be had for our adopters with a release from the
r17.12 branch? If not, as there is already a superseding
with ESMTPSA id 603FF58133;
Sun, 12 Jan 2020 16:10:29 +0100 (CET)
To: user-unsubscribe-bojanraic+dev=gmail@ofbiz.apache.org,
dev-unsubscribe-bojanraic+dev=gmail....@ofbiz.apache.org
From: Jacques Le Roux
Organization: Les Arts Informatiques
Message-ID: <2d538de0-1dbe-1360-0f
Thanks Mathieu,
It's quite clear to me now
Jacques
Le 11/01/2020 à 21:52, Mathieu Lirzin a écrit :
Hello Jacques,
Jacques Le Roux writes:
Le 05/01/2020 à 18:32, Mathieu Lirzin a écrit :
Michael Brohl writes:
This project is not only about tech, it has a user base with serious
business
Also jquery.x is not much maintained, last changes are from June 2015...
Le 11/01/2020 à 11:44, Jacques Le Roux a écrit :
Just noticed it needs Bower to install and at the moment Bowers says
"...psst! While Bower is maintained, we recommend using Yarn <https://yarnpkg.com>
rate
<https://bower.io/blog/2017/how-to-migrate-away-from-bower/>! "
And npm warns about it
Jacques
Le 11/01/2020 à 10:32, Jacques Le Roux a écrit :
I remember having read about MVVM years ago, quite interesting, thanks James!
Jacques
Le 10/01/2020 à 16:50, James Yong a écrit :
Hi Gi
I remember having read about MVVM years ago, quite interesting, thanks James!
Jacques
Le 10/01/2020 à 16:50, James Yong a écrit :
Hi Gil,
I wonder if this library helps for a start:
https://github.com/joshualjohnson/jquery.x
Regards,
James
On 2019/12/13 15:52:38, Gil Portenseigne wrote:
Hi Pierre,
Right, how can we fix that though?
Jacques
Le 09/01/2020 à 10:01, Pierre Smits a écrit :
Hi all,
Recently I came across this Dutch website (
https://www.capterra.nl/software/164046/apache-ofbiz) that states
functions about our product. I don’t know where this originated but I
08.01.20 um 05:38 schrieb Jacques Le Roux:
Hi All,
Following Mathieu's question about "OFBiz public API" and the points he already
mentioned I decided to create a new thread.
I don't know what will happen with the other tread (mostly about
removing/replacing component-load.xm
Le 05/01/2020 à 18:32, Mathieu Lirzin a écrit :
Hello,
The arguments provided by Michael are very general and go beyond the
specific question of “component-load.xml” so I am opening a general
discussion about how to make OFBiz evolve smoothly by precising the
extent of its public API.
I urge
Le 07/01/2020 à 00:56, Mathieu Lirzin a écrit :
Hello,
Jacques Le Roux writes:
Le 06/01/2020 à 10:29, Samuel Trégouët a écrit :
what is OFBiz public API?
In my opinion we need an answer for this question otherwise we need to
discuss every single changement! which seems to be really
Hi All,
Following Mathieu's question about "OFBiz public API" and the points he already
mentioned I decided to create a new thread.
I don't know what will happen with the other tread (mostly about
removing/replacing component-load.xml). That's not the subject here.
Mathieu wrote:
<>
I
Hi Samuel,
Inline too...
Le 06/01/2020 à 10:29, Samuel Trégouët a écrit :
Hi all,
[snip...]
Michael has started to discuss because he had missed the commit which
removes component-load.xml in applications and framework and he claimed
[2] that we didn't discuss in d...@obfiz.apache.org before:
(re)Forwarded at Michael's request
Message transféré
Sujet : Re: What is OFBiz public API?
Date : Sun, 5 Jan 2020 20:33:03 +0100
De :Jacques Le Roux
Organisation : Les Arts Informatiques
Pour : dev@ofbiz.apache.org
Hi Mathieu,
Inline too...
Le 05/01/2020 à
l.org
Last-Attempt-Date: Sun, 5 Jan 2020 20:34:06 +0100 (CET)
Re: What is OFBiz public API?.eml
Sujet :
Re: What is OFBiz public API?
De :
Jacques Le Roux
Date :
05/01/2020 à 20:33
Pour :
dev@ofbiz.apache.org
Hi Mathieu,
Inline too...
Le 05/01/2020 à 18:32, Mathieu Lirzin a écrit :
Hel
Hi Michael,
First I must say that I understand your POV about production and custom projects. I have been there too and when your business depends on it, things
really matter.
That's why I suggested that we could have both solutions in parallel for a while. With the current one being
Right, it's now failing on Buildbot
https://ci.apache.org/projects/ofbiz/logs/trunk/framework/html/
The last one passed the 1st because, as mentioned Jacopo, it's almost the 2nd
of January
Jacques
Le 03/01/2020 à 09:15, Jacopo Cappellato a écrit :
Hi Mathieu,
it is actually probably
Hi Mathieu,
Thank you for your good wishes :D
It's strange that's it does not reproduce on Buildbot
https://ci.apache.org/builders/ofbizTrunkFramework
Any ideas?
Jacques
Le 02/01/2020 à 19:32, Mathieu Lirzin a écrit :
Hello,
On my system I am noticing that the integration tests are
Hi Justin,
Your message has been moderated.
Please subscribe to the user ML for such questions and then use your email
client.
See why here http://ofbiz.apache.org/mailing-lists.html.
You will get a better support, people can answer you on the ML.
The wider the audience the better the answers
Le 19/12/2019 à 13:47, Jacques Le Roux a écrit :
Now nothing should be needed thanks to .gitattributes being in repo.
Apart of course maybe adding types in .gitattributes from time to time.
Jacques
I did not had to revert finally. It would have happened anyway, I closed
OFBIZ-11279
It was few more files in trunk and a bit less than in trunk in R18. Now nothing
should be needed thanks to .gitattributes being in repo.
Le 19/12/2019 à 13:08, Jacques Le Roux a écrit :
Hi Michael,
Oops you
the problem was?
I would strongly suggest to revert this if it turns out that this was only a
local problem.
Thanks,
Michael
Am 19.12.19 um 12:32 schrieb Jacques Le Roux:
I had to do that because Git was suddenly preventing me to switch from branch to branch and caused a numerous of other never
adceb71a39e35a45077845dce7db2fde1d1dea0c
Author: Jacques Le Roux
AuthorDate: Thu Dec 19 06:46:36 2019 +0100
Normalize all the line endings
---
.../ofbiz/base/OfbizDslDescriptorForEclipse.dsld | 28 +-
runtime/.gitignore | 16 +-
.../webapp/common/js/jquery/plugins/datejs
on user@? This way maybe we can have a more
informed decision on whether to adopt this change.
On Thu, Dec 19, 2019, 10:13 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
Le 18/12/2019 à 21:09, Jacques Le Roux a écrit :
Hi Samuel, All,
Le 18/12/2019 à 14:00, Samuel Trégouët a écrit :
Le 18/12/2019 à 21:09, Jacques Le Roux a écrit :
Hi Samuel, All,
Le 18/12/2019 à 14:00, Samuel Trégouët a écrit : Le 18/12/2019 à 12:09, Jacques
Le Roux a écrit :
Mathieu asks Michael to provide an "explanation regarding why it matters in
production environments to be able to
every components in framework to be loaded,
but maybe I'm wrong about how users use obfiz framework...
We must face reality (please refer to the dependencies graph again) , as you
know component-load.xml is not only used in plugins.
Le 18/12/2019 à 12:09, Jacques Le Roux a écrit :
Mathieu asks
can reiterate if needed. Mostly for the same
reason Mathieu already exposed in his last message actually.
For the new feature itself, it seems wise to me to have it working with
component-load.xml files before starting it on the trunk...
Thanks
Jacques
Le 18/12/2019 à 12:09, Jacques Le Roux
Hi,
In this thread I superficially see a conversation where no one listens to
anyone else's point of view.
If I dig a bit more I see Mathieu's perspective who wants to achieve something
new which depends on the discussed subject (his [1] below).
And Michael's perspective who worries about
Thanks indeed Gavin for all the details,
I guess others have also implemented solutions with SPA frameworks. It would be
interesting to compare the implementations...
Thanks
Jacques
Le 17/12/2019 à 21:11, Gil Portenseigne a écrit :
Thanks Gavin for sharing, i have a clearer view now :).
Le
Hi All,
Have we a lazy consensus here?
Jacques
Le 10/12/2019 à 06:17, Jacques Le Roux a écrit :
Hi Michael, Mathieu,
Why not keeping both features and have a simple way (if it does not exist yet)
to choose the one to use?
BTW Michael, you are certainly aware, you have a mail certificate
Hi Tomek,
Sorry a bit late, please subscribe to the user ML for such questions and then
use your email client
See why here http://ofbiz.apache.org/mailing-lists.html
You will get a better support , the wider the audience the better the answers
you might get
This said, you should better
Hi,
I tend to agree, I see not reason to have it optional. Now I don't know what it
implies in term of related changes, notably for custom projects...
All in all I don't see a lot of positive doing so. Did you cross a specific
issue Suraj?
Jacques
Le 03/12/2019 à 16:42, Rishi Solanki a
Hi Michael, Mathieu,
Why not keeping both features and have a simple way (if it does not exist yet)
to choose the one to use?
BTW Michael, you are certainly aware, you have a mail certificate issue.
Thanks
Jacques
Le 09/12/2019 à 08:08, Michael Brohl a écrit :
Hi Mathieu,
inline...
Hi Mathieu,
Le 08/12/2019 à 18:27, Mathieu Lirzin a écrit :
Currently we lack a mechanism to display the global dependency graph
which is important to for example to analyse why a component is loaded
before or after another one. However this feature should be easy to
implement and could be a
implementation for POST request.
Please see OFBIZ-11306 which has a patch for POC.
Hi Jacques,
Can explain the need for CSRF token with GET request?
Regards,
James
On 2019/11/27 09:47:04, Jacques Le Roux wrote:
Hi James,
Thanks for your detailed analysis and proposition.
Le 26/11/2019 à 17:26
Le 07/12/2019 à 16:06, Mathieu Lirzin a écrit :
Hello Nico,
nma...@apache.org writes:
commit 071a74238b4d53fb95ffd214e0e68e55840a28e3
Author: Nicolas Malin
AuthorDate: Fri Dec 6 21:29:01 2019 +0100
Fixed: Fix missing else during previous refactoring
(OFBIZ-11253)
When you
Le 05/12/2019 à 12:28, Jacques Le Roux a écrit :
(starting from INFRA-19511)
Erratum: (starting from INFRA-19471)
Jacques
Hi,
It tooks 3 Infra Jiras (starting from INFRA-19511) but we again (after Svn)
have Fisheye associated with Git commits :)
Enjoy
Jacques
Le 03/12/2019 à 20:06, Mathieu Lirzin a écrit :
Jacques Le Roux writes:
With OFBIZ-11302 Mathieu removed the ofbizDebug Gradle task, because "ofbiz
--debug-jvm" can be used instead.
This is now ‘gradlew "ofbiz" --debug-jvm’ with the --debug-jvm outside
of the double quot
Happy to have you both on board :)
Jacques
Le 03/12/2019 à 12:13, Nicolas Malin a écrit :
Welcome on board my fellows :)
Nicolas
On 03/12/2019 11:25, Jacopo Cappellato wrote:
The OFBiz PMC has invited Gil Portenseigne and Mathieu Lirzin to become
members of the committee and we are glad to
Le 03/12/2019 à 08:21, Jacopo Cappellato a écrit :
Now that we have migrated to Git, in my opinion we should really consider
to adopt the workflow based on PR as our primary method for accepting
contributions. I understand that it is a relevant change for the community,
but I also see many
with.
Best Regards,
--
Rishi Solanki
*CTO, Mindpath Technology*
Intelligent Solutions
cell: +91-98932-87847
On Fri, Nov 29, 2019 at 1:28 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
I created https://issues.apache.org/jira/browse/OFBIZ-11301 for that
Le 29/11/2019 à 08:50, Jacques L
Le 02/12/2019 à 18:18, Mathieu Lirzin a écrit :
Hello,
Jacques Le Roux writes:
With OFBIZ-11302 Mathieu removed the ofbizDebug Gradle task, because "ofbiz
--debug-jvm" can be used instead.
This is now ‘gradlew "ofbiz" --debug-jvm’ with the --debug-jvm outside
of th
Hi Nicolas,
Great, I think we should use it as a team, nobody against?
Jacques
Le 03/12/2019 à 09:21, Nicolas Malin a écrit :
I haven't plugin installed, only famework.
Thanks for your sharing a will use that.
Nicolas
On 02/12/2019 17:32, Jacques Le Roux wrote:
Le 30/11/2019 à 08:58
-site.git
The following commit(s) were added to refs/heads/master by this push:
new 1aca13f We need to update
https://projects.apache.org/project.html?ofbiz
1aca13f is described below
commit 1aca13f816e61e83df032ac44d5637850c00edfe
Author: Jacques Le Roux
AuthorDate: Mon Dec 2 19:08:48 2019
by this push:
new 6c5d298 Adds Gil and Mathieu as PMC
6c5d298 is described below
commit 6c5d298df23eb948b0e360b5092014bbba7c44bd
Author: Jacques Le Roux
AuthorDate: Mon Dec 2 17:50:47 2019 +0100
Adds Gil and Mathieu as PMC
---
pmc/ofbiz.rdf | 2 ++
1 file changed, 2 insertions(+)
diff --git
Hi,
With OFBIZ-11302 Mathieu removed the ofbizDebug Gradle task, because "ofbiz
--debug-jvm" can be used instead.
I have no problem with this change, it's easy to remember. Though I like the idea of having syntax sugar to easy remember commands, like ofbizDebug
and ofbizBackground
BTW
Le 30/11/2019 à 08:58, Jacques Le Roux a écrit :
I think we should rely on a Checkstyle pre-commit hook:
https://gist.github.com/davetron5000/37350 to complement
tasks.checkstyleMain.maxErrors
So every committer would have it installed locally and the problem would be
gone \o/
What do
Hi Nicolas, Pawan,
With OFBIZ-11278 Mathieu reduced maxErrors to 37769, so it's not a worry for
you anymore :)
Jacques
Le 30/11/2019 à 08:58, Jacques Le Roux a écrit :
Hi Nicolas, Pawan,
Mathieu said that the lint errors which remains are yours:
https://markmail.org/message
19 à 08:18, Jacques Le Roux a écrit :
Done, with that something changed.
Before https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins was only failing with tests. Now it fails also with lint (as you can see[1] tests
are OK). The lint result is there[2]
It's not the case for https://ci.apache.or
wrote:
I recently pulled the latest commit, and I noticed that latest commits
have introducted linting issues.
Since a521de9ad8a0b5a0f9ceadab348c46d7961ff89a ‘gradlew check’ fails.
Pawan Verma, Nicolas Malin and Jacques Le Roux can you fix the java code
you have written to conform to OFBiz coding
I created https://issues.apache.org/jira/browse/OFBIZ-11301 for that
Le 29/11/2019 à 08:50, Jacques Le Roux a écrit :
our workflow is to contribute patches through Jira.
I want to clearly document that in
https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Contributors+Best+Practices
Hi,
Yesterday I have a short discussion with Pierre Smits about Github PRs and Jira.
Pierre was asking about https://github.com/apache/ofbiz-framework/pulls I
answered that our workflow is to contribute patches through Jira.
I want to clearly document that in
where
the check task is not run.
[1] https://ci.apache.org/projects/ofbiz/logs/trunk/plugins/html/
[2] https://ci.apache.org/projects/ofbiz/logs/trunk/checkstyle.html
Jacques
Le 27/11/2019 à 09:35, Jacques Le Roux a écrit :
To make things absolutely clear, in Buildbot we use pullAllPluginsSource
Le 28/11/2019 à 13:00, Jacques Le Roux a écrit :
Le 28/11/2019 à 12:53, Jacques Le Roux a écrit :
I guess it's a Windows thing. Because on my Ubuntu VM, on the same machine, I get the same number of errors than with Buildbot
I just noticed that on Windows there are 97 files with 0 errors
Le 28/11/2019 à 12:53, Jacques Le Roux a écrit :
I guess it's a Windows thing. Because on my Ubuntu VM, on the same machine, I get the same number of errors than with Buildbot
I just noticed that on Windows there are 97 files with 0 errors included in the
report. But there is the same thing
Le 28/11/2019 à 11:16, Mathieu Lirzin a écrit :
Hello Jacques,
Jacques Le Roux writes:
OK, now we need to agree about tasks.checkstyleMain.maxErrors in build.gradle:
https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/1041/steps/shell_1/logs/stdio
Locally with trunk
Hi All,
OK, now we need to agree about tasks.checkstyleMain.maxErrors in build.gradle:
https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/1041/steps/shell_1/logs/stdio
Locally with trunk and plugins HEAD I get
Checkstyle files with violations: 1039
Checkstyle violations by
Le Roux writes:
Not a big deal (it's only in the commits log), I'm not sure we want stuff like:
Le 27/11/2019 à 17:48, m...@apache.org a écrit :
Author: Samuel Trégouët
Normally we rather use something like
Thanks to Samuel Tregouet for this fix
I did not notice yet, we have already 10
Also we get it in the Blamelist (also in Git), but Samuel is not a committer :/
Le 27/11/2019 à 19:28, build...@apache.org a écrit :
The Buildbot has detected a new failure on builder
ofbizBranch17FrameworkPlugins while building ofbizTrunkFramework. Full details
are available at:
Hi Mathieu, All,
Not a big deal (it's only in the commits log), I'm not sure we want stuff like:
Le 27/11/2019 à 17:48, m...@apache.org a écrit :
Author: Samuel Trégouët
Normally we rather use something like
Thanks to Samuel Tregouet for this fix
I did not notice yet, we have already 10
.
[2]
https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
[3] https://www.owasp.org/index.php?title=CSRF_Guard=no
Regards,
James
On 2019/11/10 10:22:05, Jacques Le Roux wrote:
Hi James,
I see no reasons for you to not open a Jira and provide a p
submitted this
question, but I must be missing something.
Sincerely,
Charles
On 2019/11/23 11:53:49, Jacques Le Roux wrote:
Hi Charles,
Your message has been moderated.
Please subscribe to the user ML for such questions and then use your email
client
See why here http://ofbiz.apache.org/mailing
Hi James, Samuel,
I did not read all your message yet James, but I agree with Samuel's answer
when it comes about CSRF.
Jacques
Le 27/11/2019 à 09:28, Samuel Trégouët a écrit :
Hi James,
I still don't see any reason to keep checkSecureParameter in any form
because it is related to
To make things absolutely clear, in Buildbot we use pullAllPluginsSource. So
"gradlew check" will include the plugins
I created OFBIZ-11299 for that
Jacques
Le 26/11/2019 à 18:04, Mathieu Lirzin a écrit :
Jacques Le Roux writes:
Since it depends on the good will of scr
I created OFBIZ-11268 for that
Le 26/11/2019 à 11:54, Jacques Le Roux a écrit :
Yesterday we had a small conversation with Pawan on Slack. He wondered why I did not backport to R16 since we switched to Git. I explained that it
was more laziness than everything else. I asked him how he was doing
tually I'm still waiting for INFRA-19443 for that...
Jacques
Le 25/11/2019 à 11:18, Jacques Le Roux a écrit :
Here with Gitbox plugins I have 37790 errors and when using
pullAllPluginsSource (ie using svn with Github) I have 37857 errors
In both case it's more than /tasks.checkstyleMain.maxErrors =
Hi,
Yesterday we had a small conversation with Pawan on Slack. He wondered why I did not backport to R16 since we switched to Git. I explained that it was
more laziness than everything else. I asked him how he was doing it. As I suspected it's all by hand. That's why I'm reluctant to do it.
mit, and I noticed that latest commits
have introducted linting issues.
Since a521de9ad8a0b5a0f9ceadab348c46d7961ff89a ‘gradlew check’ fails.
Pawan Verma, Nicolas Malin and Jacques Le Roux can you fix the java code
you have written to conform to OFBiz coding style ?
Thanks.
Hi All, Samuel,
The reason we use only the ref and a not a link to Jira is because so far the commits template is/was(?[1]) used by Michael to deliver the information
you can find a the bottom of our monthly blog entries, eg: https://blogs.apache.org/ofbiz/
I'd like to get ahead. It seems we
Curious I compared the plugins from https://gitbox.apache.org/repos/asf/ofbiz-plugins.git and https://github.com/apache/ofbiz-plugins/trunk : no
differences :-\
Le 23/11/2019 à 21:50, Jacques Le Roux a écrit :
I checked, I'm not concerned :)
But I wonder if it was really OK
1/2019 à 17:07, Mathieu Lirzin a écrit :
I recently pulled the latest commit, and I noticed that latest commits
have introducted linting issues.
Since a521de9ad8a0b5a0f9ceadab348c46d7961ff89a ‘gradlew check’ fails.
Pawan Verma, Nicolas Malin and Jacques Le Roux can you fix the java code
you ha
Hi Charles,
Your message has been moderated.
Please subscribe to the user ML for such questions and then use your email
client
See why here http://ofbiz.apache.org/mailing-lists.html
You will get a better support , it's more fair to share with everybody and
people can answer you on the ML
-gitignore-into-the-git-repos
Jacques
Le 11/11/2019 à 13:48, Jacques Le Roux a écrit :
Hi,
As you may know I'm mostly on Windows and I use ToirtoiseGit to handle things,
and in a lesser way Git Bash and eGit (Eclipse plugin).
There is something which is annoying me with ToirtoiseGit. I don't
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
maybe
make it the last line in the body or something like that.
On Sun, Nov 17, 2019 at 7:05 PM Jacques Le Roux
wrote:
Hi,
While working in Eclipse with Git (ie using eGit which is not my favourite
tool). I found a warning telling me:
"Second line should be empty to separate commit mess
e the body of the message
Thanks
Jacques
On Sun, Nov 17, 2019 at 7:05 PM Jacques Le Roux
wrote:
Hi,
While working in Eclipse with Git (ie using eGit which is not my favourite
tool). I found a warning telling me:
"Second line should be empty to separate commit message header from body&
Hi,
While committing GitHub gave me this warning
remote: remote: GitHub found 2 vulnerabilities on apache/ofbiz-site's default
branch (2 moderate). To find out more, visit:
remote: remote: https://github.com/apache/ofbiz-site/network/alerts
but the link get to nothing. So I guess we can
Hi,
While working in Eclipse with Git (ie using eGit which is not my favourite
tool). I found a warning telling me:
"Second line should be empty to separate commit message header from body"
It was argued that it's only a convention[1], but don't we prefer "convention over
configuration"?
1201 - 1300 of 24454 matches
Mail list logo
