You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@polygene.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2017/03/05 01:17:46 UTC
Yeoman generator
A heads-up;
I am working on the Yeoman generator to create Polygene projects from
commandline, and there is some progress that I will commit shortly.
One of the new things that I have added is that it is possible to provide a
"model" in JSON, which either used as defaults for the questions, or one
can disable the prompts and it will take all the stuff from that model.
It came about because I couldn't figure out how to do "repeat questions" in
Yeoman, i.e. Add the name of a Module, then add X value types, Y entity
types..., then back to be able to add another Module and so on. If there is
someone with Yeoman experience who can fix that, please step forward.
So, I created a small json format (see sample below).
This in turn means that small "profiles" could be prepared and simply fed
into Yeoman and out comes a skeletal application, runnable at that point.
If anyone wants to help working on this, here is what you need to do,
install npm and yeoman on your system (http://yeoman.io/learning/)
cd tools/generator-polygene/
sudo npm link
That will make the "polygene" generator available in yeoman.
I typically do my workflow by first creating my "project directory", say
"mkdir niclas", then I repeatedly run,
rm -rf * && cp ../model.json imported-model.json && yo polygene --import
--export && ./gradlew clean build assemble
between each change in the source code. Above I have an "model.json"
containing the "modules" section seen in the "exported" model below. (Later
the name of import and export files will be added)
One thing that needs to be figured out, is how to make this available in
the Polygene SDK distribution. Another that Paul has brought up is how to
test all the permutations so that every combination of entitystore,
indexing, serialization, caching, rest, jmx, reindexer, migration support,
metrics and what else could be dreamt up, actually compiles after a
generation. With the new "--import" this automation should be easier to do,
although I think Yeoman has support for it too.
Anyway, a good chunk of work is going to be committed a bit later today..
{
"modules": {
"users": {
"cruds": [
{
"name": "Users"
},
{
"name": "Roles"
},
{
"name": "User"
},
{
"name": "Role"
},
{
"name": "Permission"
},
{
"name": "Group"
},
{
"name": "Groups"
}
],
"entities": [],
"values": [],
"services": [
{
"name": "AuthService",
"visibilty": "application"
}
],
"transients": [],
"objects": [],
"name": "users",
"clazz": {
"name": "AuthService",
"visibilty": "application"
}
}
},
"name": "Niclas",
"packageName": "com.acme.niclas",
"singletonApp": false,
"features": [
"rest api"
],
"entitystore": "Cassandra",
"indexing": "Rdf",
"caching": "none",
"serialization": "Jackson",
"packagename": "com.acme.niclas",
"javaPackageDir": "com/acme/niclas"
}
--
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java
Re: Yeoman generator
Posted by Niclas Hedhman <ni...@hedhman.org>.
And I think ASF policy is that "We distributed open SOURCE", so any binary
is convenience, and it should be producable from the source dist tarball.
If we fulfill that, then npm publishing should not be any different than
Maven publishing.
On Mon, Mar 6, 2017 at 7:46 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
> standalone jar vs war... Yeah, should perhaps be a choice question.
>
> I just tried to publish, and that worked....
>
> BUT, "independently" may not be the best of choices, since the
> polygeneVersion should be sync'd
>
> When one do "npm publish", it is said to create a Git tag as well,
> although it doesn't seem to have done that for me. Maybe only when .git is
> in the same directory.
>
> But it is interesting stuff...
>
> On Mon, Mar 6, 2017 at 7:27 PM, Paul Merlin <pa...@apache.org> wrote:
>
>> Niclas Hedhman a écrit :
>> > On Mon, Mar 6, 2017 at 4:49 PM, Paul Merlin <pa...@apache.org>
>> wrote:
>> >
>> >> In the yeoman world, generators are published to and fetched from the
>> >> npm registry. We should think about doing just that.
>> >
>> > Truth be told, I don't know Yeoman well, but I recognize good stuff
>> when I
>> > see it, and this registry thing is news to me. And that seems to be
>> awesome
>> > news IIUIIC.
>> >
>> > If it means that..
>> >
>> > <quote>
>> > To create an Apache Polygene project;
>> >
>> > $ # Make sure you have NPM installed and working.
>> > $ npm install yeoman-generator-polygene
>> > $ mkdir myproject && cd myproject
>> > $ yo polygene
>> > $ # answer the questions
>> > $ ./gradlew build install
>> >
>> > </quote>
>> >
>> > ... and no messing around with downloads or setting up a build, then we
>> > have lowered the bar quite a bit.
>> >
>> > I am optimistic.
>>
>> :-) Good
>> Yes, that's how it should be!
>>
>> By the way, I noticed that the :app project of the generated builds is
>> building a WAR. It uses the Gretty gradle plugin to provide tasks to run
>> the application in an embedded Jetty through the build system.
>>
>> We could add a generator permutation to this so it runs from a main
>> class instead (no WAR). Using the gradle `application` plugin that gives
>> us run, distZip ... tasks:
>>
>> npm install -q yeoman yeoman-generator-polygene
>> mkdir myproject && cd myproject
>> yo polygene
>> # answer the questions
>> ./gradlew check
>> ./gradlew :app:run
>> ./gradlew :app:distZip
>>
>>
>> I wonder about the lifecycle of such (a) generator(s). Do we want to
>> release them alongside the SDK? Do we want to store their source in the
>> main SDK repository long term? I'm not saying we should answer this
>> prior to 3.0, just wanted to share some thoughts.
>>
>>
>> `tools/generator-polygene` is not integrated into our build system yet.
>> Yeoman templates are built/tested/published using npm. We should not
>> deviate from this. Once the generator npm build is OK we'll be able to
>> just run it from our Gradle build.
>>
>> We could have yeoman tests (http://yeoman.io/authoring/testing.html) run
>> using `npm test` that use the generator and then invoke the generated
>> gradle build to :check if the generated project is working. Having this
>> for a single permutation would already be a massive win over the absence
>> of automated tests. This could easily be done using only embedded
>> services.
>>
>> For publishing, if we can publish the generators to the npm registry
>> independenty, using just npm on the command line, I'd say we're good for
>> now.
>>
>>
>
>
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org <http://zest.apache.org> - New Energy for Java
>
--
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java
Re: Yeoman generator
Posted by Paul Merlin <pa...@apache.org>.
Niclas Hedhman a �crit :
> standalone jar vs war... Yeah, should perhaps be a choice question.
>
> I just tried to publish, and that worked....
\o/
> BUT, "independently" may not be the best of choices, since the
> polygeneVersion should be sync'd
Sure, that'll be doable once we integrate the generator into our gradle
build.
But we could handle this by hand if we don't get there before 3.0.
Having automated tests is more important to me (did I say that already?
:) ).
If at some point we choose to externalize the generator(s), we'll simply
version them ; a given version of a generator will support a given
version of Polygene.
> When one do "npm publish", it is said to create a Git tag as well, although
> it doesn't seem to have done that for me. Maybe only when .git is in the
> same directory.
If we publish the generator(s) alongside Polygene releases, then we
should already have a matching version tag.
> But it is interesting stuff...
>
> On Mon, Mar 6, 2017 at 7:27 PM, Paul Merlin <pa...@apache.org> wrote:
>
>> Niclas Hedhman a �crit :
>>> On Mon, Mar 6, 2017 at 4:49 PM, Paul Merlin <pa...@apache.org>
>> wrote:
>>>> In the yeoman world, generators are published to and fetched from the
>>>> npm registry. We should think about doing just that.
>>> Truth be told, I don't know Yeoman well, but I recognize good stuff when
>> I
>>> see it, and this registry thing is news to me. And that seems to be
>> awesome
>>> news IIUIIC.
>>>
>>> If it means that..
>>>
>>> <quote>
>>> To create an Apache Polygene project;
>>>
>>> $ # Make sure you have NPM installed and working.
>>> $ npm install yeoman-generator-polygene
>>> $ mkdir myproject && cd myproject
>>> $ yo polygene
>>> $ # answer the questions
>>> $ ./gradlew build install
>>>
>>> </quote>
>>>
>>> ... and no messing around with downloads or setting up a build, then we
>>> have lowered the bar quite a bit.
>>>
>>> I am optimistic.
>> :-) Good
>> Yes, that's how it should be!
>>
>> By the way, I noticed that the :app project of the generated builds is
>> building a WAR. It uses the Gretty gradle plugin to provide tasks to run
>> the application in an embedded Jetty through the build system.
>>
>> We could add a generator permutation to this so it runs from a main
>> class instead (no WAR). Using the gradle `application` plugin that gives
>> us run, distZip ... tasks:
>>
>> npm install -q yeoman yeoman-generator-polygene
>> mkdir myproject && cd myproject
>> yo polygene
>> # answer the questions
>> ./gradlew check
>> ./gradlew :app:run
>> ./gradlew :app:distZip
>>
>>
>> I wonder about the lifecycle of such (a) generator(s). Do we want to
>> release them alongside the SDK? Do we want to store their source in the
>> main SDK repository long term? I'm not saying we should answer this
>> prior to 3.0, just wanted to share some thoughts.
>>
>>
>> `tools/generator-polygene` is not integrated into our build system yet.
>> Yeoman templates are built/tested/published using npm. We should not
>> deviate from this. Once the generator npm build is OK we'll be able to
>> just run it from our Gradle build.
>>
>> We could have yeoman tests (http://yeoman.io/authoring/testing.html) run
>> using `npm test` that use the generator and then invoke the generated
>> gradle build to :check if the generated project is working. Having this
>> for a single permutation would already be a massive win over the absence
>> of automated tests. This could easily be done using only embedded services.
>>
>> For publishing, if we can publish the generators to the npm registry
>> independenty, using just npm on the command line, I'd say we're good for
>> now.
>>
>>
>
>
Re: Yeoman generator
Posted by Niclas Hedhman <ni...@hedhman.org>.
standalone jar vs war... Yeah, should perhaps be a choice question.
I just tried to publish, and that worked....
BUT, "independently" may not be the best of choices, since the
polygeneVersion should be sync'd
When one do "npm publish", it is said to create a Git tag as well, although
it doesn't seem to have done that for me. Maybe only when .git is in the
same directory.
But it is interesting stuff...
On Mon, Mar 6, 2017 at 7:27 PM, Paul Merlin <pa...@apache.org> wrote:
> Niclas Hedhman a écrit :
> > On Mon, Mar 6, 2017 at 4:49 PM, Paul Merlin <pa...@apache.org>
> wrote:
> >
> >> In the yeoman world, generators are published to and fetched from the
> >> npm registry. We should think about doing just that.
> >
> > Truth be told, I don't know Yeoman well, but I recognize good stuff when
> I
> > see it, and this registry thing is news to me. And that seems to be
> awesome
> > news IIUIIC.
> >
> > If it means that..
> >
> > <quote>
> > To create an Apache Polygene project;
> >
> > $ # Make sure you have NPM installed and working.
> > $ npm install yeoman-generator-polygene
> > $ mkdir myproject && cd myproject
> > $ yo polygene
> > $ # answer the questions
> > $ ./gradlew build install
> >
> > </quote>
> >
> > ... and no messing around with downloads or setting up a build, then we
> > have lowered the bar quite a bit.
> >
> > I am optimistic.
>
> :-) Good
> Yes, that's how it should be!
>
> By the way, I noticed that the :app project of the generated builds is
> building a WAR. It uses the Gretty gradle plugin to provide tasks to run
> the application in an embedded Jetty through the build system.
>
> We could add a generator permutation to this so it runs from a main
> class instead (no WAR). Using the gradle `application` plugin that gives
> us run, distZip ... tasks:
>
> npm install -q yeoman yeoman-generator-polygene
> mkdir myproject && cd myproject
> yo polygene
> # answer the questions
> ./gradlew check
> ./gradlew :app:run
> ./gradlew :app:distZip
>
>
> I wonder about the lifecycle of such (a) generator(s). Do we want to
> release them alongside the SDK? Do we want to store their source in the
> main SDK repository long term? I'm not saying we should answer this
> prior to 3.0, just wanted to share some thoughts.
>
>
> `tools/generator-polygene` is not integrated into our build system yet.
> Yeoman templates are built/tested/published using npm. We should not
> deviate from this. Once the generator npm build is OK we'll be able to
> just run it from our Gradle build.
>
> We could have yeoman tests (http://yeoman.io/authoring/testing.html) run
> using `npm test` that use the generator and then invoke the generated
> gradle build to :check if the generated project is working. Having this
> for a single permutation would already be a massive win over the absence
> of automated tests. This could easily be done using only embedded services.
>
> For publishing, if we can publish the generators to the npm registry
> independenty, using just npm on the command line, I'd say we're good for
> now.
>
>
--
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java
Re: Yeoman generator
Posted by Paul Merlin <pa...@apache.org>.
Niclas Hedhman a �crit :
> On Mon, Mar 6, 2017 at 4:49 PM, Paul Merlin <pa...@apache.org> wrote:
>
>> In the yeoman world, generators are published to and fetched from the
>> npm registry. We should think about doing just that.
>
> Truth be told, I don't know Yeoman well, but I recognize good stuff when I
> see it, and this registry thing is news to me. And that seems to be awesome
> news IIUIIC.
>
> If it means that..
>
> <quote>
> To create an Apache Polygene project;
>
> $ # Make sure you have NPM installed and working.
> $ npm install yeoman-generator-polygene
> $ mkdir myproject && cd myproject
> $ yo polygene
> $ # answer the questions
> $ ./gradlew build install
>
> </quote>
>
> ... and no messing around with downloads or setting up a build, then we
> have lowered the bar quite a bit.
>
> I am optimistic.
:-) Good
Yes, that's how it should be!
By the way, I noticed that the :app project of the generated builds is
building a WAR. It uses the Gretty gradle plugin to provide tasks to run
the application in an embedded Jetty through the build system.
We could add a generator permutation to this so it runs from a main
class instead (no WAR). Using the gradle `application` plugin that gives
us run, distZip ... tasks:
npm install -q yeoman yeoman-generator-polygene
mkdir myproject && cd myproject
yo polygene
# answer the questions
./gradlew check
./gradlew :app:run
./gradlew :app:distZip
I wonder about the lifecycle of such (a) generator(s). Do we want to
release them alongside the SDK? Do we want to store their source in the
main SDK repository long term? I'm not saying we should answer this
prior to 3.0, just wanted to share some thoughts.
`tools/generator-polygene` is not integrated into our build system yet.
Yeoman templates are built/tested/published using npm. We should not
deviate from this. Once the generator npm build is OK we'll be able to
just run it from our Gradle build.
We could have yeoman tests (http://yeoman.io/authoring/testing.html) run
using `npm test` that use the generator and then invoke the generated
gradle build to :check if the generated project is working. Having this
for a single permutation would already be a massive win over the absence
of automated tests. This could easily be done using only embedded services.
For publishing, if we can publish the generators to the npm registry
independenty, using just npm on the command line, I'd say we're good for
now.
Re: Yeoman generator
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Mon, Mar 6, 2017 at 4:49 PM, Paul Merlin <pa...@apache.org> wrote:
> In the yeoman world, generators are published to and fetched from the
> npm registry. We should think about doing just that.
Truth be told, I don't know Yeoman well, but I recognize good stuff when I
see it, and this registry thing is news to me. And that seems to be awesome
news IIUIIC.
If it means that..
<quote>
To create an Apache Polygene project;
$ # Make sure you have NPM installed and working.
$ npm install yeoman-generator-polygene
$ mkdir myproject && cd myproject
$ yo polygene
$ # answer the questions
$ ./gradlew build install
</quote>
... and no messing around with downloads or setting up a build, then we
have lowered the bar quite a bit.
I am optimistic.
Cheers
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: Yeoman generator
Posted by Paul Merlin <pa...@apache.org>.
Niclas Hedhman a �crit :
> A heads-up;
> I am working on the Yeoman generator to create Polygene projects from
> commandline, and there is some progress that I will commit shortly.
\o/
> One of the new things that I have added is that it is possible to provide a
> "model" in JSON, which either used as defaults for the questions, or one
> can disable the prompts and it will take all the stuff from that model.
>
> It came about because I couldn't figure out how to do "repeat questions" in
> Yeoman, i.e. Add the name of a Module, then add X value types, Y entity
> types..., then back to be able to add another Module and so on. If there is
> someone with Yeoman experience who can fix that, please step forward.
>
> So, I created a small json format (see sample below).
> This in turn means that small "profiles" could be prepared and simply fed
> into Yeoman and out comes a skeletal application, runnable at that point.
>
> If anyone wants to help working on this, here is what you need to do,
>
> install npm and yeoman on your system (http://yeoman.io/learning/)
>
> cd tools/generator-polygene/
> sudo npm link
>
> That will make the "polygene" generator available in yeoman.
>
> I typically do my workflow by first creating my "project directory", say
> "mkdir niclas", then I repeatedly run,
>
>
> rm -rf * && cp ../model.json imported-model.json && yo polygene --import
> --export && ./gradlew clean build assemble
>
> between each change in the source code. Above I have an "model.json"
> containing the "modules" section seen in the "exported" model below. (Later
> the name of import and export files will be added)
>
> One thing that needs to be figured out, is how to make this available in
> the Polygene SDK distribution.
In the yeoman world, generators are published to and fetched from the
npm registry. We should think about doing just that.
About including the generators in the Polygene distribution, if we want
to go down that route we need to come up with some usage scenario first.
We could either bundle everything needed or require extra installation
steps. Niclas, any thoughts?
> Another that Paul has brought up is how to
> test all the permutations so that every combination of entitystore,
> indexing, serialization, caching, rest, jmx, reindexer, migration support,
> metrics and what else could be dreamt up, actually compiles after a
> generation. With the new "--import" this automation should be easier to do,
> although I think Yeoman has support for it too.
The https://github.com/srs/gradle-node-plugin could help integrate the
automation with our build system. It should even be possible to not
require any manual installation. Ideally the generated projects include
some basic tests that we could run as part of the whole SDK test suite.
> Anyway, a good chunk of work is going to be committed a bit later today..
>
> {
> "modules": {
> "users": {
> "cruds": [
> {
> "name": "Users"
> },
> {
> "name": "Roles"
> },
> {
> "name": "User"
> },
> {
> "name": "Role"
> },
> {
> "name": "Permission"
> },
> {
> "name": "Group"
> },
> {
> "name": "Groups"
> }
> ],
> "entities": [],
> "values": [],
> "services": [
> {
> "name": "AuthService",
> "visibilty": "application"
> }
> ],
> "transients": [],
> "objects": [],
> "name": "users",
> "clazz": {
> "name": "AuthService",
> "visibilty": "application"
> }
> }
> },
> "name": "Niclas",
> "packageName": "com.acme.niclas",
> "singletonApp": false,
> "features": [
> "rest api"
> ],
> "entitystore": "Cassandra",
> "indexing": "Rdf",
> "caching": "none",
> "serialization": "Jackson",
> "packagename": "com.acme.niclas",
> "javaPackageDir": "com/acme/niclas"
> }
>