On Wed, Dec 17, 2008 at 10:35 PM, Ralph Goers <ralph.go...@dslextreme.com>wrote:
> OK - I'm looking forward to seeing this. I understand the programmatic > aspect in the use case you describe with the IDE, but not with something > like the release capability. IIUC this would allow our organization to > create a standard way of doing something and then somehow make it available > to everyone. That would be a good thing. But I don't understand how that > could work without locating it in a remote repo just as a pom is currently > located. Consider the following case: Someone may decide to put a mixin file in their build. The mixin then gets applied to the pom. Any deployed or installed pom from the build has the mixins applied. In this case, mixins are never even in the remote repo. 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
