Lucene - Core
  1. Lucene - Core
  2. LUCENE-5360

Add support for developing in netbeans IDE

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Implemented
    • Affects Version/s: None
    • Fix Version/s: 4.7, 6.0
    • Component/s: None
    • Labels:
    • Lucene Fields:
      New, Patch Available

      Description

      It will be nice to have ant target for building netbeans IDE project definition.

      1. 5360.patch
        33 kB
        Michal Hlavac
      2. LUCENE-5360.patch
        23 kB
        Steve Rowe
      3. LUCENE-5360-part2.patch
        31 kB
        Michal Hlavac
      4. LUCENE-5360-part2.patch
        31 kB
        Uwe Schindler
      5. LUCENE-5360-part2.patch
        31 kB
        Uwe Schindler
      6. LUCENE-5360-part2.patch
        31 kB
        Michal Hlavac
      7. LUCENE-5360-part2.patch
        32 kB
        Uwe Schindler
      8. LUCENE-5360-part2.patch
        35 kB
        Uwe Schindler
      9. LUCENE-5360-part2.patch
        36 kB
        Steve Rowe
      10. LUCENE-5360-part2.patch
        37 kB
        Steve Rowe

        Activity

        Hide
        Steve Rowe added a comment -

        Slightly modified patch.

        Michal, note the new patch file name - the naming convention uses the whole issue ID, including the project (LUCENE).

        ant clean-netbeans doesn't need to remove .project and .classpath - AFAICT these are copy-paste-o's from the clean-eclipse target.

        Apparently Netbeans thinks .gitignore is binary, since in your patch, Michal, it's Base64-encoded. I've decoded it and included the changes in normal patch format.

        I don't use Netbeans, but to test this out I downloaded the Netbeans installer and installed it on OS X, and ran ant netbeans. I was able to open the project and look at files, so it seems to be at least minimally functional.

        Committing shortly.

        Show
        Steve Rowe added a comment - Slightly modified patch. Michal, note the new patch file name - the naming convention uses the whole issue ID, including the project (LUCENE). ant clean-netbeans doesn't need to remove .project and .classpath - AFAICT these are copy-paste-o's from the clean-eclipse target. Apparently Netbeans thinks .gitignore is binary, since in your patch, Michal, it's Base64-encoded. I've decoded it and included the changes in normal patch format. I don't use Netbeans, but to test this out I downloaded the Netbeans installer and installed it on OS X, and ran ant netbeans . I was able to open the project and look at files, so it seems to be at least minimally functional. Committing shortly.
        Hide
        ASF subversion and git services added a comment -

        Commit 1549872 from Steve Rowe in branch 'dev/trunk'
        [ https://svn.apache.org/r1549872 ]

        LUCENE-5360: Add support for developing in Netbeans IDE.

        Show
        ASF subversion and git services added a comment - Commit 1549872 from Steve Rowe in branch 'dev/trunk' [ https://svn.apache.org/r1549872 ] LUCENE-5360 : Add support for developing in Netbeans IDE.
        Hide
        ASF subversion and git services added a comment -

        Commit 1549873 from Steve Rowe in branch 'dev/branches/branch_4x'
        [ https://svn.apache.org/r1549873 ]

        LUCENE-5360: Add support for developing in Netbeans IDE. (merged trunk r1549872)

        Show
        ASF subversion and git services added a comment - Commit 1549873 from Steve Rowe in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1549873 ] LUCENE-5360 : Add support for developing in Netbeans IDE. (merged trunk r1549872)
        Hide
        Steve Rowe added a comment -

        Committed to trunk and branch_4x.

        Thanks Michal!

        Show
        Steve Rowe added a comment - Committed to trunk and branch_4x. Thanks Michal!
        Hide
        ASF subversion and git services added a comment -

        Commit 1549880 from Uwe Schindler in branch 'dev/branches/branch_4x'
        [ https://svn.apache.org/r1549880 ]

        LUCENE-5360: In branch_4x the source level is "1.6"

        Show
        ASF subversion and git services added a comment - Commit 1549880 from Uwe Schindler in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1549880 ] LUCENE-5360 : In branch_4x the source level is "1.6"
        Hide
        Michal Hlavac added a comment - - edited

        Thanks for hints. Are you sure that source level is 1.6 because there is a lot of files with 1.7 features e.g. try-with-catch and diamond operator?
        For example:
        BooleanPerceptronClassifier.java (package org.apache.lucene.classification)
        DocInverterPerField.java (org.apache.lucene.index)
        etc.

        Show
        Michal Hlavac added a comment - - edited Thanks for hints. Are you sure that source level is 1.6 because there is a lot of files with 1.7 features e.g. try-with-catch and diamond operator? For example: BooleanPerceptronClassifier.java (package org.apache.lucene.classification) DocInverterPerField.java (org.apache.lucene.index) etc.
        Hide
        Shawn Heisey added a comment -

        Are you sure that source level is 1.6 because there is a lot of files with 1.7 features e.g. try-with-catch and diamond operator?
        For example:
        BooleanPerceptronClassifier.java (package org.apache.lucene.classification)
        DocInverterPerField.java (org.apache.lucene.index)
        etc.

        The SVN trunk (which is what will become 5.0 eventually) requires Java 7 and therefore has Java 7 constructs. The branch named branch_4x (dev branch for 4.x versions) only requires Java 6. There is a LOT of testing during normal development, and even more testing before each release, so there is a very high confidence level that the 4.x version does not have Java 7 code in it.

        The BooleanPerceptronClassifier.java file doesn't exist in branch_4x at all, and with a quick glance, I didn't seem any problems in the 4x version of DocInverterPerField.java.

        If you actually do find Java 7 constructs in branch_4x, that's a bug. Feel free to file issues and submit patches for any such problems that you find in branch_4x. If you want to check branch_4x out from SVN, use the following command:

        svn co http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x
        
        Show
        Shawn Heisey added a comment - Are you sure that source level is 1.6 because there is a lot of files with 1.7 features e.g. try-with-catch and diamond operator? For example: BooleanPerceptronClassifier.java (package org.apache.lucene.classification) DocInverterPerField.java (org.apache.lucene.index) etc. The SVN trunk (which is what will become 5.0 eventually) requires Java 7 and therefore has Java 7 constructs. The branch named branch_4x (dev branch for 4.x versions) only requires Java 6. There is a LOT of testing during normal development, and even more testing before each release, so there is a very high confidence level that the 4.x version does not have Java 7 code in it. The BooleanPerceptronClassifier.java file doesn't exist in branch_4x at all, and with a quick glance, I didn't seem any problems in the 4x version of DocInverterPerField.java. If you actually do find Java 7 constructs in branch_4x, that's a bug. Feel free to file issues and submit patches for any such problems that you find in branch_4x. If you want to check branch_4x out from SVN, use the following command: svn co http: //svn.apache.org/repos/asf/lucene/dev/branches/branch_4x
        Hide
        Michal Hlavac added a comment -

        My mistake, I thought that http://svn.apache.org/repos/asf/lucene/dev/trunk is actually 4x.

        Show
        Michal Hlavac added a comment - My mistake, I thought that http://svn.apache.org/repos/asf/lucene/dev/trunk is actually 4x.
        Hide
        Steve Rowe added a comment -

        Reopening to streamline the XSLT stylesheet somewhat (lots of duplicated sorts in there), and to add a basic project code style.

        Show
        Steve Rowe added a comment - Reopening to streamline the XSLT stylesheet somewhat (lots of duplicated sorts in there), and to add a basic project code style.
        Hide
        Uwe Schindler added a comment -

        Thanks Steve. Do you need help with the XSL? I have some ideas to streamline. This XSL is approx 10 times larger than my original one I wrote for Eclipse. Its code duplication and hard to maintain. I would keep the "params" the same like for Eclipse (means only one fileset with source files) and make the distribution to the different XML elements with additional checks on the path strings (if they end in src/test or src/resources). The sorting code can be streamlined to only one for-each loop which is reused (through an xsl:template).

        Show
        Uwe Schindler added a comment - Thanks Steve. Do you need help with the XSL? I have some ideas to streamline. This XSL is approx 10 times larger than my original one I wrote for Eclipse. Its code duplication and hard to maintain. I would keep the "params" the same like for Eclipse (means only one fileset with source files) and make the distribution to the different XML elements with additional checks on the path strings (if they end in src/test or src/resources). The sorting code can be streamlined to only one for-each loop which is reused (through an xsl:template).
        Hide
        Michal Hlavac added a comment -

        I can try to minimize xsl template and send proposal tomorrow

        Show
        Michal Hlavac added a comment - I can try to minimize xsl template and send proposal tomorrow
        Hide
        Steve Rowe added a comment - - edited

        Patch implementing the ideas; also, source-level is made a stylesheet param.

        Output project.xml is identical, except that I've excluded **/test-lib/**/*.jar from the compile-scope compilation unit, where they don't belong.

        I've added a basic project.properties file containing Lucene/Solr code style settings.

        I didn't make the stylesheet sort a reusable template - Uwe or Michal if you'd like to do that, feel free - note though that not all sorts are the same in my patch.

        Show
        Steve Rowe added a comment - - edited Patch implementing the ideas; also, source-level is made a stylesheet param. Output project.xml is identical, except that I've excluded **/test-lib/**/*.jar from the compile-scope compilation unit, where they don't belong. I've added a basic project.properties file containing Lucene/Solr code style settings. I didn't make the stylesheet sort a reusable template - Uwe or Michal if you'd like to do that, feel free - note though that not all sorts are the same in my patch.
        Hide
        Uwe Schindler added a comment -

        I will take care. There can also be some <xsl:if> be removed when adding the condition as [] in the xpath of the for-each itsself.
        Most sorts can still be copypasted (and therefore made a template), because they don't hurt if they dont match anything. Unfortunately, there is no ends-with() in XPath 1.0.

        Show
        Uwe Schindler added a comment - I will take care. There can also be some <xsl:if> be removed when adding the condition as [] in the xpath of the for-each itsself. Most sorts can still be copypasted (and therefore made a template), because they don't hurt if they dont match anything. Unfortunately, there is no ends-with() in XPath 1.0.
        Hide
        Steve Rowe added a comment -

        Unfortunately, there is no ends-with() in XPath 1.0.

        Yeah, contains() is safe for these paths, though - /src/ only occurs once in any of them.

        Show
        Steve Rowe added a comment - Unfortunately, there is no ends-with() in XPath 1.0. Yeah, contains() is safe for these paths, though - /src/ only occurs once in any of them.
        Hide
        Steve Rowe added a comment -

        Michal Hlavac, your original patch (and mine) excludes **/test-files/** - is this on purpose? These are test-scope resources, and should be included somehow, I think.

        Show
        Steve Rowe added a comment - Michal Hlavac , your original patch (and mine) excludes **/test-files/** - is this on purpose? These are test-scope resources, and should be included somehow, I think.
        Hide
        Steve Rowe added a comment -

        There was a mistake in the previous version of this patch: one of the two instances of ${javac.source.and.target} is output literally into project.xml, because I didn't wrap it in <xsl:value-of select="..."/>. This patch fixes that; renames the param to the more apt $source-level; and doesn't make it a property in the top-level build.xml, but rather a literal value when passing in the param.

        Show
        Steve Rowe added a comment - There was a mistake in the previous version of this patch: one of the two instances of ${javac.source.and.target } is output literally into project.xml , because I didn't wrap it in <xsl:value-of select="..."/> . This patch fixes that; renames the param to the more apt $source-level ; and doesn't make it a property in the top-level build.xml , but rather a literal value when passing in the param.
        Hide
        Uwe Schindler added a comment -

        Removed obsolete ifs and moved them into the for-each select xpath.

        I will now move the for-each to a template

        Show
        Uwe Schindler added a comment - Removed obsolete ifs and moved them into the for-each select xpath. I will now move the for-each to a template
        Hide
        Steve Rowe added a comment -

        Another complication: source folders lucene/test-framework/src/java/ and solr/test-framework/src/java/ should actually be in the test compilation unit, despite the fact that src/java/ seems to indicate otherwise; likewise for their lib/ dirs.

        Show
        Steve Rowe added a comment - Another complication: source folders lucene/test-framework/src/java/ and solr/test-framework/src/java/ should actually be in the test compilation unit, despite the fact that src/java/ seems to indicate otherwise; likewise for their lib/ dirs.
        Hide
        Uwe Schindler added a comment -

        Here my cleanup. The compilation-unit problem is not yet fixed. But for now this should be fine.

        Show
        Uwe Schindler added a comment - Here my cleanup. The compilation-unit problem is not yet fixed. But for now this should be fine.
        Hide
        Uwe Schindler added a comment -

        Some changes:

        • The classpath elements are created mostly by ANT itsself (just change pathsep to ":" and print the resulting string as-is)
        • I made both classpaths identical, the test-lib exclusion made no sense.
        Show
        Uwe Schindler added a comment - Some changes: The classpath elements are created mostly by ANT itsself (just change pathsep to ":" and print the resulting string as-is) I made both classpaths identical, the test-lib exclusion made no sense.
        Hide
        Michal Hlavac added a comment -

        There is no need to overwrite Tabs and Indents formatting settings for java. They are same for all languages.

        Show
        Michal Hlavac added a comment - There is no need to overwrite Tabs and Indents formatting settings for java. They are same for all languages.
        Hide
        Uwe Schindler added a comment -

        Improved patch: The crazyness with the xsl:choose in the sorter template was removed again. The used trick is: Create a sorted clone of the source folders as xsl:variable. This variable can then be used with for-each and no more xsl:sort is needed. When defining the variable, the usual XSLT v1.0 document-fragment / node-set hack is needed, but that is common to people who know XSL. This also improves speed of the XSL, as it is only sorted once. Also the classpath element is also created only once now and copied 2 times into the output document.

        Show
        Uwe Schindler added a comment - Improved patch: The crazyness with the xsl:choose in the sorter template was removed again. The used trick is: Create a sorted clone of the source folders as xsl:variable . This variable can then be used with for-each and no more xsl:sort is needed. When defining the variable, the usual XSLT v1.0 document-fragment / node-set hack is needed, but that is common to people who know XSL. This also improves speed of the XSL, as it is only sorted once. Also the classpath element is also created only once now and copied 2 times into the output document.
        Hide
        Uwe Schindler added a comment -

        Use consistent sorting also in classpath.

        Show
        Uwe Schindler added a comment - Use consistent sorting also in classpath.
        Hide
        Michal Hlavac added a comment -

        Btw. on which branch do you apply this patch? Because eclipse said that this patch does not contain valid patch. I try it on dev and branch_4x

        Show
        Michal Hlavac added a comment - Btw. on which branch do you apply this patch? Because eclipse said that this patch does not contain valid patch. I try it on dev and branch_4x
        Hide
        Uwe Schindler added a comment -

        trunk. Use "svn patch", please

        Show
        Uwe Schindler added a comment - trunk. Use "svn patch", please
        Hide
        Michal Hlavac added a comment -

        Uwe's latest patch with general Tabs and Indents formatting

        Show
        Michal Hlavac added a comment - Uwe's latest patch with general Tabs and Indents formatting
        Hide
        Steve Rowe added a comment -

        +1 to commit, thanks Uwe and Michal!

        Show
        Steve Rowe added a comment - +1 to commit, thanks Uwe and Michal!
        Hide
        Uwe Schindler added a comment -

        Steve: Will you commit & backport (with 1.6)?

        Show
        Uwe Schindler added a comment - Steve: Will you commit & backport (with 1.6)?
        Hide
        Steve Rowe added a comment -

        Uwe: I will commit and backport (with 1.6).

        Show
        Steve Rowe added a comment - Uwe: I will commit and backport (with 1.6).
        Hide
        ASF subversion and git services added a comment -

        Commit 1550178 from Steve Rowe in branch 'dev/trunk'
        [ https://svn.apache.org/r1550178 ]

        LUCENE-5360: Netbeans support: streamline XSLT stylesheet; add basic code style

        Show
        ASF subversion and git services added a comment - Commit 1550178 from Steve Rowe in branch 'dev/trunk' [ https://svn.apache.org/r1550178 ] LUCENE-5360 : Netbeans support: streamline XSLT stylesheet; add basic code style
        Hide
        ASF subversion and git services added a comment -

        Commit 1550180 from Steve Rowe in branch 'dev/branches/branch_4x'
        [ https://svn.apache.org/r1550180 ]

        LUCENE-5360: Netbeans support: streamline XSLT stylesheet; add basic code style (merged trunk r1550178)

        Show
        ASF subversion and git services added a comment - Commit 1550180 from Steve Rowe in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1550180 ] LUCENE-5360 : Netbeans support: streamline XSLT stylesheet; add basic code style (merged trunk r1550178)
        Hide
        Steve Rowe added a comment -

        Committed the most recent part2 patch to trunk and branch_4x.

        Thanks again Uwe and Hlavac!

        Show
        Steve Rowe added a comment - Committed the most recent part2 patch to trunk and branch_4x. Thanks again Uwe and Hlavac!

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development