polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Pantazoglou <michael.pantazog...@gmail.com>
Subject Re: Application Code Management tool
Date Mon, 27 Apr 2015 19:55:39 GMT
Hi guys,

Apologies for picking up the discussion that Jiri opened a few days ago,
perhaps I am already off-topic.

Tower is an abstraction/utility that we devised to address the underlying
complexity of assembly/layers/visibility. At least for me, proper assembly
of infrastructure and visibility of entities across layers was one of the
'hard' things to digest when I started using Qi4j, and at times it gave
frustrating errors. Tower alleviates from a lot of details and provides us
with a kind of DSL of the form:

Tower.newInstance(Application.Mode)
        .addBlock(A, ES_a, ES_a_config, EI_b, EI_b_config)
        .addBlock(B, ES_x, ES_x_config, EI_y, EI_y_config)
        ...
        .start(httpPort);

The above would assemble an application with two *blocks* (each block is
roughly a domain model + business logic/usecases), with each using the
specified ES and EI infrastructure, and would expose the respective REST
API on the specified host and port. All the details are hidden by
identifiable assemblers which reflectively assemble all needed components
(entities, transients, values, services etc.) and can be easily reused. So
the whole idea is like building a Tower (aka a Qi4j application) with lego
pieces (the infrastructure blocks and the capability blocks).

Of course the DSL is tailored to our particular code structure and needs,
and the Tower has a few tight dependencies with both ours and some
third-party code, e.g. with rest.li. But if people here are interested, we
could explore ways to enhance it, make it more abstract and generic,
perhaps even use it somehow along with the archetype builders that are
being discussed through this thread.

In general, we are open to ideas and willing to contribute.

Cheers,
Michael


On Fri, Apr 24, 2015 at 2:39 PM, Jiri Jetmar <juergen.jetmar@gmail.com>
wrote:

> We are surely willing to donate it - its a way to say thank you to the
> Qi4j/Apache Zest
> Community. :-)
>
> Ok, the Tower code was mostly written by Michael Pantazoglou so I need to
> talk with him
> what would be the best approach to donate it. I guess we have to solve some
> dependencies and some package naming stuff, etc.
>
> @Michael - could you pls take the lead here and discuss with me and the
> Apache Zest
> community the best best approach to donate the code, clean the
> dependencies, etc ?
>
> Thank you.
>
> Cheers,
> Jiri
>
>
> 2015-04-24 13:15 GMT+02:00 Niclas Hedhman <niclas@hedhman.org>:
>
> > Maybe. I am not sure, until I see some more details. Are you willing to
> > donate it?
> >
> > I want to see that one can create Qi4j applications, where I list what
> > layers, modules and (ready-made) assemblers I want. And literally have a
> > fully-structured, Restful HelloWorld running in 1 minute, complete with
> > build system and a re-usable 'model'.
> >
> > Tower might be useful, I would like to know more...
> >
> >
> > Welcome back, Jiri.
> >
> > On Fri, Apr 24, 2015 at 6:34 PM, Jiri Jetmar <juergen.jetmar@gmail.com>
> > wrote:
> >
> > > Hi Guys,
> > >
> > > we did in the past something similar to structure & deploy our Qi4j
> Apps.
> > > We are using the Term "Tower"
> > > that contains all relevant components to deliver a service to the
> client.
> > >
> > > This components are :
> > >
> > > - (State Model) - Domain Model describes the possible states of a
> > solution.
> > > It also exposes a DM API that is used by above layers.
> > > -  (Behavioral Model) - Context, Roles
> > > - (Interaction Model) Service REST API. We are using here
> > http://rest.li/
> > > - Configuration & Bootstrapping (e.g. initial Data)
> > > - (Infrastructure) EntityStore + Index, Logging (Fluentd setup),
> > Monitoring
> > > - (Deployment) Docker based approach to "bake" docker images
> > > - Gradle based approach to glue, structure & automate the above
> approach
> > > and steps
> > >
> > > The whole approach is like to peel an onion :
> > >
> > > Hardware > OS > Docker > App > Tower(s) > Qi4j Modules and layers
> > >
> > > It took as a while to bring all the stuff working together but now it
> is
> > > pretty robust and it is
> > > fun to use it..
> > >
> > > I;m not sure Niclas if this  goes to the direction you are thinking on
> -
> > I
> > > mean in
> > > terms of simplifying and decreasing the entry level for future Qi4j
> > > hackers. We needed
> > > an approach to push Qi4j-based Apps to production in a robust,
> automated
> > > and
> > > easy way.
> > >
> > > Thank you.
> > >
> > > Cheers,
> > > Jiri
> > >
> > >
> > >
> > > 2015-04-24 5:16 GMT+02:00 Niclas Hedhman <niclas@hedhman.org>:
> > >
> > > > Gang,
> > > > After the presentation in Romania, one of the feedbacks received was
> > that
> > > > 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
> > much
> > > > 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
> > IntelliJ
> > > > 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
> > projects
> > > >   * 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?
> > > >
> > > > Cheers
> > > > --
> > > > Niclas Hedhman, Software Developer
> > > > http://zest.apache.org/qi4j <http://www.qi4j.org> - New Energy for
> > Java
> > > >
> > >
> >
> >
> >
> > --
> > Niclas Hedhman, Software Developer
> > http://zest.apache.org/qi4j <http://www.qi4j.org> - New Energy for Java
> >
>

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