DSpace
  1. DSpace
  2. DS-377

Add META tags identifying DSpace source version to Web UIs

    Details

    • Attachments:
      1
    • Comments:
      9

      Description

      Add a META tag to the HTML generated for each web-UI page that identfies the version of the DSpace source running on the site. This lets administrators and developers tell at a glance what their test servers are running, and curious visitors see what version of DSpace is behind a production site.

      The change is very simple and automated in action. Maven is already doing property-substitution on the dspace.cfg file, so let it plug in the verison of the "dspace" project (under group "org.dspace"), which should always be the same as the released or snapshot project for the source tree. From there it's a simple matter of putting it in a pageMeta element for the XMLUI.

      NOTE: This still needs a volunteer to either implement it for JSPUI or point out the most efficient way to do -- I'll be happy to code and test but I don't know the JSPUI well enough to spot the most effective place to put a META tag that goes on every page.

        Activity

        Hide
        Stuart Lewis added a comment -
        The easiest way to add this to the jspui is to edit dspace-jspui/dspace-jspui-webapp/src/main/webapp/layout/header-default.jsp

        In the code block at the top of the file add:

        String dspaceversion = ConfigurationManager.getProperty("dspace.project.version");

        Then make use of that further down in the <head>

        <meta name="DSpace.project.version" content="<%= dspaceversion %>" />


        However... would it be more correct to report it using:

        <meta name="Generator" content="DSpace {version}" />

        The jspui already includes '<meta name="Generator" content="DSpace" />' so it is just a case of changing this to be:

        <meta name="Generator" content="DSpace <%= dspaceversion %>" />
        Show
        Stuart Lewis added a comment - The easiest way to add this to the jspui is to edit dspace-jspui/dspace-jspui-webapp/src/main/webapp/layout/header-default.jsp In the code block at the top of the file add: String dspaceversion = ConfigurationManager.getProperty("dspace.project.version"); Then make use of that further down in the <head> <meta name="DSpace.project.version" content="<%= dspaceversion %>" /> However... would it be more correct to report it using: <meta name="Generator" content="DSpace {version}" /> The jspui already includes '<meta name="Generator" content="DSpace" />' so it is just a case of changing this to be: <meta name="Generator" content="DSpace <%= dspaceversion %>" />
        Hide
        Larry Stone added a comment -
        I'd assumed that the META tag with name="Generator" was magic and should be left alone, but some "research" indicates it is (a) not even loosely standardized, i.e. no mention by w3c; (b) expected to include the application version if available. So, yeah, I'll add the version to the Generator tag's value.

        This new patch includes that and the JSPUI implementation. Thanks!

        Unless Mark has any better ideas for dragging a version out of Maven, I'll commit it soon.
        Show
        Larry Stone added a comment - I'd assumed that the META tag with name="Generator" was magic and should be left alone, but some "research" indicates it is (a) not even loosely standardized, i.e. no mention by w3c; (b) expected to include the application version if available. So, yeah, I'll add the version to the Generator tag's value. This new patch includes that and the JSPUI implementation. Thanks! Unless Mark has any better ideas for dragging a version out of Maven, I'll commit it soon.
        Hide
        Stuart Lewis added a comment -
        My only worry with maven version -> dspace.cfg is that many people update dspace.cfg between versions rather than using the dspace.cfg.new and merging. So I wonder if the version will become out of date over time for a lot of people? Is there any way to get maven to write a file (e.g. config/version) which always gets overwritten?
        Show
        Stuart Lewis added a comment - My only worry with maven version -> dspace.cfg is that many people update dspace.cfg between versions rather than using the dspace.cfg.new and merging. So I wonder if the version will become out of date over time for a lot of people? Is there any way to get maven to write a file (e.g. config/version) which always gets overwritten?
        Hide
        Larry Stone added a comment -
        That's true, the value embedded in dspace.cfg probably would get out of date.

        It looks like the maven "resources" plugin can interpolate maven properties into arbitrary resource files, see http://maven.apache.org/plugins/maven-resources-plugin/ ...but I'll hold off on using it until Mark verifies that it doesn't cause obnoxious problems in builds like the overlay feature. If it can be used safely, then I think the cleanest thing to do is add a filtered resource file to dspace-api, and a Utils method to fetch its value, e.g. Utils.getVersion() => "DSpace 1.6.0"
        Show
        Larry Stone added a comment - That's true, the value embedded in dspace.cfg probably would get out of date. It looks like the maven "resources" plugin can interpolate maven properties into arbitrary resource files, see http://maven.apache.org/plugins/maven-resources-plugin/ ...but I'll hold off on using it until Mark verifies that it doesn't cause obnoxious problems in builds like the overlay feature. If it can be used safely, then I think the cleanest thing to do is add a filtered resource file to dspace-api, and a Utils method to fetch its value, e.g. Utils.getVersion() => "DSpace 1.6.0"
        Hide
        Mark H. Wood added a comment -
        I agree that this should NOT be stored in dspace.cfg -- it is not configuration data and shouldn't be offered for modification by the sysadmin.

        I note that Maven is already producing a Properties file with the version in it, which you can see thus:

        import java.io.InputStream;
        import java.io.IOException;
        import java.util.Properties;

        class VersionTest
        {
            public static void main(String[] argv)
        throws java.io.IOException
            {
        InputStream cis = VersionTest.class.getResourceAsStream
        ("/META-INF/maven/org.dspace/dspace-api/pom.properties");
        Properties constants = new Properties();
        constants.load(cis);
        System.out.println("version " + constants.get("version"));
            }
        }

        However that only helps us with a handful of Maven properties, and we might want other things later on. We might be better off adding a dspace-api/src/main/resources/constants.properties to be filtered and wrapped into dspace-api-VERSION.jar.

        Also I recommend that the value be a pure version number. It's easier to supply the literal "DSpace" where we want it than to parse the version out of a more complex string where we want only the version. That is, it should be the value of ${project.version}.
        Show
        Mark H. Wood added a comment - I agree that this should NOT be stored in dspace.cfg -- it is not configuration data and shouldn't be offered for modification by the sysadmin. I note that Maven is already producing a Properties file with the version in it, which you can see thus: import java.io.InputStream; import java.io.IOException; import java.util.Properties; class VersionTest {     public static void main(String[] argv) throws java.io.IOException     { InputStream cis = VersionTest.class.getResourceAsStream ("/META-INF/maven/org.dspace/dspace-api/pom.properties"); Properties constants = new Properties(); constants.load(cis); System.out.println("version " + constants.get("version"));     } } However that only helps us with a handful of Maven properties, and we might want other things later on. We might be better off adding a dspace-api/src/main/resources/constants.properties to be filtered and wrapped into dspace-api-VERSION.jar. Also I recommend that the value be a pure version number. It's easier to supply the literal "DSpace" where we want it than to parse the version out of a more complex string where we want only the version. That is, it should be the value of ${project.version}.
        Hide
        Larry Stone added a comment -
        New, and final, version of the patch.. This one grabs the version from dspace-api's pom.properties (thanks, Mark!) and adds it to the META name="Generator" tag in both UIs. Since this is all we need right now, I'm for keeping the change as small as practical.

        org.dspace.app.util.Util.getSourceVersion() returns e.g. "1.6.0-SNAPSHOT"

        It appears to be possible to just add properties files under main/resources and use the <resources> plugin in the POM to interpolate properties ("filter"). There is also the JAR manifest file, which can be adjusted in the POM. That leaves enough room for future adventures.
        Show
        Larry Stone added a comment - New, and final, version of the patch.. This one grabs the version from dspace-api's pom.properties (thanks, Mark!) and adds it to the META name="Generator" tag in both UIs. Since this is all we need right now, I'm for keeping the change as small as practical. org.dspace.app.util.Util.getSourceVersion() returns e.g. "1.6.0-SNAPSHOT" It appears to be possible to just add properties files under main/resources and use the <resources> plugin in the POM to interpolate properties ("filter"). There is also the JAR manifest file, which can be adjusted in the POM. That leaves enough room for future adventures.
        Hide
        Tim Donohue added a comment -
        Additional comments from Committers meeting on Nov 18, 2009.

        Summary: We came to an agreement that Larry's patch looks good as-is for 1.6. However, there are some addition features/suggestions we may want to look into post-1.6. The discussion below is long, but there are some good ideas for future additions that came up.

        [15:16] <StuartLewis_> And the second patch is:
        [15:17] <StuartLewis_> http://jira.dspace.org/jira/browse/DS-377 Add META tags identifying DSpace source version to Web UIs
        [15:17] <StuartLewis_> See the comments in this one, especially Larry's last comment to explain how the version will be identified.
        [15:18] <mdiggory> Looking at the topic...
        [15:18] <tdonohue> +1 sounds good to me - glad we can populate based on version in Maven POM
        [15:18] <mhwood> +1
        [15:18] <mdiggory> A maven based approach would use filtering in the mvn package phase
        [15:19] <kshepherd> +1
        [15:19] <mdiggory> you don't really need to java code this
        [15:20] <tdonohue> mdiggory: does this mean you disagree with Larry's approach?
        [15:20] <kshepherd> hmm.. needs more discussion?
        [15:20] <mdiggory> identify the files you want to filter and create a parameter in them, map that parameter in the pom.xml
        [15:20] <mdiggory> on release that parameter will be processed
        [15:21] <mdiggory> Seems like its coding before researching
        [15:21] <tdonohue> mdiggory: so you are saying you'd list the specific files in XMLUI or JSPUI that need a parameter to be replaced?
        [15:21] <mdiggory> pretty much
        [15:21] <tdonohue> and the maven will replace it during the packaging?
        [15:21] <mhwood> So you want the package phase to customize the XSL or something? It'd have to track down all a site's themes....
        [15:21] <mdiggory> war generation includes filtering
        [15:22] <tdonohue> would it also work for completely custom themes, like mhwood brings up?
        [15:22] <mdiggory> I assume you would run this risk if you were overriding that header in dri2xhtml
        [15:23] <jeffreytrimble> We'd have to warn users about this....so they remember to re-customize those files affected by this.
        [15:24] <mdiggory> but i will add... theres no reason this couldn't be in a properties file or the default Navigation transformer rather than chasing individual xslt templates
        [15:24] <mhwood> It's being fetched from a properties file now.
        [15:24] <jeffreytrimble> But it is entirely possible to gather up a list of files that this change would/does affect and let the users know the work they have in store?
        [15:24] <mdiggory> in which case, it might not even be maven based filtering... just use SVN versioning infor
        [15:25] <mdiggory> svn keywords in the java classes
        [15:25] <mdiggory> or a properties file
        [15:25] <bradmc> Seems fragile to have it scattered among customizable files. An include of a single file that gets changed seems more robust - but creates other issues.
        [15:25] <tdonohue> jeffreytrimble: yes, you are right...we should warn users about this either way...and i think once we've finalized how to do this, we can get you a list of affected files
        [15:25] <mdiggory> int he classpath for xmlui-api, dspace-api or jspui-api
        [15:25] * StuartLewis__ (n=StuartLe@121.98.157.79) has joined #duraspace
        [15:26] <mhwood> If sites have to be warned about such matters...do we really want to do that to them?
        [15:26] <jeffreytrimble> let's not use the word warning...let just say they need to be aware that the upgrade has some changes they may need to address in customizations.
        [15:27] <tdonohue> bradmc +1 changing in one place is probably best.
        [15:27] <mdiggory> doesn't need to be perfect... you cannot guarantee UI html serialization behavior... another option might be response headers?
        [15:28] <mdiggory> which could be theme independent
        [15:28] <tdonohue> seems like we are over thinking this....to be honest, Larry's patch is rather small
        [15:29] <tdonohue> and maybe there is some use to being able to get that version via a Java call
        [15:29] <mdiggory> not really, All I'm talking about in this case is one line in the servlets that spits out the build number, replaced using svn keyword substitution
        [15:29] <tdonohue> maybe eventually one could run "dspace --version" to get a report of what version they are running, etc
        [15:30] <mdiggory> seems like a job for the XMLUI Control Panel
        [15:30] <mhwood> I kinda want to use the same information in a human-readable place, like: "This is DSpace 1.6.0, ScholarWorks build 123"
        [15:31] <bradmc> like having dspace validate that it's code matches it's database schema? Couldn't do that at the UI level.
        [15:31] <snail1> it would also be useful to have the version in an HTML comment on the homepage by default
        [15:32] <StuartLewis__> snail1: It was that suggestion that kicked-off this discussion :)
        [15:32] <mdiggory> downfall with svn keyword approach is that it might change across repos where the code is being duplicated (yuck)
        [15:32] <kshepherd> the original patch added a meta tag
        [15:32] <kshepherd> but the discussion's gone a bit over my head since then ;)
        [15:33] <mdiggory> can add meta tag, can also add response header... both relatively easy, first is UI dependent, second can be deeper in the content generation layer
        [15:33] <mdiggory> big question, what is wanted to be known by "us" when looking at a DSpace instance
        [15:34] <mhwood> I think it boils down to whether the cost of keeping multiple copies in sync. outweighs the cost of going to a single definitive copy every time you want it.
        [15:34] <mdiggory> as someone troubleshooting DSpace I want to know (1) version (2) build (3) build date (4) by whom
        [15:34] <tdonohue> so, how do we come to a consensus here? mdiggory are you still against Larry's approach?
        [15:35] <mdiggory> Yes I'm against this code solution
        [15:36] <mdiggory> hmmm.... wait
        [15:36] <mdiggory> let me review it just a little more.
        [15:36] * bradmc muses on bikesheds
        [15:37] <kshepherd> i'm a bit worried about complicating things too much for a small feature that was an idea /we/ had rather than the community-at-large
        [15:38] <mdiggory> ok... no I am not against this approach.
        [15:38] <mdiggory> I will add
        [15:38] <mdiggory> that if you want "build" specific customization...
        [15:39] <tdonohue> ok, so do we want to revote to (1) start with Larry's approach for 1.6...after 1.6 (2) we can review it and see if it needs to be tweaked to provide more info (like kshepherd suggests)
        [15:39] <mdiggory> generalize this slightly to (1) return the properties as well as string and (2) add ability to lookup pom by package
        [15:40] <StuartLewis__> +1 Larry's solution, look at improving it later if required.
        [15:40] <mdiggory> the mhwood can add his modules/xmlui/pom.xml properties for his particular build as a second property
        [15:40] <mdiggory> in that packages pom.xml pom.properties
        [15:42] <mdiggory> recommend adding call to this class in DSpaceServlet and/or appropriate class in XMLUI to support setting response headers
        [15:42] * StuartLewis_ (n=StuartLe@121.98.157.79) Quit (Read error: 110 (Connection timed out))
        [15:42] <tdonohue> mdiggory: I think you are starting into a different feature request. This feature was just a recommendation for a simple HTML <Meta> tag to identify the version of DSpace you are running
        [15:43] <tdonohue> but, I think we could add a new Jira request for some of the features you are talking about
        [15:43] <mdiggory> no, XMLUI themes may have overridden the creation of html head meta
        [15:43] <mdiggory> sticking it into the response header assures robustness
        [15:43] <tdonohue> mdiggory: true...but ast jeffreytrimble said, we can let users know that in the upgrade docs
        [15:44] <mdiggory> we see this usefull for different reasons
        [15:44] <mdiggory> response header requires no documentation caveats
        [15:44] <jeffreytrimble> On the UI side, it's good to know what version a site is running....
        [15:44] <tdonohue> yea, i can agree with that. That's part of why I wonder if this needs to be a separate Jira issue that we can vote on separately
        [15:44] <jeffreytrimble> on the admin side, it's good to know the version and the build.
        [15:45] <mdiggory> this is both cases
        [15:45] <StuartLewis__> But joe-average-dspace-repo-manager doedn't know how to interrogate http headers
        [15:45] <mhwood> I think the code as it stands can be used for several quite different purposes, including the original one. A separate issue could then evolve it as needed, later.
        [15:45] <jeffreytrimble> really? My users could care less what build we are running...let alone versions...but all of us here today would be interested in at least the version
        [15:46] <mdiggory> This is not for average joe
        [15:46] <mdiggory> this is for webdeveloper troublshooter
        [15:46] <mdiggory> developer administrator
        [15:46] * tdonohue notices we've been on this same issue for 30+ minutes
        [15:46] <StuartLewis__> Well it might be - if we tell them 'view the html source and tell us what is says at GENERATOR='
        [15:46] <mhwood> And my supervisor, who regularly asks, "what versions are we running now?"
        [15:46] <mdiggory> no, I say... send me a link to your site and I look
        [15:47] <tdonohue> ok, i'd like to suggest we agree to disagree on this, and just choose something for 1.6. It can always be tweaked for 1.6.1 :)
        [15:48] <mdiggory> you can always put it in the control panel or present it in the footer if you have such interested supervisors
        [15:49] <mdiggory> agreed, at least we agree to add what is there
        [15:49] <tdonohue> do we want to revote on Larry's suggestion for 1.6? And then add a new Jira issue with these extra suggestions (so that we can track them -- some good thoughts here)
        [15:49] <kshepherd> having something simply for troubleshooting by developers sounds cool, but it can't be something that makes extra work for IR admins in terms of themes, etc...
        [15:49] <kshepherd> especially since they're not the ones asking for it ;)
        [15:50] <mdiggory> just tack them into the JIRA issue thats there... commit the patch and say... if you want to do more, continue to use this JIRA ticket.
        [15:50] <mhwood> That's why I worry that I keep seeing, "we need to document how we're going to break your themes"
        [15:50] <kshepherd> mhwood: yeah
        [15:50] <mdiggory> themes not broken...
        [15:50] <tdonohue> Ok, I'm calling for a revote on: http://jira.dspace.org/jira/browse/DS-377 as-is for 1.6.
        [15:50] <mhwood> Feature broken unless you re-customize?
        [15:50] <tdonohue> +1
        [15:51] <kshepherd> but in this case, nothing 'broken', just.. it won't work without extra effort on those custom themes
        [15:51] <mdiggory> nothing being done here is non-backward or forwards compatable
        [15:51] <StuartLewis__> DS-377: +1
        [15:51] <mhwood> +1
        [15:51] <mdiggory> using response header is just more reliable given chance that its been customized out of someones theme
        [15:51] <mdiggory> +1
        [15:52] <kshepherd> +1
        [15:52] <snail1> +1
        [15:52] <StuartLewis__> We can do headers too if we get a patch

        Show
        Tim Donohue added a comment - Additional comments from Committers meeting on Nov 18, 2009. Summary: We came to an agreement that Larry's patch looks good as-is for 1.6. However, there are some addition features/suggestions we may want to look into post-1.6. The discussion below is long, but there are some good ideas for future additions that came up. [15:16] <StuartLewis_> And the second patch is: [15:17] <StuartLewis_> http://jira.dspace.org/jira/browse/DS-377 Add META tags identifying DSpace source version to Web UIs [15:17] <StuartLewis_> See the comments in this one, especially Larry's last comment to explain how the version will be identified. [15:18] <mdiggory> Looking at the topic... [15:18] <tdonohue> +1 sounds good to me - glad we can populate based on version in Maven POM [15:18] <mhwood> +1 [15:18] <mdiggory> A maven based approach would use filtering in the mvn package phase [15:19] <kshepherd> +1 [15:19] <mdiggory> you don't really need to java code this [15:20] <tdonohue> mdiggory: does this mean you disagree with Larry's approach? [15:20] <kshepherd> hmm.. needs more discussion? [15:20] <mdiggory> identify the files you want to filter and create a parameter in them, map that parameter in the pom.xml [15:20] <mdiggory> on release that parameter will be processed [15:21] <mdiggory> Seems like its coding before researching [15:21] <tdonohue> mdiggory: so you are saying you'd list the specific files in XMLUI or JSPUI that need a parameter to be replaced? [15:21] <mdiggory> pretty much [15:21] <tdonohue> and the maven will replace it during the packaging? [15:21] <mhwood> So you want the package phase to customize the XSL or something? It'd have to track down all a site's themes.... [15:21] <mdiggory> war generation includes filtering [15:22] <tdonohue> would it also work for completely custom themes, like mhwood brings up? [15:22] <mdiggory> I assume you would run this risk if you were overriding that header in dri2xhtml [15:23] <jeffreytrimble> We'd have to warn users about this....so they remember to re-customize those files affected by this. [15:24] <mdiggory> but i will add... theres no reason this couldn't be in a properties file or the default Navigation transformer rather than chasing individual xslt templates [15:24] <mhwood> It's being fetched from a properties file now. [15:24] <jeffreytrimble> But it is entirely possible to gather up a list of files that this change would/does affect and let the users know the work they have in store? [15:24] <mdiggory> in which case, it might not even be maven based filtering... just use SVN versioning infor [15:25] <mdiggory> svn keywords in the java classes [15:25] <mdiggory> or a properties file [15:25] <bradmc> Seems fragile to have it scattered among customizable files. An include of a single file that gets changed seems more robust - but creates other issues. [15:25] <tdonohue> jeffreytrimble: yes, you are right...we should warn users about this either way...and i think once we've finalized how to do this, we can get you a list of affected files [15:25] <mdiggory> int he classpath for xmlui-api, dspace-api or jspui-api [15:25] * StuartLewis__ (n=StuartLe@121.98.157.79) has joined #duraspace [15:26] <mhwood> If sites have to be warned about such matters...do we really want to do that to them? [15:26] <jeffreytrimble> let's not use the word warning...let just say they need to be aware that the upgrade has some changes they may need to address in customizations. [15:27] <tdonohue> bradmc +1 changing in one place is probably best. [15:27] <mdiggory> doesn't need to be perfect... you cannot guarantee UI html serialization behavior... another option might be response headers? [15:28] <mdiggory> which could be theme independent [15:28] <tdonohue> seems like we are over thinking this....to be honest, Larry's patch is rather small [15:29] <tdonohue> and maybe there is some use to being able to get that version via a Java call [15:29] <mdiggory> not really, All I'm talking about in this case is one line in the servlets that spits out the build number, replaced using svn keyword substitution [15:29] <tdonohue> maybe eventually one could run "dspace --version" to get a report of what version they are running, etc [15:30] <mdiggory> seems like a job for the XMLUI Control Panel [15:30] <mhwood> I kinda want to use the same information in a human-readable place, like: "This is DSpace 1.6.0, ScholarWorks build 123" [15:31] <bradmc> like having dspace validate that it's code matches it's database schema? Couldn't do that at the UI level. [15:31] <snail1> it would also be useful to have the version in an HTML comment on the homepage by default [15:32] <StuartLewis__> snail1: It was that suggestion that kicked-off this discussion :) [15:32] <mdiggory> downfall with svn keyword approach is that it might change across repos where the code is being duplicated (yuck) [15:32] <kshepherd> the original patch added a meta tag [15:32] <kshepherd> but the discussion's gone a bit over my head since then ;) [15:33] <mdiggory> can add meta tag, can also add response header... both relatively easy, first is UI dependent, second can be deeper in the content generation layer [15:33] <mdiggory> big question, what is wanted to be known by "us" when looking at a DSpace instance [15:34] <mhwood> I think it boils down to whether the cost of keeping multiple copies in sync. outweighs the cost of going to a single definitive copy every time you want it. [15:34] <mdiggory> as someone troubleshooting DSpace I want to know (1) version (2) build (3) build date (4) by whom [15:34] <tdonohue> so, how do we come to a consensus here? mdiggory are you still against Larry's approach? [15:35] <mdiggory> Yes I'm against this code solution [15:36] <mdiggory> hmmm.... wait [15:36] <mdiggory> let me review it just a little more. [15:36] * bradmc muses on bikesheds [15:37] <kshepherd> i'm a bit worried about complicating things too much for a small feature that was an idea /we/ had rather than the community-at-large [15:38] <mdiggory> ok... no I am not against this approach. [15:38] <mdiggory> I will add [15:38] <mdiggory> that if you want "build" specific customization... [15:39] <tdonohue> ok, so do we want to revote to (1) start with Larry's approach for 1.6...after 1.6 (2) we can review it and see if it needs to be tweaked to provide more info (like kshepherd suggests) [15:39] <mdiggory> generalize this slightly to (1) return the properties as well as string and (2) add ability to lookup pom by package [15:40] <StuartLewis__> +1 Larry's solution, look at improving it later if required. [15:40] <mdiggory> the mhwood can add his modules/xmlui/pom.xml properties for his particular build as a second property [15:40] <mdiggory> in that packages pom.xml pom.properties [15:42] <mdiggory> recommend adding call to this class in DSpaceServlet and/or appropriate class in XMLUI to support setting response headers [15:42] * StuartLewis_ (n=StuartLe@121.98.157.79) Quit (Read error: 110 (Connection timed out)) [15:42] <tdonohue> mdiggory: I think you are starting into a different feature request. This feature was just a recommendation for a simple HTML <Meta> tag to identify the version of DSpace you are running [15:43] <tdonohue> but, I think we could add a new Jira request for some of the features you are talking about [15:43] <mdiggory> no, XMLUI themes may have overridden the creation of html head meta [15:43] <mdiggory> sticking it into the response header assures robustness [15:43] <tdonohue> mdiggory: true...but ast jeffreytrimble said, we can let users know that in the upgrade docs [15:44] <mdiggory> we see this usefull for different reasons [15:44] <mdiggory> response header requires no documentation caveats [15:44] <jeffreytrimble> On the UI side, it's good to know what version a site is running.... [15:44] <tdonohue> yea, i can agree with that. That's part of why I wonder if this needs to be a separate Jira issue that we can vote on separately [15:44] <jeffreytrimble> on the admin side, it's good to know the version and the build. [15:45] <mdiggory> this is both cases [15:45] <StuartLewis__> But joe-average-dspace-repo-manager doedn't know how to interrogate http headers [15:45] <mhwood> I think the code as it stands can be used for several quite different purposes, including the original one. A separate issue could then evolve it as needed, later. [15:45] <jeffreytrimble> really? My users could care less what build we are running...let alone versions...but all of us here today would be interested in at least the version [15:46] <mdiggory> This is not for average joe [15:46] <mdiggory> this is for webdeveloper troublshooter [15:46] <mdiggory> developer administrator [15:46] * tdonohue notices we've been on this same issue for 30+ minutes [15:46] <StuartLewis__> Well it might be - if we tell them 'view the html source and tell us what is says at GENERATOR=' [15:46] <mhwood> And my supervisor, who regularly asks, "what versions are we running now?" [15:46] <mdiggory> no, I say... send me a link to your site and I look [15:47] <tdonohue> ok, i'd like to suggest we agree to disagree on this, and just choose something for 1.6. It can always be tweaked for 1.6.1 :) [15:48] <mdiggory> you can always put it in the control panel or present it in the footer if you have such interested supervisors [15:49] <mdiggory> agreed, at least we agree to add what is there [15:49] <tdonohue> do we want to revote on Larry's suggestion for 1.6? And then add a new Jira issue with these extra suggestions (so that we can track them -- some good thoughts here) [15:49] <kshepherd> having something simply for troubleshooting by developers sounds cool, but it can't be something that makes extra work for IR admins in terms of themes, etc... [15:49] <kshepherd> especially since they're not the ones asking for it ;) [15:50] <mdiggory> just tack them into the JIRA issue thats there... commit the patch and say... if you want to do more, continue to use this JIRA ticket. [15:50] <mhwood> That's why I worry that I keep seeing, "we need to document how we're going to break your themes" [15:50] <kshepherd> mhwood: yeah [15:50] <mdiggory> themes not broken... [15:50] <tdonohue> Ok, I'm calling for a revote on: http://jira.dspace.org/jira/browse/DS-377 as-is for 1.6. [15:50] <mhwood> Feature broken unless you re-customize? [15:50] <tdonohue> +1 [15:51] <kshepherd> but in this case, nothing 'broken', just.. it won't work without extra effort on those custom themes [15:51] <mdiggory> nothing being done here is non-backward or forwards compatable [15:51] <StuartLewis__> DS-377 : +1 [15:51] <mhwood> +1 [15:51] <mdiggory> using response header is just more reliable given chance that its been customized out of someones theme [15:51] <mdiggory> +1 [15:52] <kshepherd> +1 [15:52] <snail1> +1 [15:52] <StuartLewis__> We can do headers too if we get a patch
        Hide
        Larry Stone added a comment -
        Although the response headers are harder to see (not for experts like us, sure, but if you are trying to collect data from an end-user it's much easier to say, "save the page as HTML source", than "run curl -D..."), I agree it's worth doing, but I have no more time to work on this.

        I'll hold off patching this for a few days, so if anyone would like to implement version in response headers for XMLUI _and_ JSPUI, please comment here right away and I'll wait for you.

        Also: Since many sites have their own local version and build identification, depending on local versioning tools, they ought to follow this pattern to add their own META tags with the local identifying marks to their DSpace implementation. I've done that for my site, that's how I got this idea.
        Show
        Larry Stone added a comment - Although the response headers are harder to see (not for experts like us, sure, but if you are trying to collect data from an end-user it's much easier to say, "save the page as HTML source", than "run curl -D..."), I agree it's worth doing, but I have no more time to work on this. I'll hold off patching this for a few days, so if anyone would like to implement version in response headers for XMLUI _and_ JSPUI, please comment here right away and I'll wait for you. Also: Since many sites have their own local version and build identification, depending on local versioning tools, they ought to follow this pattern to add their own META tags with the local identifying marks to their DSpace implementation. I've done that for my site, that's how I got this idea.
        Hide
        Larry Stone added a comment -
        Committed the latest patch in changeset 4589
        Show
        Larry Stone added a comment - Committed the latest patch in changeset 4589

          People

          • Assignee:
            Larry Stone
            Reporter:
            Larry Stone
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: