Dependency management tends to fall into two camps -- Maven and OSGi. While I've used both before, I've found that most of the public repositories for various libraries use Maven -- mvnrepository.com is the one I use most often. At one point Spring was working on an OSGi repository but I think that fell through. The nice thing about potentially using Maven is that the SVN repo wouldn't need to be cluttered up with libraries and seems to work well with Hudson. There's an OSGi plugin for Maven (although I've never used it).
You might also want to look at Apache Ivy which can be used with Ant and also works with Maven repositories. Dependency injection is a separate topic altogether. It is more concerned with the usage of interfaces, to insure that "dependencies" like mock classes can be injected into a method for unit testing purposes. For example if you have a method like this: public void myGreatMethod( IHttpRequest request) ... can be tested by passing simply passing MockHttpRequest into the method. No need to fire up a web server to test out your method. Mark On Thu, Apr 14, 2011 at 11:21 AM, 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=2719884 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]]
