You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/12/10 20:18:45 UTC

Development Strategies

After releasing Framework, I want to start adding a new chapter to the Developing with Avalon
book.  This chapter focuses on strategies used in Avalon development.  This includes Logging
Strategies, Testing Strategies, Parallel Development Strategies, and Security Strategies.

I would like to have more community help on this chapter--but I will slowly add to it as I
have time.  When there is enough information in the chapter, we will officially incorporate
it as a Chapter in the Developing with Avalon book.

Technically, I *could* add the new chapter now as it would not be built until I include it
in the book.xml and index.xml files.  I will *not* be doing that at this time because we
are in Code freeze.  I look forward to when we can get 4.1 out the door.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Development Strategies

Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:

> On Tue, 11 Dec 2001 06:18, Berin Loritsch wrote:
> 
>>After releasing Framework, I want to start adding a new chapter to the
>>Developing with Avalon book.  This chapter focuses on strategies used in
>>Avalon development.  This includes Logging Strategies, Testing Strategies,
>>Parallel Development Strategies, and Security Strategies.
>>
> 
> Just FYI. For the tutorial I am writing on Phoenix I have written a basic 
> server to format java files using jrefactory. ie You submit a file to server, 
> it formats it if possible. If not failed then formatted version is added to 
> CVS and not the submitted version.
> 
> This is one way to enforce code conventions rather well ;)


Cool!


> Theres also a few other checks I am programming in at the moment (ie make 
> sure the PR in commit matches a number in bug database and so forth).
> 


Even better.


>>I would like to have more community help on this chapter--but I will slowly
>>add to it as I have time.  When there is enough information in the chapter,
>>we will officially incorporate it as a Chapter in the Developing with
>>Avalon book.
>>
> 
> I would *love* to see JDepend integrated into Avalons build. JDepend is a 
> tool that generates metrics for your java files. So you can tell which 
> packages are too highly coupled and so forth. It generates reports similar to 
> junits reports (at least latest Ant CVS does). Very very very useful for 
> determining the quality of a software product. Any volunteers? ;)


I would too.  I think that it would be a real benefit.  There are some other
JUnit extensions I would like to work in (such as the one that performs
multithreaded load testing on your components--I have to look up the project
name though).


> Other things I would love to see is a better "smoke test" for some of our 
> components that go beyond the unit tests and actually test more complex 
> interactions and so forth (especially in cornerstone and phoenix and a bit in 
> excalibur).


:).  Load Testing?  Multi-threaded interactions?


> Other than that I am happy to have a go though my English may be a little ... 
> errr... in need of editing ;) So is this kinda going to be a list of sections 
> like
> 
> * Ant best practices wrt to Avalon
> * Junit best practices wrt to Avalon
> * Nightly builds
> * Smoke tests


All these are good.  We may need to break the strategies chapter into multiple
chapters, but we will see.


> As well as design sections like
> * how to break down logging namespace


Yep.  I started on this, and would really like your input as I may be way off
base, or my arguments may be weak in this area.


> * how to create easily testable code


Yep--as well as an overview of the ExcaliburTestCase to help testing Components.


> * determining what should be a containers responsibility and what should be a 
> components responsibility - though I think we may go to war over this one ;)


My approach on this is to lay out the considerations, the pros and cons, the
difference between *system* security and *component* security, and let the
reader do their own cost-benefit analysis.  For instance, a read-only MimeType
component would not require as stringent protection as a PaymentProcessingComponent.

I will lay out both sides of the arguments with the additional warning that this
is a hotly debated area.  Perhaps after reading the section, you might understand
better where I am comming from.

Seriously, we don't have to agree on all the points on this one--but we have to
present both arguments well.


> * when to use declarative structures and when to use procedural 
> etc 


This might be out of the scope of Developing with Avalon, or it may be another
chapter, after we get the other stuff written down, we can go in more detail
here.


> 
> This what you are thinking ?


Pretty much.





-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Development Strategies

Posted by Peter Donald <pe...@apache.org>.
On Tue, 11 Dec 2001 06:18, Berin Loritsch wrote:
> After releasing Framework, I want to start adding a new chapter to the
> Developing with Avalon book.  This chapter focuses on strategies used in
> Avalon development.  This includes Logging Strategies, Testing Strategies,
> Parallel Development Strategies, and Security Strategies.

Just FYI. For the tutorial I am writing on Phoenix I have written a basic 
server to format java files using jrefactory. ie You submit a file to server, 
it formats it if possible. If not failed then formatted version is added to 
CVS and not the submitted version.

This is one way to enforce code conventions rather well ;)

Theres also a few other checks I am programming in at the moment (ie make 
sure the PR in commit matches a number in bug database and so forth).

> I would like to have more community help on this chapter--but I will slowly
> add to it as I have time.  When there is enough information in the chapter,
> we will officially incorporate it as a Chapter in the Developing with
> Avalon book.

I would *love* to see JDepend integrated into Avalons build. JDepend is a 
tool that generates metrics for your java files. So you can tell which 
packages are too highly coupled and so forth. It generates reports similar to 
junits reports (at least latest Ant CVS does). Very very very useful for 
determining the quality of a software product. Any volunteers? ;)

Other things I would love to see is a better "smoke test" for some of our 
components that go beyond the unit tests and actually test more complex 
interactions and so forth (especially in cornerstone and phoenix and a bit in 
excalibur).

Other than that I am happy to have a go though my English may be a little ... 
errr... in need of editing ;) So is this kinda going to be a list of sections 
like

* Ant best practices wrt to Avalon
* Junit best practices wrt to Avalon
* Nightly builds
* Smoke tests

As well as design sections like
* how to break down logging namespace
* how to create easily testable code
* determining what should be a containers responsibility and what should be a 
components responsibility - though I think we may go to war over this one ;)
* when to use declarative structures and when to use procedural 
etc 

This what you are thinking ?

-- 
Cheers,

Pete

------------------------------------------------------------
 I just got lost in thought... It was unfamiliar territory.
------------------------------------------------------------


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Development Strategies

Posted by Vincent Massol <vm...@octo.com>.
I can help with the Testing strategies using Mock Objects (very well
suited for unit testing Avalon components). I have already submitted
some code in a past email showing how it works. I don't have a lot of
time on the writing side, but I can certainly help with feedback as I'm
doing it on a production project now.

Thanks
-Vincent

-----Original Message-----
From: Berin Loritsch [mailto:bloritsch@apache.org] 
Sent: 10 December 2001 19:19
To: Avalon Developers List
Subject: Development Strategies

After releasing Framework, I want to start adding a new chapter to the
Developing with Avalon
book.  This chapter focuses on strategies used in Avalon development.
This includes Logging
Strategies, Testing Strategies, Parallel Development Strategies, and
Security Strategies.

I would like to have more community help on this chapter--but I will
slowly add to it as I
have time.  When there is enough information in the chapter, we will
officially incorporate
it as a Chapter in the Developing with Avalon book.

Technically, I *could* add the new chapter now as it would not be built
until I include it
in the book.xml and index.xml files.  I will *not* be doing that at this
time because we
are in Code freeze.  I look forward to when we can get 4.1 out the door.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>





--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>