On Sun, Jul 27, 2008 at 3:33 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > 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,
it's good to talk :-) > 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. of course > 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 ;-) sounds like a good plan > 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. cool - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
