Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (athena.apache.org: domain of dennis.reedy@gmail.com
 designates 209.85.213.41 as permitted sender)
MIME-Version: 1.0
Date: Tue, 29 Apr 2014 20:02:57 -0400
Message-ID: 
 <CAJuA6A5cQ5fx9jZT5A4R=-6b1NAh-izpvREzFSK9ggBQvDOzCg@mail.gmail.com>
Subject: Modularization
From: Dennis Reedy <dennis.reedy@gmail.com>
To: "dev@river.apache.org" <dev@river.apache.org>
Content-Type: multipart/alternative; boundary=20cf3010e5b15b77e304f8374589

--20cf3010e5b15b77e304f8374589
Content-Type: text/plain; charset=UTF-8

I've been working on creating a modular version of the project in the
qa_refactor branch. The approach I've taken is to develop a Groovy script
to load existing River jars, iterate through the contents of each jar, and
copy sources to a multi-module project. The basic assumption with the
multi-module project is that each module produces one jar.

If you checkout qa_refactor, go to the modularize directory and run
ModularizeRiver.groovy (you'll need groovy in your path). This will
populate the source tree into the multi-module project, reading each jar
for it's contents, placing PREFERRED.LIST and any META-INF/service files
into their correct location for inclusion into respective jars. I've also
taken care to not duplicate classes across modules.

I've taken the initial approach to use Maven, and once the multi-module
project is populated with source (using ModularizeRiver.groovy), you can cd
into it and run mvn install to produce a release that is in the
apache-river/dist/target/apache-river-3.0-SNAPSHOT directory.

A this point I'm soliciting opinions and thoughts. Note that using Gradle
is certainly an option here, the breakout into multi-modules is not tied to
Maven, it's based on accepted conventions. I chose Maven because it was the
quickest (for me) to get going.

I've included *most* of the River platform and services. I haven't gotten
around to others based simply on time. This is an experiment, it's located
in skunk/qa_refactor, and may help us think a little more about what River
The multi-module project might look like.

I do want to note, that this currently fixes absolutely nothing. There is
nothing wrong with the current River build. This simply offers a different
way of structuring River, using a multi-module project, where each module
reflects the basic architectural element of a distributed system.

Regards

Dennis

--20cf3010e5b15b77e304f8374589--