Mailing-List: contact dev-help@zest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zest.apache.org
Received-SPF: pass (nike.apache.org: domain of hedhman@gmail.com designates
 209.85.213.172 as permitted sender)
MIME-Version: 1.0
Sender: hedhman@gmail.com
From: Niclas Hedhman <niclas@hedhman.org>
Date: Fri, 12 Jun 2015 09:35:17 +0800
Message-ID: 
 <CADmm+Kcha1JiCcakNxcdYOzn3YN_ot3NVNFXg_N=UUaGyUZHBw@mail.gmail.com>
Subject: Release Specification flags
To: dev <dev@zest.apache.org>
Content-Type: multipart/alternative; boundary=001a11409d4248eef505184822db

--001a11409d4248eef505184822db
Content-Type: text/plain; charset=UTF-8

Gang,

The following components are failing the Release Specification[1] check of
the build process;

org.qi4j.library.cxf(false) -> beta, none, some
org.qi4j.library.eventsourcing(false) -> beta, none, some
org.qi4j.library.eventsourcing-jdbm(false) -> beta, none, some
org.qi4j.library.eventsourcing-rest(false) -> beta, none, some
org.qi4j.library.lang-scala(false) -> beta, none, some
org.qi4j.library.metrics(false) -> early, none, none
org.qi4j.library.spring(false) -> beta, none, some
org.qi4j.library.struts2-codebehind(false) -> beta, none, some
org.qi4j.library.struts2-convention(false) -> beta, none, some
org.qi4j.library.struts2-plugin(false) -> beta, none, some

Documentation is lacking as the common theme.

To simplify the Source Release of ASF, I would like to get these resolved,
rather than extensive modifications to the build system to exclude them
from the source release, yet have the resulting build system still work.

CXF and Struts --> I suggest that we drop this support. They were
implemented way back in time (pre-1.0 I think), and it is a marvel if
either one still works properly. CXF depends on a really old CXF version,
and they have made large changes in the serialization support there, which
would be required to adjust to. Struts is kind of falling out of fashion,
in favor of SPAs and Rest APIs.

Spring support is desirable, but the library has been largely neglected,
since few people here use Spring. Seems to be a tendency to quickly drop
Spring, once the Qi4j advantage is realized. However, I think it is
important to keep this, and anyone who want to give it enough Love and Care
will earn a "Qi4j Crew" T-shirt in Budapest in Sep/Oct ApacheCon Europe ;-)

Scala support was an experiment that Richard ran, quite successfully.
However, I wonder of the state, since Scala has released 1 or 2
incompatible versions since. But there are testcases, which obviously still
works. Richard posted some notes about this way-back-then, which perhaps
could be converted into documentation. If anyone would take a few hours to
see if latest Scala version works, and write up a little bit what it
supports and can do. After all, it is a single Mixin, and can't be too
complex...

The Metrics Library is all about support to add Metrics to your own
application, utilizing the Metrics SPI present. Since I started that, I
will take a day or so to stabilize that for a release, albeit 'beta' level.

That leaves the Event Sourcing package that Richard made. It is an
elaborate way of leveraging Qi4j to get CQRS and Event Sourcing. In effect,
the command enters a method, which validates the input and then dispatches
an Event which is picked up by a different method within the same Composite
to fulfill it. That dispatch sequence, allows Recording and Playback of
events, which is also included in this package. Anyone who can locate
Richard's explanation and convert that to documentation, also earns a "Qi4j
Crew" T-shirt at Budapest ApacheCon.
This library truly shows the power of Qi4j, and I would hate to take it out
due to lack of documentation.
It also has two submodules, for Rest and JDBM storage. Should look into
what those are and whether we can abstract that into something neater. But
that is not critical at this stage.

WDYT??

Cheers

[1] Each component has a self-assessment XML file which describes its state
in Code, Docs and Tests. The Release Specification is a Gradle task that
reads this and applies a requirement level for a release. We can over time
increase the requirements in small steps and see where work is needed. The
specification is currently set as;

    def satisfied = ( codebase == 'none' && docs == 'complete' && tests !=
'complete' )
    satisfied |= ( codebase == 'early' && ( docs == 'complete' || docs ==
'good') && (tests == 'complete' || tests == 'good' ) )
    satisfied |= ( codebase == 'beta' && (docs == 'complete' || docs ==
'good' || docs == 'brief') && (tests == 'complete' || tests == 'good' ||
tests == 'some') )
    satisfied |= ( codebase == 'stable' )
    satisfied |= ( codebase == 'mature' )

-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

--001a11409d4248eef505184822db--