Page History

...

This is a proposed redesign of the layout in SVN and the way we use Maven, to enable broader use of standard tooling and approaches for development and release.

As the new design takes shape over time, it will be documented here:
Maven use design as top level project

This redesign could be part of our move to a TLP (top level project), assuming we graduate .

...

• RAT reports - currently run on entire assembly, which means we have to unzip it, and run on that.
  • should run on pre-zipped things
  • Therefore, try to run on individual projects, not on distr

• Non Hierarchical POM layout (flat layout) causing problems
  • Release plugin doesn't work
    • may be fixed in latest version of Release Plugin
  • Assembly plugin "modules" doesn't work
    • because it requires the aggregator pom to be in the parent directory of the modules, I think
  • m2eclipse works nicely with hierarchical layout
    • prototyped this already, and can make things work with hierarchical directory layout
  • Simple things like checking out all of uima - uimaj, uima-as, sandbox, (uimacpp - work on this later) from SVN with one export, and then being able to build, doesn't work
    • Current extract & build requires copying over / merging separate SVN checkouts

...

• Figure out Maven's approach to properties
  • It seems that there is a mechanism for "releases" that captures the settings of properties used in build the release, for reproducibility
  • It also seems there is a concept in the Release plugin where it substitutes actual values of properties when it makes the "tag", and then puts back the \ ${xxx} variable form when it updates the trunk. This allows the tagged item to be more "independent" of other components - for instance, when it is located in a Maven repository as a downloadable artifact.

...

Currently the website is maintained completely manually. More standards could enable automatic creation of various developer reports, updating the download page as part of the release process, etc.

Design

...

After thinking that redesigning svn layout was important, I now think that's not the case, but what is important is to change how the build works, as follows:

• make each component independently buildable
  • This is the main "fix". There are several things in the current build that violate this.
    • We have a custom docbook build - that uses a "checked-out" docbook tool project, that currently has to be in a certain directory hierarchy relationship with the project being built. This is fixable by no longer using our own docbook tooling, and instead using the recently developed docbkx maven plugin.
    • We also have dependencies on parent POMs. This can be fixed by making those dependencies use poms in the maven repository (or the local repository). This requires that any updates to these POMs be put in either the local repo or separately "released".
      • I've noticed that many projects have moved to this style, and name their parent poms with release numbers like "1", "2", etc. For instance, the common Apache "parent" pom is at release "7".
      • It would be good to reduce POM changes in parent poms by isolating the POMs to particular functions. For instance, we currently often mix up the "aggregator" pom function (<modules>) with being a parent. The aggregator will change with every release - it will include particular items at particular levels for the release, while the parent poms will likely change less often.
    • We also have dependencies on particular files, such as common license / notice files. These kinds of common resources are now being handled by the maven remote-dependency plugin. The Apache Parent POM does this, for instance, and we can move to using this same style of dependency, to remove any requirement for particular checkout hierarchy.

Because of this, I don't think that any change is required in the current svn tree; we can use other use cases to motivate incremental changes to the svn tree structure, as needed.

• One possible change is to create a new top level svn node holding non-released tooling (e.g., the projects uimaj-internal-tools and uimaj-jet-expander) - and move these there. This will enable source releases to be just the zipped up sources of the svn checkout (after maybe moving some license & notice files around as needed).
  • a new top level svn node called "build" has been created, and holds build-related things such as maven parent poms, resources needed by the build processes, etc.