summary of design changes from last irc meeting

[Brett Porter <br...@apache.org>]

Here are the design changes I think we resolved, which I now need to 
update the main documents with. Can you please let me know if you agree.

*** Packaging vs Type:
- Agreed on the principles as set out, but not so much the mechanics of 
how it would work. I'll tihnk through it some more and post a new proposal

*** Lifecycle:
- Happy with this, main uncertainty was where to put the definitions
- For per-packaging lifecycles, we can do this with plexus 
configuration, so a PackagingHandler can specify a lifecycle as 
configuration, but there will be a default (which is what is there now). 
It is a replacement lifecycle, not an overlay.
- I think the best solution for executions was:
@execute phase="..." lifecycle="some ID"
where phase should be replaced by a name that represents whatever we 
call phases/goals as a combination (task?)
the lifecycle ID will be inside a /META-INF/maven/lifecycles.xml file
 * we went for a separate xml file instead of java code to be able to 
easily visualise it
 * the lifecycle in here is overlaid on the existing one when the forked 
goal is called
 * I've decided to aggregate them in one file for simplicity rather than 
having per mojo files
 * I don't think we can use plexus configuration here because it would 
require an assumption in AbstractMojo

*** Multiple goal executions:
Changing the POM to:
<plugin>
  <g/a/v>
  <configuration />
  <executions>
    <execution>
      <id />
      <configuration />
      <goals>
        <goal>
          <id/>
          <configuration/>
       </goal>
     </goals>
    </execution>
  </executions>
</plugin>

We can keep the external goals, but deprecate them. They would form a 
default execution.
Executions with the same id are merged in an inheritence scenario. Goals 
within an execution could not be duplicated.
QUESTION: do we need per-goal configuration in this case? Can we drop it 
to <goals><goal>...</goal><goal>...</goal></goals> ?

*** "Compile only" dependencies
- add a 'provided' scope which makes a dependency "compile" scope, but 
it is *not bundled*, *not on the execution classpath* (eg for surefire) 
and the dependency is *not transitive*. It is intended for use in the 
final "end POM" only.
- add an 'integration-test' scope for the integration test phase 
plugins, like cactus.

*** Dependency Filtering
- I don't think we got to a definitive answer here, but we established:
  * we need some way to filter
  * we wanted to filter out individual dependencies, not turn off 
transitivity of particular dependencies
  * there was a leaning towards making the exclusions transitive 
themself, but not a conclusive decision
- In this vein, I propose something new that satisfies all requirements:
Add
<exclusions>
  <exclusion>groupId:artifactId</exclusion>
</exclusions>
to the dependency element.
Reasoning:
 * makes a nice artifact filter for use when transitively resolving that 
dependency
 * do it per dependency so it is clear where it is coming from and 
doesn't accidentally filter out elsewhere
 * works for both Maven and Ant tasks
 * Can easily produce a report from the repository showing how it is 
used/abused
 * normally transitive because if you don't use it, then those depending 
on you should declare it explictly if they need it, as they're 
dependency on you only implies they need what you need + what they say 
they need
 * use it in dependencies to make it transitive. If you want a 
non-transitive version, it is also available in dependencyMgmt

How do these sound?

Cheers,
Brett


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org