Re: Mixins (was Re: POM construction specification)
2008/12/18 Jason van Zyl > On 18-Dec-08, at 3:02 PM, Stephen Connolly wrote: > >> Actually, I'm liking the Nixon name for these mixins >> > No chance. > So you're saying that chance is not a factor hmm sounds like a done deal so!
Re: Mixins (was Re: POM construction specification)
LOL On 18-Dec-08, at 3:07 PM, Shane Isbell wrote: On Thu, Dec 18, 2008 at 12:02 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: Actually, I'm liking the Nixon name for these mixins Sure, why not? We can just call mavenized mixins, Nixons. Now I just need a big pen to start blacking out sections of the spec. 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
Re: Mixins (was Re: POM construction specification)
On 18-Dec-08, at 3:02 PM, Stephen Connolly wrote: Actually, I'm liking the Nixon name for these mixins No chance. 2008/12/18 Ralph Goers On Dec 18, 2008, at 9:56 AM, Brian Fox wrote: 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. Yes, I agree (except with the Nixon name). I just used the coordinates as an example. 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 -- Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Mixins (was Re: POM construction specification)
On Thu, Dec 18, 2008 at 12:02 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > Actually, I'm liking the Nixon name for these mixins Sure, why not? We can just call mavenized mixins, Nixons. Now I just need a big pen to start blacking out sections of the spec.
Re: Mixins (was Re: POM construction specification)
Actually, I'm liking the Nixon name for these mixins 2008/12/18 Ralph Goers > > On Dec 18, 2008, at 9:56 AM, Brian Fox wrote: > > 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. >> >> > Yes, I agree (except with the Nixon name). I just used the coordinates as > an example. > > > Ralph > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
RE: Mixins (was Re: POM construction specification)
Gotta love Iphone autocorrect ;-) -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Thursday, December 18, 2008 1:09 PM To: Maven Developers List Subject: Re: Mixins (was Re: POM construction specification) 2008/12/18 Brian Fox > filtering or processing of it? I think it's just better to keep processing > of the Nixon separate. > > --Brian (mobile) I don't know that you'll ever get to process the Nixon... the best you can do is get him to do is resign, but his successor will probably pardon him so you'll be unable to process him. ;-) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Mixins (was Re: POM construction specification)
On Dec 18, 2008, at 9:56 AM, Brian Fox wrote: 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. Yes, I agree (except with the Nixon name). I just used the coordinates as an example. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM construction specification
On Dec 18, 2008, at 8:34 AM, Jason van Zyl wrote: 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. I am in complete agreement with what you are describing here. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Mixins (was Re: POM construction specification)
The Nixon is not crooked, it doesn't need processing. On Thu, Dec 18, 2008 at 10:08 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > 2008/12/18 Brian Fox > > > filtering or processing of it? I think it's just better to keep > processing > > of the Nixon separate. > > > > --Brian (mobile) > > > I don't know that you'll ever get to process the Nixon... the best you can > do is get him to do is resign, but his successor will probably pardon him > so > you'll be unable to process him. ;-) >
Re: Mixins (was Re: POM construction specification)
2008/12/18 Brian Fox > filtering or processing of it? I think it's just better to keep processing > of the Nixon separate. > > --Brian (mobile) I don't know that you'll ever get to process the Nixon... the best you can do is get him to do is resign, but his successor will probably pardon him so you'll be unable to process him. ;-)
Re: Mixins (was Re: POM construction specification)
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 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 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
Re: POM construction specification
On 18-Dec-08, at 9: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". In my examples it is a normal POM that parses on its own, but I actually need something now would make it not parse. Anyway I want to refactor for a while before I attempt to make a branch for this. 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 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. anyone wanna play a drinking game on the thread for each mixin mention? ;-) -Original Message- From: Shane Isbell [mailto:shane.isb...@gmail.com] Sent: Thursday, December 18, 2008 2:57 AM To: Maven Developers List Subject: Re: POM construction specification On Wed, Dec 17, 2008 at 11:49 PM, Ralph Goers wrote: On Dec 17, 2008, at 11:31 PM, Shane Isbell wrote: And I've said multiple times that that isn't an adequate definition. Jason's post provided a better clue but still doesn't define it. Your definition is about like me telling you that I am heading a JCP committee to define a new Java entity called mixin and in it you will be able to use all the existing java grammar but I tell you nothing more than that. Would you have a clue how that is useful? No it wouldn't be useful. But if you said a mixin is like an abstract class and all it's elements can be inherited exactly like an abstract class, then I would have a pretty good clue. Yes and no. Yes, that would be understandable but it would also be inaccurate. The problem here is that you are introducing multiple inheritance into the mix so that analogy doesn't fit. If we are talking about linearized inheritance, then the analogy is correct. Maven doesn't currently support that and I think that is a very good thing. The super pom is a type of multiple (linearized) inheritance. Shane - 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 -- Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Mixins (was Re: POM construction specification)
I think mixins are important, but I think in the short term trying to focus on bring the spec up to what is known to be the behavior right now is the focus. Once all those tests are done and the spec is comprehensive with an appendix, has example, and where tests refer to sections in the POM then I think we can move on to new features and changes. It's too early right now. On 18-Dec-08, at 10:15 AM, Ralph Goers 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 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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM construction specification
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
Mixins (was Re: POM construction specification)
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 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
RE: POM construction specification
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 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. anyone wanna play a drinking game on the thread for each mixin mention? ;-) -Original Message- From: Shane Isbell [mailto:shane.isb...@gmail.com] Sent: Thursday, December 18, 2008 2:57 AM To: Maven Developers List Subject: Re: POM construction specification On Wed, Dec 17, 2008 at 11:49 PM, Ralph Goers wrote: > > On Dec 17, 2008, at 11:31 PM, Shane Isbell wrote: > > >>> And I've said multiple times that that isn't an adequate definition. >>> Jason's post provided a better clue but still doesn't define it. Your >>> definition is about like me telling you that I am heading a JCP committee >>> to >>> define a new Java entity called mixin and in it you will be able to use >>> all >>> the existing java grammar but I tell you nothing more than that. Would >>> you >>> have a clue how that is useful? >>> >> >> No it wouldn't be useful. But if you said a mixin is like an abstract >> class >> and all it's elements can be inherited exactly like an abstract class, >> then >> I would have a pretty good clue. >> >> > Yes and no. Yes, that would be understandable but it would also be > inaccurate. The problem here is that you are introducing multiple > inheritance into the mix so that analogy doesn't fit. If we are talking about linearized inheritance, then the analogy is correct. Maven doesn't currently support that and I think that is a very good thing. The super pom is a type of multiple (linearized) inheritance. Shane - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM construction specification
On Wed, Dec 17, 2008 at 11:49 PM, Ralph Goers wrote: > > On Dec 17, 2008, at 11:31 PM, Shane Isbell wrote: > > >>> And I've said multiple times that that isn't an adequate definition. >>> Jason's post provided a better clue but still doesn't define it. Your >>> definition is about like me telling you that I am heading a JCP committee >>> to >>> define a new Java entity called mixin and in it you will be able to use >>> all >>> the existing java grammar but I tell you nothing more than that. Would >>> you >>> have a clue how that is useful? >>> >> >> No it wouldn't be useful. But if you said a mixin is like an abstract >> class >> and all it's elements can be inherited exactly like an abstract class, >> then >> I would have a pretty good clue. >> >> > Yes and no. Yes, that would be understandable but it would also be > inaccurate. The problem here is that you are introducing multiple > inheritance into the mix so that analogy doesn't fit. If we are talking about linearized inheritance, then the analogy is correct. Maven doesn't currently support that and I think that is a very good thing. The super pom is a type of multiple (linearized) inheritance. Shane
Re: POM construction specification
On Dec 17, 2008, at 11:31 PM, Shane Isbell wrote: And I've said multiple times that that isn't an adequate definition. Jason's post provided a better clue but still doesn't define it. Your definition is about like me telling you that I am heading a JCP committee to define a new Java entity called mixin and in it you will be able to use all the existing java grammar but I tell you nothing more than that. Would you have a clue how that is useful? No it wouldn't be useful. But if you said a mixin is like an abstract class and all it's elements can be inherited exactly like an abstract class, then I would have a pretty good clue. Yes and no. Yes, that would be understandable but it would also be inaccurate. The problem here is that you are introducing multiple inheritance into the mix so that analogy doesn't fit. Maven doesn't currently support that and I think that is a very good thing. Treating a mixin on an equal footing with the parent pom is just wrong IMO. Treating it like an aspect or as a way of "importing" things into a pom is OK as long as the rules are well defined. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM construction specification
On Dec 17, 2008, at 11:15 PM, Shane Isbell wrote: On Wed, Dec 17, 2008 at 10:35 PM, 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. 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
Re: POM construction specification
On Wed, Dec 17, 2008 at 11:22 PM, Ralph Goers wrote: > > On Dec 17, 2008, at 10:57 PM, Shane Isbell wrote: > > On Wed, Dec 17, 2008 at 9:47 PM, 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. >>> >> >> I've defined mixin within the spec and multiple times in this thread: a >> mixin is an abstract model, meaning it is not required to have all the >> required elements of a full pom. >> > > And I've said multiple times that that isn't an adequate definition. > Jason's post provided a better clue but still doesn't define it. Your > definition is about like me telling you that I am heading a JCP committee to > define a new Java entity called mixin and in it you will be able to use all > the existing java grammar but I tell you nothing more than that. Would you > have a clue how that is useful? No it wouldn't be useful. But if you said a mixin is like an abstract class and all it's elements can be inherited exactly like an abstract class, then I would have a pretty good clue. Shane
Re: POM construction specification
On Dec 17, 2008, at 10:57 PM, Shane Isbell wrote: On Wed, Dec 17, 2008 at 9:47 PM, 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. I've defined mixin within the spec and multiple times in this thread: a mixin is an abstract model, meaning it is not required to have all the required elements of a full pom. And I've said multiple times that that isn't an adequate definition. Jason's post provided a better clue but still doesn't define it. Your definition is about like me telling you that I am heading a JCP committee to define a new Java entity called mixin and in it you will be able to use all the existing java grammar but I tell you nothing more than that. Would you have a clue how that is useful? 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. The model-builder supports the capability to add mixins (as defined above). We still need to spec out how we want to handle things like resolving. I assume you mean the model-builder for 3.0? I guess I'll have to look at the code to figure out what is actually going on. In the long run I'm probably going to be in favor of only allowing single inheritance from a parent model. I might be inclined to agree with multiple mixins if they were actually defined. They are defined. See above. Not in any meaningful way. See above. 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. In short, I would recommend either removing mention of mixins from the document or actually documenting them. It is documented. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM construction specification
On Wed, Dec 17, 2008 at 10:35 PM, 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. 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. 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. > > > 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. > 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. Shane
Re: POM construction specification
On Wed, Dec 17, 2008 at 9:47 PM, 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. I've defined mixin within the spec and multiple times in this thread: a mixin is an abstract model, meaning it is not required to have all the required elements of a full pom. > 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. The model-builder supports the capability to add mixins (as defined above). We still need to spec out how we want to handle things like resolving. > > > In the long run I'm probably going to be in favor of only allowing single > inheritance from a parent model. I might be inclined to agree with multiple > mixins if they were actually defined. They are defined. See above. > 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. > > In short, I would recommend either removing mention of mixins from the > document or actually documenting them. It is documented. Thanks, Shane
Re: POM construction specification
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. 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. 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. 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 ja
Re: POM construction specification
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
Re: POM construction specification
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. 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. In the long run I'm probably going to be in favor of only allowing single inheritance from a parent model. 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. In short, I would recommend either removing mention of mixins from the document or actually documenting them. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM construction specification
On 18/12/2008, at 1:51 PM, Shane Isbell wrote: Comments below: On Tue, Dec 16, 2008 at 10:27 PM, Brett Porter wrote: I fixed some typos - is it ok to regenerate the PDF? (mine comes out slightly different on the Mac but it's all there AFAICT). Just to add to what Brian and Ralph have already said: 3.1 - I think we have to knock multiple inheritance out at this stage, even if it is noted as a possibility for general model building, I don't think it's appropriate for the Maven rules. I know we are playing with definitions here; but if someone chooses to define a complete pom as a mixin, then it's the same as multiple inheritance. Exactly :) I think that makes a separate parent unnecessary, and possibly confusing (like which group/version to inherit). 3.2 - We should just define this by the current behaviour IMO, then look at how we fix it going forward (See below on versioning) 3.3 - I had the same confusion as Brian. Why are collections not joined? I'm just defining current behavior in regards to these collections. If the spec doesn't match current behavior, then we need to modify the spec. Yep, I think I just got a bit confused... I thought 3.2 was waiting for a "new" definition, not the current one. 2.2 - I think map handling needs to be defined for the same reason so that duplicate keys can be merged I need more information about what you are thinking here. Am wondering how this is handled: key1 value1 key1 value2 Will this be represented as a collection and all kept, with the eventual translation back to a map sorting out the key handling? Thanks, Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM construction specification
rent case, where you have a completely different project format that you want to put into the canonical data format and have it processed as though it were a pom. > > > Is this what you expect? > > BTW, should we now delete the wiki page that held basically the same info? > > Cheers, > Brett > > > On 17/12/2008, at 3:32 PM, Brian E. Fox wrote: > > "The only difference between a parent project and a mixin is that the >> mixin is >> abstract (not a complete model)." >> >> Is that really true? A Mixin should be deployed to the repository, which >> essentially means it needs to be complete enough to id and thus a complete >> model. It should be deployed as a classified artifact though to avoid mixing >> in the instructions for building/deploying from those that are intended to >> be mixed in. (ie the mixin's pom is separate) >> >> 3.1: what about multiple parents? I assume it's the first one, but should >> be explicit in the spec. >> 3.2: section is blank but contentious based on current behavior and the >> in-ability to use properties and inheritance together. >> 3.3: I don't understand this statement. A child always overrides the >> parent or joins with it. Are you saying that the parent wins here? Also >> pluginRepositories is going away soon. In general why can't the things >> listed here be extended? >> 3.4 shouldn't project.distMgt.relocation be inherited if the relocation >> lists the group? (group/artifact/version ones should be skipped, but if >> you're relocating everything in a group, it would make sense to do this at >> the top of that group tree pom) >> 3.5 I agree with Ralph here that Final is the wrong term. Private is more >> appropriate. >> >> I started this in the morning and didn't finish yet so sending what I >> have. >> >> -Original Message- >> From: Ralph Goers [mailto:ralph.go...@dslextreme.com] >> Sent: Tuesday, December 16, 2008 3:59 AM >> To: Maven Developers List >> Subject: Re: POM construction specification >> >> >> On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote: >> >> This is for the general population but I'm nudging you Ralph because >>> I know that you want to make some changes for not requiring the >>> version in the parent element. >>> >>> >> >> You should have warned me to have a glass of wine before attempting to >> read all these math notations. :-) Or put a link to >> http://en.wikipedia.org/wiki/Table_of_mathematical_symbols >> for those of use who haven't had a math class in the last 25 years. >> The funny thing is, I have a B.S. in Physics. Man it has been a long >> time. :-( >> >> Comments: >> 1.1 Mentions there are 465 model properties. An appendix should list >> them. Specifically, I'd like to see "provides" listed along with the >> project's groupId, artifactId and version and "requires" in the >> dependency declaration - or whatever other way that kind of metadata >> will be added. >> 2.1 & 2.2 Is all this simply stating that the closest definition wins >> and when two or more are equally close then the first one wins? >> 2.4 The only "definition" of mixin is "The only difference between a >> parent pro ject and a mixin is that the mixin is >> abstract (not a complete model)". That sure leaves a lot to the >> imagination. And what exactly makes a model "incomplete"? Isn't a pom >> with just a dependencyManagement complete? I also found myself >> wondering that even though it might be possible to support extending >> multiple parents, should we? I could see allowing only one parent but >> multiple mixins. >> 3.1 Even though may be obvious, it should explicitly state that >> artifactId is always required. >> 3.4 Why can't the groupId be inherited from its parent (or at least be >> set from project.parent.groupIdt)? >> 3.4 The footnote says the artifactId can be inherited from the parent. >> That makes no sense to me. Every pom should represent a unique >> artifact or at least a unique pom. >> 3.5 I found the statement This will mark the container as final, thus >> preventing inheritance:" as misleading. In java terms this would mean >> a child pom attempting to define the same plugin would fail. The >> setting of "inherited" to false in the sample indicates to me the >> opposite, the plugin definition in the parent is invisible to the >> child. Here is a question though. If A overrides a plugin defined i
Re: POM construction specification
On Tue, Dec 16, 2008 at 11:25 PM, Ralph Goers wrote: > Mine below. OK. As I read 2.2 it basically only says the first definition wins. 2.1 > talks about a collection of models, but it doesn't say anything about > dependency resolution, either directly or in its references to section 3. In > other words, I don't see anything that describes how the version of an > artifact is determined when that artifact occurs in several places in the > dependency tree. This is an issue for Mercury and the resolving rules. It's not covered in project building. > > 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. Personally, I think that including them in this list is just misleading. The > effect is exactly the same. The distinction is important. Take your case of not including the version in the project.parent.version. By removing this property, pom construction fails as it is defined in the spec. If it is a direct inheritance, it would not fail. Shane
Re: POM construction specification
Mine below. On Dec 16, 2008, at 10:36 PM, Shane Isbell wrote: Comments in line On Tue, Dec 16, 2008 at 12:58 AM, Ralph Goers >wrote: On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote: This is for the general population but I'm nudging you Ralph because I know that you want to make some changes for not requiring the version in the parent element. You should have warned me to have a glass of wine before attempting to read all these math notations. :-) Or put a link to http://en.wikipedia.org/wiki/Table_of_mathematical_symbols for those of use who haven't had a math class in the last 25 years. The funny thing is, I have a B.S. in Physics. Man it has been a long time. :-( Comments: 2.1 & 2.2 Is all this simply stating that the closest definition wins and when two or more are equally close then the first one wins? 2.1 covers the high level processing starting with the transformation from the original model (XML) to the canonical model and going through interpolation and other rules. 2.2 does cover which property wins for: singletons, collections and sets. OK. As I read 2.2 it basically only says the first definition wins. 2.1 talks about a collection of models, but it doesn't say anything about dependency resolution, either directly or in its references to section 3. In other words, I don't see anything that describes how the version of an artifact is determined when that artifact occurs in several places in the dependency tree. 2.4 The only "definition" of mixin is "The only difference between a parent pro ject and a mixin is that the mixin is abstract (not a complete model)". That sure leaves a lot to the imagination. And what exactly makes a model "incomplete"? Isn't a pom with just a dependencyManagement complete? I also found myself wondering that even though it might be possible to support extending multiple parents, should we? I could see allowing only one parent but multiple mixins. A mixin wouldn't be required to have things like project.version or project.groupId. This makes the model abstract. From the framework's perspective, it's all just a linear set of complete or incomplete models Whether it's considered multiple parents or a chains of inherited parents, it's all processed the same. My take is that if it's a complete model, it's actually just another parent. We are really just dealing with definitions here, it doesn't change processing. We can discuss more on what the definitions should be. 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. 3.4 Why can't the groupId be inherited from its parent (or at least be set from project.parent.groupIdt)? Technically, it isn't inherited from the parent. If groupId is not defined, the project.parent.groupId is used (footnote 1). Personally, I think that including them in this list is just misleading. The effect is exactly the same. 3.4 The footnote says the artifactId can be inherited from the parent. That makes no sense to me. Every pom should represent a unique artifact or at least a unique pom. I'll change the spec doc. But when we throw in mixins, it's not exactly clear whether things like artifactId shouldn't be inherited. This will be one area we will need to discuss as we move toward mixins. I think you should start another thread to explain what the concept of mixins is. You referenced it once as the "solution" for importing managed dependencies. Some concrete examples would be nice. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM construction specification
I have. -Original Message- From: Ralph Goers [mailto:ralph.go...@dslextreme.com] Sent: Tuesday, December 16, 2008 3:59 AM To: Maven Developers List Subject: Re: POM construction specification On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote: This is for the general population but I'm nudging you Ralph because I know that you want to make some changes for not requiring the version in the parent element. You should have warned me to have a glass of wine before attempting to read all these math notations. :-) Or put a link to http://en.wikipedia.org/wiki/Table_of_mathematical_symbols for those of use who haven't had a math class in the last 25 years. The funny thing is, I have a B.S. in Physics. Man it has been a long time. :-( Comments: 1.1 Mentions there are 465 model properties. An appendix should list them. Specifically, I'd like to see "provides" listed along with the project's groupId, artifactId and version and "requires" in the dependency declaration - or whatever other way that kind of metadata will be added. 2.1 & 2.2 Is all this simply stating that the closest definition wins and when two or more are equally close then the first one wins? 2.4 The only "definition" of mixin is "The only difference between a parent pro ject and a mixin is that the mixin is abstract (not a complete model)". That sure leaves a lot to the imagination. And what exactly makes a model "incomplete"? Isn't a pom with just a dependencyManagement complete? I also found myself wondering that even though it might be possible to support extending multiple parents, should we? I could see allowing only one parent but multiple mixins. 3.1 Even though may be obvious, it should explicitly state that artifactId is always required. 3.4 Why can't the groupId be inherited from its parent (or at least be set from project.parent.groupIdt)? 3.4 The footnote says the artifactId can be inherited from the parent. That makes no sense to me. Every pom should represent a unique artifact or at least a unique pom. 3.5 I found the statement This will mark the container as final, thus preventing inheritance:" as misleading. In java terms this would mean a child pom attempting to define the same plugin would fail. The setting of "inherited" to false in the sample indicates to me the opposite, the plugin definition in the parent is invisible to the child. Here is a question though. If A overrides a plugin defined in the super pom and has inherited true, then B extends A and overrides the plugin and sets inherited to false, what will C which extends from B get? It should see the definition in A. Or does this whole section mean that the plugin definition in B inherits nothing from A? 3.8 "the element will be inherited." Unless the parent definition has false ? I don't see anything in here about being able to locate a parent without having to know its version. Within the scope of the purpose of this document it may not be relevant, but at the very least somewhere in section 3 it should state that if a parent is specified than which elements are required. I hope this was the kind of feedback you were looking for. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - 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 -- We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM construction specification
On 16-Dec-08, at 3:58 AM, Ralph Goers wrote: On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote: This is for the general population but I'm nudging you Ralph because I know that you want to make some changes for not requiring the version in the parent element. You should have warned me to have a glass of wine before attempting to read all these math notations. :-) Or put a link to http://en.wikipedia.org/wiki/Table_of_mathematical_symbols for those of use who haven't had a math class in the last 25 years. The funny thing is, I have a B.S. in Physics. Man it has been a long time. :-( Comments: 1.1 Mentions there are 465 model properties. An appendix should list them. Specifically, I'd like to see "provides" listed along with the project's groupId, artifactId and version and "requires" in the dependency declaration - or whatever other way that kind of metadata will be added. We should definitely add them to the appendix. If you actually look at the implementation the parsers are domain specific and they produce the set of model properties. I think Shane did what was correct in that he focused on a concrete implementation and got it working. So right now the domain specific parser is hand-written. There is no reason that this parser cannot be generated with modello and when we do that we can use the descriptions in the modello model to generate an appendix with a description of each property. 2.1 & 2.2 Is all this simply stating that the closest definition wins and when two or more are equally close then the first one wins? Let me add actual examples with POMs and I think it will be more clear. 2.4 The only "definition" of mixin is "The only difference between a parent pro ject and a mixin is that the mixin is abstract (not a complete model)". That sure leaves a lot to the imagination. And what exactly makes a model "incomplete"? Isn't a pom with just a dependencyManagement complete? I also found myself wondering that even though it might be possible to support extending multiple parents, should we? I could see allowing only one parent but multiple mixins. 3.1 Even though may be obvious, it should explicitly state that artifactId is always required. 3.4 Why can't the groupId be inherited from its parent (or at least be set from project.parent.groupIdt)? It can be. The Maven POMs exhibit this property and it works fine so I'll fix that. 3.4 The footnote says the artifactId can be inherited from the parent. That makes no sense to me. Every pom should represent a unique artifact or at least a unique pom. Yup. 3.5 I found the statement This will mark the container as final, thus preventing inheritance:" as misleading. In java terms this would mean a child pom attempting to define the same plugin would fail. The setting of "inherited" to false in the sample indicates to me the opposite, the plugin definition in the parent is invisible to the child. Here is a question though. If A overrides a plugin defined in the super pom and has inherited true, then B extends A and overrides the plugin and sets inherited to false, what will C which extends from B get? It should see the definition in A. Or does this whole section mean that the plugin definition in B inherits nothing from A? 3.8 "the element will be inherited." Unless the parent definition has false ? I don't see anything in here about being able to locate a parent without having to know its version. Within the scope of the purpose of this document it may not be relevant, but at the very least somewhere in section 3 it should state that if a parent is specified than which elements are required. I think if it has anything to do with POM construction then we need to include it in this document. I hope this was the kind of feedback you were looking for. This is great feedback. I'll get this converted into Confluence by the end of the week and then it will be easier to collaborate. Shane also reversed engineered the rules because nothing was ever documented as it grew organically. I think a few rounds of doing this where we clarify and the rules and we'll be in a lot better shape. I have started a POM construction test suite which will act as a validation for the specification which will be complete by alpha-2. For alpha-1 I had the goal of some specific builds working to get the ball rolling. The rigor will start after alpha-2 which combined with some of the integration testing tools we have I think will ensure we go forward and never backward again. 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 ---
Re: POM construction specification
Comments in line On Tue, Dec 16, 2008 at 12:58 AM, Ralph Goers wrote: > > On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote: > > This is for the general population but I'm nudging you Ralph because I >> know that you want to make some changes for not requiring the version in the >> parent element. >> >> > > You should have warned me to have a glass of wine before attempting to read > all these math notations. :-) Or put a link to > http://en.wikipedia.org/wiki/Table_of_mathematical_symbols for those of > use who haven't had a math class in the last 25 years. The funny thing is, I > have a B.S. in Physics. Man it has been a long time. :-( > > Comments: > 2.1 & 2.2 Is all this simply stating that the closest definition wins and > when two or more are equally close then the first one wins? 2.1 covers the high level processing starting with the transformation from the original model (XML) to the canonical model and going through interpolation and other rules. 2.2 does cover which property wins for: singletons, collections and sets. > 2.4 The only "definition" of mixin is "The only difference between a parent > pro ject and a mixin is that the mixin is > abstract (not a complete model)". That sure leaves a lot to the > imagination. And what exactly makes a model "incomplete"? Isn't a pom with > just a dependencyManagement complete? I also found myself wondering that > even though it might be possible to support extending multiple parents, > should we? I could see allowing only one parent but multiple mixins. A mixin wouldn't be required to have things like project.version or project.groupId. This makes the model abstract. From the framework's perspective, it's all just a linear set of complete or incomplete models Whether it's considered multiple parents or a chains of inherited parents, it's all processed the same. My take is that if it's a complete model, it's actually just another parent. We are really just dealing with definitions here, it doesn't change processing. We can discuss more on what the definitions should be. > > 3.4 Why can't the groupId be inherited from its parent (or at least be set > from project.parent.groupIdt)? Technically, it isn't inherited from the parent. If groupId is not defined, the project.parent.groupId is used (footnote 1). > > 3.4 The footnote says the artifactId can be inherited from the parent. That > makes no sense to me. Every pom should represent a unique artifact or at > least a unique pom. I'll change the spec doc. But when we throw in mixins, it's not exactly clear whether things like artifactId shouldn't be inherited. This will be one area we will need to discuss as we move toward mixins. > > 3.5 I found the statement This will mark the container as final, thus > preventing inheritance:" as misleading. In java terms this would mean a > child pom attempting to define the same plugin would fail. The setting of > "inherited" to false in the sample indicates to me the opposite, the plugin > definition in the parent is invisible to the child. Here is a question > though. If A overrides a plugin defined in the super pom and has inherited > true, then B extends A and overrides the plugin and sets inherited to false, > what will C which extends from B get? It should see the definition in A. Or > does this whole section mean that the plugin definition in B inherits > nothing from A? You raise some good points. I was struggling a bit with the terms here. I'll give it some more thought. > > 3.8 "the element will be inherited." Unless the parent definition has > false ? > > I don't see anything in here about being able to locate a parent without > having to know its version. Within the scope of the purpose of this document > it may not be relevant, but at the very least somewhere in section 3 it > should state that if a parent is specified than which elements are required. Locating parents fell a bit outside of this original spec, but I think it's worth adding something about how this is to be handled. We would need some rule that says a parent.version is not required. And also how to cover the situation where project.parent.version and project.version are both missing. Thanks, Shane
Re: POM construction specification
I fixed some typos - is it ok to regenerate the PDF? (mine comes out slightly different on the Mac but it's all there AFAICT). Just to add to what Brian and Ralph have already said: 3.1 - I think we have to knock multiple inheritance out at this stage, even if it is noted as a possibility for general model building, I don't think it's appropriate for the Maven rules. 3.2 - We should just define this by the current behaviour IMO, then look at how we fix it going forward (See below on versioning) 3.3 - I had the same confusion as Brian. Why are collections not joined? Some more things: 1.1 - mentioned this before, but should be use a valid URI that perhaps matches the POM namespace? http://maven.apache.org/POM/... 2.2 - I didn't see anything that says that in a set, a property should overwrite a previous one if it already exists (and define how equality is measured)? 2.2 - I think map handling needs to be defined for the same reason so that duplicate keys can be merged 3.6.2 - why is the parent artifact ID listed in the (1-3) section? 3.6.2 - are join, nop and delete in a different order to the following bullets? 3.8 - how are properties represented by XML elements in the current schema handled in the URI? the "combine" technique is listed as a property, but is the attribute actually recognised as something different? 4.1 - refers to 3.4, but I think it means 3.6 4.1 - how is plugin configuration handled? it only details the combination of the artifact portion. Should executions be explicitly forbidden in the management just for clarity? 5.1.1 - timestamp format should be described? 5.1.1 - is the basedir absolute? 5.1.2 - this seems too "implementation specific" 5.1.4 - this is a self-referential definition. I don't think the difference between types of properties is clear enough - maybe defining system as dominant and environment as recessive is more descriptive 5.2.2 - need to list what the build directory elements are 5.3 - profiles are not addressed elsewhere - should their processing as an additional form of inheritance be described? Versioning... I really would like to understand how this is going to work. My impression is the following: - this document would be locked down to current behaviour as 4.0.0 (warts and all) - a new version of the document would make addition and changes, and would be a completely new rule set - the URIs would be the same, not including a version. - to operate on two versions of the model, the older would be upgraded to the new one first by a mapping of properties from one to the other. If the mapping was complicated it might need to be handled by an external converter - but the inheritance should always operate on two models of the same version. The problem here is that you can no longer honour some of the older rules from inherited POMs - but that may not be a serious consequence. Is this what you expect? BTW, should we now delete the wiki page that held basically the same info? Cheers, Brett On 17/12/2008, at 3:32 PM, Brian E. Fox wrote: "The only difference between a parent project and a mixin is that the mixin is abstract (not a complete model)." Is that really true? A Mixin should be deployed to the repository, which essentially means it needs to be complete enough to id and thus a complete model. It should be deployed as a classified artifact though to avoid mixing in the instructions for building/ deploying from those that are intended to be mixed in. (ie the mixin's pom is separate) 3.1: what about multiple parents? I assume it's the first one, but should be explicit in the spec. 3.2: section is blank but contentious based on current behavior and the in-ability to use properties and inheritance together. 3.3: I don't understand this statement. A child always overrides the parent or joins with it. Are you saying that the parent wins here? Also pluginRepositories is going away soon. In general why can't the things listed here be extended? 3.4 shouldn't project.distMgt.relocation be inherited if the relocation lists the group? (group/artifact/version ones should be skipped, but if you're relocating everything in a group, it would make sense to do this at the top of that group tree pom) 3.5 I agree with Ralph here that Final is the wrong term. Private is more appropriate. I started this in the morning and didn't finish yet so sending what I have. -Original Message- From: Ralph Goers [mailto:ralph.go...@dslextreme.com] Sent: Tuesday, December 16, 2008 3:59 AM To: Maven Developers List Subject: Re: POM construction specification On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote: This is for the general population but I'm nudging you Ralph because I know that you want to make some changes for not requiring the version in the parent element. You s
Re: POM construction specification
The way I read 3.4 the parent does not win. The child declaration simply overrides the parent. Consider project developers. If specified in a child then only those developers participate in this subproject. developers specified in the parent are ignored. Whether it makes sense to do it that way is a different question. Ralph On Dec 16, 2008, at 8:32 PM, Brian E. Fox wrote: "The only difference between a parent project and a mixin is that the mixin is abstract (not a complete model)." Is that really true? A Mixin should be deployed to the repository, which essentially means it needs to be complete enough to id and thus a complete model. It should be deployed as a classified artifact though to avoid mixing in the instructions for building/ deploying from those that are intended to be mixed in. (ie the mixin's pom is separate) 3.1: what about multiple parents? I assume it's the first one, but should be explicit in the spec. 3.2: section is blank but contentious based on current behavior and the in-ability to use properties and inheritance together. 3.3: I don't understand this statement. A child always overrides the parent or joins with it. Are you saying that the parent wins here? Also pluginRepositories is going away soon. In general why can't the things listed here be extended? 3.4 shouldn't project.distMgt.relocation be inherited if the relocation lists the group? (group/artifact/version ones should be skipped, but if you're relocating everything in a group, it would make sense to do this at the top of that group tree pom) 3.5 I agree with Ralph here that Final is the wrong term. Private is more appropriate. I started this in the morning and didn't finish yet so sending what I have. -Original Message- From: Ralph Goers [mailto:ralph.go...@dslextreme.com] Sent: Tuesday, December 16, 2008 3:59 AM To: Maven Developers List Subject: Re: POM construction specification On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote: This is for the general population but I'm nudging you Ralph because I know that you want to make some changes for not requiring the version in the parent element. You should have warned me to have a glass of wine before attempting to read all these math notations. :-) Or put a link to http://en.wikipedia.org/wiki/Table_of_mathematical_symbols for those of use who haven't had a math class in the last 25 years. The funny thing is, I have a B.S. in Physics. Man it has been a long time. :-( Comments: 1.1 Mentions there are 465 model properties. An appendix should list them. Specifically, I'd like to see "provides" listed along with the project's groupId, artifactId and version and "requires" in the dependency declaration - or whatever other way that kind of metadata will be added. 2.1 & 2.2 Is all this simply stating that the closest definition wins and when two or more are equally close then the first one wins? 2.4 The only "definition" of mixin is "The only difference between a parent pro ject and a mixin is that the mixin is abstract (not a complete model)". That sure leaves a lot to the imagination. And what exactly makes a model "incomplete"? Isn't a pom with just a dependencyManagement complete? I also found myself wondering that even though it might be possible to support extending multiple parents, should we? I could see allowing only one parent but multiple mixins. 3.1 Even though may be obvious, it should explicitly state that artifactId is always required. 3.4 Why can't the groupId be inherited from its parent (or at least be set from project.parent.groupIdt)? 3.4 The footnote says the artifactId can be inherited from the parent. That makes no sense to me. Every pom should represent a unique artifact or at least a unique pom. 3.5 I found the statement This will mark the container as final, thus preventing inheritance:" as misleading. In java terms this would mean a child pom attempting to define the same plugin would fail. The setting of "inherited" to false in the sample indicates to me the opposite, the plugin definition in the parent is invisible to the child. Here is a question though. If A overrides a plugin defined in the super pom and has inherited true, then B extends A and overrides the plugin and sets inherited to false, what will C which extends from B get? It should see the definition in A. Or does this whole section mean that the plugin definition in B inherits nothing from A? 3.8 "the element will be inherited." Unless the parent definition has false ? I don't see anything in here about being able to locate a parent without having to know its version. Within the scope of the purpose of this document it may not be relevant, but at the very least somewhere in section 3 it should state that if a parent is specified than which elements are required
RE: POM construction specification
"The only difference between a parent project and a mixin is that the mixin is abstract (not a complete model)." Is that really true? A Mixin should be deployed to the repository, which essentially means it needs to be complete enough to id and thus a complete model. It should be deployed as a classified artifact though to avoid mixing in the instructions for building/deploying from those that are intended to be mixed in. (ie the mixin's pom is separate) 3.1: what about multiple parents? I assume it's the first one, but should be explicit in the spec. 3.2: section is blank but contentious based on current behavior and the in-ability to use properties and inheritance together. 3.3: I don't understand this statement. A child always overrides the parent or joins with it. Are you saying that the parent wins here? Also pluginRepositories is going away soon. In general why can't the things listed here be extended? 3.4 shouldn't project.distMgt.relocation be inherited if the relocation lists the group? (group/artifact/version ones should be skipped, but if you're relocating everything in a group, it would make sense to do this at the top of that group tree pom) 3.5 I agree with Ralph here that Final is the wrong term. Private is more appropriate. I started this in the morning and didn't finish yet so sending what I have. -Original Message- From: Ralph Goers [mailto:ralph.go...@dslextreme.com] Sent: Tuesday, December 16, 2008 3:59 AM To: Maven Developers List Subject: Re: POM construction specification On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote: > This is for the general population but I'm nudging you Ralph because > I know that you want to make some changes for not requiring the > version in the parent element. > You should have warned me to have a glass of wine before attempting to read all these math notations. :-) Or put a link to http://en.wikipedia.org/wiki/Table_of_mathematical_symbols for those of use who haven't had a math class in the last 25 years. The funny thing is, I have a B.S. in Physics. Man it has been a long time. :-( Comments: 1.1 Mentions there are 465 model properties. An appendix should list them. Specifically, I'd like to see "provides" listed along with the project's groupId, artifactId and version and "requires" in the dependency declaration - or whatever other way that kind of metadata will be added. 2.1 & 2.2 Is all this simply stating that the closest definition wins and when two or more are equally close then the first one wins? 2.4 The only "definition" of mixin is "The only difference between a parent pro ject and a mixin is that the mixin is abstract (not a complete model)". That sure leaves a lot to the imagination. And what exactly makes a model "incomplete"? Isn't a pom with just a dependencyManagement complete? I also found myself wondering that even though it might be possible to support extending multiple parents, should we? I could see allowing only one parent but multiple mixins. 3.1 Even though may be obvious, it should explicitly state that artifactId is always required. 3.4 Why can't the groupId be inherited from its parent (or at least be set from project.parent.groupIdt)? 3.4 The footnote says the artifactId can be inherited from the parent. That makes no sense to me. Every pom should represent a unique artifact or at least a unique pom. 3.5 I found the statement This will mark the container as final, thus preventing inheritance:" as misleading. In java terms this would mean a child pom attempting to define the same plugin would fail. The setting of "inherited" to false in the sample indicates to me the opposite, the plugin definition in the parent is invisible to the child. Here is a question though. If A overrides a plugin defined in the super pom and has inherited true, then B extends A and overrides the plugin and sets inherited to false, what will C which extends from B get? It should see the definition in A. Or does this whole section mean that the plugin definition in B inherits nothing from A? 3.8 "the element will be inherited." Unless the parent definition has false ? I don't see anything in here about being able to locate a parent without having to know its version. Within the scope of the purpose of this document it may not be relevant, but at the very least somewhere in section 3 it should state that if a parent is specified than which elements are required. I hope this was the kind of feedback you were looking for. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM construction specification
On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote: This is for the general population but I'm nudging you Ralph because I know that you want to make some changes for not requiring the version in the parent element. You should have warned me to have a glass of wine before attempting to read all these math notations. :-) Or put a link to http://en.wikipedia.org/wiki/Table_of_mathematical_symbols for those of use who haven't had a math class in the last 25 years. The funny thing is, I have a B.S. in Physics. Man it has been a long time. :-( Comments: 1.1 Mentions there are 465 model properties. An appendix should list them. Specifically, I'd like to see "provides" listed along with the project's groupId, artifactId and version and "requires" in the dependency declaration - or whatever other way that kind of metadata will be added. 2.1 & 2.2 Is all this simply stating that the closest definition wins and when two or more are equally close then the first one wins? 2.4 The only "definition" of mixin is "The only difference between a parent pro ject and a mixin is that the mixin is abstract (not a complete model)". That sure leaves a lot to the imagination. And what exactly makes a model "incomplete"? Isn't a pom with just a dependencyManagement complete? I also found myself wondering that even though it might be possible to support extending multiple parents, should we? I could see allowing only one parent but multiple mixins. 3.1 Even though may be obvious, it should explicitly state that artifactId is always required. 3.4 Why can't the groupId be inherited from its parent (or at least be set from project.parent.groupIdt)? 3.4 The footnote says the artifactId can be inherited from the parent. That makes no sense to me. Every pom should represent a unique artifact or at least a unique pom. 3.5 I found the statement This will mark the container as final, thus preventing inheritance:" as misleading. In java terms this would mean a child pom attempting to define the same plugin would fail. The setting of "inherited" to false in the sample indicates to me the opposite, the plugin definition in the parent is invisible to the child. Here is a question though. If A overrides a plugin defined in the super pom and has inherited true, then B extends A and overrides the plugin and sets inherited to false, what will C which extends from B get? It should see the definition in A. Or does this whole section mean that the plugin definition in B inherits nothing from A? 3.8 "the element will be inherited." Unless the parent definition has false ? I don't see anything in here about being able to locate a parent without having to know its version. Within the scope of the purpose of this document it may not be relevant, but at the very least somewhere in section 3 it should state that if a parent is specified than which elements are required. I hope this was the kind of feedback you were looking for. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: POM construction specification
Thanks, I'll take a look. I'm interested in finally continuing the work I started on a terse POM syntax earlier in the year and can start by spec'ing out the interoperability needs. On 16/12/2008, at 7:02 AM, Jason van Zyl wrote: This is for the general population but I'm nudging you Ralph because I know that you want to make some changes for not requiring the version in the parent element. I don't think I'll be too keen on making substantive changes to how the POM is constructed until alpha-3/4 (because we need to deal with the thorny issue of interoperability between versions of the POM and version of Maven) but have a look at this: http://svn.apache.org/repos/asf/maven/components/trunk/maven-project-spec.pdf Shane tried to codify the behavior as much as possible into this spec and I think it servers as the new location for existing behavior and changes we want to make in the future. I think we can clearly mark proposals and then transition them into the document proper as proposals are accepted. This is really to get the ball rolling and get your thoughts as you have the only concrete proposal that's been tested I know of. I am going to translate that document into Confluence markup as I don't think Tex is very popular. Once that is done we can also incorporate proposals that have been made by users and link back to the JIRA. This should make the behavior more visible and potential changes known. We'll have something similar for Mercury which will tie the whole process together but this is a place to start. (The Tex source is right beside the PDF if you actually want to edit the Tex content) Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org