I am using SonarQube 4.0 . I try to created a project and run sonar-runner successfully I could see most metrics there.
But when I try to add widgets for LCOM4, RFC and Package design (to show the package tangle index), it shows "No data".
I am not sure what's wrong with my configuration, should I turn on some configuration or install some additional plugins to show LCOM4, RFC and Package tangle index?
I am running sonar-runner on plain file folder (not from SCM , didn't have POM file) , not certain if this is the cause.
If anyone has idea about this problem?
You must analyze .class files.
If you have not already done it, here is the parameter to add to your analysis configuration
# Comma-separated paths to directories with binaries (optional), in case of Java - directories with class files
sonar.binaries=build/classes
Related
I have a basic ReadTheDocs repository. As per the advice of the build page, I sought to use a .readthedocs.yml to configure it:
Configure your documentation builds! Adding a .readthedocs.yml file to your project is the recommended way to configure your documentation builds. You can declare dependencies, set up submodules, and many other great features.
I added a basic .readthedocs.yml:
version: 2
sphinx:
builder: dirhtml
fail_on_warning: true
and got a build failure:
Problem in your project's configuration. Invalid "sphinx.builder": .readthedocs.yml: Your project is configured as "Sphinx Html" in your admin dashboard, but your "sphinx.builder" key does not match.
This was surprising as it seemed contrary to the guidance in the admin dashboard at https://readthedocs.org/dashboard/PROJECTNAME/advanced/ which led me to assume that I could set whatever I liked in the admin dashboard, but it would be overridden by my .readthedocs.yml (which is the behaviour I expected and wanted):
These settings can be configured using a configuration file. That's the recommended way to set up your project. Settings in the configuration file override the settings listed here.
I updated the setting in the admin dashboard to match the .readthedocs.yml and then got a build error:
Sphinx error:
master file /home/docs/checkouts/readthedocs.org/user_builds/PROJECT_NAME/checkouts/latest/source/contents.rst not found
which looks like https://github.com/readthedocs/readthedocs.org/issues/2569 (RTD not finding Sphinx configuration) - but it's not clear why that's happening because prior to adding .readthedocs.yml, the project built just fine.
I'm struggling to model what's actually going on here:
The config file isn't acting as an "overlay" / "override" onto the web settings - as per the first error, some forms of disagreement are a build failure
It's almost like if the config file exists, the web config is ignored - this would explain the contents.rst issue arising, but this isn't consistent with the first error
Adding a python.install entry to .readthedocs.yml eventually got the site building, but it's still not clear to me if I'm generally doing the right thing, and/or how successful future config changes will be.
The reason you're getting the error is that the sphinx version you're using locally doesn't match with the version readthedocs is using at the time you initiated the build process.
See here: You can use a requirements.txt file to use the same version of sphinx you use locally. I had the same issue. I've solved it by simply adding my version Sphinx==3.1.2
Also, I added a .readthedocs.yml file in my project directory where docs/ resides, pointing to where the conf.py because
I was using an extension sphinxcontrib.napoleon which readthedocs build process fails to recognize.
Wanted readthedocsbuild process to use a specific version on Sphinx.
# .readthedocs.yml
# Read the Docs configuration file
# See https://docs.readthedocs.io/en/stable/config-file/v2.html for details
# Required
version: 1
# Build documentation in the docs/ directory with Sphinx
sphinx:
configuration: docs/source/conf.py
# Build documentation with MkDocs
#mkdocs:
# configuration: mkdocs.yml
# Optionally build your docs in additional formats such as PDF
formats:
- pdf
# Optionally set the version of Python and requirements required to build your docs
python:
version: 3.7
install:
- requirements: docs/requirements.txt
a
and added all the dependencies needed to generate the documentation in docs/requirement.txt
Babel==2.8.0
imagesize==1.2.0
readme-renderer==26.0
Sphinx==3.1.2
sphinx-argparse==0.2.5
sphinx-rtd-theme==0.5.0
sphinxcontrib-applehelp==1.0.2
sphinxcontrib-devhelp==1.0.2
sphinxcontrib-htmlhelp==1.0.3
sphinxcontrib-images==0.9.2
sphinxcontrib-jsmath==1.0.1
sphinxcontrib-napoleon==0.7
sphinxcontrib-qthelp==1.0.3
sphinxcontrib-serializinghtml==1.1.4
I'm quite confused as to how to create a deployment in SSIS 2008 that I can use throughout the various sites we are going to deploy to. I'm using the deployment utility to deploy my ETL packages which are file based and executed using a SQL job.
When I rebuild my solution, the deployment files are created along with their configuration files which I bind my connection strings to. I've discovered that each of the packages are still referencing the configuration files in my project folder, rather than the configuration files in the deployment folder. I thought that when I created a deployment, the paths referencing the configuration files would be relative paths.
Ideally, what I would have liked to have been able to do would be to copy the contents of the deployment folder to a flash drive, plug it in at the site I'm deploying to and edit the configuration file per the customer site, execute the deployment manifest file in the folder and expect everything to work. But this doesn't seem to be the case.
I also notice that the SQL job has an option to specify the configuration files for the packages, but this doesn't seem to have an effect either. I must clearly be doing something wrong here, please could someone assist.
Seems like you are encountering these two issues with SSIS deployment and execution:
Configuration file references are stored with absolute paths (meaning the concrete path used in the development environment when the configuration file reference was created, and in production this is the same path that will be used).
Specifying a different configuration file at runtime in SSIS 2008 cannot override values specified at design time (see Understanding How SSIS Package Configurations Are Applied at Run Time).
To deploy your packages with a simple file copy the way you describe, you must change your packages to use a relative reference to your configuration files:
Right click the package file and select View Source to open the XML view of the package source. Search for your configuration file, which will include the path, and remove the path; keeping only the filename portion. Alternatively, change the absolute path to a relative path to the configuration file. Save and close the XML view of the package.
Now when you deploy the package and the configuration file together, ensuring they have the same relative location to each other, the package will find the config file by the relative path, and work the way you expect.
Note: from this point forward you will need to open the BIDS IDE by double-clicking on the project or solution file. If you launch Visual Studio, and then open the project or solution from within the IDE, the IDE will not be able to find the configuration file when you execute the package (the current directory will be Windows\System32, not your package folder).
I am trying to install RMySQL on my mac (mavericks) and it errors out when I try to build it from source, saying:
Configuration error: could not find the MySQL installation include
and/or library directories. Manually specify the location of the
MySQL libraries and the header files and re-run R CMD INSTALL.
INSTRUCTIONS:
Define and export the 2 shell variables PKG_CPPFLAGS and PKG_LIBS to include the directory for header files (*.h) and
libraries, for example (using Bourne shell syntax):
export PKG_CPPFLAGS="-I"
export PKG_LIBS="-L -lmysqlclient"
Re-run the R INSTALL command:
R CMD INSTALL RMySQL_.tar.gz
I tried to follow the instructions by entering:
export PKG_CPPFLAGS="-I/usr/local/mysql/include" export
PKG_LIBS="-L/usr/local/mysql/lib -lmysqlclient"
but when I re-run RMySQL it still doesn't work. Moreover, if I type
$PKG_LIBS
to see what that variable holds, I get
-bash: -L/usr/local/mysql/lib: No such file or directory'
I know that /usr/local/mysql/lib exists and it does contain a mySQL header. Am I misunderstanding the instructions?
I'm asking here only after a lot of effort to find solutions and/or work arounds. Sucks being a noob sometimes.
I am going to assume you're trying to get RmySQL to run on R 3.1.0 on Mavericks? Rather than worry about exporting variables etc, here is a simple clean solution for you that should avoid the headaches.
The RMySQL install link Pascal provided above really is your solution. You're probably just stumbling on syntax, or getting things to work from the terminal.
Even if you're a "noob", you should be able to get this working. I'll try to offer a "dummy's guide" walk through here, as I bet there are many others who have this problem too, even after trying to read the RMySQL installation readme.
I would bet with very high confidence the problem is just that you aren't specifying correctly the locations of the library and header folders for compiling. Read the errors carefully when you try to compile... the errors will probably tell you a file/header is missing, or some .so file (shared object) is missing.
One simple way compile RMySQL from source on R 3.1.0, mavericks is as follows (this does not require you to set any environmental variables, no editing of the Renviron file, etc):
Does MySQL work by itself? i.e. Can you open/run it no problems? If not, fix that first.
Find the precise location of your mysql installation. For me, on Mavericks, I see mysql installed at /usr/local/mysql-5.6.17-osx10.7-x86_64 (your version number may be different). There is also another folder /usr/local/mysql which is an alias to /usr/local/mysql-5.6.17-osx10.7-x86_64 (/usr/local/mysql finds the current version of mysql you are using, if multiple mysql file folders exist, I think). In this directory, I see two sub directories (among many) called "include" and "lib". Take a look; "include" will contain header files (include as in #include , etc, in simple C++ programs). The "lib" folder contains compiled source code of the mysql library.
An easy way to compile and install RMySQL which doesn't exactly follow the suggested way to do it in the installation guide is this. Note that this is doing the same thing as in the installation guide, just a little easier as it's one command line from the terminal, once you know where your mysql install folder is. Go to the terminal, and type the following exactly, with one space between each chunk (with your mysql folder name adjusted appropriately for the version number):
PKG_CPPFLAGS="-I/usr/local/mysql/include/" PKG_LIBS="-L/usr/local/mysql/lib/ -lmysqlclient" R CMD INSTALL RMySQL_0.9-3.tar.gz
OR (the same thing, just more typing)
PKG_CPPFLAGS="-I/usr/local/mysql-5.6.17-osx10.7-x86_64/include/" PKG_LIBS="-L/usr/local/mysql-5.6.17-osx10.7-x86_64/lib/ -lmysqlclient" R CMD INSTALL RMySQL_0.9-3.tar.gz
Note for dummies: Make sure when you run this command, that you are doing it from the terminal in the directory that contains the RMySQL_0.9-3.tar.gz file (or whatever the name of your folder is that contains the RMySQL source code)
and RMySQL compiles!
Don't be afraid about trying to compile source code -- it's not just for 'compiled language programmers' or 'computer science graduates'. Most of the time when compiling fails it's just because files are "missing" (there is no corruption on the source code) -- the user hasn't properly specified the locations of the header and libraries (shared objects). Now pull your big boy/girl panties up and just do it .... it's easy.
Notes for people clueless about compiling source code for packages in R:
a) pay special attention to the spacing in the above, otherwise it may not work. Do not have any spaces between the = and the variable/file names (e.g. don't try and have in the above PKG_CPPFLAGS ="-I/usr/local/mysql/include/" as it won't work)
b) When compiling, you want to specify the locations of the header files and the library files and this is what the "-I/ .... " and "-L/ ...." are doing. The -I directory specifies the location of the header files, and the -L the location of the library files. The library files also require the -l[name of library] extension (the -l is short for -lib in the library object names).
c) Note that in the directory /usr/local/mysql-5.6.17-osx10.7-x86_64/lib/ I do not see a file called "lmysqlclient", or even "libmysqlclient", but I do see files named (among others) "libmysqlclient.a" and "libmysqlclient.18.dylib". So don't worry about your MySQL installation not being correct if you don't see a file just called "libmysqlclient" in the lib folder.
I've configured my SSIS configuration to load from an XML file. When I run the package with dtexec, I specify a different configuration file for each country I'm processing. In Visual Studio I specified this as France.dtsConfig (I have to choose one and this was the first one).
When I run the package with dtexec /FILE Import.dtsx /Reporting V /ConfigFile "C:\Italy.dtsConfig" I still see the output telling me that "The package is attempting to configure from the XML file France.dtsConfig".
I thought I could override the configuration by providing a different dtsConfig file for each country. Is this possible? What am I doing wrong?
I am using SQL Server 2008 R2 and I was getting the same issue with the Configuration override apparently being ignored. I found the trick I needed was to remove the XML config setting from the package (Package Configurations), and then when running the package the XML configuration file you specify is applied. There is however no message emitted about using the file (and since you removed the XML configuration definition from the package, that message is also not emitted).
MSDN has an explanation (go to section "Understanding How SSIS Package Configurations Are Applied at Run Time") that at first didn't make sense to me, but after finding that not having an XML configuration file defined gives the desired result, I can see what it is trying to say.
In my case I was using the XML file to set the instance name of the server on which the [SSIS Configurations] table was found. At design time this was DEVServer in the connection manager object, and I want to override the value to TESTSvr. Following the rules:
"The utility applies the configurations that were specified in the package at design time and in the order that is specified in the package." So the value DEVServer is loaded from the package.
"The utility then applies any options that you specified on the command line." The value in my XML file (TESTSvr) is now loaded. I can supply any filename I like here, and it will be loaded (be it France or Italy).
"The utility then reloads the configurations that were specified in the package at design time and in the order specified in the package. ... The utility uses any command-line options that were specified to reload the configurations." Note the second part of the rule, about using the command line values. Since we currently have set the server to TESTSvr, this value is now used to load the other configuration values from the [SSIS Configurations] table that you want.
I don't have a reference to an article that documents this behaviour, but I have confirmed it. If the file specified as the configuration file in the package configurations is available at run time, it will be used in preference to the one specified on the command line.
In my experience and my opinion, this is contrary to normal behaviour where specifying something in a command should override the built-in default.
To use the configuration file specified in the dtexec command, rename or delete the file that is specified in the Configuration String of the XML configuration file in the Package Configurations Organiser.
Found a way!
In the designer simply uncheck the "Enable package configurations" option under SSIS -> Package Configurations, and save.
dtexec will still honour the supplied configuration file on the /conf switch, but it will no longer attempt to use the design time configuration file even if is accessible.
I still agree that this is strange behaviour, and that the /conf should override design time settings no matter what.
This should work
/CONFIGFILE "C:\Italy.dtsConfig" /REPORTING V
Specify the complete config file location within double quotes
Edit :
When you have deployed your package in MSDB then the command to execute the package is
DTEXEC /SQL "\Package.dtsx" /SERVER "Server Name"
/CONFIGFILE "C:\Italy.dtsConfig" /REPORTING V
Else if you have deployed in File System then
DTEXEC /f "Physical Package Location"
/CONFIGFILE "C:\Italy.dtsConfig" /REPORTING V
Check whether you are pointing to the correct package
MSDN
You can use the /ConfigFile option to load additional configurations
at run time that you did not specify at design time. However, you cannot
use the /ConfigFile option to replace configured values that you also
specified at design time
I have an SSIS 2008 Package that imports some data and then writes out a text file to a local folder on the computer. Everything built, deployed and installed fine, and in my XML configuration file I have a property to set the location of the local folder. I also use an operating system Environment Variable to redirect the location of the XML Configuration file at run time. On my development machine I set the drop-off folder location to C:\Temp, but on the target computer I want this drop-off folder set to E:\SSIS\FileDropOff and I make that configuration setting change at install time. The setup for everything looks fine to me, configuration file looks ok, there were no warnings or errors in the validation check at install time, the Environment Variable is pointing to the right place, and the SSIS Package is installed in the SQL Server MSDB database.
The problem is when the SSIS Package runs on the target computer, it keeps writing the text file to C:\Temp. No matter what I do I can't seem to get it to write to the E:\SSIS\FileDropOff folder. It's like the SSIS Package is stuck on C:\Temp and is ignoring the the XML configuration file setting on the target machine. In the SQL Agent running the SSIS Package I even tried checking the box on the Job Step Properties screen, Data Sources tab and set the Connection String to E:\SSIS\FileDropOff and it still doesn't work.
Is there any place I could be missing where the SSIS Package is looking at C:\Temp? Could there be a cached value someplace that I am not aware of that forcing the package to stick on C:\Temp?
Thanks.
1.) Try restarting your SQL Agent Service. If I remember correctly, it caches environment variables.
2.) Try setting up a package variable and using that to set the connection string instead of the xml file directly.
I believe it's a common mistake when moving between environments (i.e., dev - test - prod) to forget to right click on your package in the new environment and select the latest XML config file. So what's happening is your package is still looking at the old XML config file. You need to right click, and choose to browse and open the one intended for the specific environment.
Make sense?
If you didn't do this you may have unintentionally overwritten your config file.