You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Redesigning for more standards including Maven

NOTE: This is a work-in progress as of 1/28/2010

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.

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

Goals

Fix things that work poorly now.

  • RAT reports - currently run on entire assembly, which means we have to unzip it, and run on that.
    • should run on pre-zipped things
  • Non Hierarchical POM layout (flat layout) causing problems
    • Release plugin doesn't work
    • 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
  • Source release doesn't match SVN
    • should be just a zipped up version of the svn, or generated using the source mvn plugin.
    • source assembly should be (if possible) just the sources zipped up
      • may need to have a SVN structure that separates things not in releases (e.g. uimaj-internal-tools)
  • Many parts don't change from release to release - avoid re-releasing these
    • make more use of component part versions
    • support add-on projects being individually released
  • POM hierarchy mixes up aggregation with inheritance
    • Follow new "best practice" of having at least some of the super POMs have integer version numbers, and not changing these very often (see TBD web ref)
  • POMs used for overlapping purposes
    • Consider a superpom hierarchy that separates these separately, for easier maintenance
      • maven tooling dependency version
      • component dependency version (if appropriate)
  • Make project versioning work with Release plugin
    • Substitute a more standard way for our use of "properties" for version numbers.
      • This should allow our POMs to have less version dependence.
  • Balance maintenance-motivated DRY (don't repeat yourself) with obfuscation
    • sometimes having things factored so as to inherit from things and/or use properties set elsewhere in complex ways makes future readability / maintenance difficult.

Support future incorporation of Continuous Integration (CI)

Add Website support automation

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

TBD after more "goals" / needs are identified

  • No labels