I want to parameterize the Branch name and load the shared library implicitly.
#Library('my-shared-library/$BRANCH_NAME') _
I am getting the following error message.
'''
org.jenkinsci.plugins.workflow.cps.CpsCompilationErrorsException: startup failed:
Script1.groovy: #Library value ‘my-shared-library#$BRANCH_NAME’ was not a constant; did you mean to use the ‘library’ step instead?
1 error
at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310)
at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1085)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:603)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:581)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558)
at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
'''
Is there any way I can pass the parameter only in the shared library implicitly?
There are two options for loading Shared Libraries, Static loading that occurs before the pipeline script is executed using the #Library keyword, and dynamic loading using the library.
While is static loading you can't use parameters, in dynamic loading you can do so:
As of version 2.7 of the Pipeline: Shared Groovy Libraries plugin, there is a new option for loading (non-implicit) libraries in a script: a library step that loads a library dynamically, at any time during the build.
library 'my-shared-library'
Regarding versions in dynamic libraries:
When using the library step you may also specify a version:
library 'my-shared-library#master'.
Since this is a regular step, that version could be computed rather than a
constant as with the annotation;
For example:
library "my-shared-library#$BRANCH_NAME"
Related
i try use #import is not working。
// a.less
.hello{width:100px;height:100px;background:blue;}
// index.less
#import './a.less'
// App.jsx
import './index.less';
<div styleName="hello"></div>
ERROR:
ERROR in ./src/App.jsx
Module build failed: Error: D:/workspace_js/react-redux-boilerplate/src/App.jsx: Could not resolve the styleName 'hello'.
at styleNameValue.split.filter.map.styleName (D:\workspace_js\react-redux-boilerplate\node_modules\babel-plugin-react-css-modules\dist\getClassNam
e.js:83:15)
at Array.map (<anonymous>)
at exports.default (D:\workspace_js\react-redux-boilerplate\node_modules\babel-plugin-react-css-modules\dist\getClassName.js:66:6)
at exports.default (D:\workspace_js\react-redux-boilerplate\node_modules\babel-plugin-react-css-modules\dist\resolveStringLiteral.js:27:56)
at PluginPass.JSXElement (D:\workspace_js\react-redux-boilerplate\node_modules\babel-plugin-react-css-modules\dist\index.js:183:46)
at newFn (D:\workspace_js\react-redux-boilerplate\node_modules\babel-traverse\lib\visitors.js:276:21)
at NodePath._call (D:\workspace_js\react-redux-boilerplate\node_modules\babel-traverse\lib\path\context.js:76:18)
at NodePath.call (D:\workspace_js\react-redux-boilerplate\node_modules\babel-traverse\lib\path\context.js:48:17)
at NodePath.visit (D:\workspace_js\react-redux-boilerplate\node_modules\babel-traverse\lib\path\context.js:105:12)
at TraversalContext.visitQueue (D:\workspace_js\react-redux-boilerplate\node_modules\babel-traverse\lib\context.js:150:16)
at TraversalContext.visitMultiple (D:\workspace_js\react-redux-boilerplate\node_modules\babel-traverse\lib\context.js:103:17)
at TraversalContext.visit (D:\workspace_js\react-redux-boilerplate\node_modules\babel-traverse\lib\context.js:190:19)
at Function.traverse.node (D:\workspace_js\react-redux-boilerplate\node_modules\babel-traverse\lib\index.js:114:17)
at NodePath.visit (D:\workspace_js\react-redux-boilerplate\node_modules\babel-traverse\lib\path\context.js:115:19)
at TraversalContext.visitQueue (D:\workspace_js\react-redux-boilerplate\node_modules\babel-traverse\lib\context.js:150:16)
at TraversalContext.visitSingle (D:\workspace_js\react-redux-boilerplate\node_modules\babel-traverse\lib\context.js:108:19)
# ./src/index.jsx 14:0-24 28:2-30:4 28:29-30:3
# multi webpack-hot-middleware/client?reload=true react-hot-loader/patch webpack/hot/only-dev-server ./src/index.jsx
this is test demo : git#github.com:ganxunzou/react-redux-boilerplate.git
test setp:
clone git#github.com:ganxunzou/react-redux-boilerplate.git
git checkout css-module-less-postcss
npm i
npm run dev
try use #import is not working。
Mentioned error can be caused by different factors. Firstly, provided webpack.config does not include any loader for .less css-files, so ensure to add appropriate loader into config: https://github.com/webpack-contrib/less-loader
Secondly, styles can be wrapped in independent namespaces, which is useful to avoid collisions between components - so ensure, that generated scope is used property
I'm currently attempting to start a project using JavaCV in Kotlin. I'm using IntelliJ Idea as my IDE. I'm using JavaCV 1.3.2 and OpenCV 3.20.
This is my setup for the module's dependancies for OpenCV:
and for JavaCV:
I have opencv before javacv in the dependancies.
To test that OpenCV is present and valid, I wrote the below to test. As I can loadLibrary and the version number shows correctly I can assume that OpenCV is actually working.
import org.opencv.core.Core
import org.opencv.core.Mat
import org.opencv.core.CvType
import org.opencv.core.Scalar
import org.bytedeco.javacv.OpenCVFrameGrabber
fun main(args : Array<String>) {
println("Test Built Successfully")
System.loadLibrary(Core.NATIVE_LIBRARY_NAME)
println("Running OpenCV Version ${Core.VERSION}")
val grabber = OpenCVFrameGrabber(1)
}
The line where we initialize the grabber rasies the following exception:
Exception in thread "main" java.lang.UnsatisfiedLinkError: no jniopencv_core in java.library.path
Caused by: java.lang.UnsatisfiedLinkError: no opencv_imgproc320 in java.library.path
Perhaps I am missing something here, but I have followed the instructions provided by the README.md in the Git repository for JavaCV. I haven't seen anybody else trying to use this library with Kotlin on StackOverflow, though have checked out some posts about the same exception being raised using java.
Handling this error is no different in Kotlin from Java; you need to specify the path to the native libraries for opencv. By default on Windows it will look for the native libraries in whatever is set in your PATH environment variable.
You can also explicitly specify which directory to look for the native libraries by specifying the system property java.library.path (as indicated by the error message).
For example, you can add a run configuration like this:
Where ${PATH_TO_DYNAMIC_LIB} would be where ever the native lib opencv_imgproc320.dll is - I think in your case it would be C:/Users/ms/IdeaProjects/CVTest/opencv/build/java/x64.
I was able to resolve this by leaving my VM options blank and adding all necessary OpenCV libraries as native library paths in my JavaCV library configuration.
on MacOS, you don't need to install a native library. On OpenCV3.41, as fetched from
<!-- https://mvnrepository.com/artifact/org.openpnp/opencv -->
<dependency>
<groupId>org.openpnp</groupId>
<artifactId>opencv</artifactId>
<version>3.4.2-1</version>
</dependency>
I looked in the library (jar tf ~/.m2/repository/org/openpnp/opencv/3.4.2-1/opencv-3.4.2.-1.jar) and found dlls and whatnot in it:
jar tf *1.jar | grep nu
...
nu/pattern/opencv/osx/
nu/pattern/opencv/osx/x86_64/
nu/pattern/opencv/osx/x86_64/README.md
nu/pattern/opencv/osx/x86_64/cmake.log
nu/pattern/opencv/osx/x86_64/libopencv_java342.dylib
...
This led me to this StackOverflow question on nu.pattern which show how to use the nu.pattern in code.
static {
nu.pattern.OpenCV.loadShared();
System.loadLibrary(org.opencv.core.Core.NATIVE_LIBRARY_NAME);
}
This prologue code enabled sample apps which used to fail as above to run.
I know... Another one of this... But no one else's error is the same as mine and I've been trying to build opencv with mingw32 for days now.
When building OpenCV with mingw the command mingw32-make fails at some point trying to compile sources\modules\ts\src\ts_gtest.cpp with error pic bellow:
I've tried following several tutorials, but none work cleanly and this is the best I could get stuff to work.
What I did:
Installed Mingw and added C:\Mingw\bin\ to PATH environment variable.
Installed CMake and added it too to PATH.
Extracted OpenCV to C:\ and created forlder C:\opencv\mingwBuild\
In CMake-GUI I define source folder as C:\opencv\sources\ and build folder as C:\opencv\mingwBuild\.
Hit Configure and select Mingw Makefiles, with 'Use default native compilers' (have also specified compilers explicitly and the result is the same.).
Hit Generate, which creates the Makefile.
I open C:\Mingw\msys\1.0\msys.bat to have a console with all variables loaded (have also tried directly from a simple cmd.exe, given that PATH is set for mingw, but I get the same error in compilation). Navigate to C:\opencv\mingwBuild\ and run mingw32-make.
And that's where the error shows up after a while. Any ideas?
Turns ou gTest was not compiling in Mingw for some reason.
As I don't intend to test my code (for now) I removed opencv_ts from instalation (by deselecting it in Cmake, after configuring and before generating).
Someone mentions, in the first link #Dan Masek refers, that GTest has this issue with type conversion under mingw. They say that you can edit ts_gtest.cpp to apply the correct conversion, according to error message. That may be a solution if you need this module.
Another comment in #Dan Masek's second link mentions that gcc's version 5 surpasses the issue, which version 4 has. So, getting a hold of such distro may also be a solution.
For me it seems to be fixed by applying this fix: https://github.com/msk-repo01/opencv/commit/9a1835ce6676836ce278d723da4ff55a8f900ff1
(Also see: https://github.com/opencv/opencv/issues/8105)
The fix basically replaces the "_RTL_CRITICAL_SECTION" by "_CRITICAL_SECTION" for MingW compilers in modules/ts/include/opencv2/ts/ts_gtest.h in the following way:
The lines
// assuming CRITICAL_SECTION is a typedef of _RTL_CRITICAL_SECTION.
// This assumption is verified by
// WindowsTypesTest.CRITICAL_SECTIONIs_RTL_CRITICAL_SECTION.
struct _RTL_CRITICAL_SECTION;
(around line 723 in OpenCV 3.2.0 release from Dec. 2016) are replaced by
# if GTEST_OS_WINDOWS_MINGW
// MinGW defined _CRITICAL_SECTION and _RTL_CRITICAL_SECTION as two
// separate (equivalent) structs, instead of using typedef
typedef struct _CRITICAL_SECTION GTEST_CRITICAL_SECTION;
# else
// assuming CRITICAL_SECTION is a typedef of _RTL_CRITICAL_SECTION.
// This assumption is verified by
// WindowsTypesTest.CRITICAL_SECTIONIs_RTL_CRITICAL_SECTION.
typedef struct _RTL_CRITICAL_SECTION GTEST_CRITICAL_SECTION;
# endif
and
_RTL_CRITICAL_SECTION* critical_section_;
is replaced by
GTEST_CRITICAL_SECTION* critical_section_;
If I include compile "org.jasig.cas.client:cas-client-core:3.3.3" in my BuildConfig.groovy, I get a stack overflow as seen below. If I change compile to runtime the error goes away, but I do have dependencies at compile time as well as runtime.
It looks like some kind of circular reference related to logging, and just getting a stack dump like this isn't helpful. How would I fix it?
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:253)
at org.apache.log4j.Category.<init>(Category.java:52)
at org.apache.log4j.Logger.<init>(Logger.java:35)
at org.apache.log4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:59)
at org.apache.log4j.LogManager.getLogger(LogManager.java:42)
at org.slf4j.impl.GrailsSlf4jLoggerFactory.getLogger(GrailsSlf4jLoggerFactory.java:43)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:253)
at org.apache.log4j.Category.<init>(Category.java:52)
at org.apache.log4j.Logger.<init>(Logger.java:35)
at org.apache.log4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:59)
at org.apache.log4j.LogManager.getLogger(LogManager.java:42)
at org.slf4j.impl.GrailsSlf4jLoggerFactory.getLogger(GrailsSlf4jLoggerFactory.java:43)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:253)
| Error Error executing script RefreshDependencies: null
You may have multiple versions of log4j-over-slf4j in your dependency chain. If you run 'grails dependency-report runtime', you will see a list of libs that your app sucks in.
Using transitive=false will exclude all dependencies of the lib, but you could try 'exclude "log4j-over-slf4j"' as a more focused exclude if you have multiple slf4j versions in your dependency chain. E.g.,
compile("org.jasig.cas.client:cas-client-core:3.3.3") {
exclude "log4j-over-slf4j"
}
adding transitive=false made the error go away:
compile("org.jasig.cas.client:cas-client-core:3.3.3") {
transitive=false
}
I'm not clear what I needed to exclude specifically, or how anyone could have figured that out from the stack overflow.
I'm using Grails and want to use groovyws to call an web-service.
But my groovyws.jar (0.5.2) have MANY dependences that I can't solve.
Is there any jar with all dependences included?
Note: I tried put in BuildConfig.groovy, this
dependencies {
'org.codehaus.groovy.modules:groovyws:0.5.2'
}
but I'm getting error:
Error executing script Compile: loader constraint violation: when
resolving overridden method
"org.apache.xerces.jaxp.SAXParserImpl.getParser()Lorg/xml/sax/Parser;"
the class loader (instance of
org/codehaus/groovy/grails/cli/support/GrailsRootLoader) of the
current class, org/apache/xerces/jaxp/SAXParserImpl, and its
superclass loader (instance of ), have different Class
objects for the type org/xml/sax/Parser used in the signature
You can manually exclude xerces by:
dependencies {
runtime('org.codehaus.groovy.modules:groovyws:0.5.2') {
exclude: 'xerces'
}
}
GroovyWS pulls inn CXF, which again pulls in a lot of dependencies, some of them conflicting with classes already present in Java 6. You need to exclude all these dependencies if using Java 6, to avoid errors like the one you mention.
Here's my exclude list:
compile("org.codehaus.groovy.modules:groovyws:0.5.2") {
excludes 'geronimo-servlet_2.5_spec', 'servlet-api', 'jaxb-xjc', 'jaxb-impl', 'xml-apis', 'saaj-impl', 'junit', 'slf4j-jdk14', 'xmlParserAPIs', 'jaxb-api', 'saaj-api', 'xmlbeans', 'jaxen', 'geronimo-stax-api_1.0_spec', 'geronimo-activation_1.0.2_spec', 'abdera-client', 'geronimo-activation_1.1_spec'
}
Note that on Ubuntu you need jaxb-xjc and jaxb-impl after all, don't know why.
I found:
http://docs.codehaus.org/dosearchsite.action?queryString=groovyws+standalone
Tks a lot!
(search for "groovyws standalone")
Note: I saw this tip here.