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
Date Wed, 19 May 2004 13:38:50 GMT
On Tue, 2004-05-18 at 17:06, Ate Douma wrote:
> 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
> 
> > 
> > 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).
> Like David Taylor, I would object at removing *all* container usage in 
> test cases because I also see the need and benefit of concrete database 
> interaction testing. Don't forget, Jetspeed can and will be used with 
> many different databases, each with there own behavior. OJB/Torque can 
> differentiate for that. I don't see how mocking can ever deal with all 
> those variations

I realize that we need to make sure that our components are working with
their associated back end systems and what not, however, when you start
developing unit tests that test solely for idiosyncrasies of those back
end systems, a good example being the TestRegistryDirect1 & 2, your unit
test looses focus of its true purpose which is testing the logic of the
component itself. 

That is why I suggest we develop a new set of "integration" unit tests
that are run by a separate build command against a live environment. 
Here is a radical idea, how about a subproject within the Jetspeed 2
source tree that is dedicated to nothing but integration testing?  

Another plus of this approach is that back-end specific (read RDBMS
information) is only present in one location as opposed to how it is now
with OJB artifacts and DS info replicated all over the place a myriad of
times.

> 
> > 
> > 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.
> > 
> +1
> 
> > I won't start this until i get some feedback from the list.
> > 
> As I understand merging your branch will result in many, many changes. 
> Can you give a prediction how long it will take you to do this? Days, weeks?
Hopefully days as I have already done this once before, I am using the
XP "Courage" approach to merge my branch.

> Although I fully support your approach of doing it in small steps, it 
> also starts a possibly lengthy period in which the whole codebase is in 
> flux. Doing other modifications during this period might become bothersome.

This shouldn't be to bad as I while be "compnentizing" one logical set
of components at time, testing them and committing them.  I will start
with the components least likely to change for out under me, like ID
Generator, rewriter and locator and move on to more "dynamic" ones like
Registry, Security and Aggregator.



> I surely don't want to give the impression I'm trying to push you 
> because I'd rather have it done slowly and successful than too quickly 
> with lots of complications. But I do think that it is important to have 
> this period as short as possible.
+1.  I have already burnt a lot of time already in my branch, however it
was good learning experience for me allowing me to identify what works,
what works well and what is total crap.  It was kinda like sitting, up
meditating on a mountain...okay now I am just talking stupid ;)

> 
> And maybe it might be wise to tag the current code base before this 
> merge is started so there is some common ground to compare with and/or 
> work on. I've no problem having to develop against an older version and 
> have to do some merging or refactoring myself afterwards. For that I 
> would like to have a way of retrieving that version from cvs and not 
> depend on a locally archived version.
+1.  Any ideas on what we want to call the branch?

> 
> Regards,
> 
> Ate
> 
> 
> 
> ---------------------------------------------------------------------
> 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