I have a large number of individual, unrelated Java programs in a "Programs" folder, and I'd really like to be able to calculate a technical debt score automatically for each individual program. I understand that SonarQube can allow you to do this (kind of) with Sonar-Runner, however I would really like a way to do this dynamically, so I can have a script analyze and write technical debt scores of all the programs within the "Programs" folder into a csv.
I am perfectly willing and happy to try any other sort of technical debt software (or quality for that matter) if it can do this for me. I would just really appreciate any input, or thoughts about if this would even be possible?
Yes you can, Sonar is a code analysis tool and has plugins that can even estimate technical debt in man hours or dollars. Really easy to setup and run, you just download it, extract it and start (comes with an internal DB, so no extra dependencies of configurations required). Then if you use maven, you add this to your pom.xml:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>sonar-maven-plugin</artifactId>
<version>2.0</version>
</plugin>
and run:
maven sonar:sonar
Sonar will then show you all sorts of useful info about your code, include technical debt.
------ Update 1 ------
If you have multiple projects (assuming they are maven), you can make them all children of one parent project and run mvn sonar:sonar on the parent, it will analyze all the children for you. Here is an example of multiple projects.
The Eclipse Metrics plugin may get you close to what you're looking for. It'll give you a health check on your projects by reporting on different types of complexity (coupling, cyclomatic complexity, cohesion, length of methods and so on).
From their page:
This Eclipse plugin calculates various metrics for your code during build cycles and warns you, via the Problems view, of 'range violations' for each metric. This allows you to stay continuously aware of the health of your code base. You may also export the metrics to HTML for public display or to CSV or XML format for further analysis. This export can be performed from within Eclipse or using an Ant task.
http://eclipse-metrics.sourceforge.net/
These answers were all great, but not exactly what I was looking for. I was able to create my own work around:
When I'm creating the java projects, I have a java class that automatically writes a sonar-properties.properties file to each individual project.
I then start the sonar server (through command prompt)
I then wrote a script that drills through directories looking for the sonar-properties.properties files. When if finds one, it launches sonar-runner.
Note, The properties file has a project key that corresponds to the project (so each project I'm trying to analyze has it's own project key) - and so then I can simply go to localhost and see a link for each properties file I created.
Related
I'm developing a struts2 webapp for months now using maven to manage my dependencies and I've just discovered LESS. I have installed and configured the LESS plug-in for Eclipse but it's really annoying to right click > run as > LESS compiler every time I save the .less file due to a modification of its content or something...
The thing is that I've been researching on how to plug in grunt.js (recently discovered task runners too) into maven (as explained here) but I think it's quite hard and I wondered if somebody knew an alternative to this.
In my struts2 project I have both the front and back-end of my webapp.I know it's not the right approach and if I could start all over again I would separate them into two different projects, but now it's too late (disadvantages of the learning proccess, we're not born knowing it all).
Having said all this, how can I set up a kind of task for watching my .less files and automatically compile them into .css when saved/changed?
I also found this ant task here, but I dont really know if it's what I'm looking for.
There are a lot of Java Less compiler (see Java Compiler for Less CSS?), so you can execute one of them by your build tool (e.g. Ant - maybe you need to write a simple Java application, which use the chosen compiler).
If you use Maven (or can switch to it) to project management, then you can use one of lesscss-maven-plugin:
biz.gabrys.maven.plugins:lesscss-maven-plugin
org.lesscss:lesscss-maven-plugin
see more...
It is possible to create an ant task to compile certain .less files into CSS whenever they are modified, and more or less is what I was looking for, but grunt seems to be more flexible as you can tell it to watch all your files with .less extension and in this solution I've found you have to declare in an .xml file the .less files you want ant to watch.
This is not explicitly what I was looking for so I'll leave this question open for now as I'll keep researching on how to make this solution more dynamic and see if it is possible to avoid the fact of defining every .less source and .css target you want.
Link to solution here
In a Java project I'm working (alongside a team of 8 devs), we have a large backlog of features that lack automated tests. We are covering this backlog and we need to keep track of who wrote a JUnit test and when, plus we have to measure how many test we wrote as a team in a week/month/semester (as you may have figured out already, this information is for management purposes). We figured we'd do this by marking the tests with the information we need (author, creation date) and let Eclipse do the processing work, showing us tests we wrote, who wrote'em and how far we were from reaching our goals. How would you smart people go about this? What plugins would you use?
I tried to use Eclipse Custom Tags for this, but it's not the purpose of the feature, and the results I got were kind of brittle. I created a TEST tag that was supposed to mark a test method. It looks like this: (date is mm-dd-yyyy)
//TEST my.name 08-06-2011
Since Eclipse processes tag description by substringing (contains/doesn't contain), it's, as I said, very brittle. I can timestamp the tag, but it's just a string. Eclipse can't process it as a date, compare dates, filter by date interval, stuff like that.
I searched for plugins, but no dice.
My B-plan is to create an Annotation with the information we need and process our test packages using Eclipse Annotation Processing Tool. I haven't tried anything on this front yet, though, just an idea. Anyone knows a good plugin for this kind of Annotation processing? Or any starter tips for dealing with Eclipse APT.
Thanks a bunch, folks
I would not use Eclipse for this.
Your team should be checking the tests into a version control system such as Subversion, Git, Team Foundation Server, etc. From there it should a fairly straightforward matter to determine the owner and check-in time. You can and should do this sort of metrics calculation during every build. Better yet, be sure that your build script actually runs your tests and uses a tool like EMMA to instrument the code and determine the actual coverage.
As a fallback for measuring coverage, if you choose a naming convention then you may even be able to correlate the test classes by file name back to the feature under test.
Many modern build systems, such as CruiseControl, have integration for doing these sorts of things quite nicely.
Context
big project with multi maven module or single maven module structure
Question
did you finally use multi-maven-module or single-maven-module structure?
Details
If you've worked on a big project that had long development duration and contains lots of functionality(i.e. not a trivial project), did you choose to split the project into multiple maven modules or went with the single-module approach?
For example, having a multi-module structure, crashes when running maven commands like mvn gwt:eclipse(see http://bit.ly/gs4Rmo). I guess this would have worked well with single module GWT project. And there could be other commands like the above that has issues with multi-module structure.
However, the multi-module structure could bring the benefits of a faster development, i.e. if you separate the "server" from "client" module, you could compile the business logic(server) separately and package it into resulting web archive. Compiling the GWT code, takes about 20 seconds, so if you only modify the server package, it could save you lots of time in the long run.
Which other cases like the one above did you encounter when working with a multi-module/single module project?
Thank you!
A few notes:
On development server you don't have to compile the code "by hand": dev server compiles the code automatically and reloads it. Just keep dev server running, change some code and then reload the page in browser. (this is only true if you change existing classes and don't change project structure)
Multiple maven modules have nothing to do with multiple GWT modules.
You would want to have multiple GWT modules (= multiple entry points) if you have code that executes in different environments: for example you have web and mobile sites that have quite different code bases. Then you would split the project into three modules: web, mobile and common. Then you'd reference common in both web and mobile.
Another case for multiple GWT modules would be if you, for some reason, want to have a multiple host (entry) HTML pages. There are rare cases when you'd want this, for example when you need to do redirects when integrating OpenID. The other case would be that you already have existing Web pages where you are only adding GWT to add some functionality.
Don't split the GWT project into multiple modules just to reduce download size: use Code Splitting instead.
If your main gripe is long gwt compile times then read: How do I speed up the gwt compiler?
We started with multiple modules and eventually merged into a single module. The main reason for this was maintenance of modules is a huge overhead. Each module had a pom to build the UI, RPC layer and backend services. So with 30 modules we had 90 maven projects to manage.
Merging the modules turned 90 maven projects into 3 with one parent level pom.
This considerably lowers maintenance overhead and improves build times. GWT's compiler is notoriously slow so having a single compile parsing source files once instead of multiple times makes things much faster.
On the flip side, a single module means the compiler slurps everything up into memory at once. This could make split points intolerably slow to find if you insert any in your code. Therefore if you intend to split, it may be worth considering where you're putting those points and arrange your project accordingly.
I have an application that uses several configuration files (let just consider appli.properties here).
These files contain several values that depend on the environment. We can find some information such as:
server.port=${envi.server.port}
On other side, I have a set of properties files, one per environment (dev.properties, homolo.properties, etc.).
They contain the values for some properties in configuration files. We can find here this kind of properties:
envi.server.port=4242
My build is handled by Maven2. Everything is working fine.
However, I now need to import my project into Eclipse.
My main concern is about the configuration files filtering. Indeed, if I do not modify anything in my Eclipse parameter for my project (after a mvn eclipse:eclipse command), then all my configuration file will keep the property keys (i.e. ${envi.server.port}) instead of their values. And with such configuration files, my application will not run inside Eclipse...
So I tried two solutions:
A full-Maven solution, using m2eclipse plugin. I add a Maven Builder in the project configuration, and then, each time a build is made, the filtering is done on the files.
Ant (which is only used inside Eclipse). I've hardly defined a task that simulates the Maven2 filtering of files in Ant. This task is only dedicated to the filtering, no compilation.
The common problem of these two solutions is that the filtering is made at every operation (essentially saves on Java class edition), and then take time. The second solution is however quicker (3 seconds) than the first one (more than 10 seconds).
What do you think of my approach?
How would you do that, in a better way?
If the resources are not changed that often, you can set the Maven build to only run after a Clean build, then it won't interfere so much, this doesn't do anything to speed up the build however.
As far as making the filtering quicker, I don't know of any other simple mechanism that will help, as you've said you need either Ant or Maven to run the filtering, and they both take some time to set up before building, resulting in the slow down.
If this is causing you a lot of problems, you can write a custom Incremental Eclipse builder that performs the filtering on the deltas. This should be considerably quicker, but obviously a lot more effort to write.
Almost any IDE creates lots of files that have nothing to do with the application being developed, they are generated and mantained by the IDE so he knows how to build the application, where the version control repository is and so on.
Should those files be kept under version control along with the files that really have something to do with the aplication (source code, application's configuration files, ...)?
The things is: on some IDEs if you create a new project and then import it into the version-control repository using the version-control client/commands embedded in the IDE, then all those files are sent to the respitory. And I'm not sure that's right: what is two different developers working on the same project want to use two different IDEs?
I want to keep this question agnostic avoiding references to any particular IDE, programming language or version control system. So this question is not exactly the same as these:
SVN and binaries - but this talks about binaries and SVN
Do you keep your build tools in version control? - but this talks about build tools (e.g. putting the jdk under version control)
What project files shouldn’t be checked into SVN - but this talks about SVN and dll's
Do you keep your project files under version control? - very similar (haven't found it before), thanks VonC
Rules of thumb:
Include everything which has an influence on the build result (compiler options, file encodings, ASCII/binary settings, etc.)
Include everything to make it possible to open the project from a clean checkout and being able to compile/run/test/debug/deploy it without any further manual intervention
Don't include files which contain absolute paths
Avoid including personal preferences (tab size, colors, window positions)
Follow the rules in this order.
[Update] There is always the question what should happen with generated code. As a rule of thumb, I always put those under version control. As always, take this rule with a grain of salt.
My reasons:
Versioning generated code seems like a waste of time. It's generated right? I can get it back at a push of a button!
Really?
If you had to bite the bullet and generate the exact same version of some previous release without fail, how much effort would it be? When generating code, you not only have to get all the input files right, you also have to turn back time for the code generator itself. Can you do that? Always? As easy as it would be to check out a certain version of the generated code if you had put it under version control?
And even if you could, could you ever be sure that didn't miss something?
So on one hand, putting generated code under version control make sense since it makes it dead easy to do what VCS are meant for: Go back in time.
Also it makes it easy to see the differences. Code generators are buggy, too. If I fix a bug and have 150'000 files generated, it helps a lot when I can compare them to the previous version to see that a) the bug is gone and b) nothing else changed unexpectedly. It's the unexpected part which you should worry about. If you don't, let me know and I'll make sure you never work for my company ever :-)
The major pain point of code generators is stability. It doesn't do when your code generator just spits out a random mess of bytes every time you run (well, unless you don't care about quality). Code generators need to be stable and deterministic. You run them twice with the same input and the output must be identical down to least significant bit.
So if you can't check in generated code because every run of the generator creates differences that aren't there, then your code generator has a bug. Fix it. Sort the code when you have to. Use hash maps that preserve order. Do everything necessary to make the output non-random. Just like you do everywhere else in your code.
Generated code that I might not put under version control would be documentation. Documentation is somewhat of a soft target. It doesn't matter as much when I regenerate the wrong version of the docs (say, it has a few typos more or less). But for releases, I might do that anyway so I can see the differences between releases. Might be useful, for example, to make sure the release notes are complete.
I also don't check in JAR files. As I do have full control over the whole build and full confidence that I can get back any version of the sources in a minute plus I know that I have everything necessary to build it without any further manual intervention, why would I need the executables for? Again, it might make sense to put them into a special release repo but then, better keep a copy of the last three years on your company's web server to download. Think: Comparing binaries is hard and doesn't tell you much.
I think it's best to put anything under version control that helps developers to get started quickly, ignoring anything that may be auto-generated by an IDE or build tools (e.g. Maven's eclipse plugin generates .project and .classpath - no need to check these in). Especially avoid files that change often, that contain nothing but user preferences, or that conflict between IDEs (e.g. another IDE that uses .project just like eclipse does).
For eclipse users, I find it especially handy to add code style (.settings/org.eclipse.jdt.core.prefs - auto formatting on save turned on) to get consistently formatted code.
Everything that can be automatically generated from the source+configuration files should not be under the version control! It only causes problems and limitations (like the one you stated - using 2 different project files by different programmers).
Its true not only for IDE "junk files" but also for intermediate files (like .pyc in python, .o in c etc).
This is where build automation and build files come in.
For example, you can still build the project (the two developers will need the same build software obviously) but they then could in turn use two different IDE's.
As for the 'junk' that gets generated, I tend to ignore most if it. I know this is meant to be language agnostic but consider Visual Studio. It generates user files (user settings etc..) this should not be under source control.
On the other hand, project files (used by the build process) most certainly should. I should add that if you are on a team and have all agreed on an IDE, then checking in IDE specific files is fine providing they are global and not user specific and/or not needed.
Those other questions do a good job of explaining what should and shouldn't be checked into source control so I wont repeat them.
In my opinion it depends on the project and environment. In a company environment where everybody is using the same IDE it can make sense to add the IDE files to the repository. While this depends a bit on the IDE, as some include absolute paths to things.
For a project which is developed in different environments it doesn't make sense and will be pain in the long run as the project files aren't maintained by all developers and make it harder to find "relevant" things.
Anything that would be devastating if it were lost, should be under version control.
In my opinion, anything needed to build the project (code, make files, media, databases with required program info, etc) should be in repositories. I realise that especially for media/database files this is contriversial, but to me if you can't branch and then hit build the source control's not doing it's job. This goes double for distributed systems with cheap branch creation/merging.
Anything else? Store it somewhere different. Developers should choose their own working environment as much as possible.
From what I have been looking at with version control, it seems that most things should go into it - e.g. source code and so on. However, the problem that many VCS's run into is when trying to handle large files, typically binaries, and at times things like audio and graphic files. Therefore, my personal way to do it is to put the source code under version control, along with general small sized graphics, and leave any binaries to other systems of management. If it is a binary that I created myself using the build system of the IDE, then that can definitily be ignored, because it is going to be regenerated every build. For dependancy libraries, well this is where dependancy package managers come in.
As for IDE generated files (I am assuming these are ones that aren't generated during the build process, such as the solution files for Visual Studio) - well, I think it would depend on whether or not you are working alone. If you are working alone, then go ahead and add them - they will allow you to revert settings in the solution or whatever you make. Same goes for other non-solution like files as well. However, if you are collaborating, then my recomendation is no - most IDE generated files tend to be, well, user specific - aka they work on your machine, but not neccesarily on others. Hence, you may be better of not including IDE generated files in that case.
tl;dr you should put most things that relate to your program into version control, excluding dependencies (things like libraries, graphics and audio should be handled by some other dependancy management system). As for things directly generated by the IDE - well, it would depend on if you are working alone or with other people.