On 18-Dec-08, at 1:35 AM, Ralph Goers wrote:
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.
Exactly.
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.
In this case you definitely need a coordinate to find it. The mixin
case just can support bits where there isn't a complete coordinate. I
don't know if in practice that would be useful yet. I need a
coordinate for my example.
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.
The mixin would be contributed as if you had placed all the elements
in your POM yourself. So essentially you contribute a set of
properties to the model, and then the transformation process is run.
So we need to define what bits go where but then the spec kicks in.
The behavior probably wouldn't be exactly like parent/child because it
is a composition model. Trying out the two examples I mentioned should
be relatively easy but I don't expect I want to try that until alpha-3
or 4. I just want to write tests for a while and do some refactoring
and stamp out regressions.
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
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
To do two things at once is to do neither.
-—Publilius Syrus, Roman slave, first century B.C.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
