Partial response: On Thu, Jun 12, 2008 at 11:29 PM, Brett Porter <[EMAIL PROTECTED]> wrote:
> Hi Shane, > > This looks like a pretty positive step. Is the code on your branch for > MNG-3536 an implementation of this? How far along is it? No, this is just for 2.1 and nothing to do with 3536. The implementation is pretty far along (does interpolation, xml merging, inheritance) but still a fair amount to integrate into 2.1 branch. https://svn.apache.org/repos/asf/maven/sandbox/trunk/maven/maven-project-builder (pom specific build) https://svn.apache.org/repos/asf/maven/sandbox/trunk/shared/maven-shared-model (general build model for merging and interpolating of any xml) > > > I have some questions. Bear in mind it's late on Friday, so I may just be a > bit slow :) > > - how many classes is the typical model assembly going to take? Given how > frequently they are run - the addition of ModelProperty and ModelContainer > objects in addition to the domain model classes could be quite a lot? Not many classes. 6 for the project builder, most of those small. Maven shared model has 7 classes, 6 interfaces. Performance is good. I tried in on maven-2.0.x pom and parent, took 30ms. > > - how are maps handled by #collection? > - it'd be good to keep the URI we currently use for the model as a base > - what happens when you have a collection in a collection? eg > project/build/pluginManagement/plugins/plugin/dependencies/dependency/exclusions#collection This is handled. > > - the removal of reflection seems positive - though this is effectively > done by the data source implementation of queryFor now - right? So we'd > generate one of them for the domain model? > - should system property policy be "context" policy instead? > - the definition of profiles was covered quite briefly - is this the same > behaviour as present? This has become possibly the most complicated part of > the current builder and worth visiting in more detail. > - what does "2. For (A), (C-F), : values..." mean? What is (a), (C-F) > referring to? > - I found the *management rules (3 and 4) to be incomplete - they only > refer to merging in missing versions based on a/g id. Dependencies have > additional ID components, and there are other elements in the container that > need to merge. I think you can drop the "does not contain a version" part, > and essentially join the most specialised *management container with the > same coordinate (g:a for plugin, g:a:c:t for dependency) last > - how does this interpolation relate to John's proposal? Do we need to > interpolate plugin configuration only at execution time? > - how does this change in the method of interpolation relate to the > population of plugin configuration in the first place - given that still > uses the original expression evaluator for things outside the project? > - are we disposing of the "inherited" flag for plugins? > - for the latter rules: > (7) why do we allow multiple extension versions? > (8) why delete the whole plugin container if a version differs? > (10) what are the rules for configuration under an execution / plugin? Or > is this still left up to the plugin manager to merge? > - how do the URIs relate to the eventual XML marshalling, particularly in > the case of extending the model? > - how does the versioning work? If the URIs have a different base, won't > they refuse to join any elements under this approach? Or is it expected to > transform v1 to v2 first, then process them all as v2? > > One thing I'd be interested to see is why each bit was introduced in terms > of problems we're solving. > > Cheers, > Brett > > > On 07/06/2008, at 7:44 AM, Shane Isbell wrote: > > I've created proposal for the maven-project module in 2.1: >> http://docs.codehaus.org/display/MAVENUSER/Maven+Project >> >> Thanks, >> Shane >> > > -- > Brett Porter > [EMAIL PROTECTED] > http://blogs.exist.com/bporter/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
