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). 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. 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 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 operation parameters of 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 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. -- ****************************************** * Scott T. Weaver * * <[EMAIL PROTECTED]> * * <http://www.einnovation.com> * * -------------------------------------- * * Apache Jetspeed Enterprise Portal * * Apache Pluto Portlet Container * * * * OpenEditPro, Website Content Mangement * * <http://www.openeditpro.com> * ****************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
