You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Robert Muir (JIRA)" <ji...@apache.org> on 2010/09/20 16:59:34 UTC

[jira] Issue Comment Edited: (LUCENE-2657) Auto-generate POM templates from Ant builds

    [ https://issues.apache.org/jira/browse/LUCENE-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12912487#action_12912487 ] 

Robert Muir edited comment on LUCENE-2657 at 9/20/10 10:59 AM:
---------------------------------------------------------------

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:
{noformat}
  <dependencies>
    <dependency>
      <groupId>com.ibm.icu</groupId>
      <artifactId>icu4j</artifactId>
      <version>${icu-version}</version>
    </dependency>
  </dependencies>
{noformat}

However, our ant builds (that depend on common-build/contrib-build) declare their dependencies in a semi-standard way:
* External dependencies:
{noformat}
<path id="additional.dependencies">
  <fileset dir="lib" includes="icu4j-*.jar"/>
</path>
{noformat}
* Internal dependencies:
{noformat}
<module-uptodate name="analysis/common" 
jarfile="../build/common/lucene-analyzers-common-${version}.jar"
  property="analyzers-common.uptodate" classpath.property="analyzers-common.jar"/>
{noformat}

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.


      was (Author: rcmuir):
    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:
{noformat}
  <dependencies>
    <dependency>
      <groupId>com.ibm.icu</groupId>
      <artifactId>icu4j</artifactId>
      <version>${icu-version}</version>
    </dependency>
  </dependencies>
{noformat}

However, our ant builds (that depend on common-build/contrib-build) declare their dependencies in a semi-standard way:
* External dependencies:
{noformat}
<path id="additional.dependencies">
  <fileset dir="lib" includes="icu4j-*.jar"/>
</path>
* Internal dependencies:
{noformat}
<module-uptodate name="analysis/common" jarfile="../build/common/lucene-analyzers-common-${version}.jar"
  property="analyzers-common.uptodate" classpath.property="analyzers-common.jar"/>
{noformat}

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.

  
> Auto-generate POM templates from Ant builds
> -------------------------------------------
>
>                 Key: LUCENE-2657
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2657
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Build
>            Reporter: Steven Rowe
>            Priority: Minor
>             Fix For: 3.1, 4.0
>
>
> Lucene and Solr modules' POM templates are manually maintained, and so are not always in sync with the dependencies used by the Ant build. 
> It should be possible to auto-generate POM templates using build tools extending Ant's [BuildListener|http://api.dpml.net/ant/1.6.5/org/apache/tools/ant/BuildListener.html] interface, similarly to how the [ant2ide|http://gleamynode.net/articles/2234/] project generates eclipse project files.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org