[ 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 define 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/%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