I am looking at UML tools and see that there are at least two that integrate into Eclipse: Papyrus and Eclipse UML2. How do they compare? The UML2 plugin does not seem to have been updated for several years and there are nearly no followers or questions in the uml-eclipse-plugin tag in stackoverflow for it. Is it superseded by Papyrus? Or at least have most users moved on to Papyrus?
Related
I'm new to fbinfer. I need to integrate my maven project with fbinfer for static code analysis.
Answering this a little late but Sonatype just launched a free Code quality and Software Composition Analysis (SCA) solution called Lift for devs using GitHub: http://lift.dev/
The list of included analyzers includes FBInfer and it takes two clicks (authorize GitHub app) to integrate your Maven application with Lift/FBInfer, thereby eliminating the pain of manually setting up an analyzer.
https://help.sonatype.com/lift/included-analyzers
is there any plugins available for analyzing Ruby code inn sonarqube. I have downloaded Ruby plugin for sonarqube which has just very few rules like six. is there any other plugins for analyzing Ruby in sonarqube.
Thanks.....
I've been looking for the same thing for a while now. It doesn't seem like there's any good support right now outside of ruby-sonar-plugin. SonarQube is a great tool and is awesome for managers to look into and it's a shame that the repo hasn't been updated for 2 years (at the time I'm writing this).
I know this isn't an answer, but it should provide more visibility on the question, at least.
I've haven't looked at SonarQube for some time. The latest version looks quite interesting.
The last time I checked out this product, they had a site where they had pushed various popular open source libraries (like Tomcat, ActiveMQ etc) through the SonarQube process. It was a great way of seeing how the product works.
Is this facility still available for the latest versions?
Have a look at http://sonarcloud.io (and click on "browse").
It is not a demo site - it is a globally available SonarQube server, managed by SonarSource (the company behind SonarQube). Many huge open source projects are managed there for free, but you can also host your own, private projects for closed source.
It gets updated every couple of weeks and for public releases.
Besides that, there is http://next.sonarqube.com , the publicly visible SonarQube server for SonarQube itself and related projects (yes: SonarQube for SonarQube).
This instance gets updated every couple of days. If you want to have a look at what features SonarQube's next version will look like: have a look there.
After a while I installed sonarqube 5.6 today and wondered where the dependency matrix feature is.
I found this SO question, but it is about sonarqube 4.5.
I also searched the update center to see if I must install a additional plugin now, but I had no success.
Does anyone know how to get the package design widget back?
I just found the answer. Sadly the package design widget is not available anymore.
Since sonarqube 5.2...
All design-related features were dropped
See http://www.sonarqube.org/sonarqube-5-2-in-screenshots/ section Also worth noting
All design-related features were dropped in this version (see SONAR-6553 for details), including Package Tangle Index and related metrics.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I work on a project far too big to reside in a single Visual Studio / Eclipse / NetBeans project and we have a "common software" team responsible for developing and maintaining software libraries used by other teams.
I'm struggling with how to manage the development of and changes to the common software. When method signatures and classes change, do I keep the old versions and mark them deprecated? The current plan is to distribute a new build of common libraries every two weeks.
Definitely set up a repository. If you are a Maven-hater check out Gradle, it uses Ivy. Maven has a reputation for being complex but it does have better tool support. IDEs support Maven either out-of-the-box or with plugins, they give you graphs showing what the jars in your project depend on, so you can see conflicts easily.
Either Ivy or Maven will sort out your dependencies so your projects are using the right versions. Each of your projects should list (in the pom.xml for Maven) what version of which of your common libraries that it uses.
A common feature of most version control systems is the use of external branches. Common software is fetched from a shared repository and integrated in each project on update.
A key difficulty lies in documentation changes to the public API of common software and I see two solutions : good communication of deprecated signatures adn continuous integration where finding out deprecated methods can prove painfull.
There are a few options you can have.
Option A: use a repository
For Java based systems I would recommend that you use Ant+Ivy or Maven and create an internal repository with the code in those common projects.
Option B: Classpath Project
If setting up a repository is too much, what you can do is a create an eclipse project called classpath with the following three directories in it
classpath\
docs\
sources\
jars\
The team working on the common project can have a build script which complier the common code and places it into the classpath project, all that the rest of the dev team need to do is checkout the classpath project and reference the files in it during development.
Personally I am a fan of option B unless there is a full time person dedicated to doing builds in which case I go for option A.
The way to manage changes in method signatures is to follow a common version convention so when you do a major version number increase you can say dependent code will have to be changed, and if it is a minor version number increase then dependent code does not need to change. marking code as deprecated is a very practical option because IDE and build systems should issue warnings and allow the coders to switch to newer versions. If the same team is changing the common code and the main project then you will need to have the actual eclipse projects all checked out in the same workspace so that re factoring tools can do their job.
Unless the code in common will be used across across many projects I would keep it in all in one project, you can use multiple source folders to make navigating to various parts of the code easy. If you are having trouble with developers checking in stuff that is breaking things, then I would recommend you have more frequent checkins or have developers work on branches where they merge from the trunk to their work branch frequently to eliminate sync problems, when done they can merge from the branch back to the trunk, the latest version of subversion have decent support for this, and DVCS source control systems like mercurial, and git hub are excellent at this.