On Sun, Jul 27, 2008 at 3:24 PM, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > 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 ^^^^^^^^^^ comfortable (send too early)
- robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
