My own 2 cents to this discussion... On 3/31/2011 5:08 AM, Graham Triggs wrote: > My turn!! > > I'm certainly in favour of having [more] POJO services / components, and > using Spring as a container for them. > > 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. > > 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. > > We either need to find a way to get people engaging with asynchronous > modules, or accept that they need to be part of trunk (and by extension, > part of a synchronous release). Asynchronous modules that do not have a > sufficient quorum engaging with are going to be a sustainability problem.
I agree with Graham's points completely. We need to find ways to get people engaging with asynchronous modules more, and potentially bring some of the "core functions/modules" into Trunk. I've been bouncing around an idea in my head which may or may not help with this, around a possible way to "rethink" asynchronous releases (and I'm aware this is not entirely part of "commitment to Services", but it's worth mentioning based on the direction of this thread): https://wiki.duraspace.org/display/DSPACE/Asynchronous+Release+-+Alternative+Option I would love feedback or alternative ideas from you all -- this is merely a brainstorm, and not necessarily "fully fleshed out". But, I thought I'd share it as an alternative way to look at asynchronous modules and potentially how we deal with Services in the future (e.g. my general idea is to suggest Services be moved to Trunk where they are released 'synchronously' alongside the rest of the "core" api/functions, but that other modules be potentially moved *out* of Trunk.) > Addressing Robin's point, Services framework does not necessarily imply > everything in that list. It is a necessary building block for things > like modularisation and asynchronous releases, but it we don't have to > adopt them if we use the Services framework. +1 Services Framework commitment/approval should be considered *separate* from all those other proposals like modularization & asynchronous releases. There is some overlap that will probably occur in these various discussions, but they actually don't have any real concrete dependencies. In other words, Services Framework could be released synchronously or asynchronously. It could also be released as a separate module, or moved into dspace-api. Currently Services is obviously set up as a separate module in SVN "modules/dspace-services" area under the implication that it may be asynchronously released at all times. But, we can decide to change any of those previous decisions as we see fit. (Again, See my brainstormed "Asynchronous Release - Alternative" proposal above for an idea around potentially releasing Services Framework *synchronously*) > 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). > > 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. I'm sure there are improvements we can make in trying to make the source code easier to work with. :) But, as Graham mentions, Maven is probably not going away anytime soon. It has become a "standard" tool in most major Java projects these days. We can however work to make SVN organization / Maven modules more "logical" to work with, so that it's clearer to developers where they need to look for particular Source Code. I personally think this should be a goal of any modularization / Maven restructuring that we do. In other words: We need to make source code easier to work with (or at least more logical), and not add unnecessary complications or frustrations to our development processes. Just my quick thoughts on this. Definitely feel free to disagree with anything I've said. I want this to be an open discussion of ideas, so that we can continue to work quickly towards a common decision around many of these proposals/vague ideas that have been hanging around for far too long. - Tim ------------------------------------------------------------------------------ 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
