Page History

...

• Dependencies of extensions should not be influence by the dependency requirements of the project. MNG-2934
• Transactionality and Shutdown Safety
  • Having a mechanism that writes all files out atomically where we have shutdown hooks to make sure everything is done safely. If all i/o operations pass through a simple Tx manager and the Tx manager is associated with a shutdown hook then we can make sure we don't end up with corrupted files.

–

• Artifact Resolution
• Extensions
  • Different categories of extensions: providers vs packaging vs PMD/Checkstyle resources stuff in a JAR
  • Transparent Extension Loading
    • Any Wagon or SCM providers should get picked up automatically from SCM and distributionManagement URLs
    • Any extensions containing packaging/lifecycle related bits needs to be picked up automatically
• Backward Compatibility
  • Provide layer of adapters for plugin backward compatibility,
    to avoid immediate necessity to recode entire suite of
    plugins and reports for 2.1 compat.

...

• 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
  • Repository defintions forbidden in POMs. Move toward having teams setup with the repositories they need. So that all artifact resolution processes start with a known set of repositories. This radically simplifies artifact resolution and avoids all chicken-egg problems. Teams in OSS or corporate must move toward using a proxy and/or have their settings.xml file synced up for the team. This also avoids all the crap of putting repositories in for snapshots and then taking them out. This will make the process deterministic.
  • The central repository definition is also removed from the SuperPOM and the repository definition moves to a standard settings.xml file. This way all repository definition are moved to a place where they can be easily altered. No more "mirrors" and replace versus cascading. It's all upfront and the set of repositories are fully defined before resolution. Yes this requires some stringent upfront checking to make sure things are intact but removes all question as to how resolution works.
• Domain logging
• Location/Attribute driven behavior
  • JC: This is just going back over the Convention over Configuration stuff, and pushing as much as we can into automated "special" locations where Maven just knows how to handle that sort of content, right?
    • filtering
    • velocity pre-processing
    • etc?
• Clearly separate project-own dependencies and plugin dependencies
  • the commandline option -U ('update snapshots') needs to either update plugin snapshots+deps, or project deps, not both (MNG-724 - marked won't fix - why?)
• More/Better diagnostic and validation tools
  • better diagnosis for errors
  • better validation of project configurations (dependencies and scopes, plugin config, portability, reproducibility, etc.)