I agree with Dan, and I attempted this myself many, many years ago, but at that time there were little consensus to go that route.
Although I don't like Maven, because it is very opinionated about everything, I think it is a big, good step in the right direction. Personally, I would go with Gradle, since it is more supple and easier to get to do builds that are not following the Maven model to the letter and far less sensitive to "time" (old Maven builds just stops working after enough time passed, unless a massive list of every plugin used is versioned exactly). Unfortunately, I don't have enough cycles to tackle that in the near future. Cheers Niclas On Wed, Nov 16, 2016 at 9:48 AM, Dan Rollo <danro...@gmail.com> wrote: > +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. > -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java
