You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Scott T Weaver <sw...@einnovation.com> on 2004/05/18 18:11:35 UTC
"Merging" my branch. Part 1
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 *
* <we...@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
Re: "Merging" my branch. Part 1
Posted by Scott T Weaver <sc...@binary-designs.net>.
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 *
> > * <we...@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
Re: "Merging" my branch. Part 1
Posted by David Sean Taylor <da...@bluesunrise.com>.
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 *
> * <we...@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