Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Mon, 23 May 2011 13:33:47 +0000 (UTC)
From: "Gabriele Kahlout (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: 
 <2013646337.35935.1306157627330.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1322639952.35529.1306140707866.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Issue Comment Edited] (SOLR-2537) Refactor Solr modules
 structure
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037937#comment-13037937 ] 

Gabriele Kahlout edited comment on SOLR-2537 at 5/23/11 1:32 PM:
-----------------------------------------------------------------

{quote}
I don't think it makes sense to roll that back - let's try to figure out how to make the Maven stuff work without changing the official Ant build.{quote}
The issue is that we increase complexity trying with complex maven configuration (and then people say that maven is complicated), unless we go for option 1 (parent solr-core with solr-core-src module, tesframework module, solr-core-tests-src).

The good of SOLR-2061 was to create the Testframework (content); I've had problems with its delivery.
The TestFramework module on its own is a pretty 'lazy module'/interface. It reminds me of the 'lazy class' refactoring.

{quote}can you take a step back and describe more fully why the current setup is a problem?{quote}
A maven project is not expected to contain other maven projects inside it, unless a parent. Solr-core (solr/src) has 'webapp' inside it (under src?). This is non-standard complying, but most importantly very confusing for new-comers. Then the copy-paste trick (done by the maven-helper?) adds to the complication.
Beside, the issues mentioned in the previous comment.


{quote}But this would expose a bunch of Solr tests, which aren't usable outside of Solr, to consumers of the test-jar. The solr test framework classes need to be separate from the other solr test classes.{quote}
Agreed. I've not come across any other 'maven design' approach. I hope it's possible to <exclude> unwanted packages.


      was (Author: simpatico):
    {quote}
I don't think it makes sense to roll that back - let's try to figure out how to make the Maven stuff work without changing the official Ant build.{quote}
The issue is that we increase complexity trying with complex maven configuration (and then people say that maven is complicated). Unless we go for option 1 (parent solr-core with solr-core-src module, tesframework module, solr-core-tests-src).

The good of SOLR-2061 was to create the Testframework (content); I've had problems with its delivery.
The TestFramework module on its own is a pretty 'lazy module'/interface. It reminds me of the 'lazy class' refactoring.

{quote}can you take a step back and describe more fully why the current setup is a problem?{quote}
A maven project is not expected to contain other maven projects inside it, unless a parent. Solr-core (solr/src) has 'webapp' inside it (under src?). This is non-standard complying, but most importantly very confusing for new-comers. Then the copy-paste trick (done by the maven-helper?) adds to the complication.
Beside, the issues mentioned in the previous comment.


{quote}But this would expose a bunch of Solr tests, which aren't usable outside of Solr, to consumers of the test-jar. The solr test framework classes need to be separate from the other solr test classes.{quote}
Agreed. I've not come across any other 'maven design' approach. I hope it's possible to <exclude> unwanted packages.

  
> Refactor Solr modules structure
> -------------------------------
>
>                 Key: SOLR-2537
>                 URL: https://issues.apache.org/jira/browse/SOLR-2537
>             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 EmbeddedSolrServer.java, 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] http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201105.mbox/%3c2D127F11DC79714E9B6A43AC9458147FBAD42EAD@suex07-mbx-03.ad.syr.edu%3e
> [2] http://maven.apache.org/guides/mini/guide-attached-tests.html
> [3] I've successfully used it before. https://code.google.com/p/memorizeasy/source/browse/MemoPlatform/persistenceui/pom.xml

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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