Do we need uportal-user feedback on these questions too? -Jonathan
On Mon, Dec 13, 2010 at 12:02 PM, Jen Bourey <[email protected]>wrote: > 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 [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
