Solr
  1. Solr
  2. SOLR-2770

The Solr 3.4.0 release's maven artifacts don't include the jdk1.5-compiled carrot2-core jar

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 3.4
    • Fix Version/s: 3.5
    • Component/s: Build
    • Labels:
      None

      Description

      The Solr-specific jdk1.5-compiled version of the carrot2-core jar (in solr/contrib/clustering/lib/) was not part of the 3.4.0 release - there should be a 3.4.0/ directory here but there is not: http://repo1.maven.org/maven2/org/apache/solr/solr-carrot2-core/. This artifact was part of the 3.3.0 release. The build system changes under SOLR-2452 are the cause.

      Dawid Weiss indicated on SOLR-2428 that this Solr-specific jdk1.5-compiled artifact will continue to be required for the remainder of the 3.X release line.

        Activity

        Hide
        Dawid Weiss added a comment -

        Ugh. We should have checked, thanks for catching this Steven. Is there a way to publish it still?

        Show
        Dawid Weiss added a comment - Ugh. We should have checked, thanks for catching this Steven. Is there a way to publish it still?
        Hide
        Michael McCandless added a comment -

        Looks like this just affects the maven release; the main artifacts include the carrot2 JAR.

        It makes me nervous changing 3.4.0 at this point – it's already released so it should be read only now?

        Maybe we can turn around a 3.4.1 in short order?

        Show
        Michael McCandless added a comment - Looks like this just affects the maven release; the main artifacts include the carrot2 JAR. It makes me nervous changing 3.4.0 at this point – it's already released so it should be read only now? Maybe we can turn around a 3.4.1 in short order?
        Hide
        Steve Rowe added a comment -

        It makes me nervous changing 3.4.0 at this point – it's already released so it should be read only now?

        Maybe we can turn around a 3.4.1 in short order?

        Meh, seems like a lot of process to deal with a very small problem (relatively).

        This represents an interesting test case for your assertion about the read-only nature of releases, though, since: a) it's a third-party artifact that hasn't changed since the last release, and b) it's in the "officially unsupported" maven arena... I mean, if we can't change (add to in this case) a release under this circumstance, then there likely are no circumstances in which an exception would be made to the read-only policy.

        I'll work on adjustments to the build to enable properly producing the artifact; we'll need this regardless of the targeted release.

        Show
        Steve Rowe added a comment - It makes me nervous changing 3.4.0 at this point – it's already released so it should be read only now? Maybe we can turn around a 3.4.1 in short order? Meh, seems like a lot of process to deal with a very small problem (relatively). This represents an interesting test case for your assertion about the read-only nature of releases, though, since: a) it's a third-party artifact that hasn't changed since the last release, and b) it's in the "officially unsupported" maven arena... I mean, if we can't change (add to in this case) a release under this circumstance, then there likely are no circumstances in which an exception would be made to the read-only policy. I'll work on adjustments to the build to enable properly producing the artifact; we'll need this regardless of the targeted release.
        Hide
        Steve Rowe added a comment -

        Hmm, would a Solr 3.4.1 release entail a Lucene 3.4.1 release? Exactly the same as the 3.4.0 release?

        Show
        Steve Rowe added a comment - Hmm, would a Solr 3.4.1 release entail a Lucene 3.4.1 release? Exactly the same as the 3.4.0 release?
        Hide
        Robert Muir added a comment -

        Meh, seems like a lot of process to deal with a very small problem (relatively).

        We don't have to look at the problem this way though, if we want to spin out a quick 3.4.1, we already have 5 bugfixes (core+contrib)
        in the 3.x branch we could get out to the users...

        Personally I'm almost shocked more issues didnt spin out of the massive build cleanup, it seems almost inevitable there would
        be some issues... maybe we just fix this for now in 3.5, wait a little bit for people to try the 3.4 release and see if more are uncovered?

        Show
        Robert Muir added a comment - Meh, seems like a lot of process to deal with a very small problem (relatively). We don't have to look at the problem this way though, if we want to spin out a quick 3.4.1, we already have 5 bugfixes (core+contrib) in the 3.x branch we could get out to the users... Personally I'm almost shocked more issues didnt spin out of the massive build cleanup, it seems almost inevitable there would be some issues... maybe we just fix this for now in 3.5, wait a little bit for people to try the 3.4 release and see if more are uncovered?
        Hide
        Steve Rowe added a comment -

        maybe we just fix this for now in 3.5, wait a little bit for people to try the 3.4 release and see if more are uncovered?

        Lucene/Solr's 4-8 week release interval makes it more difficult to argue against this idea

        Show
        Steve Rowe added a comment - maybe we just fix this for now in 3.5, wait a little bit for people to try the 3.4 release and see if more are uncovered? Lucene/Solr's 4-8 week release interval makes it more difficult to argue against this idea
        Hide
        Steve Rowe added a comment -

        Patch against branch_3x to generate the maven artifact for Solr-specific carrot2-core.

        Committing shortly to branch_3x - I'll also forward-port to trunk, which has the same problem.

        Show
        Steve Rowe added a comment - Patch against branch_3x to generate the maven artifact for Solr-specific carrot2-core. Committing shortly to branch_3x - I'll also forward-port to trunk, which has the same problem.
        Hide
        Steve Rowe added a comment -

        I'll also forward-port to trunk, which has the same problem.

        Ack, trunk does not have the same problem - the jdk16-compiled jar in trunk is exactly the same as the artifact already available from Maven central repository.

        Show
        Steve Rowe added a comment - I'll also forward-port to trunk, which has the same problem. Ack, trunk does not have the same problem - the jdk16-compiled jar in trunk is exactly the same as the artifact already available from Maven central repository.
        Hide
        Steve Rowe added a comment -

        Ack, trunk does not have the same problem - the jdk16-compiled jar in trunk is exactly the same as the artifact already available from Maven central repository.

        BTW, this is the source of the problem: since trunk doesn't need this behavior, I forgot to add it back when backporting the build changes to branch_3x.

        Show
        Steve Rowe added a comment - Ack, trunk does not have the same problem - the jdk16-compiled jar in trunk is exactly the same as the artifact already available from Maven central repository. BTW, this is the source of the problem: since trunk doesn't need this behavior, I forgot to add it back when backporting the build changes to branch_3x.
        Hide
        Steve Rowe added a comment -

        Committed to branch_3x in r1171192.

        Show
        Steve Rowe added a comment - Committed to branch_3x in r1171192.
        Hide
        Dawid Weiss added a comment -

        Thanks Steven.

        Show
        Dawid Weiss added a comment - Thanks Steven.
        Hide
        Richard Vowles added a comment -

        Just as a matter of course, you have completely hosed the Maven repository for other version users. This file http://repo1.maven.org/maven2/org/apache/solr/solr-core/maven-metadata.xml should refer to all versions currently available so that those who use version ranges (such as [3.3.0]) can successfully resolve. Now we can't and are forced to upgrade. Please be sure to fix this as well.

        Show
        Richard Vowles added a comment - Just as a matter of course, you have completely hosed the Maven repository for other version users. This file http://repo1.maven.org/maven2/org/apache/solr/solr-core/maven-metadata.xml should refer to all versions currently available so that those who use version ranges (such as [3.3.0] ) can successfully resolve. Now we can't and are forced to upgrade. Please be sure to fix this as well.
        Hide
        Steve Rowe added a comment - - edited

        Hi Richard,

        I was neither aware that maven-metadata.xml was hosed nor that it was the source of information for range usage (though I must say that "[3.3.0]" as a range is really strange - why not just use the exact version in that case?).

        But you are not forced to upgrade. You just specify the (exact) version you want in your dependency declaration. No?

        FYI, issues like this would get more visibility on the solr-user mailing list.

        Steve

        Show
        Steve Rowe added a comment - - edited Hi Richard, I was neither aware that maven-metadata.xml was hosed nor that it was the source of information for range usage (though I must say that " [3.3.0] " as a range is really strange - why not just use the exact version in that case?). But you are not forced to upgrade. You just specify the (exact) version you want in your dependency declaration. No? FYI, issues like this would get more visibility on the solr-user mailing list. Steve
        Hide
        Steve Rowe added a comment -

        Just as a matter of course, you have completely hosed the Maven repository for other version users. This file http://repo1.maven.org/maven2/org/apache/solr/solr-core/maven-metadata.xml should refer to all versions currently available so that those who use version ranges (such as [3.3.0]) can successfully resolve. Now we can't and are forced to upgrade. Please be sure to fix this as well.

        I have fixed the maven-metadata.xml files on the ASF source (a directory on people.apache.org) from which Maven central syncs its files, so once sync happens (should be less than 24 hours from now), these files will be fixed.

        I have opened an issue to fix the problem in future releases: LUCENE-3543.

        Show
        Steve Rowe added a comment - Just as a matter of course, you have completely hosed the Maven repository for other version users. This file http://repo1.maven.org/maven2/org/apache/solr/solr-core/maven-metadata.xml should refer to all versions currently available so that those who use version ranges (such as [3.3.0] ) can successfully resolve. Now we can't and are forced to upgrade. Please be sure to fix this as well. I have fixed the maven-metadata.xml files on the ASF source (a directory on people.apache.org) from which Maven central syncs its files, so once sync happens (should be less than 24 hours from now), these files will be fixed. I have opened an issue to fix the problem in future releases: LUCENE-3543 .

          People

          • Assignee:
            Steve Rowe
            Reporter:
            Steve Rowe
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development