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.
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.
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.
I do also see the need for basic unit tests with mock objects.
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
I think Im guilty of above on occasion
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
Good examples and clear distinction of configuration and assembly, hold on to that one ;-)
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]
