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?
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?
- 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
- 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]
