Hello!
The compilation problem is caused by the compile time dependencies. It has
nothing to do with the module loader or the eclipse launcher. We have done
the exact same thing for the model subsystem so it is not a problem to fix
it (except that I have not had time to have a look it yet, I am sorry about
that).
As an addition to the problem, the ant build is set up to be stricter in the
compile time dependencies than the Eclipse configuration. This is mostly
because it is not possible to control the dependencies that strictly in
Eclipse. This has helped us by enforcing the dependency rules in the model
subsystem.
I wish that Eclipse would make it possible to specify stricter dependency
and that we could switch to the headless build in Eclipse but I think that
more Eclipse development is needed before the tool is mature enough for
this.
/Linus
2011/4/14 Bob Tarling <[email protected]>
> The plugin dependencies in eclipse work fine. The notation module and
> state2 both compile with no problem.
>
> The eclipse launcher "ArgoUML UML2-EUML debug" adds both modules to
> the environment variable so that our ModuleLoader finds them and loads
> them. When running this from eclipse both modules are found, loaded
> and the application behaves correctly at run time when creating the
> activity diagram and placing items.
>
> So all I can see that is needed for the time being is that the ant
> scripts are amended so that notation is compiled first and the
> resulting jar is in the classpath for the compile of activity2.
>
> We do similar already I presume so that the model subsystem is
> compiled before the model implementations and the rest of argouml. So
> why is this different.
>
> I am making the assumption that the module loader will work the same
> when the app is run directly as they do when running from eclipse. A
> big assumption but one that can only be checked once the build files
> are fixed.
>
> So I would request that is done first.
>
> Then we can go back to all the old talks of replacing the module
> loader with a different mechanism and using Eclipse, OSGi etc.
>
> In the meantime I'd like to go back to being able to move the activity
> diagrams forward for UML2 and for that we just need the ANT build
> scrips fixed as I've described.
>
> Bob
>
>
>
>
> On 14 April 2011 19:21, Linus Tolke Tigris <[email protected]> wrote:
> > Hello Bob!
> > Yes, you are right. The work to split into smaller modules must continue
> but
> > this requires us to manage the dependencies.
> >
> > There are two obvious ways to solve the management of the decpendencies.
> > Either we choose the Eclipse solution, where every module provides a set
> of
> > interfaces for other modules to use and we build some kind of
> infrastructure
> > for dependencies between modules. The other solution is to consider the
> > interface of Notation as an infrastructure and then have some modules
> "Use
> > it" and other modules "Provide it" much like how some java interfaces are
> > used (java.sql, javax.xml.xpath, org.omg.CORBA, org.w3c.dom, ...). I
> guess
> > the term Dependency Injection that has gotten some attention with the
> very
> > populare Guice framework but I am not sure exactly where it fits in this.
> > I guess that we will be forced into the solution of managing dependencies
> > between modules but I would like us to consider other alternatives too,
> > especially for things like Notation that has been part of the core
> argouml
> > and that might appear in several places.
> > We don't have any tools or processes in place to manage dependencies.
> Until
> > we do, every time we set up such a dependency we will have problems.
> > /Linus
> >
> >
> > 2011/4/14 Bob Tarling <[email protected]>
> >>
> >> Linus said:
> >> > Looking at this from above it is obvious that we should not have such
> >> > dependencies
> >>
> >> How can the activity diagram not rely on notations to generate the
> >> text they display? They have done so for a long time.
> >>
> >> All thats being done here is the continuation of the breakup of
> >> ArgoUML into smaller more manageable modules that match our
> >> subsystems. Those subsystems clearly have dependencies.
> >>
> >> The splitting of functionality from core argouml should continue. It
> >> has started with some diagrams, now notations, other things like the
> >> diagram subsystem should be split out so that we can isolate ourselves
> >> from GEF, plus cognitive subsystem etc. In this process what we are
> >> seeing now will happen more.
> >>
> >> Regards
> >>
> >> Bob
> >>
> >>
> >>
> >> On 14 April 2011 05:51, Linus Tolke Tigris <[email protected]> wrote:
> >> > Hello!
> >> > There seems to be a new dependency between the
> >> > argouml-core-diagrams-activity2 module and the argouml-core-notation
> >> > module.
> >> > Looking at this from above it is obvious that we should not have such
> >> > dependencies. On the other side, I am well aware that there might be
> >> > pragmatic reasons for having such dependencies.
> >> > Do we have a plan for eventually removing this dependency or shall we
> >> > start
> >> > considering some of the argouml-core-modules to be "closer to core"
> than
> >> > others?
> >> > /Linus
> >> >
> >>
> >> ------------------------------------------------------
> >>
> >>
> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2719697
> >>
> >> 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=2719902
>
> 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=2720135
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]]
