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 2015/04/24 05:16:47 UTC
Application Code Management tool
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
Re: Application Code Management tool
Posted by Niclas Hedhman <ni...@hedhman.org>.
Had a quick look at the links... LazyBones seems like useful enough for now.
I will look into the details.
Thanks
On Fri, Apr 24, 2015 at 9:54 PM, Paul Merlin <pa...@nosphere.org> wrote:
> Paul Merlin a écrit :
> > 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.
> Mixing Groovy & Java altogether is painless.
> In fact, Gradle plugins can be written in Java.
> Most of the official ones are !
>
>
--
Niclas Hedhman, Software Developer
http://zest.apache.org/qi4j <http://www.qi4j.org> - New Energy for Java
Re: Application Code Management tool
Posted by Paul Merlin <pa...@nosphere.org>.
Paul Merlin a écrit :
> 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.
Mixing Groovy & Java altogether is painless.
In fact, Gradle plugins can be written in Java.
Most of the official ones are !
Re: Application Code Management tool
Posted by Paul Merlin <pa...@nosphere.org>.
Niclas Hedhman a écrit :
> 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
:-)
About assembly and language support. We have ApplicationBuilder that,
thanks to J8 lambdas is pretty comfy to use from pure Java. Should be
pretty nice from groovy/scala too. More idiomatic assembly plumbing
should then be put in language support modules. In 3.0 we shall work on
more J8 idiomatic assembly leveraging lambdas.
I don't like the idea that the tool that aim to ease Qi4j usage could
force users to use something else than Java.
Focusing on the "it's hard to start with Qi4j, to setup a working
project etc...". Templating + generators seems like a good choice.
Looking for inspiration in other ecosystems I found:
- https://github.com/pledbrook/lazybones
- https://github.com/n8han/giter8
- https://github.com/yeoman/yeoman
LazyBones is the closest to Qi4j as it's Gradle based. But don't support
"after initial generation generators". Not sure if they are needed to
help the community bootstrap with Qi4j development tough.
Using an approach similar to theses tools, or simply reusing one of
them, could allow us to provide a few officially supported project
templates/skeletons/whatever-the-name and provide a paved way to produce
others to the community.
Unsure, but I hope this helps making your head stop spinning :)
Cheers
/Paul
Re: Application Code Management tool
Posted by Niclas Hedhman <ni...@hedhman.org>.
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 <pa...@nosphere.org> wrote:
> Niclas Hedhman a écrit :
> > 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?
> 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 once.
>
> For me that's a tricky part. But maybe you have something in mind?
>
>
> Sandro Martini a écrit :
> > 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
>
>
>
--
Niclas Hedhman, Software Developer
http://zest.apache.org/qi4j <http://www.qi4j.org> - New Energy for Java
Re: Application Code Management tool
Posted by Paul Merlin <pa...@nosphere.org>.
Niclas Hedhman a écrit :
> 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?
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 once.
For me that's a tricky part. But maybe you have something in mind?
Sandro Martini a écrit :
> 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
Re: Application Code Management tool
Posted by Niclas Hedhman <ni...@hedhman.org>.
Had a quick look, and although there are a few things that I don't like, I
would like to focus on the "Intent" and agree that it would be good if
there is an essence of a generic scaffold here. The code is, after all,
just an implementation detail (those of you who hasn't been around since
the start, the Qi4j Core is on its 4th complete rewrite), and don't feel
offended if we are ending up far from the current position.
So a "Domain Capability" is a end-to-end application stack, complete with
stores/index/config at the bottom and service/http layer at top?? And each
DC is self-deployable?
What is a "Block" more precisely? It seems to be one layer, or possibly
multiple layers, no sure...
My guess is that the REST part here is the central point of abstraction,
and that is pretty cool on one hand, but we would need to make the REST
aspect a generic abstraction.
Thinking out loud (assuming I am getting the main point of Tower);
Tower.forCapabilityClass( RestApplication.class ) // defines layers and
major scaffolding
.onPort( HTTP_PORT ) // Type-safe from the RestApplication generic
.addBlock( Timetables.class ) // RestApplication needs a super type
with DSL in it
.using( new InMemoryEntityStore() ) // Why not ordinary Assemblers?
.using( new ElasticSearchMemoryIndexing() ).identifiedBy(
"elasticsearch" )
.start( Application.Mode.test );
public class RestApplication extends CapabilityClass
{
public RestApplication onPort( int port )
{
this.port = port;
}
@Layer( "connectivity" )
@UsesLayers( { "domain", "security" } )
public class ConnectivityLayer
{
@Module( "rest" )
public void onStart( ModuleAssembly assembly )
{
}
}
}
>From the above, another idea struck; What happens if one can define the
application structure as a single interface;
@Application
public interface MyApplication
{
@Layer
@Uses( ServiceLayer.class )
interface ConnectivityLayer
{
@Module
@Assemblers( { RestliAssembler.class, JettyAssembler.class } )
interface RestModule {}
}
@Layer
@Uses(DomainLayer.class)
@Assemblers( DynamicServicesAssembler.class ) // in case the modules
are
// not known until
runtime
interface ServiceLayer{}
@Layer
interface DomainLayer{}
:
:
}
And pass that to the ApplicationAssemblyFactory, or even a wrapper around
the whole thing at a higher level. That could actually be very useful
starting point. Of course the devil is in the details, but by avoid
replicating Assembly constructs (as current Tower does to some extent) we
might not need to sacrifice the power of flexibility, yet get something
easier to comprehend initially.
Cheers
On Sat, May 2, 2015 at 5:43 PM, Michael Pantazoglou <
michael.pantazoglou@gmail.com> wrote:
> Hi Niclas, all,
>
> I set up a temp repo in Github to share the code for this Tower utility.
>
> https://github.com/michaelpantazoglou/smartnerds-tower
>
> Unfortunately the code is not build-able, as it depends on some additional
> artefacts, but hopefully it will give you a better idea of what its
> functionality is intended for.
>
> We are using Tower extensively in our JUnit test cases in order to quickly
> assemble and launch a Qi4j app with all needed composites etc. An example
> is as follows:
>
> @Before
> public void setUp() throws Exception {
>
> tower = SmartnerdsTower.newInstance(Application.Mode.test);
>
> tower.addDomainCapabilityBlock(SmartnerdsCatalogue.DomainCapability.Timetables,
> SmartnerdsTowerConstants.DEFAULT_CONFIGURATION_PROPERTIES,
> SmartnerdsCatalogue.EntityStore.Memory,
> SmartnerdsTowerConstants.DEFAULT_CONFIGURATION_PROPERTIES,
> SmartnerdsCatalogue.EntityIndex.ElasticSearchInMemory,
> SmartnerdsTowerConstants.DEFAULT_CONFIGURATION_PROPERTIES
> ).start(HTTP_PORT);
>
> module =
> tower.getModule(SmartnerdsCatalogue.DomainCapability.Timetables.getId());
>
> restLiClient = RestLiClient.Factory.createRetLiClient(HTTP_HOST,
> HTTP_PORT);
> }
>
> @After
> public void tearDown() throws Exception {
>
> restLiClient.shutdown();
> tower.stop();
> }
>
> Here we start a Tower in test mode, hosting one Domain Capability. A Tower
> can host as many blocks as needed. For each such block, the following
> parameters are expected:
>
> 1) Domain Capability Id: This reference is used to retrieve details about
> the capability from an internal catalogue, where we register all
> capabilities. Those details include the Capability assembler, and the
> resource packages that rest.li will look into to deploy the capability's
> REST API.
>
> 2) Capability Config Properties: This is the name of the (optional)
> .properties file that is used to configure the capability (not all
> capabilities require configuration, but some do)
>
> 3) Entity Store Id: Again, this reference is used to retrieve the assembler
> of the entity store that this capability will use. Note that, we are using
> again our internal catalogue, where we register each ES for which we have
> an assembler.
>
> 4) Entity Store Config Properties: The name of the (optional) .properties
> file that may be required in order to configure the ES (e.g. see PostgreSQL
> ES)
>
> 5) Entity Index Id: Similar semantics like 3), but applies to the EI
>
> 6) Entity Index Config Properties: Similar semantics like 4), but applies
> to the EI
>
> The .start(HTTP_PORT) simply starts the rest.li server that will offer the
> REST API of that capability through the specified port.
>
> * * *
>
> So with this utility we can easily assemble and deploy as many building
> blocks as required by a particular use case, and we can easily configure
> different sets of ES/EI infrastructure to be used by each building block
> independently. We can even use many Tower instances on the same JVM to
> provision parts of our system through different ports, configurations, etc.
>
> From our point of view, it would be great if, out of this custom piece of
> code, we could derive an independent, generic mechanism that would help any
> entry-level Qi4j developer get their code up and running fast - hence make
> them feel the Zest! :-)
>
> Cheers,
> Michael
>
>
> On Tue, Apr 28, 2015 at 2:48 AM, Niclas Hedhman <ni...@hedhman.org>
> wrote:
>
> > Michael,
> > This sounds really cool, and the kind of innovation that I was hoping
> Qi4j
> > would enable when we set out on this long and bumpy journey. There is
> > definitely a lot of generic value here, and I think we just need to get a
> > deeper understanding exactly what it is.
> >
> > So, what are those five parameters in addBlock() ?? Is it an arbitrary
> list
> > of Assemblers, or something very specific in each?
> >
> > I would like to suggest;
> > If you could post the relevant API or sources somewhere, I would like to
> > take a deeper look. For me, I don't need it to be "pretty" and be
> > buildable... (You guys should have seen what Rickard sent me pre-Qi4j
> that
> > became the starting point for this project's initial steps.)
> >
> > Unless you have some IP Rights issues, just create a "temporary" repo on
> > GitHub, and I (hopefully others) will take a closer look.
> >
> >
> > Looking forward to something new and exciting.
> >
> >
> > // Niclas
> >
> > On Tue, Apr 28, 2015 at 3:55 AM, Michael Pantazoglou <
> > michael.pantazoglou@gmail.com> wrote:
> >
> > > 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 <ni...@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 <ni...@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
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > 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
Re: Application Code Management tool
Posted by Michael Pantazoglou <mi...@gmail.com>.
Hi Niclas, all,
I set up a temp repo in Github to share the code for this Tower utility.
https://github.com/michaelpantazoglou/smartnerds-tower
Unfortunately the code is not build-able, as it depends on some additional
artefacts, but hopefully it will give you a better idea of what its
functionality is intended for.
We are using Tower extensively in our JUnit test cases in order to quickly
assemble and launch a Qi4j app with all needed composites etc. An example
is as follows:
@Before
public void setUp() throws Exception {
tower = SmartnerdsTower.newInstance(Application.Mode.test);
tower.addDomainCapabilityBlock(SmartnerdsCatalogue.DomainCapability.Timetables,
SmartnerdsTowerConstants.DEFAULT_CONFIGURATION_PROPERTIES,
SmartnerdsCatalogue.EntityStore.Memory,
SmartnerdsTowerConstants.DEFAULT_CONFIGURATION_PROPERTIES,
SmartnerdsCatalogue.EntityIndex.ElasticSearchInMemory,
SmartnerdsTowerConstants.DEFAULT_CONFIGURATION_PROPERTIES
).start(HTTP_PORT);
module = tower.getModule(SmartnerdsCatalogue.DomainCapability.Timetables.getId());
restLiClient = RestLiClient.Factory.createRetLiClient(HTTP_HOST, HTTP_PORT);
}
@After
public void tearDown() throws Exception {
restLiClient.shutdown();
tower.stop();
}
Here we start a Tower in test mode, hosting one Domain Capability. A Tower
can host as many blocks as needed. For each such block, the following
parameters are expected:
1) Domain Capability Id: This reference is used to retrieve details about
the capability from an internal catalogue, where we register all
capabilities. Those details include the Capability assembler, and the
resource packages that rest.li will look into to deploy the capability's
REST API.
2) Capability Config Properties: This is the name of the (optional)
.properties file that is used to configure the capability (not all
capabilities require configuration, but some do)
3) Entity Store Id: Again, this reference is used to retrieve the assembler
of the entity store that this capability will use. Note that, we are using
again our internal catalogue, where we register each ES for which we have
an assembler.
4) Entity Store Config Properties: The name of the (optional) .properties
file that may be required in order to configure the ES (e.g. see PostgreSQL
ES)
5) Entity Index Id: Similar semantics like 3), but applies to the EI
6) Entity Index Config Properties: Similar semantics like 4), but applies
to the EI
The .start(HTTP_PORT) simply starts the rest.li server that will offer the
REST API of that capability through the specified port.
* * *
So with this utility we can easily assemble and deploy as many building
blocks as required by a particular use case, and we can easily configure
different sets of ES/EI infrastructure to be used by each building block
independently. We can even use many Tower instances on the same JVM to
provision parts of our system through different ports, configurations, etc.
>From our point of view, it would be great if, out of this custom piece of
code, we could derive an independent, generic mechanism that would help any
entry-level Qi4j developer get their code up and running fast - hence make
them feel the Zest! :-)
Cheers,
Michael
On Tue, Apr 28, 2015 at 2:48 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> Michael,
> This sounds really cool, and the kind of innovation that I was hoping Qi4j
> would enable when we set out on this long and bumpy journey. There is
> definitely a lot of generic value here, and I think we just need to get a
> deeper understanding exactly what it is.
>
> So, what are those five parameters in addBlock() ?? Is it an arbitrary list
> of Assemblers, or something very specific in each?
>
> I would like to suggest;
> If you could post the relevant API or sources somewhere, I would like to
> take a deeper look. For me, I don't need it to be "pretty" and be
> buildable... (You guys should have seen what Rickard sent me pre-Qi4j that
> became the starting point for this project's initial steps.)
>
> Unless you have some IP Rights issues, just create a "temporary" repo on
> GitHub, and I (hopefully others) will take a closer look.
>
>
> Looking forward to something new and exciting.
>
>
> // Niclas
>
> On Tue, Apr 28, 2015 at 3:55 AM, Michael Pantazoglou <
> michael.pantazoglou@gmail.com> wrote:
>
> > 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 <ju...@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 <ni...@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 <ni...@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
> > > >
> > >
> >
>
>
>
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org/qi4j <http://www.qi4j.org> - New Energy for Java
>
Re: Application Code Management tool
Posted by Niclas Hedhman <ni...@hedhman.org>.
Michael,
This sounds really cool, and the kind of innovation that I was hoping Qi4j
would enable when we set out on this long and bumpy journey. There is
definitely a lot of generic value here, and I think we just need to get a
deeper understanding exactly what it is.
So, what are those five parameters in addBlock() ?? Is it an arbitrary list
of Assemblers, or something very specific in each?
I would like to suggest;
If you could post the relevant API or sources somewhere, I would like to
take a deeper look. For me, I don't need it to be "pretty" and be
buildable... (You guys should have seen what Rickard sent me pre-Qi4j that
became the starting point for this project's initial steps.)
Unless you have some IP Rights issues, just create a "temporary" repo on
GitHub, and I (hopefully others) will take a closer look.
Looking forward to something new and exciting.
// Niclas
On Tue, Apr 28, 2015 at 3:55 AM, Michael Pantazoglou <
michael.pantazoglou@gmail.com> wrote:
> 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 <ju...@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 <ni...@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 <ni...@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
> > >
> >
>
--
Niclas Hedhman, Software Developer
http://zest.apache.org/qi4j <http://www.qi4j.org> - New Energy for Java
Re: Application Code Management tool
Posted by Michael Pantazoglou <mi...@gmail.com>.
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 <ju...@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 <ni...@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 <ju...@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 <ni...@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
> >
>
Re: Application Code Management tool
Posted by Jiri Jetmar <ju...@gmail.com>.
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 <ni...@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 <ju...@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 <ni...@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
>
Re: Application Code Management tool
Posted by Niclas Hedhman <ni...@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 <ju...@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 <ni...@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
Re: Application Code Management tool
Posted by Jiri Jetmar <ju...@gmail.com>.
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 <ni...@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
>
Re: Application Code Management tool
Posted by Niclas Hedhman <ni...@hedhman.org>.
No, it is just a guidance principle, where we do/use whatever suits us and
not what other people do/use.
In a way, what you are suggesting would "prevent innovation" since no one
would ever use something new. ;-) We would still all be on the single
Mainframe that rules the world...
And personally, I am seldom upset with Gradle, and Maven often breaks
expectations in larger projects. Maven's main feature is to get started
quickly, but Gradle is sort of beating Maven at that too.
Anyway, we won't move back to Maven for the build system. That would
require some outstanding argument. And for this tool about getting started
with Qi4j, I do want to support (eventually) that people can generate Maven
or Gradle (possibly others) projects for themselves, and I just realized
that this is probably what you are arguing for...
On Sat, Apr 25, 2015 at 8:15 AM, James Carman <ja...@carmanconsulting.com>
wrote:
> So, your build tool would have prevented innovation?
> On Fri, Apr 24, 2015 at 8:09 PM Niclas Hedhman <ni...@hedhman.org> wrote:
>
> > We had this discussion 4-5 years ago.... Qi4j wouldn't exist if we wanted
> > "mainstream and supported" ;-) LOL
> >
> >
> >
> > On Sat, Apr 25, 2015 at 7:30 AM, James Carman <
> james@carmanconsulting.com>
> > wrote:
> >
> > > I would recommend against gradle. Maven is far more mainstream and
> > > supported.
> > > On Fri, Apr 24, 2015 at 7:20 PM Niclas Hedhman <ni...@hedhman.org>
> > wrote:
> > >
> > > > Yeah, Gradle is awesome, and I ran into Hans Dockter back in 2009 and
> > > after
> > > > 4 days in the same room (DDD Immersion course), he got me convinced
> > and I
> > > > think Qi4j moved to Gradle in 2010...
> > > >
> > > > On Sat, Apr 25, 2015 at 2:02 AM, Roman Shaposhnik <
> > roman@shaposhnik.org>
> > > > wrote:
> > > >
> > > > > On Fri, Apr 24, 2015 at 12:59 AM, Sandro Martini
> > > > > <sa...@gmail.com> wrote:
> > > > > > Hi Niclas,
> > > > > > I think it's a good idea, Gradle is really a powerful tool !!
> > > > >
> > > > > A comment from a peanut gallery: I can't recommend Gradle
> > > > > highly enough.
> > > > >
> > > > > > 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 ...
> > > > >
> > > > > That's what I was thinking (without being able to commit to
> actually
> > > > > doing anything along these lines :-().
> > > > >
> > > > > Thanks,
> > > > > Roman.
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > 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
> >
>
--
Niclas Hedhman, Software Developer
http://zest.apache.org/qi4j <http://www.qi4j.org> - New Energy for Java
Re: Application Code Management tool
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Sat, Apr 25, 2015 at 4:51 PM, James Carman
<ja...@carmanconsulting.com> wrote:
> Yeah that seems to be a common gripe folks have, but the structured nature
> of the pom.xml file is what allows folks to implement support for Maven
> very easily. The IDE support for Maven is pretty good across the board.
Note that Gradle's declarative DSL could be maintained as rigidly as POM.
That of course would require developer discipline since DSL is just one short
step removed from full fledged Groovy.
Thanks,
Roman.
Re: Application Code Management tool
Posted by Niclas Hedhman <ni...@hedhman.org>.
Although we are off-topic, let me challenge common perception that the POM
is easily supported.
Without using the Maven POM parser (is that the one called Atheros?) and
using the resulting Java-level model, the 3rd party is doomed to get the
implied behaviors slightly wrong. There are far too many edge cases to get
wrong.
So, there is no difference between running the Maven parser or running the
Gradle "parser", and in both cases you get a Java-based model back. But
here is the distinction; Gradle has spent a lot more effort to define the
semantics of that model than Maven ever did, especially for multi-module
builds, builds with multiple artifact outputs or builds with advanced
publishing workflows (have they fixed the Maven Release plugin yet??)
I therefor conclude, that the premise of "implement support for Maven very
easily" is misleading, and it is even fallacious to think that "I can parse
the XML myself" for anything but the most trivial POMs.
That said; I was a strong proponent of Maven once upon a time, and the idea
of a "project model" (which may have originated there, I am not sure) is a
very powerful one, which I fully embrace. But models without strong
semantics on behavior are weak models, and Gradle has brought the project
model to the next level. And I am convinced that Gradle will continue to
gain momentum across the board, and eventually beat Maven to the dust on
all fronts.
// Cheers
Niclas
On Sun, Apr 26, 2015 at 7:51 AM, James Carman <ja...@carmanconsulting.com>
wrote:
> Yeah that seems to be a common gripe folks have, but the structured nature
> of the pom.xml file is what allows folks to implement support for Maven
> very easily. The IDE support for Maven is pretty good across the board.
> On Sat, Apr 25, 2015 at 7:48 PM Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
>
> > On Fri, Apr 24, 2015 at 5:33 PM, James Carman
> > <ja...@carmanconsulting.com> wrote:
> > > I don't like gradle because people get too cute with it. Then it takes
> > > forever to figure out what the hell the build does. Maven's opinionated
> > > nature makes it easier to just jump right in and get to work.
> >
> > I hear you. I guess I just hate XML ;-)
> >
> > Thanks,
> > Roman.
> >
>
--
Niclas Hedhman, Software Developer
http://zest.apache.org/qi4j <http://www.qi4j.org> - New Energy for Java
Re: Application Code Management tool
Posted by James Carman <ja...@carmanconsulting.com>.
Yeah that seems to be a common gripe folks have, but the structured nature
of the pom.xml file is what allows folks to implement support for Maven
very easily. The IDE support for Maven is pretty good across the board.
On Sat, Apr 25, 2015 at 7:48 PM Roman Shaposhnik <ro...@shaposhnik.org>
wrote:
> On Fri, Apr 24, 2015 at 5:33 PM, James Carman
> <ja...@carmanconsulting.com> wrote:
> > I don't like gradle because people get too cute with it. Then it takes
> > forever to figure out what the hell the build does. Maven's opinionated
> > nature makes it easier to just jump right in and get to work.
>
> I hear you. I guess I just hate XML ;-)
>
> Thanks,
> Roman.
>
Re: Application Code Management tool
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Fri, Apr 24, 2015 at 5:33 PM, James Carman
<ja...@carmanconsulting.com> wrote:
> I don't like gradle because people get too cute with it. Then it takes
> forever to figure out what the hell the build does. Maven's opinionated
> nature makes it easier to just jump right in and get to work.
I hear you. I guess I just hate XML ;-)
Thanks,
Roman.
Re: Application Code Management tool
Posted by James Carman <ja...@carmanconsulting.com>.
I don't like gradle because people get too cute with it. Then it takes
forever to figure out what the hell the build does. Maven's opinionated
nature makes it easier to just jump right in and get to work.
On Fri, Apr 24, 2015 at 8:31 PM Roman Shaposhnik <ro...@shaposhnik.org>
wrote:
> On Fri, Apr 24, 2015 at 5:15 PM, James Carman
> <ja...@carmanconsulting.com> wrote:
> > So, your build tool would have prevented innovation?
>
> See that's where the miscommunication lies: to me Gradle is not a build
> tool. It is a workflow automation tool. Maven on the other hand is totally
> a build tool. But! I've got more things to worry about in my workflows than
> just building stuff. Hence Maven doesn't really cut it. At least for me.
>
> Thanks,
> Roman.
>
Re: Application Code Management tool
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Fri, Apr 24, 2015 at 5:15 PM, James Carman
<ja...@carmanconsulting.com> wrote:
> So, your build tool would have prevented innovation?
See that's where the miscommunication lies: to me Gradle is not a build
tool. It is a workflow automation tool. Maven on the other hand is totally
a build tool. But! I've got more things to worry about in my workflows than
just building stuff. Hence Maven doesn't really cut it. At least for me.
Thanks,
Roman.
Re: Application Code Management tool
Posted by James Carman <ja...@carmanconsulting.com>.
So, your build tool would have prevented innovation?
On Fri, Apr 24, 2015 at 8:09 PM Niclas Hedhman <ni...@hedhman.org> wrote:
> We had this discussion 4-5 years ago.... Qi4j wouldn't exist if we wanted
> "mainstream and supported" ;-) LOL
>
>
>
> On Sat, Apr 25, 2015 at 7:30 AM, James Carman <ja...@carmanconsulting.com>
> wrote:
>
> > I would recommend against gradle. Maven is far more mainstream and
> > supported.
> > On Fri, Apr 24, 2015 at 7:20 PM Niclas Hedhman <ni...@hedhman.org>
> wrote:
> >
> > > Yeah, Gradle is awesome, and I ran into Hans Dockter back in 2009 and
> > after
> > > 4 days in the same room (DDD Immersion course), he got me convinced
> and I
> > > think Qi4j moved to Gradle in 2010...
> > >
> > > On Sat, Apr 25, 2015 at 2:02 AM, Roman Shaposhnik <
> roman@shaposhnik.org>
> > > wrote:
> > >
> > > > On Fri, Apr 24, 2015 at 12:59 AM, Sandro Martini
> > > > <sa...@gmail.com> wrote:
> > > > > Hi Niclas,
> > > > > I think it's a good idea, Gradle is really a powerful tool !!
> > > >
> > > > A comment from a peanut gallery: I can't recommend Gradle
> > > > highly enough.
> > > >
> > > > > 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 ...
> > > >
> > > > That's what I was thinking (without being able to commit to actually
> > > > doing anything along these lines :-().
> > > >
> > > > Thanks,
> > > > Roman.
> > > >
> > >
> > >
> > >
> > > --
> > > 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
>
Re: Application Code Management tool
Posted by Niclas Hedhman <ni...@hedhman.org>.
We had this discussion 4-5 years ago.... Qi4j wouldn't exist if we wanted
"mainstream and supported" ;-) LOL
On Sat, Apr 25, 2015 at 7:30 AM, James Carman <ja...@carmanconsulting.com>
wrote:
> I would recommend against gradle. Maven is far more mainstream and
> supported.
> On Fri, Apr 24, 2015 at 7:20 PM Niclas Hedhman <ni...@hedhman.org> wrote:
>
> > Yeah, Gradle is awesome, and I ran into Hans Dockter back in 2009 and
> after
> > 4 days in the same room (DDD Immersion course), he got me convinced and I
> > think Qi4j moved to Gradle in 2010...
> >
> > On Sat, Apr 25, 2015 at 2:02 AM, Roman Shaposhnik <ro...@shaposhnik.org>
> > wrote:
> >
> > > On Fri, Apr 24, 2015 at 12:59 AM, Sandro Martini
> > > <sa...@gmail.com> wrote:
> > > > Hi Niclas,
> > > > I think it's a good idea, Gradle is really a powerful tool !!
> > >
> > > A comment from a peanut gallery: I can't recommend Gradle
> > > highly enough.
> > >
> > > > 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 ...
> > >
> > > That's what I was thinking (without being able to commit to actually
> > > doing anything along these lines :-().
> > >
> > > Thanks,
> > > Roman.
> > >
> >
> >
> >
> > --
> > 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
Re: Application Code Management tool
Posted by James Carman <ja...@carmanconsulting.com>.
I would recommend against gradle. Maven is far more mainstream and
supported.
On Fri, Apr 24, 2015 at 7:20 PM Niclas Hedhman <ni...@hedhman.org> wrote:
> Yeah, Gradle is awesome, and I ran into Hans Dockter back in 2009 and after
> 4 days in the same room (DDD Immersion course), he got me convinced and I
> think Qi4j moved to Gradle in 2010...
>
> On Sat, Apr 25, 2015 at 2:02 AM, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
>
> > On Fri, Apr 24, 2015 at 12:59 AM, Sandro Martini
> > <sa...@gmail.com> wrote:
> > > Hi Niclas,
> > > I think it's a good idea, Gradle is really a powerful tool !!
> >
> > A comment from a peanut gallery: I can't recommend Gradle
> > highly enough.
> >
> > > 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 ...
> >
> > That's what I was thinking (without being able to commit to actually
> > doing anything along these lines :-().
> >
> > Thanks,
> > Roman.
> >
>
>
>
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org/qi4j <http://www.qi4j.org> - New Energy for Java
>
Re: Application Code Management tool
Posted by Niclas Hedhman <ni...@hedhman.org>.
Yeah, Gradle is awesome, and I ran into Hans Dockter back in 2009 and after
4 days in the same room (DDD Immersion course), he got me convinced and I
think Qi4j moved to Gradle in 2010...
On Sat, Apr 25, 2015 at 2:02 AM, Roman Shaposhnik <ro...@shaposhnik.org>
wrote:
> On Fri, Apr 24, 2015 at 12:59 AM, Sandro Martini
> <sa...@gmail.com> wrote:
> > Hi Niclas,
> > I think it's a good idea, Gradle is really a powerful tool !!
>
> A comment from a peanut gallery: I can't recommend Gradle
> highly enough.
>
> > 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 ...
>
> That's what I was thinking (without being able to commit to actually
> doing anything along these lines :-().
>
> Thanks,
> Roman.
>
--
Niclas Hedhman, Software Developer
http://zest.apache.org/qi4j <http://www.qi4j.org> - New Energy for Java
Re: Application Code Management tool
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Fri, Apr 24, 2015 at 12:59 AM, Sandro Martini
<sa...@gmail.com> wrote:
> Hi Niclas,
> I think it's a good idea, Gradle is really a powerful tool !!
A comment from a peanut gallery: I can't recommend Gradle
highly enough.
> 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 ...
That's what I was thinking (without being able to commit to actually
doing anything along these lines :-().
Thanks,
Roman.
Re: Application Code Management tool
Posted by Sandro Martini <sa...@gmail.com>.
Hi Niclas,
I think it's a good idea, Gradle is really a powerful tool !!
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 ...
Bye
2015-04-24 5:16 GMT+02:00 Niclas Hedhman <ni...@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