Lucene - Core
  1. Lucene - Core
  2. LUCENE-3948

Experiment with placing poms outside of src

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.0-ALPHA
    • Component/s: general/build
    • Labels:
      None
    • Lucene Fields:
      New, Patch Available

      Description

      Recent work in LUCENE-3944 has changed how our generated pom.xml files are handled during release preparation, placing them in build/ instead. However get-maven-poms still places the poms inside src/ so you can use them to drive a build. What I think would be ideal is if we could unify the release handling of the poms and the normal building handling, so that the poms can sit outside of src and serve both purposes.

      Some time ago I investigated how the ANT project handles its own Maven integration and it has its poms sitting in their own directory. They then reference the actual src locations inside the poms. This works for ANT but with a warning since some of their tests don't work due to how the Maven surefire plugin works, so they skip their tests.

      I have done some quick testing of my own and this process does seem to work for our poms and tests. I now want to take this to a full scale POC and see if it works fully.

      1. LUCENE-3948.patch
        56 kB
        Chris Male
      2. LUCENE-3948.patch
        56 kB
        Steve Rowe
      3. LUCENE-3948.patch
        61 kB
        Chris Male
      4. LUCENE-3948.patch
        59 kB
        Steve Rowe
      5. LUCENE-3948.patch
        66 kB
        Steve Rowe

        Activity

        Hide
        Chris Male added a comment -

        Oh no, thank you!

        Show
        Chris Male added a comment - Oh no, thank you!
        Hide
        Steve Rowe added a comment -

        Committed. Thanks Chris!

        Show
        Steve Rowe added a comment - Committed. Thanks Chris!
        Hide
        Chris Male added a comment -

        +1 to committing

        Show
        Chris Male added a comment - +1 to committing
        Hide
        Steve Rowe added a comment -

        Patch, brought up to date with the modules/->lucene/ move. Also: added info to dev-tools/maven/README.maven, and modified svn:ignore properties, to ignore top-level maven-build/, and to stop ignoring pom.xml files.

        I'll commit this tomorrow if there are no objections.

        Show
        Steve Rowe added a comment - Patch, brought up to date with the modules/ -> lucene/ move. Also: added info to dev-tools/maven/README.maven , and modified svn:ignore properties, to ignore top-level maven-build/ , and to stop ignoring pom.xml files. I'll commit this tomorrow if there are no objections.
        Hide
        Chris Male added a comment -

        Elegant, I like it.

        +1 to committing

        Show
        Chris Male added a comment - Elegant, I like it. +1 to committing
        Hide
        Steve Rowe added a comment -

        Patch, updated to current trunk, and also:

        1. regularizes module-path definitions to always be ${top-level}/${module-path}, where top-level is a separately specified property;
        2. uses top-level in definitions that would otherwise have multiple ../.. path segments;
        3. removes definitions for project.build.directory, project.build.outputDirectory and project.build.testOutputDirectory, because these values are now the same as their defaults;
        4. adds a new surefire-top-level property based on top-level – since maven-surefire-plugin runs tests with CWD <module>/target/test/, the path to access Solr's testlogging.properties file needs two extra ../'s; and
        5. adds a new target clean-maven-build to the top-level build.xml.

        TODO

        • Connect generate-maven-artifacts to this new process.

        This isn't necessary, since generate-maven-artifacts now uses a separate target to filter the POMs for release artifact production: filter-pom-templates; this target and get-maven-poms are now independent of each other.

        • Add mechanism to clean maven-build

        Done.

        • Add maven-build as an svn:ignore dir.
        • Remove svn:ignore for pom.xml in src directories.

        These will need to be done.

        I think this is ready to commit.

        Show
        Steve Rowe added a comment - Patch, updated to current trunk, and also: regularizes module-path definitions to always be ${top-level }/${module-path } , where top-level is a separately specified property; uses top-level in definitions that would otherwise have multiple ../.. path segments; removes definitions for project.build.directory , project.build.outputDirectory and project.build.testOutputDirectory , because these values are now the same as their defaults; adds a new surefire-top-level property based on top-level – since maven-surefire-plugin runs tests with CWD <module>/target/test/ , the path to access Solr's testlogging.properties file needs two extra ../ 's; and adds a new target clean-maven-build to the top-level build.xml . TODO Connect generate-maven-artifacts to this new process. This isn't necessary, since generate-maven-artifacts now uses a separate target to filter the POMs for release artifact production: filter-pom-templates ; this target and get-maven-poms are now independent of each other. Add mechanism to clean maven-build Done. Add maven-build as an svn:ignore dir. Remove svn:ignore for pom.xml in src directories. These will need to be done. I think this is ready to commit.
        Hide
        Chris Male added a comment -

        Updated patch based on Steve's last

        Changes:

        • get-maven-poms now places all the poms in maven-build/ at the top-level.
        • All build directories are now changed to target/ like they are in a traditional Maven project. This means the build and poms sit next to each other
        • Classes and test classes now output to target/classes and target/test-classes like in a traditional Maven project.
        • module-path is updated to the new pom location and to leverage module-directory for easier maintainence.

        TODO

        • Connect generate-maven-artifacts to this new process.
        • Add mechanism to clean maven-build
        • Add maven-build as an svn:ignore dir.
        • Remove svn:ignore for pom.xml in src directories.
        Show
        Chris Male added a comment - Updated patch based on Steve's last Changes: get-maven-poms now places all the poms in maven-build/ at the top-level. All build directories are now changed to target/ like they are in a traditional Maven project. This means the build and poms sit next to each other Classes and test classes now output to target/classes and target/test-classes like in a traditional Maven project. module-path is updated to the new pom location and to leverage module-directory for easier maintainence. TODO Connect generate-maven-artifacts to this new process. Add mechanism to clean maven-build Add maven-build as an svn:ignore dir. Remove svn:ignore for pom.xml in src directories.
        Hide
        Steve Rowe added a comment -

        I applied the patch, ran ant filter-pom-templates under lucene, chdir'd to lucene/build/poms/, and successfully ran the following:

        • mvn -N -P bootstrap install
        • mvn -DskipTests install
        • mvn test

        I think two things should change:

        1. ant get-maven-poms, the user-level POM acquisition target, should place the POMs in a directory at the same level as lucene/ and solr/ - it could be named maven-build/ or something like that. (Mixing Lucene and Solr build stuff together under lucene/ is bad.)
        2. The build output directory should be under maven-build/, rather than the same dirs as those used by the Ant build.
        Show
        Steve Rowe added a comment - I applied the patch, ran ant filter-pom-templates under lucene, chdir 'd to lucene/build/poms/ , and successfully ran the following: mvn -N -P bootstrap install mvn -DskipTests install mvn test I think two things should change: ant get-maven-poms , the user-level POM acquisition target, should place the POMs in a directory at the same level as lucene/ and solr/ - it could be named maven-build/ or something like that. (Mixing Lucene and Solr build stuff together under lucene/ is bad.) The build output directory should be under maven-build/ , rather than the same dirs as those used by the Ant build.
        Hide
        Steve Rowe added a comment -

        Patch, superset of your patch, Chris, fixing just one problem I found: in the smartcn analysis module's POM, the resource directory didn't have module-path in front of it.

        Show
        Steve Rowe added a comment - Patch, superset of your patch, Chris, fixing just one problem I found: in the smartcn analysis module's POM, the resource directory didn't have module-path in front of it.
        Hide
        Chris Male added a comment -

        First shot at this. I've added a <module-path> to most poms which connects them to the location of the module.

        I also fixed the solr/webapp build path in its pom.xml.template which pointed to solr/build and nuked the whole contents on mvn clean.

        I haven't changed get-maven-poms so first you must execute ant filter-pom-templates from lucene/. Then go into build/poms and then you can execute mvn commands.

        Everything seems to compile now. Can't see any bad directories being made.

        Still TODO:

        • Make use of module-directory inside module-path rather than re-specifying that information. Need to check if all tests pass.
        • Change get-maven-poms to use filter-pom-templates.

        If anybody could give this a whirl to see if it works

        Show
        Chris Male added a comment - First shot at this. I've added a <module-path> to most poms which connects them to the location of the module. I also fixed the solr/webapp build path in its pom.xml.template which pointed to solr/build and nuked the whole contents on mvn clean. I haven't changed get-maven-poms so first you must execute ant filter-pom-templates from lucene/. Then go into build/poms and then you can execute mvn commands. Everything seems to compile now. Can't see any bad directories being made. Still TODO: Make use of module-directory inside module-path rather than re-specifying that information. Need to check if all tests pass. Change get-maven-poms to use filter-pom-templates. If anybody could give this a whirl to see if it works

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development