On Wed, Dec 17, 2008 at 11:22 PM, Ralph Goers <ralph.go...@dslextreme.com>wrote:
> > On Dec 17, 2008, at 10:57 PM, Shane Isbell wrote: > > 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. >> > > And I've said multiple times that that isn't an adequate definition. > Jason's post provided a better clue but still doesn't define it. Your > definition is about like me telling you that I am heading a JCP committee to > define a new Java entity called mixin and in it you will be able to use all > the existing java grammar but I tell you nothing more than that. Would you > have a clue how that is useful? No it wouldn't be useful. But if you said a mixin is like an abstract class and all it's elements can be inherited exactly like an abstract class, then I would have a pretty good clue. Shane
