Hi Graham, Just to be clear - I'm not anti Maven at all, I just think we need to give people as much of a helping hand as possible to understand our project structure and thereby engage with the code. There have been a number of comments on the mailing lists along the lines of "Why cant I see the source for the Services classes ?". We need to address this or risk alienating developers. You touch on this with your observations about the modules area.
Cheers, Robin. On Thu, 2011-03-31 at 11:08 +0100, 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. > > > 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
