On Wed, Dec 17, 2008 at 9:47 PM, Ralph Goers <ralph.go...@dslextreme.com>wrote:
> > On Dec 17, 2008, at 9:27 AM, Shane Isbell wrote: > >> >> >> >> >>> I guess I really have no clue what functionality a mixin is supposed to >>> provide or how it would be retrieved without a version or groupid. Is it >>> being suggested they would be stored in the repo without that? I'd need a >>> lot of convincing before I could buy off on that. >>> >> >> That's more of a specific case of what we would need to resolve a mixin >> remotely. Someone may also choose to add mixins programmatically or have >> them taken from the file system. Neither of these cases would require a >> version or groupId. Narrowing the definition of a mixin for one specific >> case, limits its power. >> >> > You've totally lost me, primarily because you've still not defined what a > mixin is. I've defined mixin within the spec and multiple times in this thread: a mixin is an abstract model, meaning it is not required to have all the required elements of a full pom. > I'm also confused as to whether this document is supposed to document Maven > as it currently is or with some set of enhancements. I've seen answers that > imply that right now it should just document what currently exists. The model-builder supports the capability to add mixins (as defined above). We still need to spec out how we want to handle things like resolving. > > > In the long run I'm probably going to be in favor of only allowing single > inheritance from a parent model. I might be inclined to agree with multiple > mixins if they were actually defined. They are defined. See above. > Adding mixins programatically offhand seems like a horrible idea but that > is probably because I'm sure I don't know what you have in mind. > > In short, I would recommend either removing mention of mixins from the > document or actually documenting them. It is documented. Thanks, Shane
