Details

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

      Description

      we now fail the build on rat problems (LUCENE-1866),
      so we should make it easy to run rat-sources for people
      to test locally (it takes like 3 seconds total for the whole trunk)

      Also this is safer than putting rat in your ~/.ant/lib because that
      adds some classes from commons to your ant classpath (which we currently
      wrongly use in compile).

      1. LUCENE-3950-cachepath.patch
        15 kB
        Uwe Schindler
      2. LUCENE-3950.patch
        17 kB
        Robert Muir

        Activity

        Uwe Schindler made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Uwe Schindler made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        Uwe Schindler added a comment -

        This is already resolved in other issue.

        Show
        Uwe Schindler added a comment - This is already resolved in other issue.
        Hide
        Robert Muir added a comment -

        Robert you recall what was that problem?

        I think the problem was i tried to use the fine grained maven artifacts (rat-core + rat-tasks)

        using the big 'rat' jar with all its dependencies in one thing works great, and if it works on cachepath, even better.

        i dont care about actual jars, just that the task works

        Show
        Robert Muir added a comment - Robert you recall what was that problem? I think the problem was i tried to use the fine grained maven artifacts (rat-core + rat-tasks) using the big 'rat' jar with all its dependencies in one thing works great, and if it works on cachepath, even better. i dont care about actual jars, just that the task works
        Uwe Schindler made changes -
        Attachment LUCENE-3950-cachepath.patch [ 12536195 ]
        Hide
        Uwe Schindler added a comment -

        Patch. Works fine on different machines. I have no RAT in my .lib folder, maybe that was Robert's problem (conflict with cachepath)?

        Show
        Uwe Schindler added a comment - Patch. Works fine on different machines. I have no RAT in my .lib folder, maybe that was Robert's problem (conflict with cachepath)?
        Uwe Schindler made changes -
        Resolution Fixed [ 1 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Assignee Uwe Schindler [ thetaphi ]
        Hide
        Uwe Schindler added a comment -

        Hi, I reopen, as it works with cachepath. No fckd up lib folder with tools we dont need for compile. It is now behaving identical to cpptasks, junit, pegdown, maven-ant-tasks and all other build-tools. No License checks required.

        Show
        Uwe Schindler added a comment - Hi, I reopen, as it works with cachepath. No fckd up lib folder with tools we dont need for compile. It is now behaving identical to cpptasks, junit, pegdown, maven-ant-tasks and all other build-tools. No License checks required.
        Hide
        Dawid Weiss added a comment -

        > but I remember that Robert said, there was actually a problem with RAT running from <ivy:cachepath/>

        Robert you recall what was that problem?

        Show
        Dawid Weiss added a comment - > but I remember that Robert said, there was actually a problem with RAT running from <ivy:cachepath/> Robert you recall what was that problem?
        Hide
        Uwe Schindler added a comment -

        I had the same problem with this commit, but I remember that Robert said, there was actually a problem with RAT running from <ivy:cachepath/>. I would also really prefer to have this one only in cache, as we dont ship with this tool, so we dont have to take care of license,... We use all tasks from cachepatch (pegdown for converting markdown->HTML, cpptasks,...).

        Side note: I am thinking about adding clover, too. The required license file can be shipped together with our src package in the tools directory (Atlassian allowed this to the ASF, because the license only allows to check org.apache.* packages) and clover-2.6.1.jar can be downloaded via Ivy.

        Show
        Uwe Schindler added a comment - I had the same problem with this commit, but I remember that Robert said, there was actually a problem with RAT running from <ivy:cachepath/>. I would also really prefer to have this one only in cache, as we dont ship with this tool, so we dont have to take care of license,... We use all tasks from cachepatch (pegdown for converting markdown->HTML, cpptasks,...). Side note: I am thinking about adding clover, too. The required license file can be shipped together with our src package in the tools directory (Atlassian allowed this to the ASF, because the license only allows to check org.apache.* packages) and clover-2.6.1.jar can be downloaded via Ivy.
        Hide
        Dawid Weiss added a comment -
        +    <typedef resource="org/apache/rat/anttasks/antlib.xml" uri="antlib:org.apache.rat.anttasks">
               <classpath>
        -        <fileset dir="." includes="rat*.jar"/>
        +        <fileset dir="${common.dir}/tools/lib" includes="apache-rat-0.8.jar"/>
               </classpath>
             </typedef>
        

        I don't like this duplication of version numbers in ivy and ant files. I think it'd be nicer to use ivy's fileset or path to resolve these JARs if they're not part of the distribution?

        Show
        Dawid Weiss added a comment - + <typedef resource= "org/apache/rat/anttasks/antlib.xml" uri= "antlib:org.apache.rat.anttasks" > <classpath> - <fileset dir= "." includes= "rat*.jar" /> + <fileset dir= "${common.dir}/tools/lib" includes= "apache-rat-0.8.jar" /> </classpath> </typedef> I don't like this duplication of version numbers in ivy and ant files. I think it'd be nicer to use ivy's fileset or path to resolve these JARs if they're not part of the distribution?
        Robert Muir made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 4.0 [ 12322456 ]
        Fix Version/s 5.0 [ 12321663 ]
        Resolution Fixed [ 1 ]
        Hide
        Robert Muir added a comment -

        I'm waiting to ensure I didn't totally hose hudson before removing its local jar file and marking this resolved.

        Show
        Robert Muir added a comment - I'm waiting to ensure I didn't totally hose hudson before removing its local jar file and marking this resolved.
        rmuir committed 1360474 (6 files)
        Robert Muir made changes -
        Field Original Value New Value
        Attachment LUCENE-3950.patch [ 12536141 ]
        Hide
        Robert Muir added a comment -

        here's a patch, finally.

        Show
        Robert Muir added a comment - here's a patch, finally.
        Hide
        Robert Muir added a comment -

        So that if you want to actually test code you can apply a filter and have a quick turnaround and for full integration tests you can fire them before the commit etc.

        For this we should probably add a 'quiet' mode too for that purpose. rat-sources serves a double-duty,
        it also creates hugeish output for human review (since really for releasing thats required, its heuristical).

        But we fail on "unknown" licenses which is safe, and detects the common case of 'forgot license header'.

        Show
        Robert Muir added a comment - So that if you want to actually test code you can apply a filter and have a quick turnaround and for full integration tests you can fire them before the commit etc. For this we should probably add a 'quiet' mode too for that purpose. rat-sources serves a double-duty, it also creates hugeish output for human review (since really for releasing thats required, its heuristical). But we fail on "unknown" licenses which is safe, and detects the common case of 'forgot license header'.
        Hide
        Dawid Weiss added a comment -

        +1. I think this, license checks, CRLFs and other non-code things should be part of an integration test target. So that if you want to actually test code you can apply a filter and have a quick turnaround and for full integration tests you can fire them before the commit etc.

        Show
        Dawid Weiss added a comment - +1. I think this, license checks, CRLFs and other non-code things should be part of an integration test target. So that if you want to actually test code you can apply a filter and have a quick turnaround and for full integration tests you can fire them before the commit etc.
        Robert Muir created issue -

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development