Yup. I'll do this today. On 7/18/06, Brett Porter <[EMAIL PROTECTED]> wrote:
The list looks good. I agree with Jason - can we blend that into the wiki page and perhaps reorganise so that it is the canonical reference of what is planned, and what is underway? - Brett On 13/07/2006 5:39 PM, Jason van Zyl wrote: > > On 12 Jul 06, at 10:40 PM 12 Jul 06, John Casey wrote: > >> Hi everyone, >> >> I guess it's fairly obvious from some of the advanced discussions >> going on >> in this list that we're starting to think a little more seriously about >> writing Maven 2.1. I think it's a bad idea for us to attempt another >> massive >> release (akin to 2.0) that attempts to fix everything that's wrong >> with the >> world - and I don't think anyone would argue with me on that. ;-) >> >> So, in the spirit of really getting the ball rolling, I'd like to propose >> some general topics that we should try to address for 2.1. I've discussed >> this a little bit with Brett on IRC, and I think it would be a good >> idea if >> we could pick a few ailing subsystems and try to solve all of the known >> issues with each of them. This way, we have some coherent progress to >> report, and maybe we can move past these particular subsystems for the >> 2.2work. What follows is my own outline of what we should attempt for >> 2.1. To reiterate, it's not comprehensive of all major issues in Maven >> 2.0.x; >> it's only meant to focus on the bigger, more common pain points and >> give us >> something coherent to report with the 2.1 release. >> >> These are just some rough thoughts, but if there are no objections to >> this >> general list, I'd like to expand each section (similar to, but more >> detailed >> than, the "Details" outline given below) in order to highlight specific >> problems we're encountering now, and some possible solution strategies. >> >> WDYT? >> > > List looks good but could you aggregate/organize them with the content > already here: > > http://docs.codehaus.org/display/MAVEN/Maven+2.1+Design+Documents > > Then at the the top of that page pop in the queue the items you want to > discuss first and we'll tackle what's in the queue to keep in manageable > and to let people know what's currently being discussed. > > Did we ever reach a consensus on whether we would put some of the > refactoring into the 2.0.x branch? This is a long list so any sort of > alpha is probably months away but it would be nice to see of the > improvements in the branch if it's refactoring some base components > first. Boils down really to what level of confidence we have in our tests. > > Jason. > >> -john >> >> My thoughts: >> >> * Broad Themes >> >> - [Refactor] Artifact Handling >> >> - [Refactor] POM Loading / Building >> >> - [Refactor] Lifecycle / Plugin Handling >> >> - [Refactor] Embedder >> >> - Alternative Component Support >> >> * Details >> >> ** Artifact Handling >> >> - Version Ranges >> >> - Artifact Identity >> >> * Handling platform naming >> >> * Handling the 2^n variance problem with directives in C: possibly >> using >> an >> assertion-based approach to "sense" the flavor of artifact to use? >> >> * Alternative identity schemes? Layout, VersionRange, Artifact >> impls... >> >> - Conflict Resolution >> >> - Resolution Problems >> >> * Exclude-all >> >> * Exclusions >> >> * Role of dependencyManagement >> >> - Artifact Identity and Multi-language Support >> >> ** POM Loading / Building >> >> - Running Away from XPP3 >> >> - Encoding >> >> - Chain of Command Project Loading >> >> - Interpolation Problems >> >> - Inheritance / Profile Injection Problems >> >> ** Lifecycle / Plugin Handling >> >> - Aggregation >> >> - Suppression (reports & plugins) >> >> - Fine-grained Phase-binding Ordering >> >> - Super-lifecycle (for tools that embed Maven, like Continuum, to >> register >> pre- and post- hooks) >> >> - Flexible Artifact Filtering for Maven Core ClassRealm >> >> * Embedding >> >> We need to get this up to snuff to support some real IDE tooling, as >> this >> will >> be our bread and butter for competing with commercial tools and Eclipse. >> >> * Alternative Component Support >> >> In order to flex to meet the needs of the larger community (including >> other languages and OSGi), we may need to introduce alternative version >> conflict resolution strategies, artifact resolvers, repository >> layouts, and >> so forth. We should find a way to enable this from the POM and >> settings.xml >> (?) > > Jason van Zyl > [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
