Mailing-List: contact dev-help@zest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zest.apache.org
Received-SPF: pass (athena.apache.org: message received from 54.191.145.13
 which is an MX secondary for dev@zest.apache.org)
MIME-Version: 1.0
Sender: hedhman@gmail.com
In-Reply-To: <553A2E82.1040207@nosphere.org>
References: 
 <CADmm+KfL7Pnr98NwWbj75knrzQz0+LWpOD2fRKt_j9_ziPbuow@mail.gmail.com>
 <553A2E82.1040207@nosphere.org>
From: Niclas Hedhman <niclas@hedhman.org>
Date: Fri, 24 Apr 2015 21:24:13 +0800
Message-ID: 
 <CADmm+Kc1KMXrsH=DmVbghoFaenpZ51ybWPeGBo1igOJ3PZcesw@mail.gmail.com>
Subject: Re: Application Code Management tool
To: dev <dev@zest.apache.org>
Content-Type: multipart/alternative; boundary=001a11427d6827a5740514785132

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

I first started out by having command line, as so...

   #> qi4j create-project MyProject
   #> qi4j add-layer config

and so on.

Then Sandro was suggesting "Gradle Plugin", I want to use Qi4j for the
modelling, so I would need to get Qi4j up and running on Groovy to do that.

So, then, why not use the Groovy Shell directly, without Gradle...
   qi4j {
      project(name: "MyProject") {
          layer(name: "Config" ) {
              module( name: "Config" ) {
                  assemble DefaultConfigurationModule
              }
          }
          layer(name: "Infra", uses:["Config", "Security"] {
              module( name: "Store" ) {
                  assemble CassandraStoreModule
              }
              module( name: "Identity" ) {
                  assemble LdapModule
              }
          }
      }
  }
or whatever the syntax looks like in detail.

Then it was, so why generate the code and not allow the application
structure to be created with Groovy code instead of Java, that would
alleviate some of the messy assembly in Java, to the extent (I think) where
some rather simple templating of build scripts, directory structures and
initial classes.

Ok, but if the above is happening in Groovy, should/could therefor the
entire Bootstrap phase simply be groovy as well??

qi4j { .... }
qi4j.activate

Ok, that shouldn't be too hard either, but we can script it quickly in
Groovy Shell.

But why Groovy? Wouldn't Scala be equally well suited, as it also has a
REPL and a flexible syntax....

My head is spinning, and suffering from decision anxiety.


Niclas

On Fri, Apr 24, 2015 at 7:52 PM, Paul Merlin <paul@nosphere.org> wrote:

> Niclas Hedhman a =C3=A9crit :
> > Gang,
> > After the presentation in Romania, one of the feedbacks received was th=
at
> > it is too hard to get going with Qi4j. Not only does it require quite a
> > steep learning curve to grasp Qi4j itself, but it is tedious to set up =
a
> > working build for a new project.
> >
> > So, I want to create something similar to Maven Archetypes, but with mu=
ch
> > better understanding of Qi4j structures.
> >
> > I have created a branch for this; Gradle_archetype_toolchain
> > Name was set before I realize what I want to do, but Gradle will be the
> > first supported build system, but I think at least Maven should also be
> > supported, and possibly be able to create Eclipse Workspaces and Intell=
iJ
> > projects as well.
> >
> > Problem domain;
> >   + Support Pre-packaged application structures, i.e. templating
> >   + Support creation/removal of all Qi4j primary types, Application,
> Layer,
> > Module, Composites
> >   + Support weaving in custom code, so generation can occur more than
> once.
> >   + Support generation to many different build tools.
> >
> > Solution domain;
> >   * Strong domain model, which is kept in an entity store and modified
> > interactively or via scripting
> >   * Set of commands for manipulating the model
> >   * The entire entity store can be used as a "template" for new project=
s
> >   * Generators will use the model and generate the structures
> >   * Commands are also used to start generation
> >
> > Example Use-case 1
> > Developer Alex want to use Qi4j for a RESTful server application. He
> isues
> > the 'create-project' command and selects the 'rest-server' application
> > type, and the tool creates a operational skeleton application that
> serves a
> > 'Hello, Zest' response from http://localhost:8080/
> >
> >
> > WDYT?
> I think this is a good idea.
>
> >From a community point of view, it would be good to both support few
> official archetypes and allow easy creation/distribution/usage of others
> from outside the Apache Zest project.
>
> > + Support weaving in custom code, so generation can occur more than onc=
e.
>
> For me that's a tricky part. But maybe you have something in mind?
>
>
> Sandro Martini a =C3=A9crit :
> > What do you think on implementing these features with Gradle plugins ?
> > Just for info, Grails 3 has been rewritten and all developer-related
> > features are now on top of Gradle (with custom gradle plugins, to make
> > available shell commands and other developer-related stuff) so maybe
> > something like this could be good even here ...
> If we wrap all this in a simple facade api then we can have command
> lines, gradle/maven/whatever plugins and even start thinking about IDE
> plugins.
>
>
> Jiri's and Michael's Tower concept looks more like build/assembly
> automation focused, it seems we'll learn more about it soon :)
>
>
> My 2 cents,
>
> /Paul
>
>
>


--=20
Niclas Hedhman, Software Developer
http://zest.apache.org/qi4j <http://www.qi4j.org> - New Energy for Java

--001a11427d6827a5740514785132--