As a response to the remark from Karl
(1) Breaking up modules and putting pieces of that all over the place
I do not think they are all over the place, maybe I am thinking wrong about the modules part, but for me modules is not really clear. At the moment we have documentation, modules and tests. I suggest a slightly more separated mode with: documentation, integration-tests, framework, connectors and environment. The only change is to move some stuff from modules into a new part environment en move the other parts of modules one level up.
Each thing under modules is something you'd want to build separately, which is why I chose the arrangement in the first place. If I were deploying these on a debian system, each would be its own package. That is, each connector would necessarily be its own package, as would mod-authz-annotate, and java-environment. Indeed, java-environment was originally a debian package that was part of the LCF software grant and has not been modified even to build, because it in effect represented a Debian java deployment framework rather than actual code. Same thing with postgres-config, except that was for postgresql configuration under Debian. Furthermore, mod-authz-annotate is C, and probably cannot be built under maven (or do I have that wrong?)
Therefore, for a maven build we should plan on building the following as SEPARATE maven deliverables/targets:
- (1) Each connector
- (2) The framework
If there is a way to build C stuff under maven, then this too should be a maven deliverable/target:
- (3) mod-authz-annotate
These should exist in the tree but be ignored for now, since they are not applicable to maven at all:
- (4) java-environment
- (5) postgres-config
(2) Taking jetty-runner out of framework
I do not think that Jetty is part of your framework, you create war files and give the option for an easy start using Jetty. But maybe I am wrong.
I set the jetty example and runner up so that they do not have explicit dependencies on any individual connectors, and thus they're built as part of the framework, which they DO have a dependency on. A case could be made for having these be separated into their own module-level component, in which case they'd also be their own maven deliverable.
(3) Introducing a "src" directory under each of the framework components
At the moment when running ant. You get a lot of folders of which it is not always easy to understand whether they are original source folders or not. That is why maven comes with a clear separation of src, generated-source and target for other generated content. To my opinion this makes it easier to see what is under version control and what is not.
Check the maven page for more explanation.
I will read the page. It seems to me that we'd need to agree what the maven deliverables would be before we can decide where the "src" directory goes. If the framework is a component all by itself (and I think it should be), then naturally the structure would be "modules/framework/src/..." instead. Does maven allow multiple jars in a deliverable? That would be a necessary condition.
(4) Moving the tests so far away from the code they are related to
I am not sure if I was clear enough on this. In the original code base a test folder is available next to modules. For unit tests I would keep them as close as possible to the source code. Therefore we have the src/main and src/test in the same module. The integration tests are another beast. Usually a lot of environmental setup needs to be done, they take longer, and you might want to store them in a different folder so you can run them all at once. Another option would be to add them next to the unit tests in a different folder [src/main, src/test/ and src/integration-test] or use a different naming scheme. **Test.java and **IntegrationTest.java That way you can folder them out as well and use the maven lifecycle to decide whether to run unit test or both unit and integration tests.
As of right now, there are three kinds of tests in the system: Unit tests (which are checked in in the module they are to test), integration unit tests (which are checked in at the "modules" level), and full integration tests that are a legacy of the LCF code grant (which are checked in in the "tests" directory above the modules level). The full integration tests are not executed but were meant to furnish the rudiments of a test plan,as well as useful bits for manipulating repositories themselves during test processes, and thus must be considered "reference material" at this time. The "documentation" directory above the modules level has a similar history.
I put the integration unit tests under "modules" because the main build script was checked in at the "modules" level, and it needs to run those tests. If we move the mail build script higher up, the integration unit tests can move up also.
As for the part where we need ant to make certain deliveries, we can still do that. Than you have two options, or run the ant command to make these deliverables yourself, or add them to the package lifecycle stage of maven. It is not hard to call ant from maven. You could even create the mother of all ant build file that calls maven to build the framework and the conenctors.
Let's settle the basic questions first, and then revisit the best way to do the maven build.