Re: PROPOSAL: Remote Profiles ( a limited alternative to mixins )
I've not yet looked at maven internal code about how one might implement this ( to be honest, at this point in time I'm not sure even know WHERE to look, other than poking around classes named Profile :) So yes - intuition on my part and just logic really. How adding something like this to the system affects the build stability is highly important, main reason I was thinking that it SHOULDN'T support version ranges. From immediate thoughts I don't think this would be any more unstability to the mix that the existing profile support doesn't already add to the mix ( profiles in ~/.m2/settings.xml being among the most unstable/unpredicatble IMHO ). Is there currently any way of maven telling a user WHERE a profile was included from? -pl allows you to select profiles but there doesn't seem to be any option to LIST profiles? I could see that being very handy, also failing the build if a non-existing profile is requested ( maven currently only WARNs about the non existing profile ). -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Sun, Dec 4, 2011 at 5:50 AM, Jason van Zyl ja...@tesla.io wrote: 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.
Re: PROPOSAL: Remote Profiles ( a limited alternative to mixins )
Profile are supposed to contains optional things. AFAIK it is always possible to disable a profile (-P!profileId). I don't think it is the same for mixins. I don't see a use case where mixins should be disabled. I even believe it is bad for build reproducibility. My 2 cents. De : Mark Derricutt m...@talios.com À : Maven Developers List dev@maven.apache.org Envoyé le : Lundi 5 Décembre 2011 11h31 Objet : Re: PROPOSAL: Remote Profiles ( a limited alternative to mixins ) I've not yet looked at maven internal code about how one might implement this ( to be honest, at this point in time I'm not sure even know WHERE to look, other than poking around classes named Profile :) So yes - intuition on my part and just logic really. How adding something like this to the system affects the build stability is highly important, main reason I was thinking that it SHOULDN'T support version ranges. From immediate thoughts I don't think this would be any more unstability to the mix that the existing profile support doesn't already add to the mix ( profiles in ~/.m2/settings.xml being among the most unstable/unpredicatble IMHO ). Is there currently any way of maven telling a user WHERE a profile was included from? -pl allows you to select profiles but there doesn't seem to be any option to LIST profiles? I could see that being very handy, also failing the build if a non-existing profile is requested ( maven currently only WARNs about the non existing profile ). -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Sun, Dec 4, 2011 at 5:50 AM, Jason van Zyl ja...@tesla.io wrote: 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. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: PROPOSAL: Remote Profiles ( a limited alternative to mixins )
the code is in DefaultModelBuilder [1] Regards, Hervé [1] http://maven.apache.org/ref/3.0.4/maven-model-builder/ Le Lundi 5 Décembre 2011 23:31:03 Mark Derricutt a écrit : I've not yet looked at maven internal code about how one might implement this ( to be honest, at this point in time I'm not sure even know WHERE to look, other than poking around classes named Profile :) So yes - intuition on my part and just logic really. How adding something like this to the system affects the build stability is highly important, main reason I was thinking that it SHOULDN'T support version ranges. From immediate thoughts I don't think this would be any more unstability to the mix that the existing profile support doesn't already add to the mix ( profiles in ~/.m2/settings.xml being among the most unstable/unpredicatble IMHO ). Is there currently any way of maven telling a user WHERE a profile was included from? -pl allows you to select profiles but there doesn't seem to be any option to LIST profiles? I could see that being very handy, also failing the build if a non-existing profile is requested ( maven currently only WARNs about the non existing profile ). 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. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: PROPOSAL: Remote Profiles ( a limited alternative to mixins )
On Sat, Dec 3, 2011 at 5:50 AM, Mark Derricutt m...@talios.com 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. Maintaining common meta-data without mixin's is a major PITA for projects like James who have scores of modules organised by consumer product not function. It leads to lots of unnecessary duplication. Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: PROPOSAL: Remote Profiles ( a limited alternative to mixins )
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; modelVersion4.0.0/modelVersion ... profiles profile idosgibundle/id dependency groupIdcom.talios/groupId artifactIdosgibundle/artifactId version1.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 typepom/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
PROPOSAL: Remote Profiles ( a limited alternative to mixins )
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; modelVersion4.0.0/modelVersion ... profiles profile idosgibundle/id dependency groupIdcom.talios/groupId artifactIdosgibundle/artifactId version1.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 typepom/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
