On 1 April 2011 11:08, Mark Diggory <[email protected]> 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 pushed back excessively on creating more than on
> trunk at that time.
>
The thing is, we are looking for a genuine benefit to operating in that way
- and so far, personally, I can't see one. Even in the 'simplest' case of
dspace-services, it isn't really taking advantage of separate releasing -
it's basically being released at the same time as the main release. Except
it's more work to have to do separately each time.
And with the nature of the application - that the interfaces, ingest
mechanisms, batch processes, all need to understand and work with the domain
model/services - the vast majority of the time we won't be able to take
advantage of separate releases. We'll just have to do lots of individual
releases, at the same time.
IMHO, there is a simpler test and definition that needs to apply - if we
have some code, that does not depend on the dspace (/duraspace) 'namespace',
and provides a general service that can be used by applications other than
dspace, then we should want it to have separate releasing. Then again, it
probably should be split out to a new project entirely to raise it's profile
amongst the rest of the development community - even if the initial
'community' for it is only a set of interested dspace developers.
> I have to be critical that DSpace Services have no reason to be in the main
> DSpace trunk. It is a standalone tool with no dependency on dspace-api,
> this was how it was designed to be.
>
It is not standalone though. It may not have a dependency on dspace-api, but
it is in itself very distinctly a part of the 'core' of dspace. And
something that everything else does depend - directly or indirectly. It is
that nature of it's relationship to the rest of dspace that marks it out as
something that should be part of trunk - something that gives it two
extremely good reasons to be so:
1) Your entire DSpace installation depends on it. So when your organisation
is taking a copy of all of the source that went to build that installation
to hold locally - so that it is preserved for it's own maintenance
requirements - you can get it easily. Being outside of trunk - and worse,
part of a directory that includes many things that aren't part of a typical
dspace installation, and in many cases are simply unfinished prototypes -
just makes that harder.
2) It needs to be maintained and reviewed by members of the community. Not
being part of trunk seriously hampers that.
IMHO, the desire for separate releases is obscuring some really important
reality. In terms of dspace releases (as in by the committers, for the
community), it's just not that relevant - you can't escape releasing most
(if not all) of them at the same time, and very few people would adjust
their local projects in such a way to make use of them anyway.
And to be honest, none one should be locally altering the implementation of
> the Service Manager codebase in the customization of your DSpace instance.
> This doesn't mean other committers in the group can't alter the code and
> contribute improvements to it, everyone is certainly welcome to contribute.
> Its very serious, you shouldn't be touching this code if you are just
> customizing your local DSpace instance, this is why its source is separate
> from the distribution and has separate release cycles.
>
I agree that if you are just customizing a local instance, then there are
parts of the code that should only be modified as a last resort - that
includes various parts of the domain model, not just the service manager.
But that's our role to document and educate - not babysit. It's far more
important that we don't obstruct the review of code, and hold people back
from debugging, fixing, contributing to that code than it is for us to try
to prevent someone making a local modification that they will find hard to
maintain - when they probably won't anyway.
G
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
