lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Rowe (JIRA)" <>
Subject [jira] [Commented] (SOLR-2537) Refactor Solr modules structure
Date Mon, 23 May 2011 18:36:47 GMT


Steven Rowe commented on SOLR-2537:

Regarding the .zip it's indeed time-consuming to explore. I had summarized the the differences
(essentially putting all children at the same level and changing the core pom.xml), and meant
the zip just for extra reference.

BTW solution 1. could be implemented w/o changing dirs structure. Solr core becomes an aggregator,
the tests/src becomes a child module, and there we have the 3 modules w/o circular dependency
as described above. I think this is a more 'maven-friendly' solution to the maven-helper copy-paste
workaround. What do you think?
I could try and patch that perhaps.

Patches welcome!

You've proposed several different things.  While some of them sound "essentially" reasonable,
getting a restructured build to work in all the ways it needs to is non-trivial.  While you
may think that an actual implementation is "just for extra reference", I strongly disagree.
 Show me the code! :)  (In patch form, please.)

See Robert Muir's example on LUCENE-2995 for how to specify things that don't fit into patches
- he gives a series of Subversion commands to be run before the patch can apply.  Restructuring
requires this because Subversion's patch format does not represent moves, deletes, etc.

> Refactor Solr modules structure
> -------------------------------
>                 Key: SOLR-2537
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Gabriele Kahlout
>            Priority: Minor
>             Fix For: 3.1.1
> Solr modules are nested in a non-standard archeotype (e.g. Solr Core module is in the
src dir of Solr parent).
> Also, a workaround for avoiding maven dependencies between Solr Core and Testframework
makes it impossible to add a depenency on Solr-3.2-SNAPHOST (Solr Search Server) since it's
packaged as a war, to import, for example. It has been discussed on
the mailing list[1].
> I've, in the mlist, suggested to "create yet one more module for Tests which depend on
Solr Core and on the Test Framework. The org burden of that extra module, versus the ease
of building configuration, I believe, outweights."
> However I realize there's a major drawback in that, i.e. that Solr Core will build without
passing the tests in the other module. There're 2 solutions:
> 1. Make Solr Core a parent module that encompasses a thin Solr Core, the TestFramework
module, and the Tests-only module;
> 2. 'Downgrade' Testframework from being a fully-fledged module by moving the packages
under Solr Core. 
> 2a. Move them under Solr Core test packages.
> 2b. move them under Solr Core src
> To me 2a is most intuitive. Those that want a dependency on Solr TestFramework declare
it with <classifier>tests</classifier>, which packages only the tests, and the
Solr Core classes those require.[2][3]
> The same refactoring applies to lucuene.
> [1]
> [2]
> [3] I've successfully used it before.

This message is automatically generated by JIRA.
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message