Re: [PROPOSAL] Plugin packs and concrete versioning
Sorry, I've not read this entire thread, but have a quick comment... This idea of plugin packs could easily be extended to the more generic pom inclusion stuff I've talked about previously. There other things besides plugin version binding that could be bundled up into a reusable package (like a common IDE configuration profile for example). Sure, grouping up plugins bound to specific versions is very handy and should help simplify many projects (and even help reduce build fragility), but IMO it would be a whole lot nicer to see a general import some pom (by artifact:groupId:version) and merge the contents into the current poms for execution. --jason On Sep 1, 2007, at 4:35 AM, Hervé BOUTEMY wrote: Le samedi 1 septembre 2007, Brian E. Fox a écrit : 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. +1 IMHO, a link to it should be added to http://maven.apache.org/ plugins/, because it's the same information in another format. Plugins groups (or packs) are already organized here, and can be represented in the pluginManagement snippet as XML comments WDYT? Hervé - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Plugin packs and concrete versioning
Jason van Zyl wrote: On 1 Sep 07, at 7:42 PM 1 Sep 07, Brett Porter wrote: I'd be ok with it looking like this: project modelVersion4.0.0/modelVersion groupIdtest/groupId artifactIdtest/artifactId nameTest/name version1.0-SNAPSHOT/version build plugins pluginPacks pluginPack groupIdorg.apache.maven.plugins.packs/groupId artifactIdmaven-java-plugin-pack/artifactId version1.0/version /pluginPack /pluginPacks /plugins /build /project You don't need that to start, the minimal POM is fine for someone starting. For corporate build you have to lock everything down. You can have no variability until someone decides it can change. That is the only way to have something as stable as checking in all the JARs. We don't need that plugin packs element. The vast majority of time in maintaining a build is not the initial setup, it's the maintenance. No one I have been with, sitting on a production build, is adverse to locking down the versions in a parent POM. If we can do that with mixins, that's great. I definitely don't think we can require people to paste things in if it becomes a core requirement, though - the smallest POM example gets another 30 lines. That's almost 3 times the size of above, and 5 times the original. Remember, we already get complaints that the POM is too verbose - let's listen to those users on this one :) Do you think anyone thinks this is a burden if it guarantees them stability? They don't, and tooling would make it dead simple. Sit with the users, with their builds and it's not a burden. You are removing their ability to mix and match their versions with one element that gives them no visibility. Another issue what would need to be addressed is the archetypes - do we need to re-release the quickstart archetype all the time, does it stick to an old version, or does it start substituting in version values itself? For anyone starting new they can get whatever version is the latest, for anyone in a corporate environment it would again be locked down. People experimenting for the first time can do whatever they want. It doesn't affect a team. It's probably worth considering whether other people have a use for plugin packs. Has anyone seen a use case for a related set of plugins outside of the packagings defined by Maven? Maybe NMaven? All people care about is the plugins they use and how to make sure what is used is consistent. - 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) Yeah, but for mvn clean to not work without it is a bit scary. Maven starts getting a bad rep from all the projects that use Maven to build and forget to declare it. No it's not. Once someone on the build/scm team has set it up it's not seen by the developers. Everything has to be locked down. Maybe it isn't such a special case :) Maybe it is time to start thinking about pushing all the standard plugin versions into the super POM again. -1 Absolutely not. It's just not the place to put them. The Super POM will remain largely unchanging between versions and will serve as the housing for default locations. The set of viable plugins over time will shift and the set of plugins that people actually use cannot be covered by notion of a plugin pack. Anyone who has a build who needs it to be stable will understand the plugins they use, version them all and stabilize the entire environment. Now that the standard plugins are relatively stable, this may not be such an issue as it was originally and gets us the hard requirement while keeping brevity. This is really not an issue. It's always the job of a team or small group of people to stabilize this. Plugin packs will not help because the second they use plugins outside the scope of the pack they are again in the same position of locking down versions in the way Brian and I describe which is what happens in real life. There is no way you can pre-determine what set of plugins people will use and so the mechanism to lock them all down should be the same. Not a mix of plugin packs and then doing what I suggest. It should be the same. This is not a difficult task. It simply isn't. It takes very little time right now and a plugin to piece together a snippet of all the latest releases would go a long way to helping people get what they need. 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
Re: [PROPOSAL] Plugin packs and concrete versioning
Dennis Lundberg wrote: Jason van Zyl wrote: On 1 Sep 07, at 7:42 PM 1 Sep 07, Brett Porter wrote: I'd be ok with it looking like this: project modelVersion4.0.0/modelVersion groupIdtest/groupId artifactIdtest/artifactId nameTest/name version1.0-SNAPSHOT/version build plugins pluginPacks pluginPack groupIdorg.apache.maven.plugins.packs/groupId artifactIdmaven-java-plugin-pack/artifactId version1.0/version /pluginPack /pluginPacks /plugins /build /project You don't need that to start, the minimal POM is fine for someone starting. For corporate build you have to lock everything down. You can have no variability until someone decides it can change. That is the only way to have something as stable as checking in all the JARs. We don't need that plugin packs element. The vast majority of time in maintaining a build is not the initial setup, it's the maintenance. No one I have been with, sitting on a production build, is adverse to locking down the versions in a parent POM. If we can do that with mixins, that's great. I definitely don't think we can require people to paste things in if it becomes a core requirement, though - the smallest POM example gets another 30 lines. That's almost 3 times the size of above, and 5 times the original. Remember, we already get complaints that the POM is too verbose - let's listen to those users on this one :) Do you think anyone thinks this is a burden if it guarantees them stability? They don't, and tooling would make it dead simple. Sit with the users, with their builds and it's not a burden. You are removing their ability to mix and match their versions with one element that gives them no visibility. Another issue what would need to be addressed is the archetypes - do we need to re-release the quickstart archetype all the time, does it stick to an old version, or does it start substituting in version values itself? For anyone starting new they can get whatever version is the latest, for anyone in a corporate environment it would again be locked down. People experimenting for the first time can do whatever they want. It doesn't affect a team. It's probably worth considering whether other people have a use for plugin packs. Has anyone seen a use case for a related set of plugins outside of the packagings defined by Maven? Maybe NMaven? All people care about is the plugins they use and how to make sure what is used is consistent. - 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) Yeah, but for mvn clean to not work without it is a bit scary. Maven starts getting a bad rep from all the projects that use Maven to build and forget to declare it. No it's not. Once someone on the build/scm team has set it up it's not seen by the developers. Everything has to be locked down. Maybe it isn't such a special case :) Maybe it is time to start thinking about pushing all the standard plugin versions into the super POM again. -1 Absolutely not. It's just not the place to put them. The Super POM will remain largely unchanging between versions and will serve as the housing for default locations. The set of viable plugins over time will shift and the set of plugins that people actually use cannot be covered by notion of a plugin pack. Anyone who has a build who needs it to be stable will understand the plugins they use, version them all and stabilize the entire environment. Now that the standard plugins are relatively stable, this may not be such an issue as it was originally and gets us the hard requirement while keeping brevity. This is really not an issue. It's always the job of a team or small group of people to stabilize this. Plugin packs will not help because the second they use plugins outside the scope of the pack they are again in the same position of locking down versions in the way Brian and I describe which is what happens in real life. There is no way you can pre-determine what set of plugins people will use and so the mechanism to lock them all down should be the same. Not a mix of plugin packs and then doing what I suggest. It should be the same. This is not a difficult task. It simply isn't. It takes very little time right now and a plugin to piece together a snippet of all the latest releases would go a long way to helping people get what they need. 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
RE: [PROPOSAL] Plugin packs and concrete versioning
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]
RE: [PROPOSAL] Plugin packs and concrete versioning
I haven't used the enforcer myself yet. How would turn on the enforcer rule look inside a pom? See here for an example. Note that multiple rules can be configured at once. (also this rule is in the current snapshot rev) http://maven.apache.org/plugins/maven-enforcer-plugin/rules/requirePlugi nVersions.html If this pom section is simple enough, I think people who care about reproducibility will use it. Would it be possible to combine this with a warning? Yes it is because all the rules take a message parameter where you can put any message you deem useful. It will use this message and append to it any specific warnings generated by the rule. The rules can also be set as warnings not hard failures. --Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Plugin packs and concrete versioning
If this pom section is simple enough, I think people who care about reproducibility will use it. Would it be possible to combine this with a warning? I'm not 100% certain, but I think that would require pulling some of the enforcer logic into the core... This might be a good thing, i.e. just having a setting in the pom that controls whether to enforce plugin versions or not. project ... build ... plugin-versionsrequired|warn|latest/plugin-versions ... /build ... /project The super-pom can set this to warn. Corporate builds can set to required once they have a build working. Non-corporate builds can set to latest if they want turn off warnings Well, this could be considered too I suppose with a flag as you mentioned. However this can be achieved already with the plugin. Just define the enforcer in the corp super-pom using a property in the message and warn values. Then you can set the properties with a default but override them in your projects. Having it separate in a plugin means a little bit more configuration but gains more flexibility. Releases of the plugins can/should occur more frequently than maven itself and changes don't require new model versions to use them. --Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Plugin packs and concrete versioning
Brian E. Fox wrote: I haven't used the enforcer myself yet. How would turn on the enforcer rule look inside a pom? See here for an example. Note that multiple rules can be configured at once. (also this rule is in the current snapshot rev) http://maven.apache.org/plugins/maven-enforcer-plugin/rules/requirePlugi nVersions.html If this pom section is simple enough, I think people who care about reproducibility will use it. Would it be possible to combine this with a warning? Yes it is because all the rules take a message parameter where you can put any message you deem useful. It will use this message and append to it any specific warnings generated by the rule. The rules can also be set as warnings not hard failures. So, we could put the enforcer configuration, found on the link you provided, in the super pom and tell it to warn but not fail. That would be the default configuration. If someone wanted hard failures they would simply override the hardFailure configuration option in their corporate parent pom. --Brian -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Plugin packs and concrete versioning
Hi Brian, Thanks for the great response - comments inline... On 02/09/2007, at 11:30 PM, Brian E. Fox wrote: 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. Yep, since that was my original gut feeling many moons ago, and since we're seeing the same feeling from the poll, I agree this is the best way to go (in conjunction with some warnings/assistance like you are discussing with Dennis). 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. I've always been a big fan of help:effective-* for this. Even today you can look at the POM and see something different to what is used, or have to hunt around through all the parents due to the existence of *Management sections. However, it makes a good point, and is something that is not in favour of mixins in general. Everything else you said below makes sense and is pretty much in line with my experience, so I think it's best to defer this for a general mixins proposal (if at all). Thanks, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Plugin packs and concrete versioning
Everything else you said below makes sense and is pretty much in line with my experience, so I think it's best to defer this for a general mixins proposal (if at all). I'm pretty sure that a general ability to include or mixin some other piece of xml into the pom would come in handy, but this is a totally different topic and would need some thought around inheritance, deployment, etc. I agree with with Wayne's comments in the poll thread: I am concerned though that providing mixins will send us further down the path of moving more and more pieces out of the pom which is not the right move IMO. If we add plugin+version in mixin v1, then people will want plugin+version+configuration in mixin v2, and in a short period of time we'll have re-invented parent and pluginManagement in non-pom files which really makes no sense at all. If we do mixins, we need to be careful that we don't open things up too much and make total messes out of the build. I could see this leading towards ant like craziness when things aren't linear (inheritance) or self contained.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Plugin packs and concrete versioning
I agree that the ability to lock down a build is important for release management, but part of the beauty of Maven is the ability to concisely declare a build and at the same time benefit from incremental improvements in various components of it. Inhouse, we use a buildinfo-plugin (from Better Builds ..) to capture all the build information and this data is packaged up with each built artifact. So it is always possible to recreate a build exactly. This gives us the ability to assimilate new plugin versions without needing to modify POMs or parent POMs. I'd hate to lose that. So I would rather see this requirement fulfilled by a mechanism that can be switched on or off as needed like the enforcer-plugin. William -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Sunday, 2 September 2007 1:26 AM To: Maven Developers List Subject: [***POSSIBLE SPAM***] - Re: [PROPOSAL] Plugin packs and concrete versioning - Email has different SMTP TO: and MIME TO: fields in the email addresses On 1 Sep 07, at 4:35 AM 1 Sep 07, Hervé BOUTEMY wrote: Le samedi 1 septembre 2007, Brian E. Fox a écrit : 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. +1 IMHO, a link to it should be added to http://maven.apache.org/ plugins/, because it's the same information in another format. Plugins groups (or packs) are already organized here, and can be represented in the pluginManagement snippet as XML comments WDYT? Yes, that's all that's necessary. As noted previously we already have, even for 2.0.x users, a way with the enforcer plugin to help greatly stabilize builds and if we started publishing these snippets tomorrow we'll go another big step. How we make this more seamless can come in time but it can all come in the form of external tooling to find the snippets. We could even fake mixins in this particular case by making people use a certain comment element and we could insert this snippet. When mixins are supported we can transition over to using that without much problem. I don't think the idea of a plugin pack buys us anything configuration management wise as we 1) loose visibility of plugin versioning which is important in a corporate build, 2) don't need anything special in the model to represent this, it just makes things more complicated. Hervé - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Plugin packs and concrete versioning
On 03/09/2007, at 8:46 AM, Brian E. Fox wrote: Everything else you said below makes sense and is pretty much in line with my experience, so I think it's best to defer this for a general mixins proposal (if at all). I'm pretty sure that a general ability to include or mixin some other piece of xml into the pom would come in handy, but this is a totally different topic and would need some thought around inheritance, deployment, etc. I agree with with Wayne's comments in the poll thread: I am concerned though that providing mixins will send us further down the path of moving more and more pieces out of the pom which is not the right move IMO. If we add plugin+version in mixin v1, then people will want plugin+version+configuration in mixin v2, and in a short period of time we'll have re-invented parent and pluginManagement in non-pom files which really makes no sense at all. If we do mixins, we need to be careful that we don't open things up too much and make total messes out of the build. I could see this leading towards ant like craziness when things aren't linear (inheritance) or self contained.. Agreed :) - Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Plugin packs and concrete versioning
Le samedi 1 septembre 2007, Brian E. Fox a écrit : 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. +1 IMHO, a link to it should be added to http://maven.apache.org/plugins/, because it's the same information in another format. Plugins groups (or packs) are already organized here, and can be represented in the pluginManagement snippet as XML comments WDYT? Hervé - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Plugin packs and concrete versioning
On 1 Sep 07, at 4:35 AM 1 Sep 07, Hervé BOUTEMY wrote: Le samedi 1 septembre 2007, Brian E. Fox a écrit : 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. +1 IMHO, a link to it should be added to http://maven.apache.org/ plugins/, because it's the same information in another format. Plugins groups (or packs) are already organized here, and can be represented in the pluginManagement snippet as XML comments WDYT? Yes, that's all that's necessary. As noted previously we already have, even for 2.0.x users, a way with the enforcer plugin to help greatly stabilize builds and if we started publishing these snippets tomorrow we'll go another big step. How we make this more seamless can come in time but it can all come in the form of external tooling to find the snippets. We could even fake mixins in this particular case by making people use a certain comment element and we could insert this snippet. When mixins are supported we can transition over to using that without much problem. I don't think the idea of a plugin pack buys us anything configuration management wise as we 1) loose visibility of plugin versioning which is important in a corporate build, 2) don't need anything special in the model to represent this, it just makes things more complicated. Hervé - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Plugin packs and concrete versioning
On 01/09/2007, at 8:00 AM, Brian E. Fox wrote: 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. Cool. 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. Right - I definitely agree for today. I'll come back to Maven 2.1 with your point at the end. 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. Sorry, I was certainly agreeing it's the right way to do it - I just think we've seen occasional problems in Maven where it's not quite as easy as Jason described. Though I'd say that was likely due to pinning to unstable alpha plugins more than anything else, so I'll trust your experience on this one. 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. I think it can be easier. Jason and I typically have a slide in our Maven presentations that show what a minimal Maven POM looks like: project modelVersion4.0.0/modelVersion groupIdtest/groupId artifactIdtest/artifactId nameTest/name version1.0-SNAPSHOT/version /project I'd be ok with it looking like this: project modelVersion4.0.0/modelVersion groupIdtest/groupId artifactIdtest/artifactId nameTest/name version1.0-SNAPSHOT/version build plugins pluginPacks pluginPack groupIdorg.apache.maven.plugins.packs/groupId artifactIdmaven-java-plugin-pack/artifactId version1.0/version /pluginPack /pluginPacks /plugins /build /project If we can do that with mixins, that's great. I definitely don't think we can require people to paste things in if it becomes a core requirement, though - the smallest POM example gets another 30 lines. That's almost 3 times the size of above, and 5 times the original. Remember, we already get complaints that the POM is too verbose - let's listen to those users on this one :) Another issue what would need to be addressed is the archetypes - do we need to re-release the quickstart archetype all the time, does it stick to an old version, or does it start substituting in version values itself? It's probably worth considering whether other people have a use for plugin packs. Has anyone seen a use case for a related set of plugins outside of the packagings defined by Maven? Maybe NMaven? - 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) Yeah, but for mvn clean to not work without it is a bit scary. Maven starts getting a bad rep from all the projects that use Maven to build and forget to declare it. Maybe
Re: [PROPOSAL] Plugin packs and concrete versioning
On 1 Sep 07, at 7:42 PM 1 Sep 07, Brett Porter wrote: I'd be ok with it looking like this: project modelVersion4.0.0/modelVersion groupIdtest/groupId artifactIdtest/artifactId nameTest/name version1.0-SNAPSHOT/version build plugins pluginPacks pluginPack groupIdorg.apache.maven.plugins.packs/groupId artifactIdmaven-java-plugin-pack/artifactId version1.0/version /pluginPack /pluginPacks /plugins /build /project You don't need that to start, the minimal POM is fine for someone starting. For corporate build you have to lock everything down. You can have no variability until someone decides it can change. That is the only way to have something as stable as checking in all the JARs. We don't need that plugin packs element. The vast majority of time in maintaining a build is not the initial setup, it's the maintenance. No one I have been with, sitting on a production build, is adverse to locking down the versions in a parent POM. If we can do that with mixins, that's great. I definitely don't think we can require people to paste things in if it becomes a core requirement, though - the smallest POM example gets another 30 lines. That's almost 3 times the size of above, and 5 times the original. Remember, we already get complaints that the POM is too verbose - let's listen to those users on this one :) Do you think anyone thinks this is a burden if it guarantees them stability? They don't, and tooling would make it dead simple. Sit with the users, with their builds and it's not a burden. You are removing their ability to mix and match their versions with one element that gives them no visibility. Another issue what would need to be addressed is the archetypes - do we need to re-release the quickstart archetype all the time, does it stick to an old version, or does it start substituting in version values itself? For anyone starting new they can get whatever version is the latest, for anyone in a corporate environment it would again be locked down. People experimenting for the first time can do whatever they want. It doesn't affect a team. It's probably worth considering whether other people have a use for plugin packs. Has anyone seen a use case for a related set of plugins outside of the packagings defined by Maven? Maybe NMaven? All people care about is the plugins they use and how to make sure what is used is consistent. - 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) Yeah, but for mvn clean to not work without it is a bit scary. Maven starts getting a bad rep from all the projects that use Maven to build and forget to declare it. No it's not. Once someone on the build/scm team has set it up it's not seen by the developers. Everything has to be locked down. Maybe it isn't such a special case :) Maybe it is time to start thinking about pushing all the standard plugin versions into the super POM again. -1 Absolutely not. It's just not the place to put them. The Super POM will remain largely unchanging between versions and will serve as the housing for default locations. The set of viable plugins over time will shift and the set of plugins that people actually use cannot be covered by notion of a plugin pack. Anyone who has a build who needs it to be stable will understand the plugins they use, version them all and stabilize the entire environment. Now that the standard plugins are relatively stable, this may not be such an issue as it was originally and gets us the hard requirement while keeping brevity. This is really not an issue. It's always the job of a team or small group of people to stabilize this. Plugin packs will not help because the second they use plugins outside the scope of the pack they are again in the same position of locking down versions in the way Brian and I describe which is what happens in real life. There is no way you can pre-determine what set of plugins people will use and so the mechanism to lock them all down should be the same. Not a mix of plugin packs and then doing what I suggest. It should be the same. This is not a difficult task. It simply isn't. It takes very little time right now and a plugin to piece together a snippet of all the latest releases would go a long way to helping people get what they need. 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
Re: [PROPOSAL] Plugin packs and concrete versioning
Jason, I completely agree with everything you said below, in terms of what users want at least. So I'm obviously not communicating what I want well, since you seem to have completely missed my point in every response. 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. 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. That's why I started the two poll threads - I'd appreciate it if you could respond there so I am 100% clear on where you are coming from. Hopefully we'll hear from plenty of other folks too that don't have time to wade through this thread... - Brett On 02/09/2007, at 2:37 PM, Jason van Zyl wrote: On 1 Sep 07, at 7:42 PM 1 Sep 07, Brett Porter wrote: I'd be ok with it looking like this: project modelVersion4.0.0/modelVersion groupIdtest/groupId artifactIdtest/artifactId nameTest/name version1.0-SNAPSHOT/version build plugins pluginPacks pluginPack groupIdorg.apache.maven.plugins.packs/groupId artifactIdmaven-java-plugin-pack/artifactId version1.0/version /pluginPack /pluginPacks /plugins /build /project You don't need that to start, the minimal POM is fine for someone starting. For corporate build you have to lock everything down. You can have no variability until someone decides it can change. That is the only way to have something as stable as checking in all the JARs. We don't need that plugin packs element. The vast majority of time in maintaining a build is not the initial setup, it's the maintenance. No one I have been with, sitting on a production build, is adverse to locking down the versions in a parent POM. If we can do that with mixins, that's great. I definitely don't think we can require people to paste things in if it becomes a core requirement, though - the smallest POM example gets another 30 lines. That's almost 3 times the size of above, and 5 times the original. Remember, we already get complaints that the POM is too verbose - let's listen to those users on this one :) Do you think anyone thinks this is a burden if it guarantees them stability? They don't, and tooling would make it dead simple. Sit with the users, with their builds and it's not a burden. You are removing their ability to mix and match their versions with one element that gives them no visibility. Another issue what would need to be addressed is the archetypes - do we need to re-release the quickstart archetype all the time, does it stick to an old version, or does it start substituting in version values itself? For anyone starting new they can get whatever version is the latest, for anyone in a corporate environment it would again be locked down. People experimenting for the first time can do whatever they want. It doesn't affect a team. It's probably worth considering whether other people have a use for plugin packs. Has anyone seen a use case for a related set of plugins outside of the packagings defined by Maven? Maybe NMaven? All people care about is the plugins they use and how to make sure what is used is consistent. - 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) Yeah, but for mvn clean to not work without it is a bit scary. Maven starts getting a bad rep from all the projects that use Maven to build and forget to declare it. No it's not. Once someone on the build/scm team has set it up it's not seen by the developers. Everything has to be locked down. Maybe it isn't such a special case :) Maybe it is time to start thinking about pushing all the standard plugin versions into the super POM again. -1 Absolutely not. It's just not the place to put them. The Super POM will remain largely unchanging between versions and will serve as the housing for default locations. The set of viable plugins over time will shift and the set of plugins that people actually use cannot be covered by notion of a plugin pack. Anyone who has a build who needs it to be stable will understand the plugins they use, version them all and stabilize the entire environment. Now that the standard plugins are relatively stable, this may not be such an issue as it was originally and gets us the hard requirement while keeping brevity. This is really not an issue. It's always the job of a team or small group of people to
[PROPOSAL] Plugin packs and concrete versioning
I have revised the proposal I made earlier based on Jason and John's feedback. See: http://docs.codehaus.org/display/MAVEN/Plugin+packs+and+concrete +versioning Text included below for inline comments (which I'll feed back into the document as needed). Context Currently, plugin versions, if unspecified, resolve to the latest from the repository, which (depending on the repositories included) can include snapshots. It also means that builds change change without the POM changing. In addition to the ones the users specify, several plugins with no version attached are implied by the lifecycle, making it quite cumbersome to specify all the plugins that a build might use in the POM to ensure that the versions are locked down over time. While this situation is problematic, the alternative of requiring every single plugin version be provided is too cumbersome and verbose a task in many situations - particularly in the case of the implied plugins. It should also be noted that anything in the Maven installation itself (such as the settings, or in the past the plugin registry) is not an adequate solution - the POM must be the definitive reference for how to build the software and changing Maven installations should have no effect. Out of Scope The original discussion also touched on the following, which are related but separate issues: - locking down versions at release time where they were not specified (a more general problem, as it includes not only RELEASE/LATEST, but ranges too). - separation of declaration from instantiation for a POM. Solution Required Plugin Versions After implementation, Maven will require the version in plugin definitions that are bound to the lifecycle in the POM from modelVersion 4.1.0+. Plugins will not be resolved to the latest version (except for the CLI exception listed below). However, in 4.0.0 modelVersions, Maven will continue to allow the RELEASE as the version for backwards compatibility. Super POM The Super POM should declare a default version of the clean plugin as a special case. This will not be the case for the site plugin, or standard packaging plugins. Plugin Packs The additional requirement to declare all versions is not an inconvenience when the plugin is already declared - just one additional line. However, for the implied plugins (jar, compile, resources, etc) - this would involve an undesirable amount of boilerplate. To better facilitate this, we should add the concept of plugin packs. After the releases of one or more included plugins, a pack release can be made that includes the plugins and their versions. This is achieved through the deployment of a POM project that declares a number of plugins - this has the advantage of having the same syntax, as well as easy cut-and-paste if necessary. For example, the Java plugin pack: project groupIdorg.apache.maven.plugins.packs/groupId artifactIdmaven-java-plugins/artifactId version1.0/version packagingpom/packaging build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId version2.1/version /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.2/version /plugin ... /plugins /build reporting plugins ... /plugins /reporting /project To incorporate this into a project: project ... packagingjar/packaging pluginPacks pluginPack groupIdorg.apache.maven.plugins.packs/groupId artifactIdmaven-java-plugins/artifactId version1.0/version /pluginPack /pluginPacks ... /project Only the build and reporting plugins sections of the POM will be incorporated into the project - not the plugin management or other sections such as configuration. In addition, if multiple plugin packs are declared, they should be applied sequentially, overriding any prior. Note: this facility could later be addressed by mixins in the POM. h4. Plugin Management The plugin management section, when declaring a version, must always win over all plugin packs. A version will not be required in the plugin management section (which can still be used to apply configuration to an already-defined plugin, including those called from the CLI). CLI When running a goal from the command line, it should seek the plugin from those defined in the POM (including their versions). If the plugin is not defined in the project at all (or in the case that there is no project, such as with archetype:create), at present the current rules will be retained. It should be a recommended best practice to declare any plugins you use from the command line in the POM that are not once-off goals. A future enhancement may be to be able to (and if so, require) plugin versions to be declared in the Maven settings files.
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? - 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. - 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. - 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. - 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. - 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? 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. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Plugin packs and concrete versioning
On 31 Aug 07, at 9:20 AM 31 Aug 07, Brett Porter wrote: 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? - 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, You can I'm just saying this is undesirable in stable environment. Who might have been caught out with the faulty release of Archetype if we didn't catch it and it wasn't locked down in a given environment? 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. Not at all. It has be easy to experiment, no argument there. But what's killing people is the stable build requirement. The enforcer can either be turned on in a profile to check, I've had one client who wants it on all the time as configuring plugins is not the developer's job. But there is no question if you want stability in a corporate environment you must lock down everything and this I hear over and over again from clients. Build/SCM leads care less about experimentation and more about stability. There's not reason we can't make both work easily. - 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. Why is it a problem? For someone working even a couple hours a week on builds, and normally we're talking full time people this is not a problem in practice. You can't hide the version set in a plugin pack where people can't see the versions being used easily. I'm against that because I've seen what users want in corporate environments. They want stability and they want to see exactly what's being used without having to run a report. - 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. - 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 still better then putting it in the SuperPOM. If we're providing the pre-defined sets what is the point in separating the specification of one plugin from the rest? As simple as it may seem what if we did lock that version down and there was something wrong with it? We should manage them from one place. The SuperPOM is the place for our directory structure defaults and locations. Plugin configuration is
Re: [PROPOSAL] Plugin packs and concrete versioning
... A future enhancement may be to be able to (and if so, require) plugin versions to be declared in the Maven settings files. but in that case it could be interesting to be able to have an extend mechanism of settings using the repository like a parent pom. The idea is to be able to define custom settings for a corporate environment, a project team in a common place. The problem then, will be to be able to reproduce a build. In that case we could have a reference to it in the pom (it could be quickly difficult to resolve versions) Arnaud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Plugin packs and concrete versioning
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
