Hi all,
All I was thinking of was some means of helping a developer or admin
select and add modules to their local DSpace. At the very least we could
provide patches but it would be nice to do something more sophisticated,
you could call it the DSpace AppStore and provide some downloader that
would fetch the module and update the pom for the user (fantasising
now).
All the developers that I have worked alongside, without exception, have
struggled with the Maven infrastructure of DSpace. I see no harm in
acknowledging that and considering what we can do to give them a helping
hand. I fear the consequences if we make modules 'selectable' (nod to
Graham :)) and require the developer or admin to edit the pom by hand.
Cheers, Robin.
On Tue, 2011-05-10 at 16:51 +0100, Mark Diggory wrote:
> On May 10, 2011, at 5:38 AM, Robin Taylor wrote:
>
> > Apologies for starting this up again but...
> >
> > Whilst I tend towards being in favour of Mark's proposal, I think there
> > is still a lot og grey areas so its important to keep the discussion
> > going.
> >
> > Picking up on a couple of Peter's points...
> >
> >
> >> Adding a new module to DSpace is as easy as editing a
> >> pom. https://github.com/DSpace/DSpace/blob/master/dspace/pom.xml#L502
> >> I should be able to just simply edit that and add an entry for the
> >> REST API, or for WebMVC and when the project gets rebuilt, it has a
> >> new module attached.
> >>
> >
> > Whilst editing a pom is an option for developers who are familiar with
> > the DSpace Maven infrastructure I think we need to come up something
> > much more user friendly. In the UK at least most sites do not have a
> > dedicated repo developer. I also suspect most sites take the code from
> > the downloadable zip and never go near SVN. There is already a Jira
> > issue from the DCAT group asking for an install process that doesn't
> > require the installer to get involved with Maven and Ant. I think we
> > risk alienating a section of the community if we don't provide an easy
> > mechanism to add modules and/or find the source code. This is not an
> > insurmountable problem, we just need to figure out some good solutions.
> > I'm looking forward to seeing Tim's Installer, it might spark off some
> > good discussions.
>
> Hmm, so you would favor a custom installer that we would have to put more
> resources into maintaining rather than a tried and true build tool thats got
> tons of documentation, tutorials and uptake? Doesn't this result in even
> more additional training and complexity? Do you not expect that there are
> more developers in the world with experience using Maven then there are in
> DSpace?
>
> I think you need to ask the question, "who" is saying they want a simple
> installer, is it a developer, a system admin or is it a curator/repository
> manager? What should the technical background be developing DSpace and what
> should there technical background be for installing DSpace. TBH, if you
> choose one approach you risk excluding the others and we should be cautious
> about that. I say this from experience because we do have much more complex
> cases than a simple installer will ever be able to support, we have cases
> where we have multi-stage, multi-tiered, multi-tenant dspace enterprise
> platforms with webui developers redeploying webapplications remotely, we will
> be very cautious of any solution that may impact this. In this regard, such
> an installer needs to be itself "one-off" or an separate module/tool from the
> default build process.
>
> >
> >>
> >> Project Restructuring
> >> There is a minimum necessary amount of project rearrangement needed
> >> for this pick-and-choose modularization mechanism to work smoothly.
> >> Mainly the current [dspace-source]/dspace directory has to be off on
> >> its own in the code repository. It shouldn't have a parent pom, and
> >> dspace-jspui, dspace-xmlui, etc shouldn't be its "neighbors". JSPUI,
> >> and XMLUI should become pluggable modules that one enables to have as
> >> the web interface to their DSpace repository.
> >>
> >
> > But we do need a to agree on an easily understandable, consistent
> > approach. Should nothing other than the core 'dspace' module be included
> > in the first instance and everything else be optional ?
>
> The "trunk/dspace/pom.xml" and its src/main/assemble/assembly.xml is a build
> configuration that defines what is required/optional for a deployment/build.
>
> > I think Mark
> > still envisages 'stats' and 'discovery' being referenced as Maven
> > modules, just that the source code would live outside in the modules
> > directory in order to enable async releases. How would that be possible
> > if the XMLUI was not included by default ?
>
> Yes, they would be default dependencies of xmlui and the other webapps/lib,
> but default dependencies can be "excluded" and "overridden" within the maven
> build process.
>
> > Would we follow that approach
> > for all the other modules so that we effectively have a binary release
> > that includes all modules but only source code for core dspace ? Is that
> > practical ? We may have conflicting modules.
>
> It still requires management of which modules should be included, if there
> are conflicts then maven would be making a decision on the priority of the
> modules and selecting the highest priority for inclusion into the source.
>
> Mark
>
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
