Page History

...

• 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
  • 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

...

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

...

Principles:

• top level in svn tree:
  • uima - overall top
    • uimaj - java sdk for framework
    • uimacpp - cpp for framework
    • uima-as - uima addon for asynch scaleout
    • sandbox - for developing things, not all released, not necessarily well documented, etc.
    • site

• new top level things:
  • under uima
    • internal-tools - things not in normal binary distributions, but used in building, etc.
    • super-poms - non-aggregate poms in the super-pom hierarchy
    • annotators - released and more fully documented/supported annotators from the sandbox (called out because of importance)
    • add-ons - released and more fully documented/ supported add-ons, such as simple-server

Each of these (other than site) are "releasable" and have trunk/branch/tag nodes.

Some of these have individually releasable parts (e.g., each pom in super-poms, each annotator in annotators), while others are multi-module projects (like uimaj).

It should be possible (he said bravely) to do releases of parts individually, even when the trunk/tag/branch is at a higher level. For doing this, let's follow a convention, of naming the tag with a name-part starting with the releasable-part name.

• For example, with sandbox/trunk/projXyz the tag would be sandbox/tags/projXyz-version-number-etc
• To give a counter-example, what we're not doing is something like
  • (not doing) sandbox/projXyz/trunk
  • (not doing) sandbox/projXyz/tags/version-number-etc ...

• separate "aggregate" and "super" poms
  • put aggregate poms in hierarchy in "natural" place, in the dir above the collection of contained projects, where there is one aggregation (currently this is the case always)
  • for super poms - put in containing super-poms project
• scm element in pom needs to point to where this pom is, in the svn tree (to make releasing conventional)
• leave tag/branch/trunk spots alone, for now
  • currently here; under uimaj, uima-as, sandbox, uimacpp
• add