[Accelutils-devel] Breaking up pvmanager into submodules - things learned

[Carcassi, G. <car...@bn...>]

Hi all,

I finished the first big chunk of breaking up pvmanager from a single library to multiple modules. The build was successful:
https://openepics.ci.cloudbees.com/job/pvManager%20-%20Build/83/

There are some cool things in both maven and Jenkins, so I thought I'd share.

First of all, as you can see from the build, the build is one and the Jenkins job is one, even though there are 9 modules (core, extra, jca, loc, pva, sample, sim, test and vtype). There one pom that works both as "parent pom" (keeps the configuration that is common) and "multi-module root pom" (building that trigger the sub-module builds in the right order). Jenkins understands this, and can give you the breakdown for everything (how much each module took to build, which tests were run as part of which module). All this is automatic.

The "parent pom" makes it so that the sub-module have very little configuration. You seem to have to, though, change the version in each of the sub-modules, which is kind of a pain.

The multi-module build looks for circular dependencies. Since I wanted to make some test utilities public, I had to move my tests in that module too: the tests need the test utilities and the test utilities need the core. This is kind of a pain, but getting rid of circular dependencies is a good thing.

The site goal of the root pom aggregates javadocs automatically, so that the generated site actually has all the javadocs of all the sub-modules together. Which is something I was worried it would be a pain to do.

NetBeans, in his wisdom, understands all of this. So, when you open the parent pom, it asks you to open all of the sub-modules. When you create a new sub-module, it actually understand by itself that is a sub-module, so it adds it automatically in the root pom. Chopping the project up was actually pretty straight forward.

The build time gets a long longer, more than double in my case. A lot of that time may be simply upload to sourceforge 9 projects instead of one...

Still have a lot of things to do, but: you may want to consider putting services/java api/... in a single repo sitory for olog and/or channelfinder. You could have an "olog" super pom, with "olog-service", "olog-api", "olog-itest".

Gabriele