polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Merlin <paulmer...@apache.org>
Subject Re: Thoughts on Release 3.0
Date Thu, 13 Jul 2017 16:13:21 GMT
Hey folks,

Niclas Hedhman a écrit :
> 1. Polygene generator doesn't produce functioning projects. It is quite
> close, but there are issues in security and perhaps in Configuration
> handling. I get indexer complaining on restarts that Configuration type is
> not visible and other odd things. Part of the issues is in the generator,
> but I think part of it is problems in at least the SQL Indexer. I suggest
> that we leave out the tools/generator-polygene in the 3.0 release and
> target 3.1 instead.


> 2. Mentioned above; I am suspicious about the SQL Indexer and its "reindex"
> on start up. I have frequent exceptions on that when working on the
> generator, and although one bug was fixed (thanks Stan) I think there are
> others in the type lookup. One hypothesis I have, which is not confirmed,
> is that "Module" is written into the SQL database, which I think is used on
> reindexing, and during reindexing that "Module" field becomes the indexer's
> module, and on the second restart and its indexing things are messed up. I
> suggest that we do not include the SQL indexer in 3.0

@Niclas: could you create an issue with this?

> 3. Paul has previously brought up that Extensions are not unified and
> implements different amounts of features, and it is difficult to know what
> is supported. Solr indexer is a example of something that doesn't support
> much of the Indexing SPI, and is actually addressing a different concern;
> Text Search, which I think should be a separate API in a new Query API
> which I would like to work on for Release 3.2. I suggest that Solr Indexer
> is dropped from 3.0

I'm with Kent on this, the Solr index/query extension has value and its
documentation states clearly what is supported and what is not:
I see no reason to not ship it with 3.0.

> 4. There will soon be a new SQL Entity Store, and I don't think there is
> any point in keeping the existing one. I suggest (and prefer) that it is
> dropped from 3.0, or at least renamed to something like
> entitystore-legacysql

What about entitystore-map-sql instead?
It is a MapEntityStore.
We can deprecate and retire it at some point, but the word "legacy"
makes me itchy.

> 5. Roadmap. Below is what I would like to do and the goals I would like to
> have and willing to work on.
>     July 2017 - Release 3.0
>     Oct 2017 - Release 3.1 : The new SQL Entity Store, Polygene Generator
> and Kotlin showcasing.
>     Jan 2018 - Release 3.2 : New indexing system and new Query API.
>     April 2018 - Release 3.3 : Timeseries support

This makes a lot of sense to me.

I already started on Kotlin and have a library with Kotlin extensions to
the core & bootstrap APIs. I'll push it on a branch right after 3.0 and
some polishing, we'll go from there.

Here are some areas I would like to work on next with the tentative
calendar above in mind:


- Kotlin, see above
- Tooling
    - a suite of Gradle plugins: polygene-library, polygene-extension,
polygene-application .. to make it damn easy to setup the build of
Polygene apps
    - formalize Extensions vs. Features (reporting, documentation, testing?)
    - reinstate checkstyle checks now that it supports Java 8


- Polygene runs on Jigsaw
- Performance testing, some guarantee that we don't introduce
regressions would be awesome
- Performance optimisations (e.g. known hot spots in serialization
fixable once Johnzon supports JSR-374)
- Collaboration on the new indexing system / query api is appealing!
- Don't know yet

I'll start rolling 3.0 during the weekend, or early Monday my-morning.



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