On Tue, 2004-05-18 at 17:06, Ate Douma wrote: > Scott T Weaver wrote: > > > Here is my approach for "merging" in my branch changes into HEAD. > > > > I have gone through many iterations on updating the way build/deploy our > > components. I ended up coming to the conclusion that simple is better. > > Since many things have changed since I created my branch, I thought it > > best that I replicate my approach by duplicating what I did in my branch > > and not directly patching or merging. That way I can do little, > > incremental changes, test them and commit (the way it should have been > > done in the first place). > +1 > > > > > Some other things I will be doing: > > > > 1. I propose we DO NOT (yes, I said NOT) use containers in component > > test cases as it really is not a requirement since all components can > > should be usable/testable with out a container. All that is need is > > mocking of the dependencies. I have started using jMock for this > > instead of having to create the mock objects by hand (jMock uses a > > dynamic proxy approach). > Like David Taylor, I would object at removing *all* container usage in > test cases because I also see the need and benefit of concrete database > interaction testing. Don't forget, Jetspeed can and will be used with > many different databases, each with there own behavior. OJB/Torque can > differentiate for that. I don't see how mocking can ever deal with all > those variations
I realize that we need to make sure that our components are working with their associated back end systems and what not, however, when you start developing unit tests that test solely for idiosyncrasies of those back end systems, a good example being the TestRegistryDirect1 & 2, your unit test looses focus of its true purpose which is testing the logic of the component itself. That is why I suggest we develop a new set of "integration" unit tests that are run by a separate build command against a live environment. Here is a radical idea, how about a subproject within the Jetspeed 2 source tree that is dedicated to nothing but integration testing? Another plus of this approach is that back-end specific (read RDBMS information) is only present in one location as opposed to how it is now with OJB artifacts and DS info replicated all over the place a myriad of times. > > > > > 2. NanoQuickDeployer is an evil hack that I created out of sheer > > laziness and I ought to be shot, drawn and quartered, flayed, etc. for > > introducing it. So, I propose we delete it and just manually assemble > > components in jetspeed.groovy. There are two reasons for this: > > > > 1. This should alleviate the issue of components starting 2 or 3 > > times. > > 2. We can see EVERYTHING that is being assembled into the engine by > > just looking in one location. > > > +1 > > > I won't start this until i get some feedback from the list. > > > As I understand merging your branch will result in many, many changes. > Can you give a prediction how long it will take you to do this? Days, weeks? Hopefully days as I have already done this once before, I am using the XP "Courage" approach to merge my branch. > Although I fully support your approach of doing it in small steps, it > also starts a possibly lengthy period in which the whole codebase is in > flux. Doing other modifications during this period might become bothersome. This shouldn't be to bad as I while be "compnentizing" one logical set of components at time, testing them and committing them. I will start with the components least likely to change for out under me, like ID Generator, rewriter and locator and move on to more "dynamic" ones like Registry, Security and Aggregator. > I surely don't want to give the impression I'm trying to push you > because I'd rather have it done slowly and successful than too quickly > with lots of complications. But I do think that it is important to have > this period as short as possible. +1. I have already burnt a lot of time already in my branch, however it was good learning experience for me allowing me to identify what works, what works well and what is total crap. It was kinda like sitting, up meditating on a mountain...okay now I am just talking stupid ;) > > And maybe it might be wise to tag the current code base before this > merge is started so there is some common ground to compare with and/or > work on. I've no problem having to develop against an older version and > have to do some merging or refactoring myself afterwards. For that I > would like to have a way of retrieving that version from cvs and not > depend on a locally archived version. +1. Any ideas on what we want to call the branch? > > Regards, > > Ate > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
