TL;DR -> Force code smells to apear as SonarCloud issues on IDE
I got SonarLint plugin (vscode) installed locally and configured with external SonarCloud rules (by my organization's project).
The thing is even though it is well configured, some issues fail to count as an acttual issue locally on my IDE and only apears online (e.g. github integration).
I have not yet realized what is common between those slippery sonarcloud issues, might be code smells.
I have seen some StackOverflow questions regarding that matter, but have not yet encountered an answer which explicitly suggests a workaround or a method to configure it as I wish.
Did anyone ever manage to work it out?
Related
In our team we have a number of APIs specified using the Open API Specification (formerly Swagger). We use Maven and OpenAPI Generator to generate code, build and publish the artifact to our local nexus. We build our code on TeamCity. The artifact is given the version that is specified in the pom.xml file of Maven.
During development we only use snapshot versions, that is versions which can be overwritten and will be cleaned up. This is opposite to release versions, that cannot be overwritten and needs administrative privileges to clean up. The reason for this is, that a developer usually changes a little bit at the time, which is much more convenient with snapshot versions. This also makes cleaning up outdated unreleased artifacts much easier.
Our problem is, that from time to time a developer makes API changes but forgets to set a new version. This works fine locally, but when the code is build on TeamCity the changed API overwrites the artifact of an older version. A developer not working on this branch will then experience a compile error, because the code does not match the API artifact being used.
What does others do? Is there a best practice? Preferably with standard tools. We have tried many things and nothing works well. At the same time this issue is so basic that someone must have a good solution - or at least experience enough to point to the least bad solution.
Can I change the default precompilation location to something different than ~/.perl6? I want to allow for using different versions of Rakudo-Star on my system without having to totally remove this directory each time I switch versions (i.e. to avoid precompilation issues).
There is absolutely no reason for you to remove ~/.perl6. The whole precompilation management system was specifically designed for being able to share installed modules between different versions of rakudo. Everything should just work fine without any user intervention.
If you do come across issues, that's bugs we want to fix. So please report those issues to rakudobug#perl.org or on the #perl6 IRC channel. Feel free to alert me (nine) on the IRC channel about those.
I recently installed SonarLint in IDEA 2016.2 and it has been very helpful, but one minor annoyance is the banner for a minor issue won't go away. I realize that this is an issue that needs to be addressed, but I can't control the Sonar project settings and updating all these files would involve doing a huge commit. I know how to disable the syntax highlighting for minor errors, but how to disable the banner?
Currently, that's not possible.
The plan is to track issues when connected to a SonarQube server and hide issues that are marked as resolved: https://jira.sonarsource.com/browse/SLI-83
In your case, you wil be able to mark all minor issues in those files as "won't fix".
I've used DCEVM hotswap technology in eclipse and IntelliJ IDE which was pretty cool feature. By using DCEVM in IDE what I can do is, I can change into the source code i.e add/remove/edit method, classes, properties at the runtime without doing restart the program.
Now my question is:
I want to apply the same features in my running application which is run without using any IDE. To be more specific the running applications source code(compiled code) can change on the fly. And for that bytecode how to deploy on DCEVM for runtime hotswapping?
What I've found is:
We can do hotSwapping without using IDE for that we can write own JNI code to directly hook into JVMTI and trigger a hotswap.
any idea/help would be much helpfull. thanks
Fortunately I found the solution.We can use the HotSwapper plugin to solve this kind of problem. The same question is asked in dcevm discussion forume:
https://groups.google.com/forum/#!topic/hotswapagent/Uk3cUdkHNYQ
Although the information from this link https://news.ycombinator.com/item?id=3198497 is very helpfull but it was asked four years ago, so that I was stuck in.
Now the DCEVM is being more smart It can support various plugin such as Hotswapper, AnonymousClassPatch, WatchResources, Hibernate, Spring, Jersey2, Jetty, Tomcat, ZK, Logback, JSF, Seam, ELResolver, OsgiEquinox and even we can write own plugin too which is more easy to develope.
i am build forge as build tool. it is executing maven mvn commands fine ,but it couldnt recognizing the maven project pom.xml to run the build.so i tried to execute the same pom.xml through the command window and that is working fine could any one can help me how to solve the issue
i am using maven 2.09 version and build forge 7.1
is there any compatibility issues with maven if so what are they
thanks Dagg
I'm not sure you'll find more Build Forge knowledge here on SO (but I may be wrong) than on the forum where you posted the same question :) Build Forge doesn't seem to be very popular actually (and its forums not very active). That said, according to this message, it should be possible to kick off a maven project but, according to other messages from the same thread, the support seems limited and you are "on your own".
In your case, my guess is that maven is not started in the right "working directory" (or it should be able to find the pom). But this is just a guess, I don't have any BF knowledge (lucky me).
To be honest, you should consider talking to your IBM commercial guy or to IBM support or, if this is an option, just using something else than BF unless it's really providing value. Maybe your organization will thank you after all.