On Dec 9, 2010, at 6:26 PM, Eric Dalquist 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.
I agree that we want a setup that is only dependent on source directory resources. It should make the project easier to build, plus it prevents us from breaking the boundaries between maven projects. It also seems to me like we'd get more mileage out of using the shared filter file as the filtering resource in the portlets, rather than using the rdbm.properties file, since that gives us access to many more filter tokens. >> 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. > 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. I'm personally open to adding this patch to 3.2.x, and it would probably make my life easier. However, I'd really love some community feedback before we decide either way. I'm particularly worried about schools who may have had their maven customization done by someone who's busy at the moment, or perhaps done by a consultant (we've helped some institutions to set up local maven filtering). I'd hate to get into a situation where schools can't pick up some of the recent important bug fixes because they don't have the time to work through all the subversion conflicts and redo their deployment strategy. Given our general release policy, it seems to me like this might be too big of a change, but I'd really like the community as a whole to weight the benefits and costs of applying this patch to the maintenance branch and tell us what they'd like to do. If this is going to cause significant trouble upgrading for many people, we can always offer it as an optional patch instead. My other concern about applying this patch to 3.2.x right now is that it feels unfinished to me. I'd love more testing and community feedback before we integrate it into 3.2.x. Do people feel this patch is sufficient? Do they like the overall strategy? Do people like the filter token names, or are they too long? (I actually personally picked them, so I'm not complaining, but I can see how they might seem unwieldly). Personally I feel like for this strategy to be useful and to replace what our adopters have already implemented locally, we likely need to go further. We'd probably want to go ahead and apply the shared filter files to the CAS context, and to the portlet overlays. I'd like to make sure that the version that's integrated into 3.2.x is a mostly-final version of the changes, so that 3.2.x adopters only have to integrate these changes once, rather than resolving conflicts several times as we refine our filtering strategy. - Jen -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
