[Dspace-devel] [DuraSpace JIRA] Commented: (DS-852) Split the Creative Commons and Licence steps into two seperate steps.
[ https://jira.duraspace.org/browse/DS-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20413#action_20413 ] Robin Taylor commented on DS-852: - Changes committed to trunk, version 6384. Note. Any references to flag webui.submit.enable-cc can now be deleted from the code and config. I'll do this once MIT's Creative Commons work is committed. > Split the Creative Commons and Licence steps into two seperate steps. > - > > Key: DS-852 > URL: https://jira.duraspace.org/browse/DS-852 > Project: DSpace > Issue Type: Improvement > Components: XMLUI >Reporter: Robin Taylor >Assignee: Robin Taylor > Fix For: 1.8.0 > > Attachments: Add_CC_License_Step.patch, CCLicenseStep.java, > CCLicenseStep.java, item-submission.xml, JSPCCLicenseStep.java, > JSPLicenseStep.java, LicenseStep.java, LicenseStep.java > > > At the moment I'm just looking for comments as I may have misunderstood the > code, but it seems to me that.. > The Creative Commons step and the Licence step are somewhat artificially > grouped together as one step in item-submission.xml. In order for this to > work there is a test at the start of LicenseStep that checks to see if > webui.submit.enable-cc is set to true in dspace.cfg and if so then control is > effectively passed to CCLicenseStep. It would be simpler if these classes > were completely independent of each other and defined as separate steps in > item-submission.xml. It would also mean we could remove the unneccessary flag > webui.submit.enable-cc from dspace.cfg. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including 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
[Dspace-devel] [DuraSpace JIRA] Closed: (DS-825) Market ticket for work being done to allow the user to select licences other than those offered by Creative Commons.
[ https://jira.duraspace.org/browse/DS-825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Taylor closed DS-825. --- Resolution: Won't Fix No longer a priority for my own institution. > Market ticket for work being done to allow the user to select licences other > than those offered by Creative Commons. > > > Key: DS-825 > URL: https://jira.duraspace.org/browse/DS-825 > Project: DSpace > Issue Type: Improvement > Components: DSpace API >Reporter: Robin Taylor >Assignee: Robin Taylor > Fix For: 1.8.0 > > > Create a new Licence Service that manages the retrieval of licence > information from a number of sources, not just the Creative Commons website. > I am aware of the work being done at MIT to revamp the existing CC but I > don't foresee a conflict. > I would be grateful for any comments, positive or negative. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including 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
[Dspace-devel] [DuraSpace JIRA] Resolved: (DS-780) MetadataExposure.java doesn't check the boolean value of hidden field in dspace.cfg
[ https://jira.duraspace.org/browse/DS-780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Taylor resolved DS-780. - Resolution: Duplicate Fix Version/s: 1.8.0 Please correct me if I am wrong but I believe this bug was fixed by Kim Shepherd in DS-853 (release 1.7.1). I've just tested on trunk and it appears to be working with the default XMLUI theme. > MetadataExposure.java doesn't check the boolean value of hidden field in > dspace.cfg > --- > > Key: DS-780 > URL: https://jira.duraspace.org/browse/DS-780 > Project: DSpace > Issue Type: Bug > Components: DSpace API >Affects Versions: 1.6.2 >Reporter: Samuel Ottenhoff >Assignee: Robin Taylor > Fix For: 1.8.0 > > > To replicate > 1) Add item to DSpace > 2) Set metadata.hide.dc.description.provenance = false in dspace.cfg > 3) Restart > 4) View full item as anonymous user -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including 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
[Dspace-devel] [DuraSpace JIRA] Assigned: (DS-634) Improvment to OAI-PMH + OAI-ORE harvesting support
[ https://jira.duraspace.org/browse/DS-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Taylor reassigned DS-634: --- Assignee: (was: Robin Taylor) Returned status to unassigned as I have no plans to do this work in the foreseeable future. > Improvment to OAI-PMH + OAI-ORE harvesting support > -- > > Key: DS-634 > URL: https://jira.duraspace.org/browse/DS-634 > Project: DSpace > Issue Type: New Feature > Components: OAI-PMH >Affects Versions: 1.6.2 > Environment: All >Reporter: Paul Brindley > > At the moment the OAI-PMH + OAI-ORE harvester will allow the admin to harvest > from an external source and to set up a scheduled harvest. However it would > be nice to be able to specify different frequencys for different collections. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including 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
[Dspace-devel] [DuraSpace JIRA] Commented: (DS-841) 'IllegalArgumentException: No such column rnum' error in DSpace 1.7.x XMLUI admin eperson (with Oracle backend)
[ https://jira.duraspace.org/browse/DS-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20419#action_20419 ] diwakar timilsina commented on DS-841: -- I am having the same issue. Version 1.7.1 with Oracle back end. > 'IllegalArgumentException: No such column rnum' error in DSpace 1.7.x XMLUI > admin eperson (with Oracle backend) > --- > > Key: DS-841 > URL: https://jira.duraspace.org/browse/DS-841 > Project: DSpace > Issue Type: Bug >Affects Versions: 1.7.0, 1.7.1 > Environment: RHEL5, with Oracle on the back end >Reporter: Hardy Pottinger > Fix For: 1.7.2 > > Attachments: DS-841-fix-Oracle-compatibility-for-ePerson.patch > > > In using the 1.7.x branch for testing with Oracle. Everything installed fine, > and I've got a bare-bones repository up and running. However, in the XMLUI, > when I click on the admin ePeople link, I get the following error: > java.lang.IllegalArgumentException: No such column rnum > Here are the first few lines of the stack trace: > java.lang.IllegalArgumentException: No such column rnum > at > org.dspace.storage.rdbms.TableRow.canonicalizeAndCheck(TableRow.java:581) > at org.dspace.storage.rdbms.TableRow.setColumn(TableRow.java:433) > at > org.dspace.storage.rdbms.DatabaseManager.process(DatabaseManager.java:) > at > org.dspace.storage.rdbms.TableRowIterator.next(TableRowIterator.java:151) > at > org.dspace.storage.rdbms.TableRowIterator.toList(TableRowIterator.java:204) > at org.dspace.eperson.EPerson.search(EPerson.java:358) > at > org.dspace.app.xmlui.aspect.administrative.eperson.ManageEPeopleMain.addBody(ManageEPeopleMain.java:121) > at > org.dspace.app.xmlui.wing.AbstractWingTransformer.startElement(AbstractWingTransformer.java:223) > at sun.reflect.GeneratedMethodAccessor213.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:71) > at $Proxy66.startElement(Unknown Source) > at > org.apache.cocoon.components.sax.XMLTeePipe.startElement(XMLTeePipe.java:87) > at > org.apache.cocoon.xml.AbstractXMLPipe.startElement(AbstractXMLPipe.java:94) > at > org.dspace.app.xmlui.wing.AbstractWingTransformer.startElement(AbstractWingTransformer.java:240) > at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:71) > at $Proxy49.startElement(Unknown Source) > No such error is thrown when using the JSPUI. > > org.dspace.storage.rdbms.TableRow.canonicalizeAndCheck(TableRow.java:581 > Looking more closely at the stack trace, the problem appears to be that the > canonicalizeAndCheck method in TableRow is failing when it attempts to verify > the rnum column, which is created back in org.dspace.eperson.EPerson.search. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including 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
[Dspace-devel] [DuraSpace JIRA] Updated: (DS-875) DSpace Configuration service error when using "dspace" script.
[ https://jira.duraspace.org/browse/DS-875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Van de Velde updated DS-875: -- Attachment: dspace_temp_classpath_fix.patch Configuration_service_log_fix.patch I have created temporary bugfix for this issue (to be committed in DSpace 1.72). The configuration service patch should be applied on the services and a new version of these should be released for DSpace 1.7.2 with a new minor version number (the bugfix itself is just replacing the e.printstacktrace with log.error). The temp classpath fix patch will only pass a classpath along to the scriptlauncher if one is explicitly set. For DSpace 1.8.0 a different solution will be developed so that the crash cannot occur (as suggested by Mark Diggory). I also opted not to show an error if a classpath is set, since the configurationservice isn't used in DSpace 1.7.2 so it matters little if it actually does crash. >From the Developers meeting about this topic (2011/05/18) [20:32] [ https://jira.duraspace.org/browse/DS-875 ] - [#DS-875] DSpace Configuration service error when using "dspace" script. - DuraSpace JIRA [20:33] T.b.h. the thing is I don't know what the "best" way to fix it is... [20:33] yea, thanks KevinVdV. I was also curious to see others opinions on this. Do we remove 'CLASSPATH' altogether (like current patch does) or see if we can find another way around it. [20:34] any other ideas on Ds-875 from anyone? [20:35] I was trying to comment... basically, I think if your going to pass in a CLASSPATH... the problems that it causes are upto you to manage [20:35] could we remove the e.printStacktrace ? [20:35] I think we should protect the command with at least a warning [20:35] We could but that will not fix the issue [20:36] and use if conditionals to configure the commandline to have CLASPATH only if it is set [20:36] conditional example provided needs work... theres a better way in bash [20:36] * hpottinger has to run, sorry folks [20:37] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) Quit (Quit: Page closed) [20:37] mdiggory -- so, something similar to what stuartlewis suggested then? [20:37] But I think it should also be clear IF it crashes the user should be aware of this [20:37] But we may not have bash. [20:37] Perhaps a cleaner error could be thrown... [20:38] But more explict, check for CLASSSPATH present in environment, set it only if it is present, right now what it dumps onto the executable is not correct with CLASSPATH is not set [20:38] its a bash script [20:38] KevinVdV - yea, I can see a cleaner error perhaps. But, I do like the idea of keeping the CLASSPATH in there, if it is set. [20:39] mwood@mhw ~/servers/johncock/build/dspace/dspace-1.7.0/dspace/bin $ head dspace [20:39] #!/bin/sh [20:39] I agree with you on the fact that the CLASSPATH should stay in (if explicitly set) [20:40] Agreed, do not want to lose CLASSPATH if we can deal with odd values. [20:40] Ok. it sounds like we have several of us in agreement that "preserving the inclusion of CLASSPATH" is a good thing. So, sounds like we need a few of us to revisit Ds-875 then, and see if we can throw better errors if they should occur. [20:41] A warning clarifying that if your CLASSPATH is "dirty" you may break DSpace would be good to toss in there [20:41] and like KevinVdV suggested, maybe a light/quick review of that path might help... [20:41] yea, a cleaner warning or error would be best -- either one [20:42] likewise, I would still research use of classworlds in this case as a possible means to let a third party open source tool dedictated to managing classpaths on commandline execution of java deal with such problems instead of us [20:43] because then one solution would apply to both *nix and Windblows [20:43] Using a third party tool might also work if it does a propper job [20:43] Ok. any volunteers to continue work on this? Obviously need to prioritize Ds-875 if we want to "make the deadline" for 1.7.2 [20:43] Well I can create a patch for a clean error pretty swiftly [20:44] I think thats best for 1.7.2 [20:44] KevinVdV -- that'd be great. If we can combine that with an updated patch that preserves the CLASSPATH, that seems like a good solution for 1.7.2 [20:44] save the classworlds overhaul for 1.8 [20:44] +1 mdiggory [20:44] I will indeed save the classworlds until 1.8 [20:45] I can also attempt to look into the "optional" CLASSPATH > DSpace Configuration service error when using "dspace" script. > -- > > Key: DS-875 > URL: https://jira.duraspace.org/browse/DS-875 > Project: DSpace > Issue Type: Bug > Components: DSpace API >Affects Versions: 1.7.1 >Reporter: Kevin Van de Velde >Priority: Major >
[Dspace-devel] [DuraSpace JIRA] Commented: (DS-724) createAdministrators() and createSubmitters() should not add policies if the associated group already exists
[ https://jira.duraspace.org/browse/DS-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20424#action_20424 ] Robin Taylor commented on DS-724: - Hi Andreas, The patch looks sensible, however, I can't figure out when the error condition would ever occur. Looking at the code it looks like createSubmitters() and create createAdministrators() can only ever get called once. Did you have a real world example or did you just notice that the code was inconsistent ? Thanks, Robin. > createAdministrators() and createSubmitters() should not add policies if the > associated group already exists > > > Key: DS-724 > URL: https://jira.duraspace.org/browse/DS-724 > Project: DSpace > Issue Type: Bug > Components: DSpace API >Affects Versions: 1.6.2 >Reporter: Andreas Schwander >Assignee: Robin Taylor > Attachments: Collection.patch > > > New policies will be created when the methods createAdministrators() and > createSubmitters() in org.dspace.content.Collection will be called even if > the administrators or the submitters group already exists. > These methods should just return the group if one exists and should not > update the database or add policies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including 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
Re: [Dspace-devel] [duraspace-gsoc] Regarding GSoC Project : New UI built over RESTful services
Hi Vibhaj, I made: https://github.com/DSpace/restclient Its forked from the repository you mentioned for your extJS code. You can continue committing to your entitybrowser repository as usual, so you won't be slowed down. When you've got improvements, you can then either contact the mentor of your project, or send a pull request to DSpace/restclient to have your changes merged in. Having someone review the code before merging it is a way for us to have someone review your code. I named it restclient because that is more meaningful than than just clientUI. If you don't want it to be forked from the extJS project, or if it really should be named dspace-clientui, then please let me know, since its very easy to change. Peter Dietz On Fri, May 20, 2011 at 2:52 AM, Vibhaj Rajan < vibhaj.rajan.cs...@itbhu.ac.in> wrote: > Hi all, > > I thank you for answering my queries. > > I understand the licensing issues behind GPLv3 from Sencha Ext JS. > The other libraries provide the following licenses : > >1. Dojo Toolkit : MIT License >2. JxLib : MIT License >3. UIZE : BSD License >4. MochaUI : MIT License > > I would like the community to help me in finalizing the suitable library > for use in the project. Though some of these libraries make for a small > learning curve, it would be a great opportunity for me to learn another > javascript framework. > > Just as the XMLUI is based on Cocoon, webmvc is based on Spring WebMVC and > DSpace REST is based on EntityBus, I would like the ClientUI to be based on > a generic UI framework for consuming RESTful services. > > This would be an independent project hosted at > http://github.com/tr4n2uil/entitybrowser > Extensions to the EntityBrowser would be designed in the course of the GSoC > project to provide support for each of the functional requirements > [Repository Browsing and Manipulation / Search / Statistics]. > > In this way changes to REST API in view of its possible migration to Spring > REST from EntityBus would have little changes to the ClientUI. > > I have already started work on EntityBrowser in Ext JS (though not > committed yet) but I would be happy to port it to other javascript > frameworks as per the decision of the community regarding the licensing > issue. > > And as mentioned by Graham Triggs, the ClientUI will be a part of the > DSpace (though currently as an independent module). Hence I would request > Peter Dietz to create a new repository in DSpace (Git or SVN) for > dspace-clientui module and provide me access since I have not yet obtained > access to any repository. > > Warm regards, > > > -- > *Vibhaj Rajan > Junior Undergraduate > Department of Computer Engineering > Institute of Technology BHU Varanasi > +91 92 3531 2784 > * > > -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including 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
Re: [Dspace-devel] [duraspace-gsoc] Regarding GSoC Project : New UI built over RESTful services
Hi Peter, Thank you for creating the repository. The name restclient if fine. I would like to suggest that restclient repository be a new empty one and not a fork from entitybrowser since entitybrowser is a different project from restclient. I mean that I would be using entitybrowser as a framework to build the DSpace RestClient. Just provide me with an empty repository for RestClient work which I'll fork and use the entitybrowser framework there. I feel this would be cleaner. Thank you very much for the support. Warm regards, On Fri, May 20, 2011 at 9:47 PM, Peter Dietz wrote: > Hi Vibhaj, > > I made: https://github.com/DSpace/restclient > > Its forked from the repository you mentioned for your extJS code. You can > continue committing to your entitybrowser repository as usual, so you won't > be slowed down. When you've got improvements, you can then either contact > the mentor of your project, or send a pull request to DSpace/restclient to > have your changes merged in. > > Having someone review the code before merging it is a way for us to have > someone review your code. > > I named it restclient because that is more meaningful than than just > clientUI. If you don't want it to be forked from the extJS project, or if it > really should be named dspace-clientui, then please let me know, since its > very easy to change. > > Peter Dietz > > > > > On Fri, May 20, 2011 at 2:52 AM, Vibhaj Rajan < > vibhaj.rajan.cs...@itbhu.ac.in> wrote: > >> Hi all, >> >> I thank you for answering my queries. >> >> I understand the licensing issues behind GPLv3 from Sencha Ext JS. >> The other libraries provide the following licenses : >> >>1. Dojo Toolkit : MIT License >>2. JxLib : MIT License >>3. UIZE : BSD License >>4. MochaUI : MIT License >> >> I would like the community to help me in finalizing the suitable library >> for use in the project. Though some of these libraries make for a small >> learning curve, it would be a great opportunity for me to learn another >> javascript framework. >> >> Just as the XMLUI is based on Cocoon, webmvc is based on Spring WebMVC and >> DSpace REST is based on EntityBus, I would like the ClientUI to be based on >> a generic UI framework for consuming RESTful services. >> >> This would be an independent project hosted at >> http://github.com/tr4n2uil/entitybrowser >> Extensions to the EntityBrowser would be designed in the course of the >> GSoC project to provide support for each of the functional requirements >> [Repository Browsing and Manipulation / Search / Statistics]. >> >> In this way changes to REST API in view of its possible migration to >> Spring REST from EntityBus would have little changes to the ClientUI. >> >> I have already started work on EntityBrowser in Ext JS (though not >> committed yet) but I would be happy to port it to other javascript >> frameworks as per the decision of the community regarding the licensing >> issue. >> >> And as mentioned by Graham Triggs, the ClientUI will be a part of the >> DSpace (though currently as an independent module). Hence I would request >> Peter Dietz to create a new repository in DSpace (Git or SVN) for >> dspace-clientui module and provide me access since I have not yet obtained >> access to any repository. >> >> Warm regards, >> >> >> -- >> *Vibhaj Rajan >> Junior Undergraduate >> Department of Computer Engineering >> Institute of Technology BHU Varanasi >> +91 92 3531 2784 >> * >> >> > -- *Vibhaj Rajan Junior Undergraduate Department of Computer Engineering Institute of Technology BHU Varanasi +91 92 3531 2784 * -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including 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
Re: [Dspace-devel] [duraspace-gsoc] Regarding GSoC Project : New UI built over RESTful services
To be honest, we don't really need to be creating repositories in DSpace for this. You could just create an empty public repo under your own name - fork it from any existing repository that you need to, you can get people to collaborate on it and/or fork from it. And we can have the repo moved to the DSpace account at some point in the future when it is deemed appropriate. Regards, G On 20 May 2011 18:35, Vibhaj Rajan wrote: > Hi Peter, > > Thank you for creating the repository. The name restclient if fine. > > I would like to suggest that restclient repository be a new empty one and > not a fork from entitybrowser since entitybrowser is a different project > from restclient. I mean that I would be using entitybrowser as a framework > to build the DSpace RestClient. > > Just provide me with an empty repository for RestClient work which I'll > fork and use the entitybrowser framework there. I feel this would be > cleaner. > > Thank you very much for the support. > > Warm regards, > > > > On Fri, May 20, 2011 at 9:47 PM, Peter Dietz wrote: > >> Hi Vibhaj, >> >> I made: https://github.com/DSpace/restclient >> >> Its forked from the repository you mentioned for your extJS code. You can >> continue committing to your entitybrowser repository as usual, so you won't >> be slowed down. When you've got improvements, you can then either contact >> the mentor of your project, or send a pull request to DSpace/restclient to >> have your changes merged in. >> >> Having someone review the code before merging it is a way for us to have >> someone review your code. >> >> I named it restclient because that is more meaningful than than just >> clientUI. If you don't want it to be forked from the extJS project, or if it >> really should be named dspace-clientui, then please let me know, since its >> very easy to change. >> >> Peter Dietz >> >> >> >> >> On Fri, May 20, 2011 at 2:52 AM, Vibhaj Rajan < >> vibhaj.rajan.cs...@itbhu.ac.in> wrote: >> >>> Hi all, >>> >>> I thank you for answering my queries. >>> >>> I understand the licensing issues behind GPLv3 from Sencha Ext JS. >>> The other libraries provide the following licenses : >>> >>>1. Dojo Toolkit : MIT License >>>2. JxLib : MIT License >>>3. UIZE : BSD License >>>4. MochaUI : MIT License >>> >>> I would like the community to help me in finalizing the suitable library >>> for use in the project. Though some of these libraries make for a small >>> learning curve, it would be a great opportunity for me to learn another >>> javascript framework. >>> >>> Just as the XMLUI is based on Cocoon, webmvc is based on Spring WebMVC >>> and DSpace REST is based on EntityBus, I would like the ClientUI to be based >>> on a generic UI framework for consuming RESTful services. >>> >>> This would be an independent project hosted at >>> http://github.com/tr4n2uil/entitybrowser >>> Extensions to the EntityBrowser would be designed in the course of the >>> GSoC project to provide support for each of the functional requirements >>> [Repository Browsing and Manipulation / Search / Statistics]. >>> >>> In this way changes to REST API in view of its possible migration to >>> Spring REST from EntityBus would have little changes to the ClientUI. >>> >>> I have already started work on EntityBrowser in Ext JS (though not >>> committed yet) but I would be happy to port it to other javascript >>> frameworks as per the decision of the community regarding the licensing >>> issue. >>> >>> And as mentioned by Graham Triggs, the ClientUI will be a part of the >>> DSpace (though currently as an independent module). Hence I would request >>> Peter Dietz to create a new repository in DSpace (Git or SVN) for >>> dspace-clientui module and provide me access since I have not yet obtained >>> access to any repository. >>> >>> Warm regards, >>> >>> >>> -- >>> *Vibhaj Rajan >>> Junior Undergraduate >>> Department of Computer Engineering >>> Institute of Technology BHU Varanasi >>> +91 92 3531 2784 >>> * >>> >>> >> > > > -- > *Vibhaj Rajan > Junior Undergraduate > Department of Computer Engineering > Institute of Technology BHU Varanasi > +91 92 3531 2784 > * > > -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including 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
Re: [Dspace-devel] [duraspace-gsoc] Regarding GSoC Project : New UI built over RESTful services
Hi Graham, Thanks for the suggestion. I'll do as you said. Warm regards, On Fri, May 20, 2011 at 11:46 PM, Graham Triggs wrote: > To be honest, we don't really need to be creating repositories in DSpace > for this. You could just create an empty public repo under your own name - > fork it from any existing repository that you need to, you can get people to > collaborate on it and/or fork from it. > > And we can have the repo moved to the DSpace account at some point in the > future when it is deemed appropriate. > > Regards, > G > > On 20 May 2011 18:35, Vibhaj Rajan wrote: > >> Hi Peter, >> >> Thank you for creating the repository. The name restclient if fine. >> >> I would like to suggest that restclient repository be a new empty one and >> not a fork from entitybrowser since entitybrowser is a different project >> from restclient. I mean that I would be using entitybrowser as a framework >> to build the DSpace RestClient. >> >> Just provide me with an empty repository for RestClient work which I'll >> fork and use the entitybrowser framework there. I feel this would be >> cleaner. >> >> Thank you very much for the support. >> >> Warm regards, >> >> >> >> On Fri, May 20, 2011 at 9:47 PM, Peter Dietz wrote: >> >>> Hi Vibhaj, >>> >>> I made: https://github.com/DSpace/restclient >>> >>> Its forked from the repository you mentioned for your extJS code. You can >>> continue committing to your entitybrowser repository as usual, so you won't >>> be slowed down. When you've got improvements, you can then either contact >>> the mentor of your project, or send a pull request to DSpace/restclient to >>> have your changes merged in. >>> >>> Having someone review the code before merging it is a way for us to have >>> someone review your code. >>> >>> I named it restclient because that is more meaningful than than just >>> clientUI. If you don't want it to be forked from the extJS project, or if it >>> really should be named dspace-clientui, then please let me know, since its >>> very easy to change. >>> >>> Peter Dietz >>> >>> >>> >>> >>> On Fri, May 20, 2011 at 2:52 AM, Vibhaj Rajan < >>> vibhaj.rajan.cs...@itbhu.ac.in> wrote: >>> Hi all, I thank you for answering my queries. I understand the licensing issues behind GPLv3 from Sencha Ext JS. The other libraries provide the following licenses : 1. Dojo Toolkit : MIT License 2. JxLib : MIT License 3. UIZE : BSD License 4. MochaUI : MIT License I would like the community to help me in finalizing the suitable library for use in the project. Though some of these libraries make for a small learning curve, it would be a great opportunity for me to learn another javascript framework. Just as the XMLUI is based on Cocoon, webmvc is based on Spring WebMVC and DSpace REST is based on EntityBus, I would like the ClientUI to be based on a generic UI framework for consuming RESTful services. This would be an independent project hosted at http://github.com/tr4n2uil/entitybrowser Extensions to the EntityBrowser would be designed in the course of the GSoC project to provide support for each of the functional requirements [Repository Browsing and Manipulation / Search / Statistics]. In this way changes to REST API in view of its possible migration to Spring REST from EntityBus would have little changes to the ClientUI. I have already started work on EntityBrowser in Ext JS (though not committed yet) but I would be happy to port it to other javascript frameworks as per the decision of the community regarding the licensing issue. And as mentioned by Graham Triggs, the ClientUI will be a part of the DSpace (though currently as an independent module). Hence I would request Peter Dietz to create a new repository in DSpace (Git or SVN) for dspace-clientui module and provide me access since I have not yet obtained access to any repository. Warm regards, -- *Vibhaj Rajan Junior Undergraduate Department of Computer Engineering Institute of Technology BHU Varanasi +91 92 3531 2784 * >>> >> >> >> -- >> *Vibhaj Rajan >> Junior Undergraduate >> Department of Computer Engineering >> Institute of Technology BHU Varanasi >> +91 92 3531 2784 >> * >> >> > -- *Vibhaj Rajan Junior Undergraduate Department of Computer Engineering Institute of Technology BHU Varanasi +91 92 3531 2784 * -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay___ Dspace-devel mailing li
