Broadleaf Framework Integration Module Error - broadleaf-commerce

I have been able to download and run the demosite source code in eclipse luna
I was unable to change the broadleaf logo in the DemoSite project , so I downloaded the broadleaf framework source code and imported into eclipse . BLC framework is a multi-module project . On running clean install on the broadleaf sub-module all modules build successfully except the integration module which results in this following stack trace ( Edited )
------------------------------------------------------------------ -------------
Test set: TestSuite
Tests run: 153, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 196.714 sec <<< FAILURE!
testCheckout(org.broadleafcommerce.core.checkout.service.CheckoutTest) Time elapsed: 0.407 sec <<< FAILURE!
org.broadleafcommerce.core.pricing.service.exception.PricingException: Unable to execute pricing for order -- id: 24
at org.broadleafcommerce.core.pricing.service.PricingServiceImpl.executePricing( PricingServiceImpl.java:44)
at org.broadleafcommerce.core.order.service.OrderServiceImpl.save(OrderServiceIm pl.java:276)
at sun.reflect.GeneratedMethodAccessor92.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl. java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUt ils.java:317)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProx y.java:201)
at com.sun.proxy.$Proxy139.save(Unknown Source)
at org.broadleafcommerce.core.checkout.service.CheckoutTest.testCheckout(Checkou tTest.java:115)
Caused by: org.broadleafcommerce.core.workflow.WorkflowException: java.lang.UnsupportedOperationException: No currency conversion service is registered, cannot add different currency types together (USD INR)
at org.broadleafcommerce.core.workflow.DefaultErrorHandler.handleError(DefaultEr rorHandler.java:60)
at org.broadleafcommerce.core.workflow.SequenceProcessor.doActivities(SequencePr ocessor.java:90)
at org.broadleafcommerce.core.pricing.service.PricingServiceImpl.executePricing( PricingServiceImpl.java:39)
... 47 more
Caused by: java.lang.UnsupportedOperationException: No currency conversion service is registered, cannot add different currency types together (USD INR)
at org.broadleafcommerce.common.money.Money.add(Money.java:182)
at org.broadleafcommerce.core.pricing.service.workflow.TotalActivity.setTaxSums( TotalActivity.java:135)
at org.br oadleafcommerce.core.pricing.service.workflow.TotalActivity.execute(TotalActi vity.java:48)
at org.broadleafcommerce.core.workflow.SequenceProcessor.doActivities(SequencePr ocessor.java:77)
... 48 more
I hence cannot run the projects .Can any one please help .
I would also like to know why there is no demosite sub-module in the framework code . How to run the frame work source code from eclipse . I also don't see any build.xml files like we had in demosite project .

It seems you are trying to build Broadleaf Commerce's framework project from source . If your aim is to change the Broadleaf Logo you don't need to build the entire Broadleaf framework source code .
All you need is to override certain portions of the DemoSite source code . Suggest you search this forum for more details regarding this issue .
Hope this helps . Good luck .

Related

Sencha Architect 4.3.2.19 - Directory *** does not contain a valid framework

I installed and registered Sencha Architect 4.3.2.19. However, after I created a new classic ExtJs 7.6.0 project, it doesn't initialize Cmd properly, and in the command output I see:
Exception in thread "Thread-15"
com.sencha.exceptions.BasicException: com.sencha.exceptions.ExState: Directory C:\Users\costa\Documents\Architect\frameworks/ext76/7.6.0.41/commercial does not contain a valid framework.
at com.sencha.tools.server.service.tasks.DispatchTask.execute(DispatchTask.java:55)
at com.sencha.tools.server.service.tasks.BaseServiceTask$1.run(BaseServiceTask.java:42)
at com.sencha.util.ThreadUtil$1.run(ThreadUtil.java:65)
at com.sencha.util.ThreadUtil$2.run(ThreadUtil.java:162)
at java.base/java.lang.Thread.run(Thread.java:1589)
Caused by: com.sencha.exceptions.ExState: Directory C:\Users\costa\Documents\Architect\frameworks/ext76/7.6.0.41/commercial does not contain a valid framework.
at com.sencha.command.app.AppCommands$InitCommand.validateEnvironment(AppCommands.java:1874)
at com.sencha.command.app.AppCommands$InitCommand.execute(AppCommands.java:1750)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
at java.base/java.lang.reflect.Method.invoke(Method.java:578)
at com.sencha.util.MethodInvoker$Arguments.invoke(MethodInvoker.java:175)
at com.sencha.cli.Command.dispatch(Command.java:43)
at com.sencha.command.BasePluginCommands$BasePluginCommand.dispatch(BasePluginCommands.java:289)
at com.sencha.cli.Commands.dispatch(Commands.java:64)
at com.sencha.cli.Commands.dispatch(Commands.java:64)
at com.sencha.command.Sencha.dispatch(Sencha.java:80)
at com.sencha.cli.AbstractCommand.dispatch(AbstractCommand.java:124)
at com.sencha.tools.server.service.tasks.DispatchTask.execute(DispatchTask.java:52)
... 4 more
The Cmd base directory is set to: C:\Users\costa\bin\Sencha\Cmd which contains the subdirectory 7.6.0.87.
Any idea on how to fix the exception? Time to open a ticket?
Edit: I've got the previous error on Windows 2016. I just gave SA 4.3.2.19 for macosx a try. It has a different problem. I created a blank ExtJs 7.6.0 Modern project. When I save the project in the folder I get (I set the app name to App) :
/Users/costa/bin/Sencha/Cmd/7.6.0.87/extensions/sencha-service/shell-wrapper.sh: line 41: cordova: command not found
/Users/costa/bin/Sencha/Cmd/7.6.0.87/extensions/sencha-service/shell-wrapper.sh: line 41: phonegap: command not found
[INF] Initializing empty workspace at /Users/costa/Documents/development/javascript/TestAppModern01
[INF] Copying framework to /Users/costa/Documents/development/javascript/TestAppModern01/ext
[INF] Added framework ext to workspace.json
[ERR] The specified string cannot be converted into a valid namespace identifier
Exception in thread "Thread-61" com.sencha.exceptions.BasicException: com.sencha.exceptions.ExState: Invalid namespace : App
at com.sencha.tools.server.service.tasks.DispatchTask.execute(DispatchTask.java:55)
at com.sencha.tools.server.service.tasks.BaseServiceTask$1.run(BaseServiceTask.java:42)
at com.sencha.util.ThreadUtil$1.run(ThreadUtil.java:65)
at com.sencha.util.ThreadUtil$2.run(ThreadUtil.java:162)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: com.sencha.exceptions.ExState: Invalid namespace : App
at com.sencha.util.NameUtil.stringToNamespace(NameUtil.java:76)
at com.sencha.command.generator.GeneratorCommands$AppCommand.validateAppName(GeneratorCommands.java:680)
at com.sencha.command.generator.GeneratorCommands$AppCommand.execute(GeneratorCommands.java:420)
at com.sencha.command.app.AppCommands$InitCommand.execute(AppCommands.java:1819)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at com.sencha.util.MethodInvoker$Arguments.invoke(MethodInvoker.java:175)
at com.sencha.cli.Command.dispatch(Command.java:43)
at com.sencha.command.BasePluginCommands$BasePluginCommand.dispatch(BasePluginCommands.java:289)
at com.sencha.cli.Commands.dispatch(Commands.java:64)
at com.sencha.cli.Commands.dispatch(Commands.java:64)
at com.sencha.command.Sencha.dispatch(Sencha.java:80)
at com.sencha.cli.AbstractCommand.dispatch(AbstractCommand.java:124)
at com.sencha.tools.server.service.tasks.DispatchTask.execute(DispatchTask.java:52)
... 4 more
An identical error occurs when I save a classic project.
What am I missing? There seems to be something wrong overall with SA 4.3.2, or maybe it's missing something.
Both versions, windows & macosx, don't allow me to set Build Tools to Enabled. I click Save, I come back to the dialog and Build Tools is set to Disabled.
More than that, I downloaded ExtJs 7.6.0 and unzipped in a local folder, then in the above dialog I chose Complete or Custom Path, I entered the folder where I unzipped ExtJs, clicked Save, came back to the dialog and Build Tools is Disabled again.
Thank you
ok, I found a workaround for the first problem I had on windows. I installed Sencha Cmd from the installer - I don't know if that made a difference or not.
After creating the classic app, and saving it in SA, I went to the command line and I ran inside the project folder: C:\Users\costa\bin\Sencha\Cmd\7.6.0.87\sencha.exe app init -n App -e ..\..\ext760 --classic
You'd have to adjust the parameters according to your needs. I re-opened the project in SA, and it got its brains back. In my case I used a workspace, and the folder for the workspace was 2 levels up from the project folder. I placed the 7.6.0 ExtJs files in the ext760 directory.
Update: I created a ticket with Sencha and they came back with the fix.
The framework code has been incorrectly installed by SA 4.3.2 in this folder: C:\Users\<UserName>\Documents\Architect\frameworks\ext76\7.6.0.41\commercial\ext-7.6.0. The solution is to copy the files in this folder one level up, i.e. in C:\Users\<UserName>\Documents\Architect\frameworks\ext76\7.6.0.41\commercial, and then it's going to work.

Add an AAR dependency in Android Studio 4.2

I'm trying to use https://github.com/brim-borium/spotify_sdk in Android Studio with Flutter
As such, I need to import Spotify SDK (two AAR files), and to be able to add them to the build process.
Because of spotify_sdk (flutter package), I can't use (which seem to work)
implementation (name: 'spotify-app-remote', ext: 'aar')
implementation (name: 'spotify-auth', ext: 'aar')
in my project, I specifically need Gradle to consider spotify-app-remote & spotify-auth as projects, because spotify_sdk imports them like this.
implementation project(':spotify-auth')
implementation project(':spotify-app-remote')
Here is the Gradle error:
FAILURE: Build failed with an exception.
* What went wrong:
Could not determine the dependencies of task ':app:compileDebugJavaWithJavac'.
> Could not resolve all task dependencies for configuration ':app:debugCompileClasspath'.
> Could not resolve project :spotify-auth.
Required by:
project :app
> No matching configuration of project :spotify-auth was found. The consumer was configured to find an API of a component, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'debug', attribute 'org.jetbrains.kotlin.platform.type' with value 'androidJvm' but:
- None of the consumable configurations have attributes.
> Could not resolve project :spotify-app-remote.
Required by:
project :app
> No matching configuration of project :spotify-app-remote was found. The consumer was configured to find an API of a component, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'debug', attribute 'org.jetbrains.kotlin.platform.type' with value 'androidJvm' but:
- None of the consumable configurations have attributes.
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 1s
Exception: Gradle task assembleDebug failed with exit code 1
Here is my settings.gradle
def localPropertiesFile = new File(rootProject.projectDir, "local.properties")
def properties = new Properties()
assert localPropertiesFile.exists()
localPropertiesFile.withReader("UTF-8") { reader -> properties.load(reader) }
def flutterSdkPath = properties.getProperty("flutter.sdk")
assert flutterSdkPath != null, "flutter.sdk not set in local.properties"
apply from: "$flutterSdkPath/packages/flutter_tools/gradle/app_plugin_loader.gradle"
So I need to be able to force Gradle to import these AAR as a projet.
Here is my project structure, if it useful
Project Structure
From documentation and StackOverflow posts, I've read that Android Studio used to have an Import AAR/Jar file functionality. It is now missing in Android Studio 4.2
Is there any functionality that replaces Import AAR/Jar file? Or any way to force Gradle to recognize these files as projects?
Thank you very much

sbt resources not copied

It appears as though sbt (1.2.1, 1.2.3) is not copying resource files (from src/main/resources) to the target directory.
The build is multi-project, with a root project that aggregates subprj1 (for now).
Showing below: project structure (main directories and one resource file: application.conf), the resourceDirectory as proof that we have not overridden it, proof of successful compilation - and yet the application.conf file has not been copied to the output (target) directory.
Tried sbt versions 1.2.1, 1.2.3.
Why are the resources not being copied to the output, since we are complying with the standard directory structure?
Project structure
/main/project/home/dir/build.sbt
/main/project/home/dir/subprj1/src/main/resources
/main/project/home/dir/subprj1/src/main/resources/application.conf
/main/project/home/dir/subprj1/src/main/scala/com/myco/foo/bar/server/*.scala
IJ][subprj1#master] λ show resourceDirectory
[info] subprj1 / Compile / resourceDirectory
[info] /main/project/home/dir/subprj1/src/main/resources
build/sbt clean compile
...
[success] Total time: 22 s, completed Feb 8, 2019 3:10:04 PM
find . -name application.conf
./subprj1/src/main/resources/application.conf
It works if we run copyResources after compile, but why is that not automatic?
build/sbt copyResources
find . -name application.conf
./subprj1/src/main/resources/application.conf
./subprj1/target/scala-2.12/classes/application.conf
I can inspect the dependencies among tasks and I can see that compile does not depend on copyResources, but was it always like this, or is this a recent change? I have been using sbt for years, and I have this expectation that the build would copy resources to output automatically.
build/sbt -Dsbt.log.noformat=true "inspect tree compile" > t.txt
It turns out someone had added the settings below to build.sbt. Once I commented out these lines, the resources started being copied to the output directory.
, unmanagedResourceDirectories in Compile := Seq()
, unmanagedResourceDirectories in Test := Seq()

SonarQube Analysis not showing code coverage

I have a Jenkins project to do SonarQube analysis of my NodeJS project. I added istanbul as a dependency to my project's package.json. In the Jenkins build configuration, first I run a shell script:
cd ./project-name
npm install
node_modules/.bin/istanbul cover ./node_modules/.bin/_mocha path-to-unit-tests
node_modules/.bin/istanbul report cobertura
cd ..
This installs the dependencies, runs the tests and generates a code coverage report and generates a cobertura-coverage.xml file.
After the shell script, I run a Invoke Standalone SonarQube Analysis with the following properties for code coverage:
sonar.java.coveragePlugin=cobertura
sonar.dynamicAnalysis=reuseReports
sonar.cobertura.reportPath=./project-name/coverage/cobertura-coverage.xml
The Jenkins job runs successfully with a SonarQube dashboard describing various things such as the lines of code, technical debt, issues and so on for the project. But the code coverage for the unit tests doesn't show up on the SonarQube dashboard. I made sure that the dashboard has the Unit Tests widget.
Version of SonarQube server: 5.2
Version of JavaScript plguin used on SonarQube: 2.9
Version of Cobertura plugin used on SonarQube: 1.6.3
Version of Cobertura plugin used on Jenkins: 1.9.7
Version of NodeJS plugin used on Jenkins: 0.2.1
I verified that the workspace does have the cobertura-coverage.xml file. Also checked the build console logs and found no bugs. I have also tried pushing the code coverage using LCOV format before:
sonar.dynamicAnalysis=reuseReports
sonar.javascript.lcov.reportPath=./project-name/coverage/lcov.info
The report doesn't get published to SonarQube even though the coverage report does get generated in Jenkins workspace. I looked at the workspace contents and verified. The console logs show the coverage report getting generated. Also tried
sonar.dynamicAnalysis=reuseReports
sonar.javascript.lcov.reportPath=project-name/coverage/lcov.info
and
sonar.dynamicAnalysis=reuseReports
sonar.cobertura.reportPath=project-name/coverage/cobertura-coverage.xml
to no avail. I also restarted the Jenkins and SonarQube servers 2 times each. Looked at many similar questions on StackOverflow and elsewhere but didn't find anything that works.
If I add a post-build action Publish Cobetura Coverage Report and specify the path to the cobetura-coverage.xml file in the Cobertura xml report pattern field, the code coverage report does get published in Jenkins.
Looked at the background task logs in SonarQube and saw an exception.
java.lang.IllegalStateException: Cannot persist sources of project-key:project-name/node_modules/jscs/jscs-browser.js
at org.sonar.server.computation.step.PersistFileSourcesStep$FileSourceVisitor.visitFile(PersistFileSourcesStep.java:132) ~[sonar-server-5.2.jar:na]
at org.sonar.server.computation.component.DepthTraversalTypeAwareCrawler.visitNode(DepthTraversalTypeAwareCrawler.java:72) ~[sonar-server-5.2.jar:na]
at org.sonar.server.computation.component.DepthTraversalTypeAwareCrawler.visit(DepthTraversalTypeAwareCrawler.java:44) ~[sonar-server-5.2.jar:na]
at org.sonar.server.computation.component.DepthTraversalTypeAwareCrawler.visitChildren(DepthTraversalTypeAwareCrawler.java:91) ~[sonar-server-5.2.jar:na]
at org.sonar.server.computation.component.DepthTraversalTypeAwareCrawler.visit(DepthTraversalTypeAwareCrawler.java:47) ~[sonar-server-5.2.jar:na]
at org.sonar.server.computation.component.DepthTraversalTypeAwareCrawler.visitChildren(DepthTraversalTypeAwareCrawler.java:91) ~[sonar-server-5.2.jar:na]
at org.sonar.server.computation.component.DepthTraversalTypeAwareCrawler.visit(DepthTraversalTypeAwareCrawler.java:47) ~[sonar-server-5.2.jar:na]
at org.sonar.server.computation.step.PersistFileSourcesStep.execute(PersistFileSourcesStep.java:89) ~[sonar-server-5.2.jar:na]
at org.sonar.server.computation.step.ComputationStepExecutor.execute(ComputationStepExecutor.java:39) ~[sonar-server-5.2.jar:na]
at org.sonar.server.computation.taskprocessor.report.ReportTaskProcessor.process(ReportTaskProcessor.java:53) ~[sonar-server-5.2.jar:na]
at org.sonar.server.computation.taskprocessor.CeWorkerRunnableImpl.executeTask(CeWorkerRunnableImpl.java:78) [sonar-server-5.2.jar:na]
at org.sonar.server.computation.taskprocessor.CeWorkerRunnableImpl.run(CeWorkerRunnableImpl.java:55) [sonar-server-5.2.jar:na]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_45-internal]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [na:1.8.0_45-internal]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [na:1.8.0_45-internal]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [na:1.8.0_45-internal]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_45-internal]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_45-internal]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45-internal]
Caused by: org.apache.ibatis.exceptions.PersistenceException:
### Error updating database. Cause: com.mysql.jdbc.PacketTooBigException: Packet for query is too large (7989143 > 4194304). You can change this value on the server by setting the max_allowed_packet' variable.
### The error may involve org.sonar.db.source.FileSourceMapper.insert-Inline
### The error occurred while setting parameters
### SQL: INSERT INTO file_sources (project_uuid, file_uuid, created_at, updated_at, binary_data, line_hashes, data_hash, src_hash, data_type, revision) VALUES (?, ?, ?, ?, ?, ?, ?, ?,?, ?)
### Cause: com.mysql.jdbc.PacketTooBigException: Packet for query is too large (7989143 > 4194304). You can change this value on the server by setting the max_allowed_packet' variable.
at org.apache.ibatis.exceptions.ExceptionFactory.wrapException(ExceptionFactory.java:26) ~[mybatis-3.2.7.jar:3.2.7]
at org.apache.ibatis.session.defaults.DefaultSqlSession.update(DefaultSqlSession.java:154) ~[mybatis-3.2.7.jar:3.2.7]
at org.apache.ibatis.session.defaults.DefaultSqlSession.insert(DefaultSqlSession.java:141) ~[mybatis-3.2.7.jar:3.2.7]
at org.apache.ibatis.binding.MapperMethod.execute(MapperMethod.java:51) ~[mybatis-3.2.7.jar:3.2.7]
at org.apache.ibatis.binding.MapperProxy.invoke(MapperProxy.java:52) ~[mybatis-3.2.7.jar:3.2.7]
at com.sun.proxy.$Proxy84.insert(Unknown Source) ~[na:na]
at org.sonar.db.source.FileSourceDao.insert(FileSourceDao.java:117) ~[sonar-db-5.2.jar:na]
at org.sonar.server.computation.step.PersistFileSourcesStep$FileSourceVisitor.persistSource(PersistFileSourcesStep.java:160) ~[sonar-server-5.2.jar:na]
at org.sonar.server.computation.step.PersistFileSourcesStep$FileSourceVisitor.visitFile(PersistFileSourcesStep.java:130) ~[sonar-server-5.2.jar:na]
... 18 common frames omitted
Caused by: com.mysql.jdbc.PacketTooBigException: Packet for query is too large (7989143 > 4194304). You can change this value on the server by setting the max_allowed_packet' variable.
at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3540) ~[mysql-connector-java-5.1.35.jar:5.1.35]
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2417) ~[mysql-connector-java-5.1.35.jar:5.1.35]
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2582) ~[mysql-connector-java-5.1.35.jar:5.1.35]
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2535) ~[mysql-connector-java-5.1.35.jar:5.1.35]
at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1911) ~[mysql-connector-java-5.1.35.jar:5.1.35]
at com.mysql.jdbc.PreparedStatement.execute(PreparedStatement.java:1203) ~[mysql-connector-java-5.1.35.jar:5.1.35]
at org.apache.commons.dbcp.DelegatingPreparedStatement.execute(DelegatingPreparedStatement.java:172) ~[commons-dbcp-1.4.jar:1.4]
at org.apache.commons.dbcp.DelegatingPreparedStatement.execute(DelegatingPreparedStatement.java:172) ~[commons-dbcp-1.4.jar:1.4]
at org.apache.ibatis.executor.statement.PreparedStatementHandler.update(PreparedStatementHandler.java:44) ~[mybatis-3.2.7.jar:3.2.7]
at org.apache.ibatis.executor.statement.RoutingStatementHandler.update(RoutingStatementHandler.java:69) ~[mybatis-3.2.7.jar:3.2.7]
at org.apache.ibatis.executor.ReuseExecutor.doUpdate(ReuseExecutor.java:50) ~[mybatis-3.2.7.jar:3.2.7]
at org.apache.ibatis.executor.BaseExecutor.update(BaseExecutor.java:105) ~[mybatis-3.2.7.jar:3.2.7]
at org.apache.ibatis.executor.CachingExecutor.update(CachingExecutor.java:71) ~[mybatis-3.2.7.jar:3.2.7]
at org.apache.ibatis.session.defaults.DefaultSqlSession.update(DefaultSqlSession.java:152) ~[mybatis-3.2.7.jar:3.2.7]
... 25 common frames omitted
So now I've updated the shell script code coverage generation line to
node_modules/.bin/istanbul cover -x node_modules ./node_modules/.bin/_mocha path-to-unit-tests
Still getting the exception. Based on max_allowed_packet, I don't have MySQL, I need to bump up the value of MAX_ALLOWED_PACKET in the database settings. Just done that and retriggered the Jenkins job for SonarQube analysis. The exception disappeared. The background task in SonarQube was successful. But I still don't see Unit test code coverage in the dashboard. There are no other exceptions. When I click on 'Configure Widgets' button, the Unit test widget has 'No data' label on it. When I go back to the dashboard, the Unit test widget disappears.
Any idea what I am missing?
The first time (~a year back) when I started exploring "Sonarqube" and while doing set up everything worked fine. I was able to see all the metrics along with "code coverage".
For that used version was:
sonarqube-6.7.5, sonar-scanner:
sonar-scanner-3.2.0.1227-macosx
After that, when I tried today for some other project but I struggled almost ~3 hours to identify why code coverage is not being displayed in the sonarqube report though everything is configured properly.
After spending some time I have found below two blog topics which helps me to understand why I was not getting the coverage report.
If I read it correctly then it seems that there was a bug where after "lcov" report path was not recognized though it was configured accurately.
Reference links:
unable-to-get-code-coverage-for-javascript
Fix: js-coverage-doesnt-work-anymore
Used version: Docker image of sonarqube:8.3.0 & newtmitch/sonar-scanner as a sonar-scanner.
For reference, Dockerfile from my local setup which is used to run the sonar-scanner:
FROM newtmitch/sonar-scanner AS sonarqube_scan
COPY . /usr/src
RUN ls -list
RUN sonar-scanner \
-Dsonar.host.url="http://localhost:9000" \
-Dsonar.projectKey="test-node-app" \
-Dsonar.projectVersion="1.0" \
-Dsonar.sources="/usr/src" \
-Dsonar.language="javascript" \
-Dsonar.sourceEncoding="UTF-8" \
-Dsonar.dynamicAnalysis="reuseReports" \
-Dsonar.javascript.lcov.reportPaths="/usr/src/app/coverage/lcov.info"
I hope someone this helpful!
Happy learning!
The lcov report publishing worked after I had fixed the exception mentioned in the question. But sometimes, I randomly see another exception. Moreover, the Unit test widget on the SonarQube dashboard shows only the Conditionals coverage. Need to fine tune the solution more.
sonar.dynamicAnalysis=reuseReports
sonar.javascript.lcov.reportPath=project-name/coverage/lcov.info

Error grabbing Grapes ... unresolved dependency ... not found

UPDATE 8/6:
The beefed up logging has shown me that there is an issue deleting the old jar from the cache, which leads to the fatal "not found" error. There are other threads similar to this, but only when someone is locking the file with their IDE. We are running a single groovy script from Jenkins, and no one is logged into this box.
We ran process explorer right after the failure and there were no locks. Then I login with the user that Jenkins is using to run the script, and I get no error deleting the files.
Also it seems there was a fix in IVY 2.1 to not fail when the jar cannot be deleted, and I'm on Ivy 2.2 (Groovy 1.8.4). What gives?
Couldn't delete outdated artifact from cache: C:\Users\myUser\.groovy\grapes\com.a.b.c\x-y-z\jars\x-y-z-1.496.jar
then the false(?) error:
Caught: java.lang.ExceptionInInitializerError
java.lang.ExceptionInInitializerError
Caused by: java.lang.RuntimeException: Error grabbing Grapes -- [unresolved dependency: com.a.b.c#x-y-z;1.+: not found]
at smokeTestSuccess.<clinit>(smokeTestSuccess.groovy)
Interestingly enough, this happens everyday the first time the script is run after 5am. I guess the cache gets invalidated through some default config at 5am? Is this some kind of clue??
Original post:
I am intermittently getting an error when running a number of different Groovy scripts which all share an identical #Grab declaration. (file names changed to protect the innocent). First the full Grab declaration:
#GrabResolver(name = 'libs.release', root = 'http://myserver:8081/artifactory/libs-release', m2compatible = 'true') #Grapes([
#Grab(group = 'com.a.b.c, module = 'x-y-z', version = '1.+', changing = true),
#Grab('commons-lang:commons-lang:2.3'),
#Grab('log4j:log4j:1.2.16'),
#Grab('gpars:gpars:0.12'),
#Grab('jsr166y:jsr166y:1.7.0'),
#Grab('org.codehaus.groovy.modules.http-builder:http-builder:0.6'),
#Grab('org.apache.commons:commons-collections:3.2.1'),
#Grab('org.apache.httpcomponents:httpclient:4.2.2'),
#Grab('org.apache.httpcomponents:httpcore:4.2.3'),
#Grab('org.cyberneko.html:nekohtml:1.9.17'),
#Grab('xerces:xercesImpl:2.11.0'),
]) #GrabConfig(systemClassLoader = true)
Then the error:
Caught: java.lang.ExceptionInInitializerError
java.lang.ExceptionInInitializerError
Caused by: java.lang.RuntimeException: Error grabbing Grapes -- [unresolved dependency: com.a.b.c#x-y-z;1.+: not found]
Upon doing numerous internet searches, the cause always seems to be very simple, either one of these two basic problems:
1. Repository unreachable
2. Jar file doesn’t exist
However, in the artifactory logs, I've proven that the file is actually being downloaded:
*Artifactory did accept the request for download:
2014-07-17 07:58:19,938 [ACCEPTED DOWNLOAD] libs-release-local:com/a/b/c/x-y-z/1.477/x-y-z-1.477.jar for anonymous/165.226.40.155.
*Artifactory did deliver jar:
20140717075820|156|REQUEST|165.226.40.155|non_authenticated_user|GET|/libs-release/com/a/b/c/x-y-z/1.477/x-y-z-1.477.jar|HTTP/1.1|200|1276695
The scripts all work about 100% of the time if they are simply restarted. This all leads me to believe that the issue is the Grab timing out. Theoretically the second time I run the script, the file is in the cache, and things happen faster, thus it doesnt fail.
For the above real request, I can see about 20 seconds of elapsed time in the http log from request to download.
Questions:
Does my theory seem correct?
Is there a way to increase the amount of time that the script will wait for the #Grab to resolve?
Does putting a try / catch block around the #Grab statements seem like a good idea? Or will that just hide the real problem?
thanks in advance!!!!
I think I finally figured out the answer to my own question.
I believe there is some sort of bug within Groovy 1.8.4 (or Ivy 2.2), especially since this behavior does mirror an ancient documented Ivy bug with this exact error message scheme and behavior.
Upgrading to Groovy 2.3.6 (which includes Ivy 2.3) appears to solve the issue.
I also still have no idea why the jars cannot be deleted, nothing is locking them. I experimented with moving the grape cache to a less secure folder to rule out a permission issue, but this didn't help:
-Dgrape.root=D:\Temp\grapeCache
UPDATE 8/19:
Once we upgraded to Groovy 2.3.6, the error went away, but I then figured out that the jar was no longer being downloaded at all, when using the "1.+" resolver. Something in the defaultgrapeConfig.xml was causing an issue. Everything is finally working properly after (in addition to the Groovy upgrade) we overrode defaultgrapeConfig.xml with our own stripped down file using this command line JAVA_OPT:
-Dgrape.config=D:\Temp\myGrapeConfig.xml
which had these contents:
<ivysettings>
<settings defaultResolver="downloadGrapes"/>
<resolvers>
<chain name="downloadGrapes">
</chain>
</resolvers>
</ivysettings>
ALSO:
For completeness (further steps):
In Jenkins GUI, update the job(s):
a. Update the drop down for each script: Execute Groovy Script > Groovy Version > Groovy-2.3.6
b. Update the JAVA_OPTS for each script (have to click the ‘advanced’ button under the script to see JAVA_OPTS):
-Dgrape.config=D:\Software\SfGrapeConfig.xml
Optional logging switches: -Dgroovy.grape.report.downloads=true -Divy.message.logger.level=4
In the actual Groovy script itself, delete this option within the #GrabResolver annotation: , m2compatible = 'true'
If you get this or a similar error:
"could not find client or server jvm under [Whatever JAVE_HOME is], please check that it is a valid jdk / jre containing the desired type of jvm"
Delete groovy.exe & groovyw.exe from D:\Software\Groovy-2.3.6\bin (if the exe’s do not exist, the Jenkins groovy plugin will use the bat file versions of these, and they handle the 32-bit / 64-bit problem better than the exe’s)

Resources