Re: [Dspace-devel] We need commitment on Services

All, Just a few comments in agreement with what Graham has mentioned... On 4/6/2011 3:40 PM, Graham Triggs wrote: > On 1 April 2011 11:08, Mark Diggory > wrote: > > I argued extensively during my redesign of dspace to use maven > in 2006, that many of the indi

Re: [Dspace-devel] We need commitment on Services

On 1 April 2011 11:08, Mark Diggory wrote: > I argued extensively during my redesign of dspace to use maven in 2006, > that many of the individual dspace-xxx modules should have had their own svn > project spaces (trunk/branches/tags) so that they could have separate > releasing, but the group pu

Re: [Dspace-devel] We need commitment on Services

Hi Tim, Mark, etc Thought I might also chime in in advance of our Dev meeting. While I sympathize with the sentiments expressed here, I'm a little unclear on what a vote would really buy us. I have no particular attachment to our legacy service implementations (e.g. ConfigurationManager, Plugi

Re: [Dspace-devel] We need commitment on Services

On Thu, Mar 31, 2011 at 04:06:54PM -0500, Tim Donohue wrote: > 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. Agreed. Although, the more I work with Maven, the more I itch to try something sizable

Re: [Dspace-devel] We need commitment on Services

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 > Servic

Re: [Dspace-devel] We need commitment on Services

Tim et. al., The http://scm.dspace.org/svn/repo/modules directory is intended by me to be the "archetype" for how and where we should be maintaining literally all the modules of DSpace including portions of DSpace API. I understand at the moment it looks a little bit chaotic, but what needs to be

Re: [Dspace-devel] We need commitment on Services

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 ba

Re: [Dspace-devel] We need commitment on Services

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

Re: [Dspace-devel] We need commitment on Services

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 roo

Re: [Dspace-devel] We need commitment on Services

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

Re: [Dspace-devel] We need commitment on Services

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 Me