+1 to breaking up code into independently released modules. This would avoid 
tricky builds that re-use the same source files to produce different jars 
containing the same .class files, and it would ensure interdependencies are 
validated by build tooling. This approach would also avoid a “boil the ocean” 
syndrome where nothing can be released until it’s “all done”.

-Dan

From: Peter <j...@zeus.net.au <mailto:j...@zeus.net.au>>
Subject: Re: River revamp
Date: November 12, 2016 at 1:25:49 AM EST
To: dev@river.apache.org <mailto:dev@river.apache.org>


We could make this the basis for a new release, almost as is.  I'd need to 
create some JIRA issues to capture the changes.  This would include Secure 
serialization, which is a step towards secure IoT.

However I'm also tempted to break up the codebase into modules and release each 
separately; a further step along the pathe of the secure IoT theme, from the 
root of the dependency tree.

The qa test suite would remain a separate ant build.

Regards,

Peter.

Reply via email to