I have now, finally, resolved issue 5553. I will go ahead now to make the
release 0.27.3 now then. Please let me know immediately if we shouldn't go
ahead on this now.
/Linus
2008/12/19 Bob Tarling <[email protected]>
> I'll do the class moves today in time for the first build containing
> sequence2 which is due tomorrow.
>
> I've updated the release plan to indicate the correct release date for
> seq2 (and also removed xml property panels for this release).
>
> If anyone else has anything in the release schedule the think needs
> adjusting then please do so. Is there anything not going to make it in
> time? Are there any other major new features to note?
>
> Linus - a reminder for you to take a look at issue 5553. Please make
> sure that the new build does create a new style sequence diagram
> before making it publicly available.
>
> Bob.
>
> 2008/12/18 Bob Tarling <[email protected]>:
> > Yes, the proppanel stuff is minimal. I'd be happy to have those in the
> > main package for the module it makes sense to also have the module
> > registration there.
> >
> > I'd suggest that, for the time being, the one notation class that is
> > currently in the sequence2 module is moved to core ArgoUML with the
> > other UML1.4 notations. If nobody objects I'll go ahead and do that.
> >
> > I don't think a notation belongs to any one diagram type even if it is
> > only used by that diagram. I think all the notations for UML1.4 belong
> > in one place for reuse by what ever needs it.
> >
> > For example if the sequence diagram module was rewritten once more
> > using eclipse graph elements then it would want access to the same
> > notations.
> >
> > It would be nice to see the UML1.4 notation moving to its own module
> > or maybe within Model/MDR.
> >
> >> As I've said many times, the OSGi/Eclipse plugin model is the one that
> >> ArgoUML should migrate to.
> >
> > I don't think we have any expertise on this but I think we're all
> > agreed that using common standards can only help us.
> >
> > I'll do what I suggested previously for the wiki and create a proposal
> > page then I'll create a placeholder for this proposal.
> >
> > These are the major links I've found regarding this
> >
> > http://www.eclipse.org/equinox/
> > http://www.osgi.org/Specifications/HomePage
> >
> > Regards
> >
> > Bob.
> >
> > 2008/12/17 Tom Morris <[email protected]>:
> >> Thanks for the summary and the additional detail. That helps
> >> understand the proposal.
> >>
> >> I think the crosscutting issue is something that you are going to have
> >> no matter what organization you pick. It's just the nature of the
> >> beast. I don't see a reason that the package structure needs to
> >> mirror the structure of what's being extended.
> >>
> >> I think there are too many packages in both the old and the new
> >> structure. I can't really see having a package for 1 or 2 classes.
> >>
> >> Here's what I'd suggest - just two packages (actually I think this is
> >> the same or similar to what Linus suggested too):
> >>
> >> org.
> >> argouml.
> >> sequence2. // module registration (4), prop panel &
> >> factory(1), notation(2)
> >> diagram // The actual diagram implementation graph
> >> model, diagram Figs etc (3 & 5)
> >>
> >> Any reverse engineering stuff is probably only going to be a class or
> >> two, so it can go in the top level package as well. If it looks like
> >> there are going to be a dozen or more critic classes, they can go in
> >> their own package org.argouml.sequence2.critics.
> >>
> >>>> If the modules and subsystems match, should we redefine the subsystems
> to
> >>>> improve on the understanding of the system?
> >>>
> >>> I'm not sure what you mean by "If the modules and subsystems match".
> >>> There are no new subsystem here so that requires no new change to
> >>> subsystem descriptions.
> >>>
> >>> Maybe what needs clarifying is my view of modules as components. I
> >>> think in the past it has been assumed that a module would be a
> >>> subsystem. However seq2 proves that a module actually needs to extend
> >>> and integrate to various subsystems of the main application.
> >>
> >> Yes, modules definitely need to extend multiple subsystems, but I
> >> think we need to think in terms of making the modularity more fine
> >> grained in general. There's no reason that seq2 critics need to go
> >> into the seq2 module. They could be in a module of their own or there
> >> could be a set in the seq2 module and then someone else could come
> >> along a provide an "enhanced critics" module which provided additional
> >> seq2 critics as well as additional use case or core critics.
> >>
> >> For reference, in Eclipse terms, units of redistributable code are
> >> called "plugins". Plugins map 1:1 with Eclipse projects. Plugins can
> >> be grouped into "features" which are chunks of functionality that make
> >> sense from a user's point of view. Plugins can provide "extension
> >> points" which are well defined interfaces for plugging things
> >> together. Plugins can also provide "extensions" to the extension
> >> points defined in other plugins (thus introducing a dependency). Each
> >> plugin can provide multiple extensions and multiple extension points,
> >> so there's a many to many mapping, but no cycles are allowed in the
> >> dependency graph.
> >>
> >> As I've said many times, the OSGi/Eclipse plugin model is the one that
> >> ArgoUML should migrate to.
> >>
> >> Tom
> >>
> >> ------------------------------------------------------
> >>
> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=985890
> >>
> >> To unsubscribe from this discussion, e-mail: [
> [email protected]].
> >>
> >
>
> ------------------------------------------------------
>
> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=987419
>
> To unsubscribe from this discussion, e-mail: [
> [email protected]].
>
------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=995289
To unsubscribe from this discussion, e-mail:
[[email protected]].
