lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven A Rowe <sar...@syr.edu>
Subject RE: Improvements to the maven build
Date Wed, 04 May 2011 22:43:48 GMT
Hi David,

> I thought I'd put together a list of interesting differences between the
> ant build output and the maven build output.  Before each build I did a
> full clean and then after the build I saved a file listing to a text file
> so that I could diff it.

Cool!  Thanks for the effort.

> 1. The ant build invokes a JSP compiler to validate them.  The maven
> build does not.

My take on the Maven build is that it should ensure the POMs are in sync with the artifacts
produced.  I don't think the Maven build needs to perform all of the validity checks that
the Ant build performs (e.g. also javadocs).  I'd like to keep the build simple, so that maintenance
is easier and keeping the POMs in sync is thereby more likely.

> 2. Maven seems(?) to compile more modules' tests than the ant build does.

Not sure why this would be, but I don't think it's necessarily a problem (for the Maven build).

> 3. The ant build builds the tools module.  The maven build does not.
> Probably fine it stays this way?

In general, code under tools is used to generate other code, the results of  which is kept
checked in.  So I agree, the Maven build doesn't need to support this, KISS principlishly.

> 4. Ant doesn't build the benchmark module; maven will by default.  A
> problem for the ant build?

I don't think it's necessary to enable this by default in Ant.  For the Maven build, it's
just simpler to include every module - that way, every module's POM is checked.

> 5. The ant build artifacts tend to have a leading "apache-" in front of
> them. But the maven artifactId does not have this so the artifacts file
> names are different, trivially so any way.

This different naming of artifacts has always been so, as far as I can tell, as long as Solr
has released Maven artifacts.  

The conventional Maven artifact name template is <artifactId>-<version>[-<classifier>].jar,
where -<classifier> is optional; <artifactId> would have to be "apache-solr" in
order to make this change.  The full artifact name would be org.apache.solr:apache-solr:<version>,
which seems weird to me in the double inclusion of "maven". I'm guessing this also seemed
weird to whoever first put the Maven artifact naming scheme in place.  

Specifying "finalName" in the maven-jar-plugin might alternatively do the trick?  If this
were done, though, the Maven naming convention would not be followed, and that's fairly predictably
an omen of Bad Things To Come.

(BTW, Lucene's Maven artifacts are the same as the regular ones - this is a Solr-only issue.)

> 6. The ant solr build puts all its final artifacts into the solr/dist
> directory, the maven build does not--it leaves all of them in their build
> directory. Not a big deal but maybe there's a way to have the output file
> go someplace else?  Not sure.

I meant to keep the Maven build output location the same as the Ant build output location.
 I think the Solr modules' POMs can and should be changed to eliminate this difference.

> There were two issues that seemed like clear bugs to me that I fixed with
> an attached patch.
> 1. solrj's build directory and compile output directory were the same
> directory, but that's problematic since building the output jar will
> result in an error if it sees its own jar file as an input file to its
> output jar.  So I added a "classes" directory.  This will result in a
> different directory than where the ant builds, though.
> 2. The dataimporthandler-extras output location was specified such that
> there was a redundant path: /extras/extras/, so I fixed this.

Thanks, I agree with these changes.  I committed your patch.

> By the way, I think it would be really nice to have a maven build
> instructions file that is put into place when the get-maven-poms task is
> run.  The file would have the essential instructions, it would explain
> some of the relevant differences to the ant build (notably output file
> placement, file name differences), and it would include tips such as how
> to install the sources and javadoc jar files into your local repo.

+1.  I've hesitated to include these instructions with other build instructions, since it
might confuse users into thinking that the Maven build is officially supported.  (It's not.
 Ant is the only official build.)

Steve

Mime
View raw message