On Tue, 2004-05-18 at 16:37, David Sean Taylor wrote: > On May 18, 2004, at 1:05 PM, 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 Sounds a lot safer.
kewl, I will start on it tomorrow. > > > > > 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). > > Are you recommending replacing the existing tests with tests that > reference mock components instead of the real components? > For example, the registry tests would no longer actually hit the > database in their unit tests? > Doing so would require building the mock objects with the test data, > which could take some time. Well, Ill leave most of them in place, as is for now. > > What if we formerly defined different kinds of tests, such as unit, > system, component. > I still want the test hitting the database to exist, call them whatever > you want. > These tests would not require mock objects. These would be integration/sanity tests and SHOULD NOT run automatically at build time. Unit tests should run quickly and many times a day, integration/sanity should only need to be run once or twice a day. > I do also see the need for basic unit tests with mock objects. These are actual unit tests. > > Not sure if you want to discuss code coverage, because we are no where > near that and we don't have the resources to get there > Anyway I think you know my feelings on mock objects and that they are > only a part of the testing equation > > > > > 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. > > This one has gone back and forth many times > Thinking about how it is now, and after using for a few months, Im > concluding its a lot easier to have one jetspeed.groovy script, instead > of searching all over the class path for scripts > I think that was the original idea Yep, I cam to the same conclusion, auto-magic is not as kewl as it initially sounds. > > > > > 3. Configuration versus assembly. David Taylor and I have discussed at > > length the idea of assembly versus configuration. Assembly is defining > > the components we are using within our container and making sure those > > components' dependencies are able to be fulfilled. Defining assembly > > requires someone with relatively intimate knowledge of Jetspeed 2 and > > pico/nano container. Configuration is the defining of the operational > > parameters for components that will be assembled. Configuration values > > should be primitive and String values and should only represent those > > types of values. Configuration values should never expose the "guts" > > of your container i.e. it should never ever contain class names. > > > > Example of a good configuration value: > > > > mail.server=mail.foo.bar > > > > template.directory=/WEB-INF/templates > > > > Example of a bad configuration value: > > > > my.implementation.class=org.apache.jetspeed.MyClass > > > I think Im guilty of above on occasion > Good examples and clear distinction of configuration and assembly, hold > on to that one ;-) > We can formally define an actual JetspeedConfiguration object that has getters for all of the expected configuration values as opposed to using a generic commons Configuration object. This make it easy for us to drop any implementation of JetspeedConfiguration: properties based, RDBMS based, JNDI etc. > > > This should be defined within assembly not configuration as it exposes > > the guts of our container to the admin, this is something we should > > avoid at all costs. > > > > More later... > > > > p.s. > > > > I won't start this until i get some feedback from the list. > > > > > > --------------------------------------------------------------------- > 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]
