Hello Bob!
I agree with you that it would a good idea to split into more modules to
reduce the size of argouml-app (the argouml.jar) in favor of more modules.
When reading your mail, (and especially the item 1.) I get the feeling that
you have confused the packages with the modules. Even if we have all diagram
elements in a single module we could still use separate package for
different diagram elements. We could even move the code to a separate module
without changing the package or we could change package while still keeping
everything in argouml-app.
I don't think I understand the consequences of the different solutions well
enough to have an opinion. I want to better understand how the diagram code
and especially how the diagrams interface with other parts of argouml like
Notation and Persistence and how the diagrams will be affected by the UML2
work to be able to make up my mind about this.
On the other hand, I think you, Bob, will make the right decision in this so
don't wait for my opinion on this.
/Linus
On Sun, Apr 25, 2010 at 2:44 PM, Bob Tarling <[email protected]> wrote:
> The recent discussions on the SPL project has inspired me to want to
> discuss this again.
>
> We now have the sequence diagram successfully distributed as a module.
> I am hoping that in time the other diagrams can also go the same way.
>
> In fact is there any reason to delay with that?
>
> I'd like to go further than just moving all the existing classes in
> their existing package structure into modules I think that would mean
> we'd end up with packages being shared across different modules and
> possible name clashes.
>
> We also historically have our packages too fine-grained which has
> resulted in us having to make classes public that should not be.
>
> So I'd prefer to mimic the sequence2 packages structure where we have
>
> org.argouml.xxxx as the main package name for the module and
> org.argouml.xxxx.diagram where all the diagram specific classes are
> kept.
>
> With the other diagrams will will have different things to consider
> than we did for sequence diagrams. With the sequence diagram the
> figures are not used in any other diagram type and are unique for that
> diagram. For other diagrams that is mostly not the case.
>
> So for example FigClass should not be in the class diagram module as
> it is required for various diagrams.
>
> So I would suggest a separate module for common Figs that has some
> factory to return the required Fig.
>
> The question that comes to mind for me is whether that module actually
> contains all Figs whether or not they are used in multiple places. If
> so that would leave each diagram module only containing the graph
> model and diagram class in which case is the separation really
> worthwhile? Maybe just one diagram module for everything would do us.
>
> The options and advantages/disadvantages I see are as follows
>
> 1. One big module with all diagram code
> Advantage - extreme encapsulation, almost everything can be package scope.
> Disadvantage - One massive package. The module loader does not control
> availability of individual diagrams.
>
> 2. Split diagram modules with one module containing all figs
> Advantage - Encapsulation still good. Easy pluggable diagram types.
> Enforces dependencies (Figs don't know about concrete Diagrams and
> GraphModels).
> Disadvantage - Relatively little code in each module. Package in main
> diagram module is still large.
>
> 3. Split diagram modules with one module containing common Figs
> Advantage - Easy pluggable diagram types. Main diagram module only
> contains what is needed and code is more evenly distributed between
> modules.
> Disadvantage - Encapsulation must be broken to allow specific diagram
> types to access ancestor classes and common classes from common
> diagram module.
>
> I favour option 2 but I'd like to hear the opinion of others.
>
> Part of me wants to put this off as its not really giving the user
> anything new but on the other hand it should be a fairly easy process
> to move the relevant classes and the result I think will be a
> modularized ArgoUML that will be a lot easier for new developers to
> get in and understand where the responsible parts lie.
>
> Once this is done then I'd like to see a process of tidying up
> argouml-app to remove all direct references to tigris-GEF classes. All
> tigris-GEF classes should be encapsulated in the diagram modules and
> we will have put ourselves into a position where it would be possible
> for someone to start to develop a diagram in eclipse-GEF if they
> choose.
>
> Regards
>
> Bob.
>
> ------------------------------------------------------
>
> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2595136
>
> To unsubscribe from this discussion, e-mail: [
> [email protected]].
> To be allowed to post to the list contact the mailing list moderator,
> email: [[email protected]]
>
------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2603666
To unsubscribe from this discussion, e-mail:
[[email protected]].
To be allowed to post to the list contact the mailing list moderator, email:
[[email protected]]
