The profile mechanism is how any new mixin system would work. No other mechanism internally is really suited to provide full access to the model in the right place. Not sure if you looked at the code or this is intuition on your part but your analysis is correct in that it's collaboration with the profile mechanism. This is how mixins should work.
If you want to try you can take my bastardization and see if you can get it to work. But I would still encourage you to analyze what it would mean to grab something remotely, mix it in, and the resultant stability of the system. On Dec 2, 2011, at 9:50 PM, Mark Derricutt wrote: > Hey all, > > I was thinking again the other day about how mixins could be introduced to > maven to improve/fix some of the issues found with the rigid parent/child > lineage of poms. At the same time I was looking at the remote-resources > plugin and a small lightbulb went on in my mind - we all ready have > profiles in maven, for packaging up settings - why can't we source those > profiles from a repository? > > Something like: > > <?xml version="1.0" encoding="UTF-8"?> > <project xmlns="http://maven.apache.org/POM/4.0.0"; xmlns:xsi=" > http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/maven-v4_0_0.xsd";> > <modelVersion>4.0.0</modelVersion> > ... > <profiles> > <profile> > <id>osgibundle</id> > <dependency> > <groupId>com.talios</groupId> > <artifactId>osgibundle</artifactId> > <version>1.0.3</version> > </dependency> > </profile> > </profiles> > </project> > > In this project, we have a profile defined with an ID, and a single > top-level dependency which would direct maven to download the POM > identified by the dependency, and look for a profile defined with the same > ID - and inline it's definition and continue as normal. > > The caveats around this would be something like: > > - if your profile has a <dependency> element, then it MUST ONLY contain > <id> and <dependency> > - The dependency <type> is assumed to be <type>pom</type>. > - Similar to plugins, version ranges SHOULD NOT be resolvable ( looking at > [1] this allows maven to have a more guaranteed project outcome, just as > tho the profile was defined in the POM directly ). > > Unlike a totally new mixin system, this is an evolution of an existing > maven context, which may make it easier for people to understand. > > Thoughts? > > > [1] > http://maven.apache.org/guides/introduction/introduction-to-profiles.html > > > -- > "Great artists are extremely selfish and arrogant things" — Steven Wilson, > Porcupine Tree Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language
