On Thu, Mar 31, 2011 at 11:08:26AM +0100, Graham Triggs wrote: > Now, to address some of the practicalities. I still say that what we have > now is back-to-front, and unnecessarily complex. The Spring configurations > should be loaded at the root of the application (not embedded within the > Service manager), and a factory-aware bean should be instantiated by the > configuration for means of providing the static hooks to legacy code. That > makes it a lot easier to adjust the configurations, and wire the core > services into other areas of code (eg. WebMVC controllers), as well as > simply removing a bunch of code that we otherwise need to maintain.
Could we rework this in time for 1.8.0? Is this a drop-dead issue, or can we accept the framework as-is and fix this later? It does sound sensible that, if we're going to use Spring, we should let it drive. Cocoon may impact that, though -- I haven't investigated that. > Mark mentioned 'shadowy stuff', and it's fair enough to say that Maven is > doing its own thing. But that isn't really why they haven't been noticed - > the point is that they are 'off to the side' in the modules directory, and > not part of trunk where everyone is looking. We are always going to have > dependencies where we don't routinely examine their source. But the Services > framework (and other 'core' functions that are currently in modules) is > something that we need people to inspect, maintain, and engage with. Yes, there are two tiers of dependencies: 1. stuff from other products that we just use (log4j, Spring, etc.) 2. our own artifacts, which we should be working in as needed. Maven can just take care of group 1, but we need to remain aware of group 2 in spite of Maven's best efforts to just keep things tidy in the background. Already we no longer have a monolithic source kit, but this situation arose quietly and we haven't fully developed habits and documentation to solidify our day-to-day awareness of what we do have. > Source code accessibility is a concern, but I feel that I covered that > above. Maven is pretty much a standard tool for Java development these days, > so whilst it can intimidate I don't see that it is really problem for anyone > that does intend to get at source code (as opposed to a binary release, > where they may just be changing configuration files and templates within an > installation). Well, the source code is right there in SVN, so it is accessible. Its discoverability is considerably less. Shall we build a catalog page on the Wiki, with a definitive list of artifacts, descriptions of what each is for, links to the source, and enough information to identify them to Maven? > But they do need to know what Maven project(s) they should be interacting > with, and that is what I have yet to see, or be able to propose, with the > modules area. Let's make DSpace a shining example of how Maven is best used for "project comprehension" by actually documenting our groupID and artifactIDs for each project in an accessible manner (unlike nearly every other built-with-Maven project I'm aware of, *grumble*). -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart.
pgpwZQKZxdcCl.pgp
Description: PGP signature
------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
_______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
