asfimport
commented
13 years ago Robert Muir (@rmuir) (migrated from JIRA)
How would the BuildListener interface know about dependencies? Does it have some magic way to know this?
As an example, lets take modules/analysis/icu which has 3 dependencies:
- Lucene core itself (implicit from contrib-build.xml)
- external dependency: ICU
- internal dependency: modules/analysis/common
take a look at modules/analysis/icu's pom.xml which has:
<dependencies>
<dependency>
<groupId>com.ibm.icu</groupId>
<artifactId>icu4j</artifactId>
<version>${icu-version}</version>
</dependency>
</dependencies>However, our ant builds (that depend on common-build/contrib-build) declare their dependencies in a semi-standard way:
- External dependencies:
<path id="additional.dependencies"> <fileset dir="lib" includes="icu4j-*.jar"/> </path> - Internal dependencies:
<module-uptodate name="analysis/common" jarfile="../build/common/lucene-analyzers-common-${version}.jar" property="analyzers-common.uptodate" classpath.property="analyzers-common.jar"/>
The contrib-build.xml already has a 'dist-maven' target, that is called recursively. Perhaps an alternative would be to improve contrib-build.xml for it to have a 'generate-maven' target, also called recursively. I've already prototyped/proposed in SOLR-2002 that we migrate the solr build to extend the lucene build, so everywhere would use it.
Furthermore, couldnt we also make a recursive 'test-maven' target, that generates a maven project to 'download' or whatever it needs, then tries to run all the tests? If somehow the maven is broken, the tests simply won't pass.
I realize that running all of a modules tests again redundantly via 'maven' might not be the most elegant solution, but it seems like it would test that everything is working.
The current Maven POM templates only contain dependency information, the bare bones necessary for uploading artifacts to the Maven repository.
The full Maven POMs in the attached patch include the information necessary to run a multi-module Maven build, in addition to serving the same purpose as the current POM templates.
Several dependencies are not available through public maven repositories. A profile in the top-level POM can be activated to install these dependencies from the various
lib/directories into your local repository. From the top-level directory:Once these non-Maven dependencies have been installed, to run all Lucene/Solr tests via Maven's surefire plugin, and populate your local repository with all artifacts, from the top level directory, run:
When one Lucene/Solr module depends on another, the dependency is declared on the artifact(s) produced by the other module and deposited in your local repository, rather than on the other module's un-jarred compiler output in the
build/directory, so you must runmvn installon the other module before its changes are visible to the module that depends on it.To create all the artifacts without running tests:
I almost always include the
cleanphase when I do a build, e.g.:Migrated from LUCENE-2657 by Steven Rowe (@sarowe), 6 votes, resolved Jan 22 2011 Attachments: LUCENE-2657.patch (versions: 16), LUCENE-2657-branch_3x.patch (versions: 2) Linked issues:
2010
1697