You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Stefano Bagnara <ap...@bago.org> on 2007/09/05 01:52:30 UTC

[jSPF] refactoring to remove cyclic dependencies and find a better structure

I'm trying to reorganize code for jSPF in order to be able to provide
some sort of architectural documentation and to remove cyclic
dependencies between packages.

As you can see from the last 2 commits this means moving around a lot of
classes.

I also plan to do some renaming if I find better names.

I will work with a CTR approach as most changes are better understood
checking out the updated tree.

99.9% of the changes are IDE-managed refactoring, so even if I change a
lot of classes they are plain/straight refactorings and should not harm
the stability of the code.

If anyone prefer to release 0.9.5 with the old structure I can move this
task to a branch. Otherwise I'll try to put some more effort in this
before 0.9.5 (e.g: now that there are no more cyclic dependencies I feel
much better than before).

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Re: [jSPF] refactoring to remove cyclic dependencies and find a better structure

Posted by Bernd Fondermann <be...@googlemail.com>.
Stefano,

thanks for taking care of all this.
I will review commits I did not already visit yet later.

  Bernd

On 9/17/07, Stefano Bagnara <ap...@bago.org> wrote:
> Stefano Bagnara ha scritto:
> > I'm trying to reorganize code for jSPF in order to be able to provide
> > some sort of architectural documentation and to remove cyclic
> > dependencies between packages.
> >
> > As you can see from the last 2 commits this means moving around a lot of
> > classes.
>
> I played with the big class dependency graph and with some custom code
> to run com.sun.jini.tool.ClassDep against each one of our jSPF classes
> and export the result in GraphML to visualize it with yEd and using its
> facilities to optimize the rendering of a graph.
>
> This helped me re-clustering classes in different packages so to reduce
> the application packages layers.
>
> After the moves I also added some basic dev documentation.
>
> > I also plan to do some renaming if I find better names.
>
> I only renamend Configurable to ConfigurationEnabled to follow the
> naming convention used in the rest of the code for enabling interfaces.
>
> > I will work with a CTR approach as most changes are better understood
> > checking out the updated tree.
>
> Everything is there. After you will have reviewed this, if everything is
> ok we can try releasing it.
>
> One thing that could be improved is the command line usage/argument help
> for the main spf command line. I this the configuration I used for
> DNSTestingServerLauncher is a bit better than the one used in SPFQuery
> (usage in DNSTestingServerLauncher is automatically managed by the cli
> library).
>
> I also ran RAT, but I will post another message to track this.
>
> Stefano
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Re: [jSPF] refactoring to remove cyclic dependencies and find a better structure

Posted by Stefano Bagnara <ap...@bago.org>.
Stefano Bagnara ha scritto:
> I'm trying to reorganize code for jSPF in order to be able to provide
> some sort of architectural documentation and to remove cyclic
> dependencies between packages.
> 
> As you can see from the last 2 commits this means moving around a lot of
> classes.

I played with the big class dependency graph and with some custom code
to run com.sun.jini.tool.ClassDep against each one of our jSPF classes
and export the result in GraphML to visualize it with yEd and using its
facilities to optimize the rendering of a graph.

This helped me re-clustering classes in different packages so to reduce
the application packages layers.

After the moves I also added some basic dev documentation.

> I also plan to do some renaming if I find better names.

I only renamend Configurable to ConfigurationEnabled to follow the
naming convention used in the rest of the code for enabling interfaces.

> I will work with a CTR approach as most changes are better understood
> checking out the updated tree.

Everything is there. After you will have reviewed this, if everything is
ok we can try releasing it.

One thing that could be improved is the command line usage/argument help
for the main spf command line. I this the configuration I used for
DNSTestingServerLauncher is a bit better than the one used in SPFQuery
(usage in DNSTestingServerLauncher is automatically managed by the cli
library).

I also ran RAT, but I will post another message to track this.

Stefano



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Re: [jSPF] refactoring to remove cyclic dependencies and find a better structure

Posted by Bernd Fondermann <be...@googlemail.com>.
On 9/5/07, Norman Maurer <no...@apache.org> wrote:
> Stefano Bagnara schrieb:
> > I'm trying to reorganize code for jSPF in order to be able to provide
> > some sort of architectural documentation and to remove cyclic
> > dependencies between packages.
> >
> > As you can see from the last 2 commits this means moving around a lot of
> > classes.
> >
> > I also plan to do some renaming if I find better names.
> >
> > I will work with a CTR approach as most changes are better understood
> > checking out the updated tree.
> >
> > 99.9% of the changes are IDE-managed refactoring, so even if I change a
> > lot of classes they are plain/straight refactorings and should not harm
> > the stability of the code.
> >
> > If anyone prefer to release 0.9.5 with the old structure I can move this
> > task to a branch. Otherwise I'll try to put some more effort in this
> > before 0.9.5 (e.g: now that there are no more cyclic dependencies I feel
> > much better than before).
> >
> > Stefano
>
> Go ahead,
>
> I think its better to  "fix" this as soon as possible. I will try to
> keep track of your changes ..

Me too.

+1

  Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Re: [jSPF] refactoring to remove cyclic dependencies and find a better structure

Posted by Norman Maurer <no...@apache.org>.
Stefano Bagnara schrieb:
> I'm trying to reorganize code for jSPF in order to be able to provide
> some sort of architectural documentation and to remove cyclic
> dependencies between packages.
>
> As you can see from the last 2 commits this means moving around a lot of
> classes.
>
> I also plan to do some renaming if I find better names.
>
> I will work with a CTR approach as most changes are better understood
> checking out the updated tree.
>
> 99.9% of the changes are IDE-managed refactoring, so even if I change a
> lot of classes they are plain/straight refactorings and should not harm
> the stability of the code.
>
> If anyone prefer to release 0.9.5 with the old structure I can move this
> task to a branch. Otherwise I'll try to put some more effort in this
> before 0.9.5 (e.g: now that there are no more cyclic dependencies I feel
> much better than before).
>
> Stefano

Go ahead,

I think its better to  "fix" this as soon as possible. I will try to 
keep track of your changes ..

bye
Norman


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org