Hi Michael -
It is probably not possible to execute the hooks automatically. There are
security implications to it based on a bit of research as the hooks run on
the client side.
I think sharing is not an issue because the gradle plug-in takes care of
generating the hook with any gradle command r
Thanks to all for your wishes!!
Thanks and Regards
--
Akash Jain
On Thu, Jan 28, 2021 at 10:10 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
> The OFBiz PMC has invited Akash Jain to become member of the committee and
> we are glad to announce he has accepted the nomination.
>
> On b
Many Congratulations Girish!!
Thanks and Regards
--
Akash Jain
On Thu, Jan 28, 2021 at 10:10 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
> The OFBiz PMC has invited Girish Vasmatkar to become member of the
> committee and we are glad to announce he has accepted the nomination.
>
>
Many Congratulations Daniel!!
Thanks and Regards
--
Akash Jain
On Thu, Dec 31, 2020 at 9:50 PM Jacopo Cappellato <
jacopo.cappell...@gmail.com> wrote:
> The OFBiz PMC has invited Daniel to become a new committer and we are
> pleased to announce that he has accepted the nomination.
>
> Welcome o
Thanks a lot for the comprehensive informations, Aditya!
I somehow missed this activity or simply forgot.
The hooks are not generated by default, during the build, right? If we
would do this automatically we could close this gap (which is minor
because the build does the checks anyway).
For
+1 to stabilize on jdk11 for next release branch and move forward to
jdk17 for trunk
Nicolas
On 04/02/2021 13:12, Aditya Sharma wrote:
> +1 for jdk11
>
> Thanks and regards,
> Aditya Sharma
>
>
> On Thu, Feb 4, 2021 at 11:02 AM Suraj Khurana
> wrote:
>
>> Hi,
>>
>> +1 for jdk11.
>>
>> --
>> Best
+1 for jdk11
Thanks and regards,
Aditya Sharma
On Thu, Feb 4, 2021 at 11:02 AM Suraj Khurana
wrote:
> Hi,
>
> +1 for jdk11.
>
> --
> Best Regards,
> Suraj Khurana
> Senior Technical Consultant
>
>
> On Thu, Feb 4, 2021 at 2:30 AM Eugen Stan wrote:
>
> > +1 for jdk11.
> >
> > We can focus on j
Hi Michael,
With OFBIZ-11304[1], we introduced a Gradle plugin
git-hooks-gradle-plugin[2]. The plugin generates a pre-push hook on the
developer's local. I think as the plugin persists it should work along with
the forks too. Along with that, we used GitHub action that runs
checkstyleMain task on
Hi Girish,
which githook plugin are you using? I found several, not sure which one
to choose.
It seems that they do exactly what I described, just have to check. If
this is the case, I would recommend to use such a Gradle plugin which
automatically sets up the git hooks in the local reposito
Hi Michael/Jacques
+1 for the proposal. However, I do not face this issue on my local, partly
because I never tried to push to the repository without running any gradle
command. The gitHook gradle plug-in is essentially creating hooks on the
local repository that's why when I push to my forked OFB
Sorry, I am on it.
Am 03.02.21 um 14:35 schrieb build...@apache.org:
The Buildbot has detected a new failure on builder ofbizTrunkFrameworkPlugins
while building ofbiz-framework. Full details are available at:
https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/1973
Buildbot
Hello folks,
Hope you are doing good.
Recently we encountered a client's requirement which led us to have two
separate condition-services with exact same code but opposite output. In
one case true and false for another.
We can enhance existing behaviour by having one more attribute in the
seca/e
Le 03/02/2021 à 17:59, Michael Brohl a écrit :
So I think we should find a way to deploy the hooks to the user's local repository to make sure they are used there also. Else we would always chase
after newly introduced checkstyle problems, especially if we use pull requests.
I found a solution
13 matches
Mail list logo
