Comments inline also -----Original Message----- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Friday, August 31, 2007 12:20 PM To: Maven Developers List Subject: Re: [PROPOSAL] Plugin packs and concrete versioning
sorry for the brevity - I'm heading off to bed and am afk for a day and a bit so wanted to get a quick response in... On 01/09/2007, at 1:45 AM, Jason van Zyl wrote: >> A couple notes that you can incorporate from experiences I've had >> based on a client setup: >> >> - The enforcer plugin now has a rule to fully lock down all plugin >> versions >right, so that's the tooling referred to? I thought it just checked, >didn't actually apply the changes? It only checks for the condition and fails the build. It currently does not make changes or suggestions. The enforcer is about enforcing, not fixing ;-) but the rule could be executed by another plugin and used as a starting place to lookup for suggestions. >> >> - You do have to lock down all plugins including things like >> "eclipse:eclipse" because these are used extensively by many groups >> and these changing can have serious repercusions in a build >> environment. Everything must be locked down for it to be stable. So >> someone can start a new project to try something but when it >> officially becomes part of the build that must be communicated to >> the build team and the plugin needs to be locked down. A single >> point that can vary, let's say the eclipse plugin that has a bug >> and many people are screwed. It's easy to either use a POM that >> doesn't have enforcement turned on by not inheriting from the POM >> with the rule declaration, or an option to turn off enforcement >> which would always be turned on for blessed builds. >I agree that you want to flip the switch that enforces it in most >cases, but I think maybe this could be configurable. I don't want to >lose the ability to run archetype:create on a default install, or to >be able to try out other plugins not defined in the POM. This is >especially the case for distributed source code - you don't want to >ask a user to have to edit a POM to add the IDEA plugin they love >just because the project only defines the eclipse configuration. >I'm concerned that begin too heavy handed on this loses sight of the >new user experience a bit. This is where the plugin comes in handy. It's only turned on by those who want it. We can add the configuration to ignore certain plugins like clean. >> >> - Putting all versions in an organization POM is not that >> loathsome. It's 30 minutes work but it could be easier. I locked >> down everything with a client including eclipse, idea, and site >> plugins pretty shortly. It now works great. So in practice this is >> not that bad. >I think the long term maintenance of that is a problem. We're already >seeing it with the parent POM structure and locked down versions we >have here. I disagree strongly here. Since I started with Maven about 2 yrs ago, I've had an internal company super-pom that all projects derive from. I use it expressly for the purpose of maintaining pluginManagement across the board and occasionally dependencyManagement but very sparingly. I have not found this to be cumbersome at all. I would periodically scan for new plugin releases and then someone on the CM team would test them out before we rolled it out. Occasionally this means changes to our poms to support new config etc, but the good thing is these changes can be committed along with the bump to the next internal super-pom. That means we don't break outstanding developer branches, etc. I really think that manually maintaining these versions is the safest way to have control over your project. I will agree that sometimes it isn't as required to lock down every version and in those cases (I don't do that in any of my maven plugins), don't use the enforcer, or tell it to ignore certain plugins you don't care about. >> >> - One mixin with a plugin configuration chunk and someone would be >> done. If we provided a loosely couple set of plugins we think work >> then people can grab those and put them in their POM. We can have a >> tool to help them. OBSERVATION: I've noted that build/scm people >> want to see these versions in an actual file. So being able to grab >> the recommended set, grab a snippet and check it in. From what I'm >> seeing the mixins would allow people to put all their version >> information in one place. A reference to some artifact seems to >> make people uncomfortable. >I tried to address this by using a POM as the source so you can just >see it and grab it - did I miss something? Obviously generic mixins >would be better, but I haven't seen a proposal for that yet. I think we can do this just by generating a sample pluginManagement snippet on the site somewhere. I don't think anything fancy is needed, simply providing the snipet so someone can copy and paste will be more than sufficient. Having it generated with the current latest release would then make it a good starting point as most people would want the latest by default and would only resort to reverting if they hit a problem with a particular plugin. >> >> - No versions of anything should be declared in the Super POM. This >> should be totally externalized. >I special cased the clean plugin only because it's just dumb to have >to define that in every project, it so rarely changes. It's a slippery slope that's not needed for a single plugin. With the snipet published as mentioned above, this is about 60 seconds for someone to fix (again only if they have decided to use the enforcer) >> >> - We don't need any new internal mechanism to model this. We can >> make snippets for people to use, and they will mix and match >> because they will. We just need to get them started. A snippet >> inside pluginManagement will do. >Snippet? Are you saying cut and paste, or another name for a mixin, >or something else? Discussed above. >> Cleaning up the internal model, and providing mixins and we have >> what we need. >I'm happy to use mixins instead if they exist - I just didn't want to >risk missing getting this in because the other feature wasn't there. >> The lifecycle doesn't need to be refactored for this >Not sure what you mean - I didn't think I suggested refactoring the >lifecycle for this (I did say there was some optional, related work >that could be done at the end). >Anyway, we can always boil this proposal down to the elements that >still remain once the mixins are implemented. We still need to force >the versions to be specified at least. I used to be in the camp that it should be required by maven core. I think that all the work around making that requirement not cumbersome has me rethinking that position. I think that a recommended best practice of using the enforcer rule along with easy access to the configuration needed to make it work is all that's needed. Give people who don't care the option to ignore it and give the people who do the tools and the config and we're all happy. Also worth mentioning is that the rules interface was designed to allow other modules the ability to execute the rules. Once I complete the refactor (possibly tonight) then the rules themselves will be outside the plugin jar. This means ide tools could incorporate this check along with some special ability to fix the poms. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
