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

Steven Rowe commented on SOLR-2537:
-----------------------------------

My take-away from your problem description here is that the Lucene/Solr Maven 
setup is complicated and non-standard, and this causes problems for users.  
While I agree and sympathize, the Maven build is not an official build; 
correctness of the POMs for the purpose of describing the release artifacts is 
the primary goal.  The fact that they can be used to drive a build is a bonus.

That said, if we can find a way to simplify the project structure, and even 
make it closer to Maven convention, without negatively impacting the official 
Ant build, that would be great.  Along those lines, Robert Muir has started an 
issue to clean up the Solr Ant build: SOLR-2537.

bq. A maven project is not expected to contain other maven projects inside it, 
unless a parent.

This is false.  Maven explicitly separates the parent-child relationship from 
the aggregation relationship.  Aggregation-only POMs are run-of-the-mill.

> 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/%3c2d127f11dc79714e9b6a43ac9458147fbad42...@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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to