topic Re: Maven build in sdk 2.2 fails to run junit tests that access Solr in Alfresco Archive

Maven build in sdk 2.2 fails to run junit tests that access Solr

marco_altieri — Tue, 08 Nov 2016 13:21:49 GMT

I used the archetype for "all-in-one" and I modified the sample test case adding a simple lucene query as shown in the attached java file.When I execute: mvn testthe test fails because it seems that Alfresco cannot access Solr (see attached maven.log file).In this log, I also found a warning: [INF

Re: Maven build in sdk 2.2 fails to run junit tests that access Solr

ycoulon — Tue, 08 Nov 2016 13:44:59 GMT

Hi,

I was able to reproduce.

The issue is that SolR is not run during the test phase. That's why you get the "java.net.ConnectException: Connection refused" error.

I don't know if there is a way to get SolR run during the test phase.

Maybe you could create an issue on github GitHub - Alfresco/alfresco-sdk: The Alfresco SDK based on Apache Maven, includes support for rapid and standard developm…

Development team of the SDK will answer you.

Marco Altieri a écrit:

In this log, I also found a warning:
[INFO] --- alfresco-maven-plugin:2.2.0:refresh (refresh-webscripts-repo-and-share) @ marco-repo-amp ---
[WARNING] Connection failed to localhost:8080, null webapp refresh aborted

That is linked to the hot reloading feature. That feature is for RAD for more information about RAD see : Rapid Application Development (RAD) | Alfresco Documentation

Yann

Re: Maven build in sdk 2.2 fails to run junit tests that access Solr

jego — Thu, 10 Nov 2016 20:50:56 GMT

There are 2 alternatives:

You can use the buildonly in index.subsystem.name which is made for the purpose to rely not on any solr server to start up (Lucene no longer available in 5.0.b · Issue #228 · Alfresco/alfresco-sdk · GitHub )
You can swith to Alfresco SDK 3beta4 which runs the repository and SOLR for testing

I hope this helps.

Re: Maven build in sdk 2.2 fails to run junit tests that access Solr

marco_altieri — Fri, 11 Nov 2016 15:36:39 GMT

Thank you Jens.

I did not realise that the issue that you mentioned was closed on a newer version of the SDK.

I guess that with the current SDK 2.2 the workaround is still necessary.