+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.