Ivan and Domingo, Why not manage this in the dspace svn modules directory (http://scm.dspace.org/svn/repo/modules/) and we setup a process to get the Maven repository publishing necessary for your's and others modules? Once we get the artifacts deployed there, you can drop having have the user having to compile them on installation.
Its another excellent use-case for dspace modularity and we are about to entertain a discussion on the topic in an upcoming special topics meeting in the near future? this makes two, we have the dspace-srw work we see Ralph LeVan and other approaching and this use-case where we have a need to release separate versions of oai-extended to support various versions of DSpace. This is where we need feedback from the community, where are the pain-points in the current approach to modularity, how do we continue to step away from the idea of patching DSpace to include addons? These are questions you can provide requirements/feedback on to assist us in improving the mechanism. For instance, adding in configuration requires merging into the dspace/config directory those files required to customize the oai options. Can this be alleviated by having some installer functionality in the Service-Manager that creates the files in config if they are absent? Separate files for that configuration rather than merging into the dspace.cfg is a great start, if the addon can operate on defaults without the files present, your alleviating another installation step and leaving such additions for customizing default behavior after installation. We welcome your feedback and interaction. Cheers, Mark On Fri, Jul 23, 2010 at 1:02 AM, helix84 <[email protected]> wrote: > On Fri, Jul 23, 2010 at 09:48, Domingo Iglesias <[email protected]> wrote: >> I think the problem is not related with the access to the repository >> from the dspace server since I cannot access the following urls with >> my browser: >> http://repo1.maven.org/maven2/org/dspace/dspace-oaiextended-webapp/1.5.2/dspace-oaiextended-webapp-1.5.2.pom >> http://repo1.maven.org/maven2/org/dspace/dspace-oaiextended-api/1.5.2/dspace-oaiextended-api-1.5.2.pom >> http://repo1.maven.org/maven2/org/dspace/dspace-oaiextended-webapp/1.5.2/dspace-oaiextended-webapp-1.5.2.war >> http://repo1.maven.org/maven2/org/dspace/dspace-oaiextended-api/1.5.2/dspace-oaiextended-api-1.5.2.jar >> >> it reports http error 404, file not found, but I can access the file >> that appears in the thread >> (http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia/1.0-alpha-11/doxia-1.0-alpha-11.pom) > > Ah, you're right. It's not a problem on your side, the files are > missing in the maven repository. > > Which version of dspace are you building? The regular release > (dspace-1.5.2-release.zip) or the source release > (dspace-1.5.2-src-release.zip)? In the former case it may help if you > use the source release instead and build the modules yourself (the > procedure is the same, only building takes a minute longer). I'm not > sure it will help but it might. > > Regards, > ~~helix84 > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > DSpace-tech mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-tech > -- Mark R. Diggory Head of U.S. Operations - @mire http://www.atmire.com - Institutional Repository Solutions http://www.togather.eu - Before getting together, get t...@ther ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
