<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<body link="#355491" alink="#4262a1" vlink="#355491" style="background: #e2e2e2; margin: 0; padding: 20px;">
<div>
<table cellpadding="0" bgcolor="#FFFFFF" border="0" cellspacing="0" style="border: 1px solid #dadada; margin-bottom: 30px; width: 100%; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tbody>
<tr>
<td>
<table border="0" cellpadding="0" cellspacing="0" bgcolor="#FFFFFF" style="border: solid 2px #ccc; background: #dadada; width: 100%; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tbody>
<tr>
<td bgcolor="#000000" valign="middle" height="58px" style="border-bottom: 1px solid #ccc; padding: 20px; -moz-border-radius-topleft: 3px; -moz-border-radius-topright: 3px; -webkit-border-top-right-radius: 5px; -webkit-border-top-left-radius: 5px;">
<h1 style="color: #333333; font: bold 22px Arial, Helvetica, sans-serif; margin: 0; display: block !important;">
<!-- To have a header image/logo replace the name below with your img tag -->
<!-- Email clients will render the images when the message is read so any image -->
<!-- must be made available on a public server, so that all recipients can load the image. -->
<a href="https://community.jboss.org/index.jspa" style="text-decoration: none; color: #E1E1E1">JBoss Community</a></h1>
</td>
</tr>
<tr>
<td bgcolor="#FFFFFF" style="font: normal 12px Arial, Helvetica, sans-serif; color:#333333; padding: 20px; -moz-border-radius-bottomleft: 4px; -moz-border-radius-bottomright: 4px; -webkit-border-bottom-right-radius: 5px; -webkit-border-bottom-left-radius: 5px;"><h3 style="margin: 10px 0 5px; font-size: 17px; font-weight: normal;">
Single Installation Patching
</h3>
<span style="margin-bottom: 10px;">
new comment by <a href="https://community.jboss.org/people/brian.stansberry">Brian Stansberry</a> <a href="https://community.jboss.org/docs/DOC-47500#comment-11120">View all comments on this document</a>
</span>
<hr style="margin: 20px 0; border: none; background-color: #dadada; height: 1px;">
<div class="jive-rendered-content"><p>Jeff, </p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>This will need to be more complex.</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>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.</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>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.</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>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.</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>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.</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>I'm not in favor of analyzing the module.xml to determine what resources to hash. For two reasons:</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>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.</p><p>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.</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>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.</p></div>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</div>
</body>
</html>