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
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.
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).
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
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?I won't start this until i get some feedback from the list.
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.
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.
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.
Regards,
Ate
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
