mirror of https://github.com/apache/maven.git
remove old docs
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191110 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
Brett Leslie Porter
parent
07ddeab2d1
commit
f4fb75176a
|
|
@ -1,151 +0,0 @@
|
||||||
---
|
|
||||||
Goal Resolution Discussion
|
|
||||||
---
|
|
||||||
The Maven Team
|
|
||||||
---
|
|
||||||
21-Sept-2004
|
|
||||||
---
|
|
||||||
|
|
||||||
Goal Resolution
|
|
||||||
|
|
||||||
This document is intended to be a working memory of sorts for the goal
|
|
||||||
resolution algorithm used in Maven-2. It is not intended to supplant the
|
|
||||||
living bible of Maven, the lifecycle.apt document. Instead it is meant to
|
|
||||||
add depth to the goal resolution step of the lifecycle and provide a place
|
|
||||||
for discussing the dirty details of its implementation.
|
|
||||||
|
|
||||||
*Conceptual Resolution
|
|
||||||
|
|
||||||
Conceptually, goal resolution must take place in a particular order in order
|
|
||||||
to preserve the encapsulation of the goal and it's implied requirements as a
|
|
||||||
single operation. Obviously, since implied requirements are themselves goals,
|
|
||||||
this is a recursive definition. This model is further complicated by the fact
|
|
||||||
that such implied requirements can be derived from two sources: a mojo's
|
|
||||||
declared pre-requisites (non-optional, these are required for correct
|
|
||||||
operation of the mojo itself), and any goal decorations which may have been
|
|
||||||
declared in a project-specific manner via the project POM.
|
|
||||||
|
|
||||||
In general, the following should be the combined outcome of all implied
|
|
||||||
requirements.
|
|
||||||
|
|
||||||
+-----+
|
|
||||||
|
|
||||||
[ main-preGoal* ] [ prereq ]* main-goal [ main-postGoal* ]
|
|
||||||
|
|
||||||
+-----+
|
|
||||||
|
|
||||||
Note that each of the elements in this formula is a goal in its own right,
|
|
||||||
and will therefore be subject to resolution (taking the place of <<<main-goal>>>
|
|
||||||
above) and substitution into the parent (replace <<<main-preGoal>>> with the
|
|
||||||
list of goals implied by <<<main-preGoal>>> <in correct order>).
|
|
||||||
|
|
||||||
*Functional Resolution
|
|
||||||
|
|
||||||
The fact we must merge two sources of implied-goal information in order to
|
|
||||||
construct a complete execution chain complicates goal resolution beyond simple
|
|
||||||
use of a directed acyclical graph (DAG). This is especially true because of the
|
|
||||||
differing lifecycle and scope of the two sources. One is the plugin
|
|
||||||
descriptor, which has a lifecycle arguably longer than the JVM lifecycle
|
|
||||||
itself, and system-wide scope (provided plugin versioning is tracked). The
|
|
||||||
other is the project's POM, which has an extremely short lifecycle (probably
|
|
||||||
roughly equivalent to the maven-session lifecycle, which is <not> the same as
|
|
||||||
the JVM lifecycle in some embedded use cases), and only project scope (don't
|
|
||||||
want one POM's decorations polluting the builds of other POMs). While the
|
|
||||||
plugin descriptor information may be cached - even to disk - the POM goal
|
|
||||||
information must be rebuilt for each maven-session.
|
|
||||||
|
|
||||||
On the other hand, one very important distinction between information derived
|
|
||||||
from plugin descriptors and information from POMs is that POMs lack the
|
|
||||||
ability to declare new goals. This means that in theory we should be able to
|
|
||||||
clone a DAG that describes all of the conventional requirements for all of the
|
|
||||||
plugins referenced, and simply add inter-goal relationships to account for any
|
|
||||||
extra decoration from the POM. When the session is over, we can then discard
|
|
||||||
the modified DAG, retaining the plugin-derived DAG for future use in memory or
|
|
||||||
on disk.
|
|
||||||
|
|
||||||
<NOTE:> There are other reasons to be very careful when caching the DAG to
|
|
||||||
disk, notably the handling and updating of -SNAPSHOT plugins.
|
|
||||||
|
|
||||||
*Algorithm
|
|
||||||
|
|
||||||
Here is the current algorithm implemented by the GoalResolutionPhase:
|
|
||||||
|
|
||||||
<NOTE:> The separation of the plugin resolution step from the process of
|
|
||||||
actually building the execution chain is new, and has not yet been implemented.
|
|
||||||
However, this appears to be a required separation since the DAG cannot
|
|
||||||
function properly until all plugins - and consequently the prereqs implied by
|
|
||||||
them - are resolved. So, we'll take a second pass later to actually build the
|
|
||||||
execution list; for now, we'll just resolve plugins.
|
|
||||||
|
|
||||||
<<Resolve Plugins:>>
|
|
||||||
|
|
||||||
<NOTE:> Can we re-separate this as a plugin-resolution phase, and provide
|
|
||||||
some sort of reusable tree-visit logic (akin to the topo sorter) where we
|
|
||||||
could pass in some sort of visitation command to execute per visited goal?
|
|
||||||
|
|
||||||
[[1]] Initialize recursion
|
|
||||||
[[a]] Instantiate Set for caching resolved goals. <resolved>
|
|
||||||
[[b]] Set current goal to be resolved. <goal>
|
|
||||||
[]
|
|
||||||
[[2]] If <goal> is contained in <resolved>, Return.
|
|
||||||
[[3]] Verify plugin for <goal>.
|
|
||||||
[[4]] Add <goal> to resolved.
|
|
||||||
[[5]] Foreach <preGoal> of <goal>,
|
|
||||||
[[a]] Set <goal> = <preGoal>
|
|
||||||
[[b]] Call [2]
|
|
||||||
[]
|
|
||||||
[[6]] Foreach <prereq> of <goal>,
|
|
||||||
[[a]] Set <goal> = <prereq>
|
|
||||||
[[b]] Call [2]
|
|
||||||
[]
|
|
||||||
[[7]] Foreach <postGoal> of <goal>,
|
|
||||||
[[a]] Set <goal> = <postGoal>
|
|
||||||
[[b]] Call [2]
|
|
||||||
[]
|
|
||||||
[[8]] Return.
|
|
||||||
[]
|
|
||||||
|
|
||||||
<<Build Execution Chain:>>
|
|
||||||
|
|
||||||
<NOTE:> Visitation logic is eerily similar to the above recursive process.
|
|
||||||
Can we create a graph visitation utility and pass in some sort of command
|
|
||||||
to be executed per visited node?
|
|
||||||
|
|
||||||
[[1]] Initialize recursion
|
|
||||||
[[a]] Instantiate LinkedList to hold execution chain. <chain>
|
|
||||||
[[b]] Instantiate Set for caching visited goals. <visited>
|
|
||||||
[[c]] Set current goal to be executed. <goal>
|
|
||||||
[]
|
|
||||||
[[2]] If <visited> contains <goal>, Return.
|
|
||||||
[[3]] Process preGoals of <goal>
|
|
||||||
[[a]] Retrieve List of preGoals bound to <goal>
|
|
||||||
[[b]] Foreach <preGoal> in <preGoals>
|
|
||||||
[[i]] Set <goal> = <preGoal>
|
|
||||||
[[ii]] Call [1]
|
|
||||||
[]
|
|
||||||
[]
|
|
||||||
[[4]] Process prereqs of <goal>
|
|
||||||
[[a]] Retrieve List of prereqs bound to <goal>
|
|
||||||
[[b]] Foreach <prereq> in <prereqs>
|
|
||||||
[[i]] Set <goal> = <prereq>
|
|
||||||
[[ii]] Call [1]
|
|
||||||
[]
|
|
||||||
[]
|
|
||||||
[[5]] Add <goal> to <chain>
|
|
||||||
[[6]] Add <goal> to <visited>
|
|
||||||
[[7]] Process postGoals of <goal>
|
|
||||||
[[a]] Retrieve List of postGoals bound to <goal>
|
|
||||||
[[b]] Foreach <postGoal> in <postGoals>
|
|
||||||
[[i]] Set <goal> = <postGoal>
|
|
||||||
[[ii]] Call [1]
|
|
||||||
[]
|
|
||||||
[]
|
|
||||||
[[8]] Return.
|
|
||||||
[]
|
|
||||||
|
|
||||||
<NOTE:> Since the user's intent most likely aligned with separate, serial
|
|
||||||
execution of all goals listed on the command line <in order>, the above
|
|
||||||
algorithm must be repeated for each <goal> in <user-goals>, with the execution
|
|
||||||
chains of each being appended to a single list in order to resolve a complete,
|
|
||||||
end-to-end picture of the current build session.
|
|
||||||
|
|
||||||
|
|
@ -1,185 +0,0 @@
|
||||||
-----
|
|
||||||
Maven Lifecycle Phases
|
|
||||||
-----
|
|
||||||
The Maven Team
|
|
||||||
-----
|
|
||||||
|
|
||||||
Maven Lifecycle Phases
|
|
||||||
|
|
||||||
* generate sources [modello, antlr, javacc]
|
|
||||||
|
|
||||||
* process sources [qdox, xdoclet, jam]
|
|
||||||
|
|
||||||
* generate resources [modello -> persistence mappings]
|
|
||||||
|
|
||||||
* process resources [process persistence mappings]
|
|
||||||
|
|
||||||
* compile [plexus component or something else]
|
|
||||||
|
|
||||||
* process classes [eg JDO, coverage]
|
|
||||||
|
|
||||||
* generate test sources [generating junit tests]
|
|
||||||
|
|
||||||
* process test sources
|
|
||||||
|
|
||||||
* generate test resources [plexus component or something else]
|
|
||||||
|
|
||||||
* process test resources
|
|
||||||
|
|
||||||
* test compile
|
|
||||||
|
|
||||||
* process test classes
|
|
||||||
|
|
||||||
* test [surefire, testNG, dbunit ...]
|
|
||||||
|
|
||||||
* package [jar or making a dist]
|
|
||||||
|
|
||||||
* package tests which required the entire app/assembly to be finished [integration and more]
|
|
||||||
|
|
||||||
* install
|
|
||||||
|
|
||||||
* deploy
|
|
||||||
|
|
||||||
Mojos only know what they need as input and what phase they contribute to perform their task.
|
|
||||||
They don't know anything about Maven specifically because Maven controls how they are executed in the lifecycle
|
|
||||||
using the lifecycle configuration which looks like the following:
|
|
||||||
|
|
||||||
+-----+
|
|
||||||
|
|
||||||
%{snippet|id=lifecycle|url=http://cvs.apache.org/viewcvs.cgi/*checkout*/maven-components/maven-core/src/main/resources/META-INF/plexus/components.xml}
|
|
||||||
|
|
||||||
+-----+
|
|
||||||
|
|
||||||
You can see that we use the mojo id to indicate what mojo we want to execute at a particular place in the lifecycle
|
|
||||||
to protected against any package refactoring and generally protects against any changes that might occur with
|
|
||||||
naming.
|
|
||||||
|
|
||||||
An example of something commonly done is Maven is to compile the sources of your project:
|
|
||||||
|
|
||||||
+-----+
|
|
||||||
|
|
||||||
m2 compile
|
|
||||||
|
|
||||||
+-----+
|
|
||||||
|
|
||||||
This would invoke the lifecycle up to, and including, the compile phase.
|
|
||||||
|
|
||||||
What about mojos that fall outside of this standard lifecycle? Things like <<<clean:clean>>>, <<<archetype:create>>>,
|
|
||||||
and <<<idea:idea>>>? These mojos can be executed by invoking Maven as such.
|
|
||||||
|
|
||||||
+-----+
|
|
||||||
|
|
||||||
m2 <pluginId>:<mojoId>
|
|
||||||
|
|
||||||
+-----+
|
|
||||||
|
|
||||||
These mojos that execute can be thought of as stand-alone tools, they may require dependency resolution
|
|
||||||
but aside from that they do not interact with any other mojos
|
|
||||||
|
|
||||||
Adding Mojos into the lifecycle
|
|
||||||
|
|
||||||
Here we are using antlr and it is known to maven that this plugin contributes to the generate-sources phase. In
|
|
||||||
m1 the antlr plugin, in fact, worked by magic i.e. if there was a grammar present antlr would try to fire. This
|
|
||||||
is a little too tricky and it would make sense to allow users to specify what they want fired as part of their
|
|
||||||
build process.
|
|
||||||
|
|
||||||
+-----+
|
|
||||||
|
|
||||||
<project>
|
|
||||||
...
|
|
||||||
<plugins>
|
|
||||||
<id>antlr</id>
|
|
||||||
<configuration>
|
|
||||||
<grammars>
|
|
||||||
<grammar>src/grammars/confluence.g</grammar>
|
|
||||||
</grammars>
|
|
||||||
</configuration>
|
|
||||||
</plugins>
|
|
||||||
...
|
|
||||||
</project>
|
|
||||||
|
|
||||||
+-----+
|
|
||||||
|
|
||||||
So here the user specifies the use of the antlr mojo that takes a grammar and generates sources and maven knows
|
|
||||||
that this mojo contributes to the <<<generate-sources>>> phase and so executes the antlr mojo inside the
|
|
||||||
the <<<generate-sources>>> phase. In cases where there is a possible domination problem we can state that the order
|
|
||||||
in which the the configurations are listed is the dominant order. I think in most cases there will no be any
|
|
||||||
domination ordering problems but when there could be you have to be able to explicity state what the order
|
|
||||||
would be.
|
|
||||||
|
|
||||||
notes to finish copying:
|
|
||||||
|
|
||||||
-> mojos will contain @tags for parameters and the phase they contribute to, a mojo will be limited to
|
|
||||||
contributing to one phase in the lifecycle.
|
|
||||||
-> goal resolution within phases
|
|
||||||
-> file dependency timestamp checking (mhw)
|
|
||||||
-> strict use of artifact handlers for things like package/install/deploy
|
|
||||||
this again would be a mapping so a handler could delegate to another utility for packaging
|
|
||||||
-> how users decorate or completely override the lifecycle, but most of this should be alleviated by a mojo
|
|
||||||
having a defined place in the lifecycle by telling maven what phase it contributes too. in this way maven
|
|
||||||
can probably assemble the entire execution chain by looking at the mojos the user has specified for use
|
|
||||||
in the build process.
|
|
||||||
|
|
||||||
[Added, jdcasey/2005-01-23]
|
|
||||||
Notes for discussion:
|
|
||||||
|
|
||||||
- What about enabling goals only for certain enviornments (introduce the concept
|
|
||||||
of a target "environment", like CI/dev/QA/production/etc.)
|
|
||||||
|
|
||||||
We can't enforce a vocabulary of environments IMO, since different teams
|
|
||||||
will have different needs, and shouldn't be forced to adapt.
|
|
||||||
|
|
||||||
What about something like:
|
|
||||||
+---+
|
|
||||||
.
|
|
||||||
.
|
|
||||||
.
|
|
||||||
<phase>
|
|
||||||
<id>test</id>
|
|
||||||
<goal>
|
|
||||||
<environment>dev</environment>
|
|
||||||
<id>surefire:test</id>
|
|
||||||
</goal>
|
|
||||||
</phase>
|
|
||||||
.
|
|
||||||
.
|
|
||||||
.
|
|
||||||
+---+
|
|
||||||
|
|
||||||
With an invocation style similar to <<<m2 [-Dtarget.environment=dev] test>>>
|
|
||||||
|
|
||||||
- In keeping with the concept of providing tons of flexibility but providing
|
|
||||||
a comprehensive set of sensible defaults, the default phase-goal bindings
|
|
||||||
will probably be provided in the implied root POM.
|
|
||||||
|
|
||||||
That said, how do we allow users to <suppress> those phase-goal bindings?
|
|
||||||
|
|
||||||
How do we allow users to specify <where> a new binding will go in relation
|
|
||||||
to the defaults provided in the root POM?
|
|
||||||
|
|
||||||
However we solve this, we need to emphasize intuitive XML as a solution IMO.
|
|
||||||
The implicit ordering in the phase-goal bindings is a step in the right
|
|
||||||
direction, but when you factor inheritance into the mix, this could get
|
|
||||||
really sticky.
|
|
||||||
[/Added, jdcasey/2005-01-23]
|
|
||||||
|
|
||||||
[Added, brett/2005-02-13: Inserting these as things left over from previous
|
|
||||||
mails to m2-dev that were pre-lifecycle]
|
|
||||||
|
|
||||||
Multiple lifecycles will be able to be used and defined - for example "site"
|
|
||||||
would have an additional lifecycle. This interface may even be available to
|
|
||||||
users, though strongly discouraged as the default lifecycles should accommodate
|
|
||||||
almost any use case.
|
|
||||||
|
|
||||||
As the site runs through, it will want to ensure that parts of the lifecycle
|
|
||||||
already complete are not run again unless the parameters change.
|
|
||||||
|
|
||||||
eg. For coverage - no need to compile again, but do add an additional
|
|
||||||
instrumentation step, then run the tests again on the new instrumented classes
|
|
||||||
(in a new directory, not over the top of the old ones).
|
|
||||||
|
|
||||||
To simplify this, we may actually allow some steps to re-run and rely on the
|
|
||||||
file timestamping to make it effecient.
|
|
||||||
|
|
||||||
[/Added, brett/2005-02-13]
|
|
||||||
|
|
||||||
|
|
@ -1,46 +0,0 @@
|
||||||
<lifecycle>
|
|
||||||
<phases>
|
|
||||||
<phase>
|
|
||||||
<id>generate-sources</id>
|
|
||||||
</phase>
|
|
||||||
<phase>
|
|
||||||
<id>process-sources</id>
|
|
||||||
</phase>
|
|
||||||
<phase>
|
|
||||||
<id>generate-resources</id>
|
|
||||||
</phase>
|
|
||||||
<phase>
|
|
||||||
<id>process-resources</id>
|
|
||||||
</phase>
|
|
||||||
<phase>
|
|
||||||
<id>compile</id>
|
|
||||||
</phase>
|
|
||||||
<phase>
|
|
||||||
<id>process-classes</id>
|
|
||||||
</phase>
|
|
||||||
<phase>
|
|
||||||
<id>generate-test-sources</id>
|
|
||||||
</phase>
|
|
||||||
<phase>
|
|
||||||
<id>process-test-sources</id>
|
|
||||||
</phase>
|
|
||||||
<phase>
|
|
||||||
<id>process-test-resources</id>
|
|
||||||
</phase>
|
|
||||||
<phase>
|
|
||||||
<id>test-compile</id>
|
|
||||||
</phase>
|
|
||||||
<phase>
|
|
||||||
<id>test</id>
|
|
||||||
</phase>
|
|
||||||
<phase>
|
|
||||||
<id>package</id>
|
|
||||||
</phase>
|
|
||||||
<phase>
|
|
||||||
<id>install</id>
|
|
||||||
</phase>
|
|
||||||
<phase>
|
|
||||||
<id>deploy</id>
|
|
||||||
</phase>
|
|
||||||
</phases>
|
|
||||||
</lifecycle>
|
|
||||||
|
|
@ -1,166 +0,0 @@
|
||||||
-----
|
|
||||||
Maven Lifecycle
|
|
||||||
-----
|
|
||||||
The Maven Team
|
|
||||||
-----
|
|
||||||
|
|
||||||
Maven Lifecycle
|
|
||||||
|
|
||||||
*Lifecycle Permutations
|
|
||||||
|
|
||||||
* Single goal
|
|
||||||
|
|
||||||
- session lifecycle[1]
|
|
||||||
|
|
||||||
- dep resolution (if POM present)
|
|
||||||
|
|
||||||
- dep download[2]
|
|
||||||
|
|
||||||
- each downloaded dep is registered in MavenSession to track
|
|
||||||
snapshot downloads
|
|
||||||
|
|
||||||
- goal lifecycle
|
|
||||||
|
|
||||||
- goal resolution (we assume here only one goal is resolved)[3]
|
|
||||||
|
|
||||||
- download plugin for goal if necessary[2]
|
|
||||||
|
|
||||||
- goal execution
|
|
||||||
|
|
||||||
+-----+
|
|
||||||
|
|
||||||
+------------> goalX
|
|
||||||
| |
|
|
||||||
| |
|
|
||||||
| is the plugin for
|
|
||||||
| goalX present?
|
|
||||||
| |
|
|
||||||
| |
|
|
||||||
| yes ---+--- no
|
|
||||||
| | |
|
|
||||||
| | v
|
|
||||||
| | download the plugin which
|
|
||||||
| | contains code for this goal
|
|
||||||
| | |
|
|
||||||
| | |
|
|
||||||
| | v
|
|
||||||
| | process the plugin descriptor
|
|
||||||
| | and cache the results
|
|
||||||
| | |
|
|
||||||
| | |
|
|
||||||
| |<---------+
|
|
||||||
| |
|
|
||||||
| |
|
|
||||||
| |
|
|
||||||
| v
|
|
||||||
| does goalX have any preGoals?
|
|
||||||
| |
|
|
||||||
| yes ---+----- no
|
|
||||||
| | |
|
|
||||||
| v |
|
|
||||||
/----------------/ | foreach(pregoal) |
|
|
||||||
|each pregoal is | | (1)| (2)| |
|
|
||||||
|a goal which | +----+ | |
|
|
||||||
|may be in | | +------->|
|
|
||||||
|another plugin | | |
|
|
||||||
/----------------/ | |
|
|
||||||
| v
|
|
||||||
| does goalX have any prereqs?
|
|
||||||
| |
|
|
||||||
| yes ---+----- no
|
|
||||||
| | |
|
|
||||||
| v |
|
|
||||||
/---------------/ | foreach(prereq) |
|
|
||||||
|each prereq is | | (1)| (2)| |
|
|
||||||
|a goal which | | | | |
|
|
||||||
|may be in | | | |<-------+
|
|
||||||
|another plugin | | | |
|
|
||||||
/---------------/ | | |
|
|
||||||
+------------+ |
|
|
||||||
| |
|
|
||||||
| v
|
|
||||||
| does goalX have any postGoals?
|
|
||||||
| |
|
|
||||||
| yes ---+------ no
|
|
||||||
| | |
|
|
||||||
| v |
|
|
||||||
/---------------/ | foreach(postgoal) |
|
|
||||||
|each postgoal | | (1)| (2)| |
|
|
||||||
|is a goal which| +-----------+ | |
|
|
||||||
|may be in | +-------->|
|
|
||||||
|another plugin | |
|
|
||||||
/---------------/ |
|
|
||||||
v
|
|
||||||
|
|
||||||
/-----------------------------------------------------------------------------/
|
|
||||||
| The general form for goal resolution is: |
|
|
||||||
| |
|
|
||||||
| [ main-preGoal* ] [ prereq ]* main-goal [ main-postGoal* ] |
|
|
||||||
| |
|
|
||||||
| where each goal (whether it be preGoal, prereq, goal, or postGoal) is |
|
|
||||||
| subject to the same recursive resolution process. |
|
|
||||||
/-----------------------------------------------------------------------------/
|
|
||||||
|
|
||||||
+-----+
|
|
||||||
|
|
||||||
* Multiple goals
|
|
||||||
|
|
||||||
- session lifecycle[1]
|
|
||||||
|
|
||||||
- dep resolution (if POM present)
|
|
||||||
|
|
||||||
- dep download[2]
|
|
||||||
|
|
||||||
- goal lifecycle (assume that multiple goals are supplied by user)
|
|
||||||
|
|
||||||
- goal resolution (assume multiple goals)
|
|
||||||
|
|
||||||
- download plugin for goal(s) as necessary[2]
|
|
||||||
|
|
||||||
- goal execution
|
|
||||||
|
|
||||||
* Implied goals (prereq, preGoal, postGoal)
|
|
||||||
|
|
||||||
* Reactor with a single goal
|
|
||||||
|
|
||||||
* Reactor with multiple goals
|
|
||||||
|
|
||||||
|
|
||||||
*Use Cases
|
|
||||||
|
|
||||||
* where one goal needs to use and modify another goal
|
|
||||||
eg jcoverage:report does jcoverage:instrument [compiler:compile],
|
|
||||||
then calls surefire:test (adding classpath entries and changing the test
|
|
||||||
classes directory parameter)
|
|
||||||
the does the report
|
|
||||||
|
|
||||||
* where a goal does not require a pom.xml (pom-writer, for example).
|
|
||||||
Here, the pom should NOT be read.
|
|
||||||
|
|
||||||
* is there a case where a goal should in fact be executed twice in a
|
|
||||||
session? Something like "m2 clean foo clean"
|
|
||||||
|
|
||||||
- DAG (or DAG-like process) is used for goal resolution, which
|
|
||||||
should ensure that only explicit multi-calls execute multiple
|
|
||||||
times.
|
|
||||||
|
|
||||||
* ability to alias a goal to a series of other goals, eg: my-goal: clean, foo, clean
|
|
||||||
|
|
||||||
*Notes
|
|
||||||
|
|
||||||
[[1]] POM reading: we always attempt to read the POM but it may not be
|
|
||||||
present because some goals don't require the presence of a POM like
|
|
||||||
stub generation, project setup or whatever. So we can flag this state
|
|
||||||
and throw an exception down the line if a goal in fact requires a
|
|
||||||
project, or if there is a POM when there shouldn't be one.
|
|
||||||
|
|
||||||
[[2]] Artifact downloading: all artifacts downloaded during session
|
|
||||||
execution should be registered in a session-scope collection of id's
|
|
||||||
to avoid multiple download of -SNAPSHOT and other artifacts.
|
|
||||||
|
|
||||||
[[3]] Goal Resolution: Involves resolving all implied goals (via prereqs,
|
|
||||||
pre- and post-goal decorations, and resolving/downloading any associated
|
|
||||||
plugins. Plugin download must be a utility used by this, to ensure that
|
|
||||||
any goals - specified or resolved - have their associated plugins
|
|
||||||
downloaded.
|
|
||||||
|
|
||||||
|
|
@ -1,70 +0,0 @@
|
||||||
---
|
|
||||||
Maven2 alpha-1 Deployment Checklist
|
|
||||||
---
|
|
||||||
---
|
|
||||||
|
|
||||||
* Convert repository at beaver:repository/ibiblio-v1 to beaver:repository/ibiblio-v3
|
|
||||||
|
|
||||||
* Re-deploy anything required from ibiblio-v2 to ibiblio-v3
|
|
||||||
|
|
||||||
Start by changing the <distributionManagement/> stanza for each root-pom,
|
|
||||||
verifying that the <modules/> stanza covers all relevant projects,
|
|
||||||
committing any changes to pom's, and finally running 'm2 deploy' for each.
|
|
||||||
|
|
||||||
- plexus (all)
|
|
||||||
- maven-components (all)
|
|
||||||
- marmalade (core, utils, ognl-el, commons-el, ant-compat, jelly-compat ...)
|
|
||||||
- modello (all)
|
|
||||||
- mojos (all)
|
|
||||||
- doxia (all)
|
|
||||||
- wagon (all)
|
|
||||||
- surefire (all)
|
|
||||||
- maven-scm (all)
|
|
||||||
|
|
||||||
* Setup vhost on codehaus pointing to ibiblio-v3 repository directory for
|
|
||||||
testing.
|
|
||||||
|
|
||||||
* Run test with locally-changed super-pom that references new ibiblio-v3 vhost.
|
|
||||||
|
|
||||||
When this succeeds, we should be able to shutdown that test vhost.
|
|
||||||
|
|
||||||
* Setup staging directory for rsync from feeder repositories.
|
|
||||||
|
|
||||||
This directory will be used to bring in the contents of other artifact
|
|
||||||
repositories, whereupon the repoclean utility will be run periodically to
|
|
||||||
convert them over to the format required for ibiblio-v3 (and dump them in
|
|
||||||
there).
|
|
||||||
|
|
||||||
The synchronization process should do the following:
|
|
||||||
|
|
||||||
[[1]] synchronize artifact feeds into the staging directory. [STAGE-1]
|
|
||||||
|
|
||||||
[[2]] run repoclean on the staging directory, and feed the output to the
|
|
||||||
ibiblio-sync staging directory. [STAGE-2]
|
|
||||||
|
|
||||||
This will convert poms from v3 to v4, and directory structures from
|
|
||||||
old layout to new layout.
|
|
||||||
|
|
||||||
[[3]] clean out the inbound sync staging directory (STAGE-1).
|
|
||||||
|
|
||||||
[[4]] synchronize STAGE-2 to ibiblio.org/maven2.
|
|
||||||
|
|
||||||
* Setup synchronization between beaver:repository/ibiblio-v3 and ibiblio:/maven2.
|
|
||||||
|
|
||||||
* Change the redirect for repo1.maven.org to point to ibiblio.org.
|
|
||||||
|
|
||||||
* Change the repository directory structure for repo1.maven.org in super-pom
|
|
||||||
to point to /maven2.
|
|
||||||
|
|
||||||
This will enable switching from redirect aliasing to CNAME aliasing of
|
|
||||||
ibiblio repository transparently, since usage of the CNAME method will
|
|
||||||
require the correct URL path (URL rewriting and vhost on ibiblio side are
|
|
||||||
not allowed). Basically, this allows us to keep our options open with an
|
|
||||||
eye toward user support once m2 is released.
|
|
||||||
|
|
||||||
* Wait for and/or push initial sync to ibiblio:/maven2.
|
|
||||||
|
|
||||||
* Run test builds to verify new repository access is working.
|
|
||||||
|
|
||||||
* Weed out the ibiblio-v2 repository to only m2 stuff, and then archive these
|
|
||||||
artifacts in case we need them. Remove ibiblio-v2 directory.
|
|
||||||
Loading…
Reference in New Issue