polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Merlin <paulmer...@apache.org>
Subject Re: Yeoman generator
Date Mon, 06 Mar 2017 12:02:54 GMT
Niclas Hedhman a écrit :
> 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

Sure, that'll be doable once we integrate the generator into our gradle
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 <paulmerlin@apache.org> wrote:
>> Niclas Hedhman a écrit :
>>> On Mon, Mar 6, 2017 at 4:49 PM, Paul Merlin <paulmerlin@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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message