Brian Stansberry [https://community.jboss.org/people/brian.stansberry] commented on the document "Single Installation Patching" To view all comments on this document, visit: https://community.jboss.org/docs/DOC-47500#comment-11120 -------------------------------------------------- Jeff, This will need to be more complex. For a CP, we don't want to ignore AS modules just because the only change is creation dates. If you apply a CP patch, the modules you should run should be the same as if you had downloaded a fresh install of that version. I discussed this with Jimmy Wilson of GSS a while back. A critical question is whether a build of a product involves a complete rebuild from source of all 3rd party libs, or whether an existing built-from-source binary is re-used if the source is unchanged. I expect the latter; otherwise a new maven GAV would be needed for every build. And if that is case, again, for a CP there is no reason not to include a 3rd party module even if the diff is only creation dates. For whatever reason the module was rebuilt. For one-off patches, the patch generator includes the ability for the patch-config to explicitly declare what modules are different. I did this as something of a workaround to the problem you're attacking. The person preparing the one-off will probably do a complete big from source of a tag + bug-fix patch, and generating a diff of that will produce spurious diffs. Your approach here provides another way to help with this case. But it shouldn't be done for CPs and for one-offs the patch-config should include a config to turn it off. Re: the .index files, I had some discussions about those and I thought they were no longer being generated. If that's wrong, then yes, we'll need to deal with them. I'm not in favor of analyzing the module.xml to determine what resources to hash. For two reasons: 1) The user-side patch tool shouldn't add any functionality that isn't really necessary. The more it does, the more ways it can break. And breaking is bad. 2) It's not the business of the patch tool to parse and understand the contents of module.xml. If jboss-modules changes something, we don't want to have to update the patch tool to understand that. I don't think it's a big deal if users stick a README in a module and we treat that as a conflict. The users looks, sees the difference (the README would likely have a different filesystem date from the rest of the module) and provides the param to the patching operation indicating that it's ok to override modules with conflicts. --------------------------------------------------