>The misunderstanding seems to be: >1) that I thought we were going to require plugin versions to be >specified in the future. You seem to say that is no longer the case.
I think you're right here. After reading your response to my comments, I realized my (and I think Jason's) assumption is that the core doesn't require the versions. We're using a plugin to get this behavior. You mentioned that if tooling is required, that's a sign of a problem. I don't think I really agree since all of maven is basically a plugin. Plugins are nice because people can choose to use them if they want or develop their own. Back when we discussed having the versions required, lots of people spoke up and said they wouldn't like that. I think this is the best solution between flexibility and lock down and it's up to the user / CM team to decide. In my instance, the developers essentially don't touch the poms, this is the job of the CM team. We let them add dependencies as needed but then the CM team reviews for consistency and conflicts. Without locking down, we had so many problems with "well, it works on our machines." Granted it was alpha/beta m2 but it was still a major issue and can be today with any plugin release that potentially changes behavior (for good or bad, a change needs to be understood). The enforcer was originally created because I continued to have compatibility issues within the team because they weren't all running the same "blessed" maven version. We discussed this functionality in core and it was decided to be a plugin, I don't see any difference here. We're just talking about having the tools to allow people to do what they want/need without being overly heavy handed. >2) that you think I'm trying to make it a black box. I'm simply >looking for a more concise way to express exactly what you are saying >already. I can tell you that the simple pack config looks appealing at first glance. However, if this existed today here's what I believe corp users would experience: First, what exactly is in the java pack 1.0? (which plugins and which versions?) What happens if I don't want 1 of the plugins in the pack...I'm back to defining the pluginManagement section for that one. Over time, you will find that you get pMgt creep and soon the pack isn't really useful anymore because you've had to redefine too many versions. The other problem I see is that changing too many plugins at once would make it hard to identify any changes/issues and any new bugs that creep in. We used to update a bunch of plugins at once in between releases but quickly found this not to be a good idea. When I see a new plugin release that we might want to bump up, we review the release notes and jiras fixed in the release. Then we will make the change and test it out on the CM team boxes. If it's a significant plugin change (or maven change), I've been known to have a developer compare the resulting artifacts (wars mostly) to ensure the same libs are included. Only after we decide this plugin works as good as the last and make any changes to use new features does the company super-pom get updated and rolled out in the scm. I can't imagine trying to do this with a handful of plugins at once. Between that and the pMgt creep I mentioned above, I doubt seriously that I would even consider looking at the packs for my Corp builds. I think that's really the crux of the problem with them. Someone who is really trying to lock down their versions will be diligent enough to really understand what they need in each plugin. I think it is really just a crutch between the builds that don't need lock down and the corp ones who won't/can't use it. --Brian --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
