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 "Merging" my branch
Date Tue, 18 May 2004 20:05:43 GMT
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 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 

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


Mime
View raw message