On Sun, Jul 27, 2008 at 2:43 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> 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?

i like modules and my libraries finely grained so you know what my
answer would be ;-)

IMHO it's worthwhile spending a little time writing up some
documentation to help newbies when splitting up into modules (yes, i
know i should have done that)

- robert

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

Reply via email to