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. 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. 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. G On 31 March 2011 09:33, Robin Taylor <robin.tay...@ed.ac.uk> wrote: > I'll contribute a few unstructured thoughts if you don't mind. > > The banner of Services Framework seems to cover quite a lot of design > changes - the adoption of Spring and a Service Oriented Architecture, > increasing modularisation, asynchronous releases etc. generally I'm in > favour of all this stuff but my one area of concern is the accessibility > of the source code. If we move towards a binary release we have to be > confident that people can easily find and use the source code. A lot of > people find Maven intimidating and telling them that they just need to > add a module(s) to their project and checkout the required code isn't > friendly enough. I'm sure there is an acceptable solution, I just dont > know what it is yet :) > > Cheers, Robin. > > > > On Wed, 2011-03-30 at 19:16 +0100, Tim Donohue wrote: > > Mark W, > > > > Thanks for getting down to the heart of the issue/question. > > > > I agree completely, that we should officially vote on our commitment to > > DSpace Services, and officially mark all classes that will be replaced > > with @deprecated notes. > > > > I've added a note about this to today's DSpace Developer Meeting agenda. > > I cannot guarantee we'll get to it today (as we have a lot of topics > > already), but I'll make sure to carry it over to next week's agenda as > > necessary. > > > > https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-03-30 > > > > Personally, I feel we should commit to Services Framework for all new > > code additions, and deprecating the older ways of doing things. However, > > I'd like to also hear any concerns others may have around going this > > route, and whether there are ways to alleviate those concerns. For > > instance, is there a way we can bring Services more "into the light", > > rather than being in the "shadows", as Mark W puts it. > > > > https://wiki.duraspace.org/display/DSDOC/DSpace+Services+Framework > > > > So, if anyone has concerns/questions to pose around the Services > > Framework, please feel free to do so in this email thread. > > > > To get this issue behind us, I'd like to call for an official 'vote' on > > deprecating older classes in very near future (likely in our meeting > > next week, April 6, if we can fit it in). So, I ask that we please try > > to discuss any concerns/questions via email, if possible. > > > > - Tim > > > > On 3/30/2011 9:03 AM, Mark H. Wood wrote: > > > There are several things going on here. > > > > > > o The dark side of greater modularity and Maven's magical > > > behind-your-back dependency management is that we lose sight of > > > some of the pieces. The Services Framework and core services have > > > been In There for some time but we never notice them; "DSpace" is > > > whatever you get when you check out svn/repo/dspace/trunk, plus > > > some shadowy stuff that Maven takes care of (which now includes > > > Services and will surely grow to encompass other parts of the > > > product). > > > > > > o I don't believe there has ever been a completed call for consensus > > > on Services. The developer community as a whole have not signed up > > > to the notion that this is the way forward. Without a group > > > commitment, inertia will rule and Services will languish. We've > > > talked about it quite a lot but the talk has never advanced to a > > > decision. > > > > > > We need to reach that decision and, assuming "yes", mark the > > > ConfigurationManager and PluginManager as @deprecated so we're > > > constantly reminded, "oh, yes, I should use the Whatsit Service now." > > > If there are reservations then let's get them on the schedule and > > > address them. We need to get beyond this point, one way or the other. > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > 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 > > > > > ------------------------------------------------------------------------------ > > 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 > > > > > ------------------------------------------------------------------------------ > 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 >
------------------------------------------------------------------------------ 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
