Apache
/
maven
mirror of https://github.com/apache/maven.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

remove old docs 

git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@345839 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
Brett Leslie Porter 2005-11-21 05:21:17 +00:00
parent 88091f6d63
commit 7bef1723ce
2 changed files with 0 additions and 92 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

64
plugin-inheritance-and-profiles-notes-jdcasey-20050526.txt
View File

@ -1,64 +0,0 @@
marching orders:
===========================
[X] 1. Add concept of inherit=(true|false) for plugins at plugin/goal levels
[X] 2. Add is|setInheritedByDefault methods to MojoDescriptor to support setting
the default inheritance behavior per mojo.
[X] 3. Add annotation for @inheritedByDefault (true|false).
[ ] 4. Change plugin inheritance to be enabled, cumulatively
-> Not sure how best to do this.
It cannot happen in the MavenProjectBuilder, since no plugins have
been resolved at this point, and we cannot know what the default
inheritance semantics are for a particular plugin.
If this happens at the DefaultLifecycleExecutor, we've dragged the
Profiles assembly and injection out of the assembly code and into the
build-execution code (that is, out of maven-project and into
maven-core). This has implications for people using maven-project
outside of m2 itself.
-> Possibly we need to move plugin verification outside of the lifecycle
executor to a post-MavenProjectBuilder phase, which would also
take place before injection of Profile values. This is complicated, as
it would leave maven-project in an incomplete state (plugin
inheritance wouldn't be part of the basic MavenProjectBuilder, since
the plugin manager is part of maven-core). Since Profiles must be
applied after inheritance is finished, it also means that Profiles
cannot be applied as part of the maven-project API as accessed
through the MavenProjectBuilder
-> Alternately, we could inherit all plugins, but only APPLY/EXECUTE the
ones where inherit=true...that would keep the phases of the build
process essentially unchanged, but could result in quite a bit of
useless overhead as we calculate/inject plugin configurations which
will not be inherited/used. The problem here is knowing which ones
actually were inherited and should have the inherit=true test
applied, and which ones are supplying inherit=true|false but were
specified at this level.
[ ] 5. Add profiles, defined in POM, ${basedir}/profiles.xml, and settings.xml
-> Different validation rules for allowed elements in each, to maintain
portability.
-> Info in profiles will be applied AFTER all assembly, but BEFORE cli
values (what cli values are we using??)
-> Profiles can be ordered
* settings.xml:
<activeProfiles><profileId/><profileId/></activeProfiles>
* profiles.xml:
<profiles><profile><id/>..</profile><profile/></profiles>
* pom.xml: {see profiles.xml}
[ ] 6. Add --show-profiles execution mode for maven, storage of
profiles-in-effect in MavenSession for later access?

28
upgrading-dependencies.apt
View File

@ -1,28 +0,0 @@
-----
Upgrading Maven2's dependencies
-----
Jason van Zyl
-----
Upgrading Maven2's dependencies
When changing the dependencies that Maven2 requires and to have the
bootstrap work correctly there are a few things that must be changed:
* MBoot
The references to dependencies in the mboot must be changed to reflect any
updates in the core dependencies. These are primarily Plexus artifacts and
Modello artifacts.
* Top level POM
The references to common dependencies for the bootstrap build should be
changed in the top-level POM to reflect the change in core dependencies
and these should match the changes in mboot.
* Reference to Classworlds in the verifier
The verifier currently has a reference to Classworlds in order to run. This
should ulimately be changed as the integration tests should be run as
Maven is run itself.