maven-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jvan...@apache.org
Subject svn commit: r682816 - /maven/site/branches/maven-2.1-doco/maven-2.1-architectural-goals.apt
Date Tue, 05 Aug 2008 17:31:35 GMT
Author: jvanzyl
Date: Tue Aug  5 10:31:35 2008
New Revision: 682816

URL: http://svn.apache.org/viewvc?rev=682816&view=rev
Log:
o first pass at elimination cruft and adding the information i have. no time now to finish.
will do it tonight.

Modified:
    maven/site/branches/maven-2.1-doco/maven-2.1-architectural-goals.apt

Modified: maven/site/branches/maven-2.1-doco/maven-2.1-architectural-goals.apt
URL: http://svn.apache.org/viewvc/maven/site/branches/maven-2.1-doco/maven-2.1-architectural-goals.apt?rev=682816&r1=682815&r2=682816&view=diff
==============================================================================
--- maven/site/branches/maven-2.1-doco/maven-2.1-architectural-goals.apt (original)
+++ maven/site/branches/maven-2.1-doco/maven-2.1-architectural-goals.apt Tue Aug  5 10:31:35
2008
@@ -2,10 +2,20 @@
 
 h2. Architectural Goals
 
-h3. Embedder
+h3. POM changes
+* tags/categories
+* dependency excludes && symmetry
+* terse attribute based format for the POM
+* properties on dependencies
+* Specification Dependencies
+* Schematron/RelaxNG descriptor for each plugin -- Bryon Jacob proposed a flexible model
but XSD is hard to fight here
+* Mixin support -- allowing a paramterizable template which can be imported with one line.
+
+h3. Embedding
 
 h3. Custom Components
 * Tycho
+* Kenney did a first implementation of this -- need to link the documentation and process
 
 h3. Mercury
 * Sustained connections for transfers (releasing and deploying)
@@ -22,21 +32,45 @@
 *  Dependency extensions
   *   Exclude all
 
+h3. Plugin API
+* Symmetric output expressions
+* Java5 Mojo annotations (Yoav Landman has this working already)
+* Clean separation of plugins from reports. It's not good that those are the same thing in
the Maven internals.
+
 h3. Core Refactorings
 * Project Builder
+** Maven shared model work
 ** Pluggable model readers
- * A new terse format that uses attributes
- * Allow mixin capabilities using an import directive
- * Automatic parent versioning
- * New interpolation component (plexus-interpolation)
- * Dynamic build sections ([MNG-3530|http://jira.codehaus.org/browse/MNG-3530])
+** A new terse format that uses attributes
+** Allow mixin capabilities using an import directive
+** Automatic parent versioning
+** New interpolation component (plexus-interpolation)
+** Dynamic build sections ([MNG-3530|http://jira.codehaus.org/browse/MNG-3530])
+** Not using concrete XML classes in the Plugin API (Xpp3Dom)
+* Remove the use of separate plugin repositories. We only need to pull resources from one
repository. We started doing this but I've had a couple
+   clients that want to separate the tools they use from the code they are developing/building.
+* Decouple script-based Plugins from the core -- we are a large part of the way here I need
to summarize what was done.
+* Remove Settings from the core and make it a user facing configuration (This is primarily
done -- jason)
+* Have one configuration model for request
+* Have one configuration model for session: session takes the request in the constructor
and delegates
+* Domain logging
 * Plugin Manager
+**  Removal of the Plugin Registry (done) -- we moved in a direction where people lock down
their versions and we've helped by putting default versions
+    in the parent POM.
+**  Load Plugin dependencies into a separate ClassRealm (done)
+**  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
+
 * Lifecycle Executor 
 **  Queryable Lifecycle
 *** The most important change in the embedding environment. You can actually query Maven
for the complete execution before it happens. We must know the entire
     model of execution before we execute.
-*  Java5 annotations for plugins: we have two implementations that have now been merged in
plexus-cdc. QDOX 1.7 has now been released so we may want to check the 
-   source level gleaning again. Jason Dillon has created a working class processing model.
We need to deal with Plexus components and Maven plugins.
+* Custom profile activators -- we don't have a lot of users except the C-based builds so
it might be worth while getting rid of it.
+
+h3. Java 5
+
+Java5 annotations for plugins: we have two implementations that have now been merged in plexus-cdc.
QDOX 1.7 has now been released so we may want to check the 
+source level gleaning again. Jason Dillon has created a working class processing model. We
need to deal with Plexus components and Maven plugins.
    
 h3. Integration and promotion of scriptable plugins
 
@@ -48,111 +82,9 @@
     *  JC: Don't allow builds where versions come from profiles that
        have to be activated manually
        
-       
-  *  Toolchains
-    *  Some preliminary work has been done on a branch by Milos and
-       myself, we're basically going to steal all the profile work from
-       Netbeans
-    *  JC: Do we even have specific requirements documented for this?
-       Where are they?
-  *  Plugin Testing
-    *  Results from ApacheCon discussion
-      *  JC: Posted where?
-    *  We Kenney's and Johns tools which are complementary embedder
-       inside the invoker
-  *  Integration Testing
-    *  Still not entirely happy with the current setup but it's working
-       and relatively easy to update
-    *  Too many tools
-      *  IT plugins: john's with kenney goodies and fold john's into
-         the IT plugins as well
-      *  Invokers
-      *  Verifiers
-    *  JC: IMO, this would benefit greatly from having a decoupled
-       plugin invoker, since it would be really nice to orchestrate
-       several plugins for an IT setup, using a single IT plugin
-      *  thinking about the component-it-plugin, invoker-plugin, and
-         maybe verifier plugin or similar...
-  *  Custom Components
-    *  Allowing easy plugging in of new resolvers and such
-    *  Kenney has finished this and it's working in 2.1
-      *  JC: IMO we need to address this as a first-class citizen of
-         the container, not simply rewriting the component descriptor
-         for the existing component.
-  *  Specification Dependencies
-  *  POM Changes
-    *  tags/categories
-    *  source: Maven, hand bombed and put in the metadata
-      *  JC: What does this mean?
-    *  dependency excludes && symmetry (JC: consistency?) in the plugins
-    *  terse attribute based format for the POM
-    *  properties on dependencies and it was for a C build
-      *  JC: What was for a C build? What do we need these properties
-         for? If we're thinking that would be a good place to specify
-         prefix for a C dependency, it's not a very scalable approach...
-    *  tags for dependencies being used by different plugins
-      *  JC: Can we deprecate scope in favor of this, then? Or, at
-         least trim it back? It seems to me that test scope falls into
-         the tagged-for-surefire category.
-      *  JC: We should also consider tagging for plugin-execution since
-         a single plugin could be used in multiple ways (think surefire
-         +integration-testing)
-    *  the profile for an execution environment: development versus
-       production and getting the right specification dependencies,
-       packaging problems
-    *  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
-    *  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
-  *  Domain logging
-  *  Location/Attribute driven behavior
-    *  JC: What's this?
-
-- Need to ask brian and john about clarification
-| WIP | [Custom Profile Activators] | 2.1.x | ??? | [trunk|http://svn.apache.org/repos/asf/maven/components/trunk]
| John Casey | |
-| Complete | [Mirror Settings and File repositories] | 2.0.x, 2.1.x \\ | [MNG-3461|http://jira.codehaus.org/browse/MNG-3461]
| | Brian Fox \\ | March 13th, 2008 \\ |
+h3. Toolchains
+* Milos has implemented this and Shane had some feedback so this needs to be linked together
+
+h3. 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 the reporting core. We need to get Doxia out of the core. Anything it needs to
run should be isolated.



Mime
View raw message