You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Gabriele Kahlout (JIRA)" <ji...@apache.org> on 2011/05/23 10:51:47 UTC
[jira] [Created] (SOLR-2537) Refactor Solr modules structure
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
[jira] [Commented] (SOLR-2537) Refactor Solr modules structure
Posted by "Gabriele Kahlout (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037930#comment-13037930 ]
Gabriele Kahlout commented on SOLR-2537:
----------------------------------------
{quote}
I get a 403 error code when I follow this link: http://dp4j.sourceforge.net/debug/SOLR-2537/ {quote}
try http://dp4j.sourceforge.net/debug/SOLR-2537.zip
{quote} 1. Can you explain why the workaround makes it impossible to add a dependency on the Solr war? This makes no sense to me.{quote}
Sorry, I meant 'jar'. The project Solr Search Server (the one in solr/src/webapp which contains EmbeddedSolrServer) is packaged as a war. But in a Solr plugin I need to depend on the class files packaged in a jar. How do I do that? Attempts were mentioned here[1].
{quote}
2. EmbeddedSolrServer.java is included in the solr-core jar - why not depend on this smaller jar instead of the war?
{quote}
When building it locally it won't work, probably because it's under the webapp project. Steps to reproduce mentioned in the mlist[1]:
{code}
svn co -r 1104120 http://svn.apache.org/repos/asf/lucene/dev/branches/branch_3x/ solr
cd solr; ant get-maven-poms; mvn -N -Pbootstrap install; mvn -DskipTests install
wget http://dp4j.sf.net/debug/embeddedServerTest.zip
unzip embeddedServerTest.zip
cd embeddedServerTest; mvn -X test
{code}
[1] http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201105.mbox/%3cBANLkTinhw3vM9dJGPvMSRwXhS8MwJOYZEg@mail.gmail.com%3e
> 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
[jira] [Commented] (SOLR-2537) Refactor Solr modules structure
Posted by "Steven Rowe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038272#comment-13038272 ]
Steven Rowe commented on SOLR-2537:
-----------------------------------
{quote}
bq. I was able to reproduce
Could you please let it be know there?!
{quote}
Done.
{quote}
Looking at SolrBasicFunctionalityTest I was able to test what I want against r 1104120 + my structural refactoring. Now checking out without the refactoring one of them complains about java.lang.NoSuchFieldError: core at org.apache.lucene.index.SegmentTermDocs.<init>(SegmentTermDocs.java:48).
I find it difficult to believe that the structural refactorings were responsible for avoiding this though!
{quote}
Your build/test problems should have been a mailing list thread rather than tacked onto this issue, which is about something completely different: build restructuring. In the future, please bear in mind that it's much simpler (and thus more likely) for people to help you if you keep issues focused.
> 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
[jira] [Commented] (SOLR-2537) Refactor Solr modules structure
Posted by "Gabriele Kahlout (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038085#comment-13038085 ]
Gabriele Kahlout commented on SOLR-2537:
----------------------------------------
{quote} What happens for you? {quote}
{code}
Running SolrConfigTest
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.28 sec <<< FAILURE!
Results :
Failed tests:
test(SolrConfigTest): ensure your setUp() calls super.setUp()!!!
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
{code}
This is after adding an empty body dummy test method (sorry missed that, but maven 3.0.3 doesn't complain about annotations) and checking the head (1126606).
The issue I had was that it used to complain about something with the classpath. After svn -r 1104120 update and mvn test again:
{quote}
Results :
Tests in error:
test(SolrConfigTest): javax/servlet/ServletRequest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
{quote}
NetBeans doesn't recognize super.setUp().
I'm okay solving the issue against the latest revision of course. Also, I'd solved my test problem w/o EmbeddedSolrServer which seems redundant to SolrTestCaseJ4, or is there an extra layer being tested in the EmbeddedSolrServer?
> 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
[jira] [Commented] (SOLR-2537) Refactor Solr modules structure
Posted by "Steven Rowe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037922#comment-13037922 ]
Steven Rowe commented on SOLR-2537:
-----------------------------------
bq. 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].
Two issues with this:
# Can you explain why the workaround makes it impossible to add a dependency on the Solr war? This makes no sense to me.
# EmbeddedSolrServer.java is included in the solr-core jar - why not depend on this smaller jar instead of the war?
> 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
[jira] [Commented] (SOLR-2537) Refactor Solr modules structure
Posted by "Steven Rowe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038114#comment-13038114 ]
Steven Rowe commented on SOLR-2537:
-----------------------------------
bq. NetBeans doesn't recognize super.setUp().
In the .zip file containing your project, SolrConfigTest#setUp() *does* call super.setUp(), so I guess you removed it in your local version? I've never used NetBeans. By contrast, IntelliJ recognizes super.setUp() - since you're extending AbstractSolrTestCase, it should resolve to that class's setUp(). (BTW, did you know that the IntelliJ Community edition is free now?)
So I still don't understand exactly what the issue is with Solr Maven artifact consumption?
bq. Also, I'd solved my test problem w/o EmbeddedSolrServer which seems redundant to SolrTestCaseJ4, or is there an extra layer being tested in the EmbeddedSolrServer?
I don't understand any part of that sentence - can someone else chine in here if they understand it?
> 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
[jira] [Commented] (SOLR-2537) Refactor Solr modules structure
Posted by "Gabriele Kahlout (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038108#comment-13038108 ]
Gabriele Kahlout 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.
> 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
[jira] [Issue Comment Edited] (SOLR-2537) Refactor Solr modules
structure
Posted by "Gabriele Kahlout (JIRA)" <ji...@apache.org>.
[ 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/%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
[jira] [Commented] (SOLR-2537) Refactor Solr modules structure
Posted by "Steven Rowe (JIRA)" <ji...@apache.org>.
[ 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/%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
[jira] [Commented] (SOLR-2537) Refactor Solr modules structure
Posted by "Gabriele Kahlout (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037944#comment-13037944 ]
Gabriele Kahlout commented on SOLR-2537:
----------------------------------------
and those things in poms:
{code}
<parent>
<relativePath>../../pom.xml</relativePath>
</parent>
{code}
{code}
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<!-- Solrj tests are run from the solr-core build; -->
<!-- otherwise there would be a cyclic dependency, -->
<!-- since Solrj's tests depend on solr-core, and -->
<!-- solr-core depends on Solrj. -->
<skipTests>true</skipTests>
</configuration>
</plugin>
{code}
> 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
[jira] [Issue Comment Edited] (SOLR-2537) Refactor Solr modules
structure
Posted by "Gabriele Kahlout (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (SOLR-2537) Refactor Solr modules structure
Posted by "Gabriele Kahlout (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037959#comment-13037959 ]
Gabriele Kahlout commented on SOLR-2537:
----------------------------------------
{quote} without negatively impacting the official Ant build {quote}
That's the issue. Complicating the poms not to move folders is the status quo, and doesn't seem to work (war/jar issue); But as you mention, we could impact/influence SOLR-2537 so that the project lends itself to both ant and maven builders.
{quote}The fact that they can be used to drive a build is a bonus.{quote}
My +1 for escalating to more than a bonus. The I've praised the exemplarey work on dev-tools in NUTCH-892[1], essentially making it easier to build Solr allows for easier adoption, contribution, and provides newbie documentation.
Where is this issue going to? I've provided re-producable steps to a build (bonus!) issue, and recommended a simplyfing (bonus!) solution.
[1] https://issues.apache.org/jira/browse/NUTCH-892?focusedCommentId=13037537&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13037537
> 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
[jira] [Commented] (SOLR-2537) Refactor Solr modules structure
Posted by "Gabriele Kahlout (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037814#comment-13037814 ]
Gabriele Kahlout commented on SOLR-2537:
----------------------------------------
svn diff would complain about missing directories.
I've uploaded the stripped project here[1]. Essentially there's no more test-framework under both lucene and solr (classes moved under the cores packages), Solr Core has been moved out of solr/src into a solr/core, and webapp has been moved to solr/webapp a la par with core.
>From the core's pom.xml I've commented:
<!-- <plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<id>add-test-source</id>
<phase>generate-test-sources</phase>
<goals>
<goal>add-test-source</goal>
</goals>
<configuration>
<sources>
<source>test-framework</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>-->
and replaced it with:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
I've run the tests of solr core and lucene core they passed (some had errors but they had them even before, expecting Jetty).
I hope you consider this refactoring.
[1] http://dp4j.sf.net/debug/SOLR-2537
> 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
[jira] [Resolved] (SOLR-2537) Refactor Solr modules structure
Posted by "Steven Rowe (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Steven Rowe resolved SOLR-2537.
-------------------------------
Resolution: Won't Fix
Assignee: Steven Rowe
> Refactor Solr modules structure
> -------------------------------
>
> Key: SOLR-2537
> URL: https://issues.apache.org/jira/browse/SOLR-2537
> Project: Solr
> Issue Type: Improvement
> Reporter: Gabriele Kahlout
> Assignee: Steven Rowe
> Priority: Minor
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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
[jira] [Commented] (SOLR-2537) Refactor Solr modules structure
Posted by "Gabriele Kahlout (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038248#comment-13038248 ]
Gabriele Kahlout commented on SOLR-2537:
----------------------------------------
{quote}
Failed tests:
test(SolrConfigTest): ensure your setUp() calls super.setUp()!!!
{quote}
Please see LUCENE-3111, there probably is another bug. I've again posted reproducable steps.
> 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
[jira] [Commented] (SOLR-2537) Refactor Solr modules structure
Posted by "Steven Rowe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038125#comment-13038125 ]
Steven Rowe commented on SOLR-2537:
-----------------------------------
{quote}
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.
{quote}
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: 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
[jira] [Issue Comment Edited] (SOLR-2537) Refactor Solr modules
structure
Posted by "Gabriele Kahlout (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038108#comment-13038108 ]
Gabriele Kahlout edited comment on SOLR-2537 at 5/23/11 6:20 PM:
-----------------------------------------------------------------
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.
BTW, thank you for dedicating time to look into my issue.
was (Author: simpatico):
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.
> 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
[jira] [Issue Comment Edited] (SOLR-2537) Refactor Solr modules
structure
Posted by "Steven Rowe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038114#comment-13038114 ]
Steven Rowe edited comment on SOLR-2537 at 5/23/11 6:49 PM:
------------------------------------------------------------
bq. NetBeans doesn't recognize super.setUp().
In the .zip file containing your project, SolrConfigTest#setUp() *does* call super.setUp(), so I guess you removed it in your local version? I've never used NetBeans. By contrast, IntelliJ recognizes super.setUp() - since you're extending AbstractSolrTestCase, it should resolve to that class's setUp(). (BTW, did you know that the IntelliJ Community edition is free now?)
So I still don't understand exactly what the issue is with Solr Maven artifact consumption?
bq. Also, I'd solved my test problem w/o EmbeddedSolrServer which seems redundant to SolrTestCaseJ4, or is there an extra layer being tested in the EmbeddedSolrServer?
I don't understand any part of that sentence - can someone else chime in here if they understand it?
was (Author: steve_rowe):
bq. NetBeans doesn't recognize super.setUp().
In the .zip file containing your project, SolrConfigTest#setUp() *does* call super.setUp(), so I guess you removed it in your local version? I've never used NetBeans. By contrast, IntelliJ recognizes super.setUp() - since you're extending AbstractSolrTestCase, it should resolve to that class's setUp(). (BTW, did you know that the IntelliJ Community edition is free now?)
So I still don't understand exactly what the issue is with Solr Maven artifact consumption?
bq. Also, I'd solved my test problem w/o EmbeddedSolrServer which seems redundant to SolrTestCaseJ4, or is there an extra layer being tested in the EmbeddedSolrServer?
I don't understand any part of that sentence - can someone else chine in here if they understand it?
> 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
[jira] [Commented] (SOLR-2537) Refactor Solr modules structure
Posted by "Gabriele Kahlout (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038264#comment-13038264 ]
Gabriele Kahlout commented on SOLR-2537:
----------------------------------------
{quote}I was able to reproduce{quote}
Could you please let it be know there?!
{quote}If I were you, I would copy/paste a similar test from Solr's source tree, get that to succeed in your context, then tweak it to get to what you want to test.{quote}
That's always the way to do! What I even try to do is modify the test write there, because otherwise more often than not copy-pasting a method I end-up needing to copy-paste the whole package, but then there's a dependency on X-Y-Z, etc..
Looking at SolrBasicFunctionalityTest I was able to test what I want against r 1104120 + my structural refactoring. Now checking out without the refactoring one of them complains about java.lang.NoSuchFieldError: core at org.apache.lucene.index.SegmentTermDocs.<init>(SegmentTermDocs.java:48).
I find it difficult to believe that the structural refactorings were responsible for avoiding this though!
> 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
[jira] [Commented] (SOLR-2537) Refactor Solr modules structure
Posted by "Steven Rowe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038251#comment-13038251 ]
Steven Rowe commented on SOLR-2537:
-----------------------------------
Gabriele, I was able to reproduce, with both Maven 3.0.3 and 2.2.1, but I don't know enough about Solr testing to be able to help.
If I were you, I would copy/paste a similar test from Solr's source tree, get that to succeed in your context, then tweak it to get to what you want to test.
> 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
[jira] [Commented] (SOLR-2537) Refactor Solr modules structure
Posted by "Steven Rowe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037979#comment-13037979 ]
Steven Rowe commented on SOLR-2537:
-----------------------------------
bq. Where is this issue going to? I've provided re-producable steps to a build (bonus!) issue, and recommended a simplyfing (bonus!) solution.
Gabriele, I downloaded the .zip file you pointed to, and unpacked it, and it's a full Lucene/Solr source tree, apparently with the changes you want.
When I saw this, I didn't look any further. I don't want to spend the time it will take to figure out the differences between what you propose and what currently exists. The problem is that performing these comparisons is really time-consuming without tool support.
Please attach a patch to this issue with your changes, along with whatever "svn move", "svn delete", etc. instructions are required to transform the source, as well as the revision you're basing it on, so that I can look at the patch, and use my IDE to help me understand what you are proposing.
Attaching a patch also allows you to indicate acceptance of the Apache Software License for your contributions. This is very important.
> 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
[jira] [Commented] (SOLR-2537) Refactor Solr modules structure
Posted by "Steven Rowe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037929#comment-13037929 ]
Steven Rowe commented on SOLR-2537:
-----------------------------------
The test-framework was pulled out of the tests in SOLR-2061, to make them re-usable in external projects. 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.
Gabriele, can you take a step back and describe more fully why the current setup is a problem?
bq. 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.
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.
> 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
[jira] [Commented] (SOLR-2537) Refactor Solr modules structure
Posted by "Steven Rowe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037972#comment-13037972 ]
Steven Rowe commented on SOLR-2537:
-----------------------------------
bq. Where is this issue going to?
I see two issues:
# AFAICT, you have a problem consuming Maven artifacts.
# You object to Solr's non-conventional project layout.
These are completely separate in my mind. I think #2 is much, much harder to do than #1. Let's work through #1.
I tried to reproduce your build problem, except I used the (default) HEAD revision of the branch_3x branch:
{quote}
svn co http://svn.apache.org/repos/asf/lucene/dev/branches/branch_3x/
cd branch_3x; ant get-maven-poms; mvn -N -Pbootstrap install; mvn -DskipTests install
wget http://dp4j.sf.net/debug/embeddedServerTest.zip
unzip embeddedServerTest.zip
cd embeddedServerTest; mvn -X test
{quote}
I looked over your POM and everything looks okay, with the exception that the solr test framework dependency should be declared as <scope>test</scope>. I left it as-is, though, to see if it might be the source of problems.
The first problem I encountered is that Maven (v2.2.1) doesn't like annotations with the default Java 1.3 compiler setting. So I added a maven-compiler-plugin configuration to your POM, with source and target set to 1.6. This allowed everything to compile.
But you apparently don't have any real tests in your SolrConfigTest? I don't see any @Test annotations, or methods named "test..." in SolrConfigTest. This is the test output I get:
{quote}
-------------------------------------------------------------------------------
Test set: SolrConfigTest
-------------------------------------------------------------------------------
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.062 sec <<< FAILURE!
initializationError(SolrConfigTest) Time elapsed: 0.006 sec <<< ERROR!
java.lang.RuntimeException: No runnable methods!
at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.computeTestMethods(LuceneTestCase.java:1040)
{quote}
What happens for you?
> 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
[jira] [Commented] (SOLR-2537) Refactor Solr modules structure
Posted by "Steven Rowe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037918#comment-13037918 ]
Steven Rowe commented on SOLR-2537:
-----------------------------------
I get a 403 error code when I follow this link: http://dp4j.sourceforge.net/debug/SOLR-2537/
> 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
[jira] [Commented] (SOLR-2537) Refactor Solr modules structure
Posted by "Gabriele Kahlout (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037937#comment-13037937 ]
Gabriele Kahlout commented on SOLR-2537:
----------------------------------------
{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