No, that's weird that it showed up twice On Tue, 2004-05-18 at 17:23, David Sean Taylor wrote: > Didn't we receive this email before? > Scott, did you mean to send this twice? > > On May 18, 2004, at 12:40 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). > > > > 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] > > > > > > -- > David Sean Taylor > Bluesunrise Software > [EMAIL PROTECTED] > [office] +01 707 773-4646 > [mobile] +01 707 529 9194 > > > > --------------------------------------------------------------------- > 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]
