polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jiri Jetmar <juergen.jet...@gmail.com>
Subject Re: Apache Polygene - Future Directions
Date Fri, 30 Dec 2016 14:55:10 GMT
Hi Niclas,

pls find my comments below in blue:

2016-12-18 9:54 GMT+01:00 Niclas Hedhman <hedhman@gmail.com>:

> If I understand your intention (Christmas Wish) correctly, you want to
> marry our pink unicorn with the green monster, or?
:-) Well, not really to marry, but to give Polygene the ability to use what
is already here from the infrastructural building blocks / frameworks and
use our limited (coding) power for something that is unique to Polygene.
The danger is that we keep our self busy with technical issues/topics and
loose the big picture, due to the limitations we are faced with. I

> I am not a Spring addict, and don't want to see a hard dependency on it.

Same here, but Spring is a solid Framework, with lots of helping hands (..
and dollars). Therefore why not to "include" the sugar they are offering ?

> Work to strengthen the spring integration is most welcome, but I think need
> to be handled by someone with more Spring fu than I have.

Jaja, have a similar personal view on this topics. So we need to find a

> Otherwise I think I agree with you. And I think the best way to lower
> barrier are;
> 1. More Yeoman temllating.
> 2. Generation of a Angular front end from a Polygene model, and wiring in
> between.
> 3. Custom classes for Property, Association, ++
> -
This are indeed valuable steps, but I fear that we can not follow the path
to the required destination, as sooner or later we will deal with
technical/infrastructural topics.

> The last one may seem odd. But, I have now gotten push back a couple of
> times that our classes are central in data model classes.

Do you mean our Entity composites ? Independently of that, I see the
top-down approach regarding our data model as problematic. Means we are
expressing the data model in a Polygene Application and "materialise" it to
the underlying repository. Conceptually this is fine, very elegant, but the
point it that data live (Data@Store) usually much longer then the
application. Therefore there must be a way how to interface external data

I personally do not have a clear opinion on it, but would like to
contribute on this when someone with more/deeper understanding & creativity
would give me an advice.

> But people don't
> have a problem with in-house interfaces of the same. And it is probably
> something that could be supported, that people are allowed additional
> interfaces to be used. Have not thought that through completely yet, but
> interesting in its own right.
> Cheers
> Niclas
> On Dec 18, 2016 05:23, "Jiri Jetmar" <juergen.jetmar@gmail.com> wrote:
> > Hi Gang,
> >
> > now after the renaming activity is over (that is surely still ongoing,
> but
> > at least we have a final name and a path), I think it is time
> > to brainstorm about some future directions of Apache Polygene.
> >
> > From my perspective Polygene is a DCI and COP oriented programming
> approach
> > for Java (but not only). COP and DCI
> > takes lessons from the last 30-40 years of programming within the
> > information industry. It is about solving business
> > problems using a pattern that deals with the given complexity in the
> > software itself, but it also considers how humans
> > are solving problems in general, aka the mental model, roles,
> > functions/actions, etc.
> >
> > Now, Apache Polygene has a relatively thin core, a number of extensions
> as
> > well as a number of libraries. That extensions
> > and libraries are dedicated to some infrastructural or technical related
> > problems, e.g. how to connect to a repository X, ..
> >
> > We are now living in very interesting times, where lot of pretty cool
> > things happens. E.g. all the "Cloud" related things that allows nearly
> > endless scalability. Or the docker/rocket thing, that brings the
> > infrastructure on the level of code. Indeed very interesting.
> > But, at the end - why do we code ? Its about solving some problems, its
> not
> > about to deal with infrastructural, technical
> > or other things. Indeed, this things has to be solved as well, but this
> are
> > a kind of "sub-problems", we code to solve some (business-) problems.
> >
> > Therefore I;m asking my self since a couple of months, where we should go
> > with Polygene.
> >
> > Looking on the Java land, I see there Frameworks like JEE (somebody is
> > still using it??) or the green monster - aka Spring.. :-)
> > Pls do not understand me wrong, I somehow like Spring. It becomes with
> > years pretty huge and now you need a Framework for
> > the Framework to make it maintainable (Spring Boot). At the end Spring
> is a
> > DI thing, so something technical. The respectable
> > Spring Ecosystem is huge, it offers lot of building blocks to solve
> > technical and infrastructural problems..  and the company
> > behind it, is well funded :-)
> >
> > Again, why do we code ? Well yes, to solve problems, not to deal with
> > technical/infrastructural challenges as a primary goal.
> >
> > There is Christmas soon and if I would have some free wishes, I would
> like
> > to have a Java Framework that solves purely (business) problems,
> > that interacts smoothly with the technical solutions, implemented by the
> > Spring guys. Spring is well funded, they are doing a good job in solving
> > all sorts of infrastructural things, but Spring is NOT the right
> Framework
> > to solve business problems. Disclaimer - it is my own opinion, feel
> > free to argue in a different way. For me Spring is a abstraction of an
> > abstraction and at the end a POJO thing and with some DI. As we learned,
> > POJOs are not enough to solve problems we are facing in the real world.
> >
> > So imagine Apache Polygene will be the *missing* business stack that Java
> > is still lacking and is capable to interact with Spring to include
> > all sorts of already available Spring building blocks - that would be
> > really great and definitely a unique thing.
> >
> > Cheers,
> > Jiri
> >

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