2008/12/12 Ralph Goers <ralph.go...@dslextreme.com> > I agree with this. But even with managed dependencies there are still > problems. Even though you have dictated the version you really have no idea > if it is compatible with the version needed by the artifact trying to use > it. > > I have been advocating for some time that 3.0 support "requires" and > "provides". Jason has assured me that it will make it into one of the 3.0 > milestone releases. When used by artifacts this would allow Maven to pick > the latest version from a range that provides all the required attributes. > When used with a managed dependency it could report an error if the artifact > being overridden has incompatible requirements with the managed dependency. > > With 2.0.x no one should expect any real improvement in this as it would > break too many things. >
Hmmm... I could do some trickery with the versions-maven-plugin that would give static binding for this type of stuff... If we hijack the /project/build/plugins/plugin/configuration section of the versions-maven-plugin we could stash the provides and requires information in there and then versions-maven-plugin could pull the information out when doing resolution. The other idea I have is to use xml processing instructions to give hints to the versions-maven-plugin... but I have to do some checking to see if the standard maven tools leave xml processing instructions unmodified... so you could have at the project level <project> ... <?provides com.foo.bar ?> <?requires com.foo.logging ?> </project> It seems to me that (bar the loss of schema validation) this could be a way out for the 2.x line... at least versions-maven-plugin could parse the processing instructions and work out what versions can work... though I have a feeling it could get tricky!!! -Stephen > > Ralph > > > On Dec 11, 2008, at 3:25 PM, Barrie Treloar wrote: > > On Fri, Dec 12, 2008 at 7:45 AM, Stephen Connolly >> <stephen.alan.conno...@gmail.com> wrote: >> >>> Hmmmm.... you've just given me an idea for a mojo for the >>> versions-maven-plugin >>> >> >> As Stephen points out in the JIRA, the correct way is to add a >> dependencyManagement section. >> Dependencies need to be MANAGED. >> Someone needs to take this ownership, your tech lead/architect is a good >> choice. >> Otherwise you end up in chaos. >> >> The usual way to handle this is to have all your projects inherit from >> a common pom and define all versions in the dependencyManagement >> section. >> >> Then all your children artifacts NEVER define versions. They will >> always select the correct version from your parent or throw an error - >> which indicates you need to include that artifact in the parent >> dependencyManagement section. >> >> Yes its a pain and the versions-maven-plugin new feature would make >> this work easier, but it is something that you have to actively manage >> to avoid testing or conflict issues. >> >> --------------------------------------------------------------------- >> 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 > >
