Table of Contents

Present: Aaron, Andrew, Bill, Chris, Eddie

Migrating to Maven

We resolved to move our builds to use m2 instead of ant.  Initial scope is for the repository distribution.  Services can come afterward.

  • Advantages to community:
    • Easier to contribute (understand code, etc)
    • Play nice with other m2-savvy projects (Duraspace, Akubra, DSpace, Topaz, etc)
    • More up-to-date "built" docs ("site", javadocs, etc)
  • Advantages to us:
    • Easier deployment of new releases
    • Third party libs
    • Maven is mature/popular; we can benefit from plugins (eclipse, tomcat, etc)
    • Dependency tracking
    • Testing and reporting integration
    • Licensing info
    • Reduce scm downloads (developer happiness)
    • Encourages modularization to code
  • Strategy
    • 1a - Source conformant to m2 standards (files and packages) + tweak build.xml
    • 1b - Get poms for all dependencies
    • 2 - Ant-maven integration (monolithic) with main goal of installer.jar
    • 3 - m2-only (initial split-out)
      • Java Client API
      • Server Webapp
      • Installer
      • (Old GUI)
      • New GUI
    • 4 - Split out server modules as projects
  • Timing
    • Want to ensure no working branches are out during 1a, so
      • We should check outstanding branches in general
      • Soon after 3.2 release. But give 3.2 a couple weeks to settle first.
      • Needs to happen in a branch within in a short period of time (budget 2 weeks)
      • Kai's branch/local copy of his current work (will it go in prior to 3.2 release?)
    • 2 - would like to have in place for 3.3...this work can happen without disrupting outstanding branches (as much)
    • 3 - Nice-to-have by 3.3.  but will require similar "locking of trunk".  We'll revisit timing of this after 2 is done.
  • Outstanding Questions:
    • During 1a, how to we preserve svn history.
    • How to do higher-level tests (ConfigA/B)
    • How to do database config in the normal webapp way with Fedora
    • Step 2: Unsure of how to create dependent pieces (wars, etc) in m2

Maven Repository

  • We'll host our own for thirdParty and having a copy of our released artifacts.
  • We'll point to central, codehaus, java.net, etc directly in our poms.
  • We'll have our CI builds use the local mirror of above, by modifying settings.xml
  • The local mirror isn't intended for public use.  If a problem, we can put behind authN.
  • We want to deploy to central. To support that, we should:
    • Deploy org.fedoracommons stuff to a place they can point to (our repo, rsync, etc)
    • Change package names
    • Use m2.fedoracommons.org
  • Side note: need ssl cert for m2.fedoracommons.org
  • Committers need accounts to deploy poms (thirdparty, etc)

Development Community

  • Chris: Need to continue making participating inviting
  • Eddie: Community needs sense that they "own" Fedora; not just us
  • Brad McLean joined us for a few minutes and talked about some issues DSpace devs are currently facing:
    • Lots of patches, but hard to find people/time to apply them
    • Rules for committers/voting/etc.  Looking at Apache as a model for this.
#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels