On 18-Dec-08, at 12:47 AM, Ralph Goers 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.
What I'm going to try to implement first is a mixin that would contain
a capability, say the capability to release. The mixin would have some
plugins, configuration, and contain properties that can be
parameterized. So this would allow someone to use composition to add
the capability the Maven project currently has to release projects. We
do sources, javadocs, have the remote resources plugin kick in, and
sign the artifacts. Turning this into a mixin would allow anyone to
use it. Another example I would like to try is to have a mixin for
Plexus component creation: automatically tie in metadata generation
for which I need a couple dependencies and a couple plugins. So a
contribution model of sorts, the mixin would not just be inserted into
the current model but the parts of the mixin contributed to the
appropriate parts of the current model. Maybe call it a smart import
or maybe even a sharable profile. It's certainly not limited to this
but this is what I wanted to implement first as a way for people to
share thought out and well tested capabilities. I'm sure many projects
would pick up our release bits if it weren't such a pain in the ass.
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.
We are definitely trying to capture what exists with no modification
until such a time as we can deal with multiple versions of the model.
In the long run I'm probably going to be in favor of only allowing
single inheritance from a parent model.
I don't think we'll be doing multiple inheritance. Single parents with
mixins I think will provide all the flexibility we'll need.
I might be inclined to agree with multiple mixins if they were
actually defined. 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.
Here IDE integration might be the target. A user might pick some
mixins for some sort of debugging capability and activate this via a
UI. I just throwing out a sample idea but it would probably be tool
integration. I doubt anyone would do this using the CLI itself.
In short, I would recommend either removing mention of mixins from
the document or actually documenting them.
I'm writing tests for the spec at the moment but I'll commit the two
that I'm working on. The two I mentioned above.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more
examples
you look at, the more general your framework will be.
-- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
