Details

    • Type: Task Task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.0, 5.0
    • Component/s: general/build
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      I'm tired of fixing this before releases. Jenkins should detect and fail on this.

      1. LUCENE-3923.patch
        20 kB
        Uwe Schindler
      2. LUCENE-3923.patch
        5 kB
        Robert Muir

        Issue Links

          Activity

          Hide
          Uwe Schindler added a comment -

          Closed after release.

          Show
          Uwe Schindler added a comment - Closed after release.
          Hide
          Uwe Schindler added a comment -

          Committed trunk revision: 1377991
          Committed 3.x revision: 1377992

          BTW: I tried to convert also the internal svnversion calls to simple java fork="false" tasks (or scripts), but this failed du to the well-known ANT permgen issue. I will look into this another time, for now we still need the svn.exe and svnversion.exe sysprops.

          Show
          Uwe Schindler added a comment - Committed trunk revision: 1377991 Committed 3.x revision: 1377992 BTW: I tried to convert also the internal svnversion calls to simple java fork="false" tasks (or scripts), but this failed du to the well-known ANT permgen issue. I will look into this another time, for now we still need the svn.exe and svnversion.exe sysprops.
          Hide
          Uwe Schindler added a comment -

          The patch also fixes some other problems with svn usage (svnversion returns a different string in SVN 1.7 when dir is no working copy...) and cleans up code a bit.

          The main part is in extra-targets.xml

          Show
          Uwe Schindler added a comment - The patch also fixes some other problems with svn usage (svnversion returns a different string in SVN 1.7 when dir is no working copy...) and cleans up code a bit. The main part is in extra-targets.xml
          Hide
          Uwe Schindler added a comment -

          The attached task fixes the slowness problem on windows and ASF jenkins and speeds up linux, too:

          • The root build.xml file now has a combined "check-svn-working-copy" target that looks for unversioned files (leftovers after tests) and checks for the svn props
          • The work is done by JavaScript using svnkit. SvnKits license is not ASF conform, but we dont "link" against it nor we ship with it, it is just a tool downloaded to ivy:cachepath. This is not different to your GNU linux suite with "ls",... tools with GPL.

          I will commit soon to get Jenkins running better.

          Show
          Uwe Schindler added a comment - The attached task fixes the slowness problem on windows and ASF jenkins and speeds up linux, too: The root build.xml file now has a combined "check-svn-working-copy" target that looks for unversioned files (leftovers after tests) and checks for the svn props The work is done by JavaScript using svnkit. SvnKits license is not ASF conform, but we dont "link" against it nor we ship with it, it is just a tool downloaded to ivy:cachepath. This is not different to your GNU linux suite with "ls",... tools with GPL. I will commit soon to get Jenkins running better.
          Hide
          Uwe Schindler added a comment -

          I have a new patch, which is very fast without custom task.

          Show
          Uwe Schindler added a comment - I have a new patch, which is very fast without custom task.
          Hide
          Robert Muir added a comment -

          Thanks for the comments. I fixed all svn props and committed the check for now so we aren't fighting an uphill battle.

          we can refactor/simplify later in other issues.

          Show
          Robert Muir added a comment - Thanks for the comments. I fixed all svn props and committed the check for now so we aren't fighting an uphill battle. we can refactor/simplify later in other issues.
          Hide
          Robert Muir added a comment -

          Yeah maybe svnkit is ok, however its license looks pretty horrible and I want to fix these svn props first (and prevent future problems)
          and not be held up by that.

          I'll fix these issues and get this in there so our newlines are correct before the 4.0 release.

          Show
          Robert Muir added a comment - Yeah maybe svnkit is ok, however its license looks pretty horrible and I want to fix these svn props first (and prevent future problems) and not be held up by that. I'll fix these issues and get this in there so our newlines are correct before the 4.0 release.
          Hide
          Uwe Schindler added a comment -

          I assume it is slow

          2 things:

          • "svn" (the executable) should be replaced with getProject().getProperty("svn.exe")
          • Resources can be something else than files, use:
          if (!(r instanceof FileResource)) {
            throw new BuildException("Only filesystem resource are supported: " + r.getName() + ", was: " + r.getClass().getName());
          }
          File jarFile = ((FileResource) r).getFile();
          

          I am working on using SVNKit for all Java tasks.

          In general we might replace this with a <script> in our build.xml as it is quite simple from the logic.

          Show
          Uwe Schindler added a comment - I assume it is slow 2 things: "svn" (the executable) should be replaced with getProject().getProperty("svn.exe") Resources can be something else than files, use: if (!(r instanceof FileResource)) { throw new BuildException( "Only filesystem resource are supported: " + r.getName() + ", was: " + r.getClass().getName()); } File jarFile = ((FileResource) r).getFile(); I am working on using SVNKit for all Java tasks. In general we might replace this with a <script> in our build.xml as it is quite simple from the logic.
          Hide
          Robert Muir added a comment -

          here's a prototype

          Show
          Robert Muir added a comment - here's a prototype
          Hide
          Ryan McKinley added a comment -

          All the $Id$ and $Revision$ tags have been removed (SOLR-3329)

          Show
          Ryan McKinley added a comment - All the $Id$ and $Revision$ tags have been removed ( SOLR-3329 )
          Hide
          Mark Miller added a comment -

          Also to me tags like Date here are bogus (which date?! is it?),

          +1

          and Author is no different from @author.

          Right - there should be no author info in the source - we decided on that a long time ago.

          Show
          Mark Miller added a comment - Also to me tags like Date here are bogus (which date?! is it?), +1 and Author is no different from @author. Right - there should be no author info in the source - we decided on that a long time ago.
          Hide
          Mark Miller added a comment -

          We have talked about removing those svn keywords in the past - i think its just that no one has done it. I have mainly targeted the id stuff in the past because it screwed with patches - either most of that is gone, or new svn stuff handles it better - not sure. But +1 on removing any of it.

          Show
          Mark Miller added a comment - We have talked about removing those svn keywords in the past - i think its just that no one has done it. I have mainly targeted the id stuff in the past because it screwed with patches - either most of that is gone, or new svn stuff handles it better - not sure. But +1 on removing any of it.
          Hide
          Robert Muir added a comment -

          Also to me tags like Date here are bogus (which date?! is it?),
          and Author is no different from @author.

          Show
          Robert Muir added a comment - Also to me tags like Date here are bogus (which date?! is it?), and Author is no different from @author.
          Hide
          Robert Muir added a comment -

          I don't think we should set those... i think eol-style is the main
          one suggested by apache (it creates real problems otherwise,
          like entire file is changed by a one-liner etc).

          I also don't think these solr files should have all these svn
          keywords exposed, it makes applying patches difficult.

          Show
          Robert Muir added a comment - I don't think we should set those... i think eol-style is the main one suggested by apache (it creates real problems otherwise, like entire file is changed by a one-liner etc). I also don't think these solr files should have all these svn keywords exposed, it makes applying patches difficult.
          Hide
          Ryan McKinley added a comment -

          Perhaps we should also fail if a .java file does not have keywords set.

          Lots of javadocs use
          @version $Id$

          svn propset svn:keywords "Date Author Id Revision HeadURL" *.java
          

          In solr, MBeans expose $URL$, but we often don't set it

          Show
          Ryan McKinley added a comment - Perhaps we should also fail if a .java file does not have keywords set. Lots of javadocs use @version $Id$ svn propset svn:keywords "Date Author Id Revision HeadURL" *.java In solr, MBeans expose $URL$, but we often don't set it
          Hide
          Jan Høydahl added a comment -

          +1

          Show
          Jan Høydahl added a comment - +1
          Hide
          Michael McCandless added a comment -

          +1

          And, ideally, "ant test" as well...

          Show
          Michael McCandless added a comment - +1 And, ideally, "ant test" as well...

            People

            • Assignee:
              Uwe Schindler
              Reporter:
              Robert Muir
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development