THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- Wiki:
- tree structure simplification done: see Index
- page tags started: maven-dev, plugin-dev & maven-user
- Added proposal pages properties, to have in Proposals index page an automatic index with backlog-like classification (draft/wip/done/abandoned)
- good lunch in a little restaurant
- Git:
- aggregator: looked at Sling study and WIP with Google repo (
)Jira server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key SLING-7164 - Jenkins: sconnolly videos in progress (links?)
- Doxia git repo history is not so clean (strange independant branches): is it a strong issue?
- preparing new Git repos for content: looked at Sling migrate-svn-to-git.sh script which splits full svn2git mono-repo to a collection of repos based on
git filter-branch --subdirectory-filter ${module_orig}
- idea: create a git repo for dist-tool-plugin
- aggregator: looked at Sling study and WIP with Google repo (
- jansi-native Windows improvement issue #11: let's try Apache Help Wanted to find a contributor with required knowledge
- build pom vs consumer pom:
- think big, start small: should not require Maven core updates, just use flatten-maven-plugin with a "standard" configuration
- this standard configuration can start easy: just remove build, reporting and profiles
- publish simplified model documentation
- prove consumer pom deployment as default pom, and build pom as attached artifactspecial case:
- when packaging=pom, default pom remains build pom
- then discuss more aggressive simplification in consumer pom (like parent flatten or any other remaining element)
- is a key enabler to add more build features in future Maven version, with appropriate pom enhancements in
project/build
section- think big, start small: starting with the pom enhancements that are waiting for for many years as magic properties (like encoding, bytecode version, ...)
- think big, start small: should not require Maven core updates, just use flatten-maven-plugin with a "standard" configuration
- build performance enhancement (aka incremental build, or build avoidance, or...)
- need to track per mojo what are the inputs and the outputs (some configuration being a type of input), then a framework to track rebuilds
- prerequisite: monitor performance, to get real figures of where time is going and what would be useful to optimize or not (stay simple)
- would permit to check performance of a plugin mojo version after version
- or check performance when changing Maven core version
- or track what is re-done when building 2 times without modifying anything, then should be avoided
- use Chromium trace viewer to render?