portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott T Weaver <scotts-jetspeed-l...@binary-designs.net>
Subject Re: "Merging" my branch. Part 1
Date Wed, 19 May 2004 13:14:37 GMT
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              *
> > *         <weaver@apache.org>            *
> > *     <http://www.einnovation.com>       *
> > * -------------------------------------- *
> > *   Apache Jetspeed Enterprise Portal    *
> > *     Apache Pluto Portlet Container     *
> > *                                        *
> > * OpenEditPro, Website Content Mangement *
> > *     <http://www.openeditpro.com>       *
> > ******************************************
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
> >
> >
> 
> --
> David Sean Taylor
> Bluesunrise Software
> david@bluesunrise.com
> [office]   +01 707 773-4646
> [mobile] +01 707 529 9194
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message