Robert Burrell Donkin ha scritto:
On Sun, Jul 27, 2008 at 3:19 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Norman Maurer ha scritto:
Am Sonntag, den 27.07.2008, 15:43 +0200 schrieb Stefano Bagnara:
HI all,

I was thinking about a change for jSPF source tree.
I wonder if introducing multiple modules would help the project or not,
and my answer to this is currently slightly pending toward the yes.

I'm proposing to:

- move the main source tree to a "resolver" module

- promote the "stage" folder to a module (like we did in server-trunk:
this move our stage repository "hack" to a module and is better handled by
maven)

- create an "openspf-tester" module including the code used to run
openspf tests on the wire (introducing a fake yaml based dns service).

- Maybe during the refactoring it will be necessary to introduce
 a "core" or "common" module including code used by both modules (I
didn't evaluate this yet).

The advantage of this change is mainly that we have a new "product", the
openspf-tester that can be used even outside from jSPF to prove OpenSPF
compliance. This should also simplify our efforts to have jSPF declared as
compliant in the page http://www.openspf.org/Implementations (we are
"currently being evaluated" since 2006-12-04/r76)


The disadvantages are:

1) the maven "artifactId" for the library will change. (even if I don't
think there are many m2 projects around referrring to jspf, yet)

2) a multimodule project is often more difficult to grok for newbies /
occasional developers.


Opinions?

Stefano

I like the idea... so here is my +1
As I already have 2 positive feedbacks (from active developers) I'll try to
do something concrete.

My approach to similar stuff is to create a *branch* to do the work because:
- I don't know how long it will take and if it will produce something good:
working on trunk would leave trunk unbuildable and unusable until I
completed this job.
- I have to move code around and if I do everything in my eclipse before
committing this will loose svn history, so if I use a branch I can start
moving code directly on the repository and commit each change I need.
- Once it is completed we can have a review of the result and decide whether
it is ok to merge or not.

Maybe the branch will require only today, but may also be I'll need some
more time to fix issues I'll find while working.

please confirm I can use a branch for this or otherwise tell me how you
suggest to proceed.

one approach that i've used successfully in the past is to copy the
code down one level and then work directly in trunk but i'm happy for
a branch to be used if you find this more confident

(it's development branches i dislike)

Sorry if I asked, but I wanted to be sure you didn't intend this as a development branch. In my feelings this is the same of the branch I opened in mime4j fot the streams-refactoring proposal. In both cases I can't predict the future, I can only know my intent when I open it.

The fact that I never understood my mistake gives me a strong fear that anything I can do can scare/upset/disappoint people, so I prefer to ask twice now ;-)

I'll go with the branch then, because working on trunk make this experiment too much definitive, while I'm not so confident until I put my hands there.

Thank you,
Stefano

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to