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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
