Details

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.

Chris Male
added a comment - 04/Apr/12 12:48 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

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.

Steve Rowe
added a comment - 04/Apr/12 22:54 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.

Chris Male
added a comment - 05/Apr/12 04:54 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.

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.

Steve Rowe
added a comment - 11/Apr/12 19:46 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.

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.