I thought one of the main arguments in all this discussion is to make things simple and easy for users. At least those were the comments against forcing everyone to explicitly set versions for everything. The bundle will free every single user of having to go finding out what version of what to use. And it could allow for auto upgrading in a more consistent manner, if the user so chooses.
Brian E. Fox wrote: > > > Yes, but if you specify which version of each in your pom, then it will > only change when you want it to. You change the producer (or consumer) > and find they don't work, you put it back or update the other and test. > The whole point of specifying the versions manually is so that some > human makes a conscious decision to update and presumably does some > testing before pushing out to the rest of the team. > > "I see it more about having certifications and provide users with stuff > that we all know work well together. > For example, if I try using the ant-run-plugin on 2.0.5 I need to use > ant-1.6.5 even though ant-1.7.0 is out. And this means you are limited > to the ant-ssh library version you can use, and the jsch version you can > use and so on." > > These aren't multiple plugins you refer to, this is a specific problem > with a single plugin and its dependencies. While unfortunate, I don't > think we're even discussing attempting to bundle plugins and all their > related dependencies together. > Well, I needed to use Antrun which means I needed atd-1.6.5 but why should I need to specify every single jar that is part of ANT-1.6.5 separately? And why I do not have the correct dependencies in the repository for those? I should not need to deal with all that, I thought that was what the repository metadata was for. Otherwise, there is something really missing. How is maven suppose to deal with things that have multiple jars that work together? Certainly this is a basic thing. In any case I digress here. Look at bundles as a friendly way to define a <dependencyManagement> or <pluginManagement> group, that users can incorporate (like multiple inheritance). So there is a way to centralize some of this management and simplify everyone's life. And of course, do not forget being able to specify an upgrade strategy that takes into account the idea of <quality> of the bundle. Call it a management-POM if that sounds better, which is basically limited to contain the above mentioned elements. That should not be that difficult or complex to understand/implement. Jose Alberto -- View this message in context: http://www.nabble.com/Remove-auto-resolution-of-plugin-versions-from-Maven-2.1-tf3560617s177.html#a10142950 Sent from the Maven Developers mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
