OK - I'm looking forward to seeing this. I understand the programmatic
aspect in the use case you describe with the IDE, but not with
something like the release capability. IIUC this would allow our
organization to create a standard way of doing something and then
somehow make it available to everyone. That would be a good thing.
But I don't understand how that could work without locating it in a
remote repo just as a pom is currently located. And while it may not
be required to have an artifactId, version and groupId in the
programmatic case I simply can't think of a good reason not to require
it anyway.
From what you are describing it sounds like a mixin will essentially
just be a pom (hopefully with a different extension) that uses
somewhat different rules to merge with the pom referencing it. If that
indeed is what it is then I like the idea, but the devil is in the
details - as it always is around here. Since this isn't inheritance
the rules specified in the current document probably don't completely
apply to mixins. For example, if the mixin defines a plugin and the
project referencing it does also what happens? I wouldn't necessarily
expect the same behavior as I would with the parent/child relationship.
Ralph
On Dec 17, 2008, at 10:09 PM, Jason van Zyl wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
