On Dec 17, 2008, at 11:15 PM, Shane Isbell wrote:
On Wed, Dec 17, 2008 at 10:35 PM, Ralph Goers <ralph.go...@dslextreme.com
>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. 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.
Consider the following case: Someone may decide to put a mixin file
in their
build. The mixin then gets applied to the pom. Any deployed or
installed pom
from the build has the mixins applied. In this case, mixins are
never even
in the remote repo.
I doubt that would be the normal case, except when used for tools as
Jason described. Even then I suspect most of them would still be
deployed. Also, the document shows mixins being retrieved in the
normal fashion by groupId, artifactId and version. If they can be
included in some other way it isn't documented.
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.
One reason may be that the version and groupId would then be mixed
into a
pom when you may not want it to be.
That should never happen. The mixin definition should make that clear.
Since version, groupId and artifactId CAN be specified in the mixin
they have to be ignored.
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.
A mixin is a type of inheritance so the same rules apply.
Absolutely not. From the way it has been described, a mixin is more
like an aspect in Java. It is injecting behavior or attributes into a
project, the project is not inheriting them.
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.
It's the same behavior. If you place a mixin below a pom in the
relationship, then the mixin gets priority; it you place the mixin
above the
pom in the hierarchy, the child gets the priority.
Huh? I assume you mean in the XML of a pom? Are you saying that
defining a mixin before the parent element causes the mixin to take
precedence over the parent or if it is after then the parent wins?
Frankly, I wasn't even talking about the parent. I was talking about
the mixin and how it relates to the definitions within the same pom
where the mixin is referenced. I'm quite certain there will be cases
where it is not desirable to have the behavior of including a mixin to
be the same as inheriting from a parent.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
