On Tue, Dec 16, 2008 at 11:25 PM, Ralph Goers <ralph.go...@dslextreme.com>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
