Re: [Dspace-tech] Handle server problem (incorrect passphrase error) [SOLVED]
I reinstalled the handle-server, done the whole process again. This time I also installed Uncomplicated Firewall (ufw) in my Debian Lenny, configured the port number. Don't know whether this UFW done the trick but my handle-server is now working. This link is good: http://wiki.lib.sun.ac.za/index.php/SUNScholar/Handle_Server. Sorry for the chaos. Thanks to all. On Mon, Oct 11, 2010 at 7:44 PM, Altaf Mahmud altaf.mah...@gmail.comwrote: Dear community, I am trying to run handle-server by following command: ./bin/start-handle-server, but the log output in /log/handle-server generated as follows: 2010/10/11 07:30:42 BDST 25 Rotating log files Enter the passphrase for this server's authentication private key: Note: Your passphrase will be displayed as it is entered Error: Incorrect passphrase (see the error log for details.) Shutting down... And contents of my /handle-server/error.log is: 2010/10/11 07:30:43 BDST 25 Started new run. Saving global values to: /home/dspace/.handle/root_info javax.crypto.BadPaddingException: Given final block not properly padded at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..) at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..) at com.sun.crypto.provider.DESCipher.engineDoFinal(DashoA13*..) at javax.crypto.Cipher.doFinal(DashoA13*..) at net.handle.security.provider.GenericProvider.decrypt_DES_ECB_PKCS5(GenericProvider.java:146) at net.handle.hdllib.Util.decrypt(Util.java:1078) at net.handle.server.HandleServer.init(HandleServer.java:306) at net.handle.server.AbstractServer.getInstance(AbstractServer.java:72) at net.handle.server.Main.initialize(Main.java:152) at net.handle.server.Main.main(Main.java:75) Unable to initialize server signature object: java.lang.Exception: Incorrect passphrase java.lang.Exception: Incorrect passphrase at net.handle.hdllib.Util.decrypt(Util.java:1083) at net.handle.server.HandleServer.init(HandleServer.java:306) at net.handle.server.AbstractServer.getInstance(AbstractServer.java:72) at net.handle.server.Main.initialize(Main.java:152) at net.handle.server.Main.main(Main.java:75) java.lang.Exception: Incorrect passphrase at net.handle.hdllib.Util.decrypt(Util.java:1083) at net.handle.server.HandleServer.init(HandleServer.java:306) at net.handle.server.AbstractServer.getInstance(AbstractServer.java:72) at net.handle.server.Main.initialize(Main.java:152) at net.handle.server.Main.main(Main.java:75) Shutting down... I've also tried with this command: ./bin/dsrun -Ddspace.log.init.disable=true -Dlog4j.configuration=log4j-handle-plugin.properties net.handle.server.Main [dspace]/handle-server/ which shows: Error in launcher.xml: Invalid class name: -Ddspace.log.init.disable=true. What should I do now? I am running DSpace 1.6.2. Any suggestion will be appreciated. Thanks. -- Altaf Mahmud System Programmer Ayesha Abed Library, BRAC University, Bangladesh. -- Altaf Mahmud System Programmer Ayesha Abed Library, BRAC University, Bangladesh. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
[Dspace-tech] Create index error
Hi All Help appreciated. I get the following after deleting indexes and then trying to create them again. The script I run is attached. This used to work. We recently upgraded to Ubuntu 10.04 and DSpace 1.6.2, but this script ran successfully after the upgrades. The problem has only occurred during the last week or so. I suspect that something trying to be indexed is throwing the error, some metadata field content. Am I right ? Creating new indexes... Please wait. Exception: read past EOF java.io.IOException: read past EOF at org.apache.lucene.store.BufferedIndexInput.refill(BufferedIndexInput.java:146) at org.apache.lucene.store.BufferedIndexInput.readByte(BufferedIndexInput.java:38) at org.apache.lucene.store.IndexInput.readInt(IndexInput.java:66) at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:207) at org.apache.lucene.index.IndexFileDeleter.init(IndexFileDeleter.java:168) at org.apache.lucene.index.IndexWriter.init(IndexWriter.java:722) at org.apache.lucene.index.IndexWriter.init(IndexWriter.java:452) at org.dspace.search.DSIndexer.openIndex(DSIndexer.java:781) at org.dspace.search.DSIndexer.createIndex(DSIndexer.java:425) at org.dspace.search.DSIndexer.main(DSIndexer.java:539) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:212) Thanks in advance. hg -- Hilton Gibson Systems Administrator JS Gericke Library Room 1053 Stellenbosch University Private Bag X5036 Stellenbosch 7599 South Africa Tel: +27 21 808 4100 | Cell: +27 84 646 4758 #!/bin/bash # Stop the services echo Stopping services... Please wait. sudo service apache2 stop sleep 10 sudo service tomcat6 stop # Build the webapp cd /home/dspace/dspace-1.6.2-src-release echo Start building packages... Please wait mvn package -U clean package cd /home/dspace/dspace-1.6.2-src-release/dspace/target/dspace-1.6.2-build.dir echo Start ant compilation... Please wait ant -Doverwrite=true update clean_backups sleep 3 # Delete the index echo Deleting indexes... Please wait. /home/dspace/bin/dspace index -v -f -d # Create new index tables echo Creating new indexes... Please wait. /home/dspace/bin/dspace index-init # Populate the indexes echo Populating new indexes... Please wait. /home/dspace/bin/dspace index -v -i # Start the services again echo Starting services... Please wait. sudo service tomcat6 start sleep 5 sudo service apache2 start echo ** echo Remember to redeploy if there are changes to the default Tomcat ROOT interface echo ** -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Migrate Collection into new sub community
Hello Lewatle, this is not part of any documentation as it is on database level. But the db schema is in the docs see http://scm.dspace.org/svn/repo/dspace/tags/dspace-1.6.2/dspace/docs/image/db-schema.gif Make sure you got a proper update of your database befor manipulating it. The sql command would be: update community2collection set community_id=NewCommunityID where collection_id=CollectionID and community_id=OldCommunityID; Replace NewCommunityID with the ID of the target community and so on. Then run index-update to update the browse indices. Hope that helps Claudia Jürgen Am 11.10.2010 09:59, schrieb Lewatle Phaladi: Hi Claudia Thanks for reply, if you have links that I can also refer to send them, for now I don't have enough info to follow. Regards, Lewatle Johannes Phaladi Institutional Repository (WIReDSpace) Library Website How is our service ? If you wish to comment on our service or offer suggestions on service issues, please email service.ad...@wits.ac.za . Confidentiality will be respected, but anonymous complaints will not be followed up. -Original Message- From: Claudia Jürgen [mailto:claudia.juer...@ub.tu-dortmund.de] Sent: 08 October 2010 04:47 PM To: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] Migrate Collection into new sub community Hello Lewatle, via the DSpace UI it is only possible to move items. You can achieve this on db level (usually warning about backup your db) by changing community2collection and then run index-update. Hope that helps Claudia Jürgen Am 08.10.2010 16:16, schrieb Lewatle Phaladi: Hi All Is that possible to migrate existing collection to new sub community in DSPace? Anyone who has done this or have idea please assist! Regards, Lewatle htmlpfont face = verdana size = 0.8 color = navyThis communication is intended for the addressee only. It is confidential. If you have received this communication in error, please notify us immediately and destroy the original message. You may not copy or disseminate this communication without the permission of the University. Only authorized signatories are competent to enter into agreements on behalf of the University and recipients are thus advised that the content of this message may not be legally binding on the University and may contain the personal views and opinions of the author, which are not necessarily the views and opinions of The University of the Witwatersrand, Johannesburg. All agreements between the University and outsiders are subject to South African Law unless the University agrees in writing to the contrary./font/p/html -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech -- Claudia Juergen Universitaetsbibliothek Dortmund Eldorado 0231/755-4043 https://eldorado.tu-dortmund.de/ -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
[Dspace-tech] where and what changes i will make so that i will get more columns (by default 3 column) when i click on title link on browse menu
Hi all, From my last few post i think i was not able to explain my problem properly. Any body please tell me where and what changes i will make so that i will get more columns (by default 3 column) when i click on title link on browse menu please hep me if any one know this. regards shashidhar -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] manikin question
the Aspect chain accumulates a big pot of potentially useful data related to the user's request, and the Theme selects and arranges them as required to make them presentable. we need some way to represent logical structure of the data before they are selected and laid out. I think we fully agree, Mark, that conceptually this is how Manakin *should* work. And yet, I don't believe this is how Manakin actually does work. Themes don't select, arrange, or layout the data on the page. Rather, dri2xhtml/structural.xsl simply iterates over the DRI XML, converting individual DRI elements into its individual HTML counterpart. The actual order of the data, and thus the essential arrangement and layout of the page, is controlled by the Aspects, not the Theme. Just a quick glance at the body section of any DRI XML response shows quite plainly that the structure of the page is set-out here in the XML, not in the XSLT. The exception to that rule is the collections/community/item metadata. If all of Manakin was set-up like those templates are set-up, Manakin would be much, much easier to use. That's what I thought DRI was designed to be. If it isn't being used that way, I think we should fix *that*. To fix the problem -- i.e., to allow Themes to actually select, arrange, and layout the data on the page -- I see no other course of action but to rewrite the XSLT. To be able to control the layout, you've got to actually allow the XSLT to lay it out. Create page-based templates wherein someone can put down the HTML for the page, and thus decide the order and arrangement of the data. The thing is, once you do that, you'll quickly see that virtually all of the DRI can be ignored -- in fact it *has* to be ignored to allow the XSLT to decide the arrangement of the data. At that point, we no longer need an XML schema that defines layers, paragraphs, headings, unordered lists, and so on -- or, rather, pseudo-layers, pseudo-paragraphs, pseudo-headings, etc. We just need, as you said previously, a way to have structured, labeled data. We can do that very easily without the overhead, complexity, and ultimately the confusion that DRI brings with it. --Dave == David Walker Library Web Services Manager California State University http://xerxes.calstate.edu From: Mark H. Wood [mw...@iupui.edu] Sent: Monday, October 11, 2010 8:15 AM To: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question On Fri, Oct 08, 2010 at 11:04:51AM -0700, Walker, David wrote: [quoting Mark Diggory, I believe] So, to be clear, the ability to construct nested divisions, lists, options, meta sections is quite powerful for getting the structure of the content pushed into the presentation layer. I appreciate your opinion here, Mark. And, yet, I think this illustrates precisely why DRI is problematic. How the content is structured on the page *is* presentation. Conceptually, you cannot push that to the presentation layer. Any code (regardless of where it lives) that defines the structure of the page *is* the presentation layer (or at least part of it). Data structure != page structure. We need to keep the namespaces in mind. A dri:div is not the same kind of thing as an xhtml:div. One *can* use them in such a way that you eventually transform one into the other, but then again one might have some completely different use for a container of unordered data, just as one might use a dri:list to express something which would never be noticed as an ordered collection in the XHTML -- it might disappear completely. For that matter, it might be consumed by a subsequent Aspect and never reach the Theme engine. Data are structured to make them readily comprehensible by later stages. A Theme isn't required to treat that structure as prescriptive of the structure of its output. Come to think of it, an Aspect *can't* reliably coerce the final page structure, at least not in some ways you might want to try. An Aspect has no way of knowing its position in the chain, or what other Aspects are included before it, so it can't slot its work into the right place on the page; if it has something to add, it may as well stick it on the end and assume that some Theme will put it where that Theme wants it. The DRI document *has to* be an abstract representation of the content, because only the last stage in the pipeline has the certainty required to produce a concrete one. It took me a while to work out what the parts were doing, conceptually, but what finally made sense to me was that the Aspect chain accumulates a big pot of potentially useful data related to the user's request, and the Theme selects and arranges them as required to make them presentable. At least, that's the way I've tried to use the pipeline, and it seems to work. Regardless of how the physical structuring of the final page is done, we need some way to
[Dspace-tech] Show Dspace deposit license in xmlui
How can I enable the deposit license (license.txt) from the itemsummary view in xmlui? In dspace.cfg I have webui.licence_bundle.show = true are there anything else I have to change/add? Dspace 1.6.1 on RedHat/postgres/Tomcat. Thanks, Tonny -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Show Dspace deposit license in xmlui
Well, well. That setting is only for jspui. But I have now changed DIM-Handler.xsl. I have changed the lines from xsl:apply-templates select=./mets:fileSec/mets:fileg...@use='CC-LICENSE']/ TO xsl:apply-templates select=./mets:fileSec/mets:fileg...@use='CC-LICENSE' or @USE='LICENSE']/ And that seems to work :) Tonny Den 12-10-2010 15:25, Tonny Hjelmberg Laursen skrev: How can I enable the deposit license (license.txt) from the itemsummary view in xmlui? In dspace.cfg I have webui.licence_bundle.show = true are there anything else I have to change/add? Dspace 1.6.1 on RedHat/postgres/Tomcat. Thanks, Tonny -- Venlig hilsen | Kind Regards Tonny Hjelmberg Laursen Systemadministrator CBS Library IT Copenhagen Business School Solbjerg Plads 3 (D2.30), DK-2000 Frederiksberg Tel.: (+45) 3815 3697 | Mob.: (+45) 2427 3242 | thl@cbs.dk -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
[Dspace-tech] bin creation was not successful
Hi All, dspace-1.5.2-src-release/dspace/target/dspace-1.5.2-build.dir$ ant fresh_install Buildfile: build.xml init_installation: BUILD FAILED /home/xxxt/dspace-1.5.2-src-release/dspace/target/dspace-1.5.2-build .dir/build.xml:530: Directory /home/dspace/bin creation was not successful for an unknow n reason How this problem solved. Instead of reinstalling postgresql(works this way) There is build.xlm file the directory dspace-1.5.2-build.dir Regards, sisay -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] manikin question
Hi all, Very interesting discussion. I think there really are two layers of discussion going on here, one is much easier to tackle now, and one is something that may need ongoing discussion/analysis. - Theme Layer Discussions - This is basically the complaint that dri2xhtml/structural.xsl is both: (a) too confusing/complex, and (b) just does a very basic transformation of DRI elements directly into its XHTML counterparts. This is something that could be resolved immediately with no changes to the DRI schema, and likely little-to-no changes to Java Aspects. All we need is someone to volunteer to create a new theme (codename: QuickStart theme, or similar). This new QuickStart theme needs to *NOT* utilize dri2xhtml/structural.xsl. Instead, it will re-write it's own XSLT into an easier to manage theme, which could include separate templates per page (or XSLTs per page) -- based on what the theme designer(s) decides upon. I believe that building this basic theme would not go against the purposes of Manakin, and it may help in adoption (and also allow users to get up to speed more quickly). Notice, I'm not suggesting to remove or replace DRI2XHTML -- rather, we want an alternative QuickStart Theme, that people can build off of instead of DRI2XHTML. Themes which already use DRI2XHTML would be unaffected, and can continue to use that as the basis for their theme, if they choose to. DRI / Aspect Layer Discussions This is essentially David's (and others) point that perhaps DRI needs some redesign or re-thinking. This obviously is a larger issue, as reworking (or getting rid of) DRI would require major overhaul of all of Manakin. So, I'd deem this a longer term discussion -- still worthwhile to be having, but it needs more analysis. I also think that if we chose to build an Easy-Start theme, the creation of that simple theme may help us learn more about what may be limiting to the DRI that is created by aspects, and maybe even what parts of DRI schema could be done away with (maybe it could be vastly simplified). We could also work to apply small fixes to improve specific Aspects which may be more limiting to Themes than others. But, any larger scale changes would need more analysis and possibly a team of volunteer working on it. I'm not saying this to discourage discussion of DRI/Aspect changes. Rather, I just want to point out that we may be able to split this into two problems -- one of which we could tackle immediately, if we can find a volunteer or two! Just my quick thoughts, - Tim On 10/12/2010 8:45 AM, Walker, David wrote: the Aspect chain accumulates a big pot of potentially useful data related to the user's request, and the Theme selects and arranges them as required to make them presentable. we need some way to represent logical structure of the data before they are selected and laid out. I think we fully agree, Mark, that conceptually this is how Manakin *should* work. And yet, I don't believe this is how Manakin actually does work. Themes don't select, arrange, or layout the data on the page. Rather, dri2xhtml/structural.xsl simply iterates over the DRI XML, converting individual DRI elements into its individual HTML counterpart. The actual order of the data, and thus the essential arrangement and layout of the page, is controlled by the Aspects, not the Theme. Just a quick glance at thebody section of any DRI XML response shows quite plainly that the structure of the page is set-out here in the XML, not in the XSLT. The exception to that rule is the collections/community/item metadata. If all of Manakin was set-up like those templates are set-up, Manakin would be much, much easier to use. That's what I thought DRI was designed to be. If it isn't being used that way, I think we should fix *that*. To fix the problem -- i.e., to allow Themes to actually select, arrange, and layout the data on the page -- I see no other course of action but to rewrite the XSLT. To be able to control the layout, you've got to actually allow the XSLT to lay it out. Create page-based templates wherein someone can put down the HTML for the page, and thus decide the order and arrangement of the data. The thing is, once you do that, you'll quickly see that virtually all of the DRI can be ignored -- in fact it *has* to be ignored to allow the XSLT to decide the arrangement of the data. At that point, we no longer need an XML schema that defines layers, paragraphs, headings, unordered lists, and so on -- or, rather, pseudo-layers, pseudo-paragraphs, pseudo-headings, etc. We just need, as you said previously, a way to have structured, labeled data. We can do that very easily without the overhead, complexity, and ultimately the confusion that DRI brings with it. --Dave == David
[Dspace-tech] Handle server confusion
Sorry if I'm missing something obvious here, but I wonder if someone can help me better understand how the handle name resolution service works with DSpace. We are considering a URI change from http://hdl.handle.net/prefix/item to http://local.dspace/prefix/item. I know I can change the handle.canonical.prefix in dspace.cfg, but if I set it to our local server, will that also break the name resolution service that handle.net provides? Or is it possible to update the handle configuration to account for URIs that include local hostnames? Eric -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
[Dspace-tech] NOTICE: JIRA Migration - This Thursday, Oct 14, 9:30am-11:30am ET
All, This Thursday morning (Oct 14th from 9:30am-11:30am ET), DuraSpace will be merging the JIRA instance for the DSpace Project (http://jira.dspace.org) into the central DuraSpace JIRA (http://jira.duraspace.org), used by Fedora-Commons and DuraCloud. This migration will make it easier for cross-project development to occur, while also providing a much needed JIRA upgrade to the DSpace Developer community. Each of our developer communities can expect the following: === For DSpace Developers / Users === * On Thursday, during the migration, the DSpace JIRA (http://jira.dspace.org) will be continue to be available but will be READ-ONLY. * After the migration completes, you will be automatically redirected to the new JIRA location. All previously saved links/bookmarks to issues should redirect automatically to their new location. (However, saved JIRA searches or filters may no longer work and may need to be recreated.) * Your JIRA Login information: ** If you have an existing Wiki Account (http://wiki.dspace.org), after the migration completes you will use that same account password to access JIRA. (If you have forgotten your password, you can also request to reset it. More information about resetting your password will be sent after the migration has completed.) ** If you do not already have a Wiki account, your existing JIRA username will be auto-migrated to the new system. However, your password will NOT be migrated automatically. *AFTER THE MIGRATION, YOU WILL NEED TO RESET YOUR PASSWORD.* More information about resetting your password will be sent after the migration has completed. === For Fedora or DuraCloud Developers / Users === This migration will only minimally affect your access to the DuraSpace JIRA system (http://jira.duraspace.org). The DuraSpace JIRA will be restarted briefly at the start of the migration (around 9:30 AM ET) to perform a full system backup. After that, you will be able to access DuraSpace JIRA as normal. However, during the migration itself, JIRA may be slow to respond at times. Please let me know if you should have any questions or concerns. Thanks, - Tim -- Tim Donohue Technical Lead for DSpace Project DuraSpace.org -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
[Dspace-tech] Annual submission Rates
Hi All, Hope I find you well. I am interested in establishing the number of items deposited each year in our IR. Is there anyone out there who had done that and can provide me with the SQL statement to do that. Regards, Admire -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] manikin question
This is a very reasonable proposal, Tim. I feel compelled to put my development time where my mouth is -- and at least get something started. Although we need a cooler name than QuickStart theme. ;-) However, DSpace is not my main area of work. Given my other responsibilities, I definitely don't have time to complete a project of this scale by myself. It essentially means re-writing the interface from scratch. Also, if we are going to rewrite the interface, I think it would be *well* worth our time and effort to also redo the Manakin CSS, which IMO needs an overhaul as much as the XSLT. All that being said, I think the *last* thing the DSpace community needs is Yet Another Interface. Obviously, I think Manakin needs to be redesigned. And, equally obviously, a change of that scale would need proceed in parallel to existing efforts. But if the long-term outcome here is just an alternate Theme (albeit one that is fundamentally different from all the others), then I think we've just created more (and duplicate) work for everyone. At some point, it would be good if the developers, or the community as a whole, evaluated this alternate approach and actually made a yeah or nay decision on it. Long term, IMO, it either needs to replace the structural.xsl approach or just go into the recycle bin. I don't think it's sustainable otherwise. --Dave == David Walker Library Web Services Manager California State University http://xerxes.calstate.edu From: Tim Donohue [tdono...@duraspace.org] Sent: Tuesday, October 12, 2010 7:52 AM To: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question Hi all, Very interesting discussion. I think there really are two layers of discussion going on here, one is much easier to tackle now, and one is something that may need ongoing discussion/analysis. - Theme Layer Discussions - This is basically the complaint that dri2xhtml/structural.xsl is both: (a) too confusing/complex, and (b) just does a very basic transformation of DRI elements directly into its XHTML counterparts. This is something that could be resolved immediately with no changes to the DRI schema, and likely little-to-no changes to Java Aspects. All we need is someone to volunteer to create a new theme (codename: QuickStart theme, or similar). This new QuickStart theme needs to *NOT* utilize dri2xhtml/structural.xsl. Instead, it will re-write it's own XSLT into an easier to manage theme, which could include separate templates per page (or XSLTs per page) -- based on what the theme designer(s) decides upon. I believe that building this basic theme would not go against the purposes of Manakin, and it may help in adoption (and also allow users to get up to speed more quickly). Notice, I'm not suggesting to remove or replace DRI2XHTML -- rather, we want an alternative QuickStart Theme, that people can build off of instead of DRI2XHTML. Themes which already use DRI2XHTML would be unaffected, and can continue to use that as the basis for their theme, if they choose to. DRI / Aspect Layer Discussions This is essentially David's (and others) point that perhaps DRI needs some redesign or re-thinking. This obviously is a larger issue, as reworking (or getting rid of) DRI would require major overhaul of all of Manakin. So, I'd deem this a longer term discussion -- still worthwhile to be having, but it needs more analysis. I also think that if we chose to build an Easy-Start theme, the creation of that simple theme may help us learn more about what may be limiting to the DRI that is created by aspects, and maybe even what parts of DRI schema could be done away with (maybe it could be vastly simplified). We could also work to apply small fixes to improve specific Aspects which may be more limiting to Themes than others. But, any larger scale changes would need more analysis and possibly a team of volunteer working on it. I'm not saying this to discourage discussion of DRI/Aspect changes. Rather, I just want to point out that we may be able to split this into two problems -- one of which we could tackle immediately, if we can find a volunteer or two! Just my quick thoughts, - Tim On 10/12/2010 8:45 AM, Walker, David wrote: the Aspect chain accumulates a big pot of potentially useful data related to the user's request, and the Theme selects and arranges them as required to make them presentable. we need some way to represent logical structure of the data before they are selected and laid out. I think we fully agree, Mark, that conceptually this is how Manakin *should* work. And yet, I don't believe this is how Manakin actually does work. Themes don't select, arrange, or layout the data on the page. Rather, dri2xhtml/structural.xsl simply iterates over the DRI XML, converting
Re: [Dspace-tech] Annual submission Rates
Hello Admire, assuming that you count as deposited, when the item was publically available (reached the in archive status) the sql for this year would be: select count(item_id) from metadatavalue where metadata_field_id=12 and text_value like '2010%'; metadata_field_id = 12 refers to dc.date.available on a default installation Hope that helps Claudia Jürgen Am 12.10.2010 17:47, schrieb Admire: Hi All, Hope I find you well. I am interested in establishing the number of items deposited each year in our IR. Is there anyone out there who had done that and can provide me with the SQL statement to do that. Regards, Admire -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech -- Claudia Juergen Universitaetsbibliothek Dortmund Eldorado 0231/755-4043 https://eldorado.tu-dortmund.de/ -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Annual submission Rates
Hi
The following should work (on Postgres):
SELECT to_char(date_trunc('year', t1.ts), '') AS year, count(*) FROM
(SELECT to_timestamp(text_value, '-MM-DD') AS ts FROM metadatavalue
WHERE metadata_field_id = 12) t1 GROUP BY date_trunc('year', t1.ts);
George
On 12/10/10 16:47, Admire wrote:
Hi All,
Hope I find you well. I am interested in establishing the number of
items deposited each year in our IR. Is there anyone out there who had
done that and can provide me with the SQL statement to do that.
Regards,
Admire
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] manikin question
On 10/12/2010 10:50 AM, Walker, David wrote: This is a very reasonable proposal, Tim. I feel compelled to put my development time where my mouth is -- and at least get something started. Although we need a cooler name than QuickStart theme. ;-) Fine by me -- that's just a codename :) However, DSpace is not my main area of work. Given my other responsibilities, I definitely don't have time to complete a project of this scale by myself. It essentially means re-writing the interface from scratch. Also, if we are going to rewrite the interface, I think it would be *well* worth our time and effort to also redo the Manakin CSS, which IMO needs an overhaul as much as the XSLT. I was assuming this new QuickStart theme may have its own CSS, as CSS goes alongside the XSLT to make up the theme. So, I think the QuickStart theme designers could decide to build the CSS however they want. There's no requirement/expectation that all themes need to use the same CSS. All that being said, I think the *last* thing the DSpace community needs is Yet Another Interface. Obviously, I think Manakin needs to be redesigned. And, equally obviously, a change of that scale would need proceed in parallel to existing efforts. But if the long-term outcome here is just an alternate Theme (albeit one that is fundamentally different from all the others), then I think we've just created more (and duplicate) work for everyone. At some point, it would be good if the developers, or the community as a whole, evaluated this alternate approach and actually made a yeah or nay decision on it. Long term, IMO, it either needs to replace the structural.xsl approach or just go into the recycle bin. I don't think it's sustainable otherwise. Agreed it would be good to hear if others think this is a good approach to try another type of Theme (what we've been tentatively calling QuickStart theme). As for longer term maintenance, there's actually two sides to this story. :) We obviously cannot just do away with the structural.xsl, as every current Manakin user is using it (unless they rebuilt all their local XSLT from scratch). So, I'm all for competition between multiple theme models (e.g. the DRI2XHTML model vs. a QuickStart model). In the end, one may win out over the other. Or, it's also possible that they'd both survive for a while (if there are interested parties maintaining each of them), and I don't think that's necessarily a bad thing if they did (as long as we have the volunteers to manage each). It's just too early to speculate. - Tim -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] manikin question
I'll jump in... I have the shared frustration that it is really hard to get others who are skilled in regular web development to jump in and help out when it comes to XMLUI. I'm not supporting the overthrow of DRI, atleast not until an improved way of doing things is available. So, if we can improve the themes to make XMLUI development better, then lets work on themes. (In-line editing)... On Tue, Oct 12, 2010 at 11:50 AM, Walker, David dwal...@calstate.eduwrote: This is a very reasonable proposal, Tim. I feel compelled to put my development time where my mouth is -- and at least get something started. Although we need a cooler name than QuickStart theme. ;-) To me, DRI kind of sounds like DRY, (Don't Repeat Yourself), in my experience with structural.xsl, it feels like anything that could be compacted into a single function has been done. So, for starters, I would almost want a Please Repeat Yourself theme I'll call it PRY / prybar. But if the long-term outcome here is just an alternate Theme (albeit one that is fundamentally different from all the others), then I think we've just created more (and duplicate) work for everyone. Well, I'm thinking we could have community maintained themes that can live and grow outside of the central repository. May the best way of working with xmlui win for each IR. Think: not DRI+structural is wrong, but DRI+prybar works better for me. The core-themes in XMLUI haven't had much if any attention recently: 1 -- They don't contain bugs or lack features, atleast not much that has made it into our bugtracker JIRA. 2 -- They're viewed as part of a local IR's customizations. (atleast in my opinion). That doesn't mean that an effort to improve them can't take place. Down the road, to specify theme compatibility, one could say that you can version the themes. So, in the case of the hypothetical prybar theme. -- Prybar-0.1 (released today) to Prybar-1.0 (released at end of the year) will be compatible with dspace-xmlui-1.6 to dspace-xmlui-1.7 (which have no DRI modifications). -- dspace-xmlui-1.8 which could change the DRI it creates, or was refactored to simply pass data to the presentation layer, then the maintainer of prybar would need to update their theme to take advantage of these changes and release prybar-2.0 This won't be maintained by the DSpace developers, but by the theme developer. Good themes that are created can get mentioned in the XMLUI customization section of the documentation. To support more experimentation with DSpace XMLUI themes, I suggest that we consider doing distributed development (Git) for this. I sent out a proposal on dspace-tech last week, and so far I have the dspace-xmlui-webapp/src/main/webapp/ code up on Github. In there you can find a clone of xmlui/webapp tag of 1.6.2http://github.com/DSpace/xmlui-webapp. I have put my university's modifications (OSUlibrarieshttp://github.com/osulibraries/xmlui-webapp) in, and SUNScholar http://github.com/SUNScholar/xmlui-webapp has put their code up there as well. P.S. The network graph looks kind of cool: http://github.com/DSpace/xmlui-webapp/network Other people can do the same (Individuals or Organizations / Institutions). Fork the tag, add their code, and let others know what they can find from their theme customizations. My University's theme-directory has a book-reader theme, someone who wants that can clone it, make some bug fixes to their own checkout, and I can see what they've changed. Anyone who makes a QuickStart / prybar / one-file-per-page theme could do the same, and let others know that now that they've broken up their theme, its easier to modify and maintain. So, good luck, this is just a suggestion. But I think this is also easier than managing svn commit rights. -- Peter Dietz Systems Developer/Engineer Ohio State University Libraries --Dave == David Walker Library Web Services Manager California State University http://xerxes.calstate.edu From: Tim Donohue [tdono...@duraspace.org] Sent: Tuesday, October 12, 2010 7:52 AM To: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question Hi all, Very interesting discussion. I think there really are two layers of discussion going on here, one is much easier to tackle now, and one is something that may need ongoing discussion/analysis. - Theme Layer Discussions - This is basically the complaint that dri2xhtml/structural.xsl is both: (a) too confusing/complex, and (b) just does a very basic transformation of DRI elements directly into its XHTML counterparts. This is something that could be resolved immediately with no changes to the DRI schema, and likely little-to-no changes to Java Aspects. All we need is someone to volunteer to create a new theme (codename: QuickStart theme, or similar). This new QuickStart theme needs to *NOT* utilize
