It's not just about ignorig the ids. What about the distmgt info that
would be needed to deploy... Or filtering or processing of it? I think
it's just better to keep processing of the Nixon separate.
--Brian (mobile)
On Dec 18, 2008, at 10:15 AM, Ralph Goers <ralph.go...@dslextreme.com>
wrote:
On Dec 18, 2008, at 6:17 AM, Brian E. Fox wrote:
I mentioned an idea in my review that seems to have been
overlooked. I
think a regular .pom in the repository shouldn't be able to be used
as a
"mixin". We should keep inheritance and mixins separate. The way I
would
do it is with a new packaging type of mixin that would take another
xml
file like mixin.xml and deploy that to the repository, similar to a
classified artifact. You have the mixin's pom and then the mixin
itself.
Only the mixin file can be used for inclusion in a <mixin> element.
This
way the mixin can be abstract and only contain the appropriate
fragments, yet have a separate pom with all the info needed to
build and
deploy said mixin to a remote repository. Mixins are useless if they
can't be put into a repo.
No, this wasn't overlooked. I hadn't thought of just using a new
packaging type. I was thinking of a different file extension but
using a new packaging type makes much more sense. However, I'm not
sure having a separate file is really necessary. Just requiring the
mixin to have a version, artifactId and groupId and having those be
ignored when injecting the mixin should be suficient. And having the
packaging type of mixin would also prevent the pom from being used
in any other way - unless, of course, we want to allow mixins to be
able to have a parent mixin.
anyone wanna play a drinking game on the thread for each mixin
mention?
;-)
No thanks. Too early in the morning :-)
Ralph
---------------------------------------------------------------------
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