On 12/9/10 5:26 PM, Drew Wills wrote:
Our goal should be that you can cd to any module the project and run "mvn clean install" and it will work with nothing in your local maven repository. This may not always be true in code coming from trunk or a -patches branch due to snapshot issues but for any release we cut that needs to be true. Depending on something in a source directory works just fine with this goal, depending on something in a target directory does not.On 12/9/2010 2:38 PM, Eric Dalquist wrote:Drew, I'm a little concerned about commits https://developer.jasig.org/source/changelog/jasigsvn/?cs=22634 and https://developer.jasig.org/source/changelog/jasigsvn/?cs=22633I'm not sure it is ok for the WebProxyPortlet module to depend on files in the target directory of another module. Would it be better for the portlet to use the same filter file that uportal-war is using?This is a good point. I updated those poms at the tail-end of the work I did, and I guess I didn't pause long enough to think it through fully.But come to think of it, how much worse is depending "on files in the target directory of another module" than depending on files in the *source* directory of the same module (which is what we already do). I double-checked to make sure the portal was (always) built before the overlay.And also, the enhancement was designed so that users who didn't want to use the new feature wouldn't have to change *anything* about how they currently configured, built, and deployed uPortal. If we use the same filters file in the portlet overlays, wouldn't folks then be required to set it up?
Right, but our stated release policy is as little pain as possible from patches releases. If fixing a bad bug causes some pain to merge it is unavoidable. Adding a new feature that causes pain during a merge is more questionable since we don't need to do that to fix some other issue.Also after talking with Jen in IRC and looking more closely at the patches I don't think we can get the fitlering patches into 3.2. It looks like we really should do more work on standardizing our filtering configuration, filter keys and do more testing. Also it is looking like these changes might be painful the merge for anyone that already has done some 3.2 customization and that is what we don't want in a patch release.The "painful to merge" part is exactly why I was so keen to get it in. The pom changes for many reasons and in many ways between releases; if you've got home-grown filtering in place you already feel this pain (I do), even without conflicting on those specific lines.I don't believe it makes the pain much worse at all to sort out differences between the filtering that was added and whatever filtering you had. But it certainly makes the pain much better going forward, considering you only have to deal with sorting that out the one time.
-Eric
smime.p7s
Description: S/MIME Cryptographic Signature
