THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- 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
- Expressions: supporting old annotations and allowing for
- 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.
- JC: What's wrong with XSD for this? Far, far more tools
- 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??
- JC: This forces users with proprietary/custom plugins to
- Symmetric output expressions
- Refactor Plugin Manager
- 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
- Report Execution Environment: Ability to run any version of a
- 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.
- Pluggable model readers
- 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
- Remove Settings from the core and make it a user facing
- 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?
- 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?)