Page History

...

• • NAR plugin
• JC: What does this require that we cannot support? From
  looking at the site-plugin's effects on the lifecycle
  code, I'm very leary of making changes to core/syntax for
  a single plugin...
• Plugins
  • Refactor Plugin Manager
    • Removal of the Plugin Registry (done)
    • Load Plugin dependencies into a separate ClassRealm (done)
    • JC: Clean up the API for public consumption (so we can
      have a good way to orchestrate plugin execution from
      within a mojo, for example)
  • Plugin Execution Environment: Ability to run any version of a
    plugin where an environment is created which contains all the
    requirements for a particular version of the Plugin API
    • Expressions: supporting old annotations and allowing for
      new ones. The expression evaluator would become part of
      the execution environment
  • Plugin API
    • expression
    • DOM related classes into the API
    • JC: function handlers loadable as build extensions
    • JC: XPath expression syntax as alternative to what we
      have now (maybe look into jxpath)
  • Schematron/RelaxNG descriptor for each plugin
    • JC: What's wrong with XSD for this? Far, far more tools
      support it.
  • Remove the use of separate plugin repositories. We only need
    to pull resources from one repository
    • JC: This forces users with proprietary/custom plugins to
      run a repository proxy. Why is this critical??
  • Symmetric output expressions
• Reporting
  • Report Execution Environment: Ability to run any version of a
    report where an environment is created which contains all the
    requirements for a particular version of the Report API
  • Decouple reporting from core
  • JC: Decouple reporting API from Doxia
• Decouple script-based Plugins from the core
  • We should just completely push this out of the core
• Refactor Project Builder
  • Pluggable model readers
    • A new terse format that uses attributes
    • Allow mixin capabilities using an import directive
    • Automatic parent versioning
  • JC: Pipelining of the various steps occurring in the project
    builder now, according to a strict and well-documented
    workflow.
• Execution Configuration
  • Remove Settings from the core and make it a user facing
    configuration
  • Have one configuration model for request
  • Have one configuration model for session: session takes the
    request in the constructor and delegates
• Artifact Resolution
  • Graph-based artifact resolution
  • Decouple from Maven's core
  • Binary graph that is pre-resolved for a POM
  • Artifacts should never be automatically updated, the update policy should be never by default
• Domain logging
• Location/Attribute driven behavior
  • JC: What's this?