Hi Niclas, pls find my comments below in blue:
2016-12-18 9:54 GMT+01:00 Niclas Hedhman <hedh...@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 voluntary..:-) > > 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 models. 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.jet...@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 > > >