Mailing-List: contact dev-help@polygene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@polygene.apache.org
MIME-Version: 1.0
Sender: hedhman@gmail.com
In-Reply-To: <b43cabd937115f3e754b2cd9eedd0512@nosphere.org>
References: <b43cabd937115f3e754b2cd9eedd0512@nosphere.org>
From: Niclas Hedhman <niclas@hedhman.org>
Date: Mon, 24 Apr 2017 00:46:11 +0800
Message-ID: <CADmm+KdkXQPtsWGrrrhDtmNDJzbbFygrhBP2xu417Nfzf4B-sw@mail.gmail.com>
Subject: Re: :tools:generator-polygene integrated into the Gradle build
To: dev@polygene.apache.org
Content-Type: multipart/alternative; boundary=f403045f74b8a16c6b054dd83b2c
archived-at: Sun, 23 Apr 2017 16:46:43 -0000

--f403045f74b8a16c6b054dd83b2c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I don't think it will affect the local workflow on the generator, since
most the work is to look at generated code, so I have "npm link" to the
source dir, and then edit, generate with model file, figure out what needs
to be done next, iterate...

The reason I do so much on model support is a bit conniving. Put up a web
site, easier to decide what you want, entities with props/assocs,
optionality, default values and so on, spit out a model.json, run it
through the generator, and shoot the result to a Git(Hub) repository. Once
I have figured Angular out, I intend to drape Rest applications with a Web
UI, and then might as well, deploy it to a server in the same breath....
Yeah, big plans, but we have all the pieces to make this awesome with
relatively little work.

Cheers
Niclas

On Mon, Apr 24, 2017 at 12:07 AM, Paul Merlin <paulmerlin@apache.org> wrote=
:

> Gang,
>
> I spent some time to integrate the project generator into the build syste=
m.
>
> ./gradlew :tools:generator:check now runs ~40 permutations, 1m30s here
>
> You can also target the test task only:
>
>   ./gradlew :tools:generator:npmTest
>
> A dedicated task can run all the permutations, but it takes a while:
>
>   ./gradlew :tools:generator:npmTestAll
>
> Both tasks automatically installs node, npm, node dependencies and reuse
> the staged maven repository with the Polygene artifacts.
> The generators tests then use a Gradle init script to add that local
> staged maven repository to all builds invocations.
>
> I changed the tests to only to ./gradlew classes instead of
> ./gradlew build, this makes the tests faster.
>
> A JUnit compatible test report file is generated so Jenkins can take
> that into account.
>
> The only brittle thing is putting the Polygene version into the
> package.json file, which is done in-place.
> I couldn=E2=80=99t find a better way for now.
>
> Another thing to note is that if you Ctrl-C the Gradle process then some
> node processes might be hanging holding file descriptors.
> It's a know issue, see https://github.com/srs/gradle-
> node-plugin/issues/143, thumbs-it-up if you have a few seconds.
> A `killall node` and you're good.
>
> Direct npm command line usage still works:
>
>   npm run test
>   npm run test_all
>
> but you=E2=80=99ll need to invoke a Gradle task first:
>
>   ./gradle :tools:generator:generateStageMavenRepositoryInitScript
>
> @Niclas: I think this is way better already despite some loose ends.
> Please tell me if you think something should be done differently.
> This should change a bit your workflow when working on the generator, but
> for the best I hope.
> No more maven local thing etc... and our CI will exercise the tests!
>
> (We'll get some minor failures from CI, I'm fixing theses, mostly related
> to Rat=E2=84=A2 now that the project is included in the build system)
>
> Cheers
>
> /Paul
>
>


--=20
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

--f403045f74b8a16c6b054dd83b2c--