polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Yeoman generator
Date Mon, 06 Mar 2017 11:46:10 GMT
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 <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.
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

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