Re: [DISCUSS] Proposed new optional module: groovy-contracts

On 03.08.20 07:57, Paul King wrote: Hi everyone, The GContracts project (design-by-contract extension for Groovy) has been archived: https://github.com/andresteingress/gcontracts/ I believe there is sufficient merit in the functionality it offers for us to consider taking up support of the co

Re: [DISCUSS] Proposed new optional module: groovy-contracts

On 2020-08-03 09:47, Jochen Theodorou wrote: > On 03.08.20 07:57, Paul King wrote: >> >> Hi everyone, >> >> The GContracts project (design-by-contract extension for Groovy) has >> been archived: >> >> https://github.com/andresteingress/gcontracts/ >> >> I believe there is sufficient merit in the fu

Re: [DISCUSS] Proposed new optional module: groovy-contracts

The original source tree remains anyway in its original place. Perhaps we lose the lineation, but if ever we really really need to hunt through the history, it's still there. And honestly, it's pretty rare that we have to dig in anyway. On Mon, Aug 3, 2020 at 10:47 AM Marcin Zajączkowski wrote:

Re: [DISCUSS] Proposed new optional module: groovy-contracts

On 03.08.20 11:50, Guillaume Laforge wrote: [...] And honestly, it's pretty rare that we have to dig in anyway. that could be true in case of gcontracts. For groovy-core it certainly is not true. Especially if the code part I am looking at is unfamiliar it is very important to get why some thin

Re: [DISCUSS] Proposed new optional module: groovy-contracts

Agreed, but 1) it's definitely not the same size of project (only 300 commits for GContracts), and 2) the history is not lost since it stays in the old project (even if it's less convenient to have to dig in another location). Now that said, perhaps some of our ASF INFRA admins have some super git

Re: [DISCUSS] Proposed new optional module: groovy-contracts

I am inclined to do a fresh start since as others have pointed out we do have the old repo. The old code is 3-clause BSD license but this contribution is being made under Apache license. Also, the code was refactored somewhat to be more consistent with the current code base styling and tweaked to w

Re: [DISCUSS] Proposed new optional module: groovy-contracts

Do we need a ICLA contributor agreement ? On Mon, Aug 3, 2020 at 9:13 PM Paul King wrote: > I am inclined to do a fresh start since as others have pointed out we do > have the old repo. The old code is 3-clause BSD license but this > c

Re: [DISCUSS] Proposed new optional module: groovy-contracts

On Mon, Aug 3, 2020 at 9:33 PM Remko Popma wrote: > Do we need a ICLA contributor agreement > ? > I meant from Andre. Or does he already have an ICLA on file with ASF? > > On Mon, Aug 3, 2020 at 9:13 PM Paul King wrote: > >> I am inc

Re: [DISCUSS] Proposed new optional module: groovy-contracts

On 2020-08-03 14:12, Paul King wrote: > I am inclined to do a fresh start since as others have pointed out we do > have the old repo. The old code is 3-clause BSD license but this > contribution is being made under Apache license. Also, the code was > refactored somewhat to be more consistent with

Re: [DISCUSS] Proposed new optional module: groovy-contracts

I am chasing that up. On Mon, Aug 3, 2020 at 10:34 PM Remko Popma wrote: > > > On Mon, Aug 3, 2020 at 9:33 PM Remko Popma wrote: > >> Do we need a ICLA contributor agreement >> ? >> > I meant from Andre. Or does he already have an ICL

Re: [DISCUSS] Proposed new optional module: groovy-contracts

The ICLA has been submitted but I'll await confirmation from the secretary before proceeding. Cheers, Paul. On Mon, Aug 3, 2020 at 10:48 PM Paul King wrote: > I am chasing that up. > > On Mon, Aug 3, 2020 at 10:34 PM Remko Popma wrote: > >> >> >> On Mon, Aug 3, 2020 at 9:33 PM Remko Popma wro

GContracts Overview

Since there is currently a proposal on the dev mailing list whether to include the design-by-contract GContracts library (https://github.com/andresteingress/gcontracts/) into Groovy,  for everyone who has never used GContracts (or design-by-contract), and since most of the "info"-links on the G

Re: [PROPOSAL]Support conditional return

Hi mg, Just on supplying our own macros, we should do this for Groovy 4. We have been reluctant so far because we have been conservative about unforeseen implications. However, unless we start using them more widely, we aren't going to learn those implications. I'd suggest having them (to start w