Related
I've to audit the code-architecture quality and maintainability (in the end to be sure we have what we paid for) a Java EE web project based on JSF/CDI/EJB3.0/JPA (just to name some of the technologies involved).
This may not be the right place to ask but how do you deal with this kind of task?
Basically, I would proceed from coarse-grained to fine-grained, i.e. from the whole architecture to the java code.
Is it better to deal with each layer completely?
Should I spend more time on the low-level layers?
Do you assess the whole thing (build, deployment, test)?
At the lower physical/implementation level, what I like to do is adopt maven as a build tool, and then configure the extensive maven reporting, to produce a website full of various code metrics.
For starters there is the maven checkstyle plugin which can report on code conformance to a specified standard, consistency in coding standards has many obvious benefits, most projects would simply adopt one of the pre-configured standards e.g. sun or apache.
The findbugs plugin lists potential programming errors
There are a choice of code coverage reports, I've used cobertura. These show line for line in an application which parts are covered by unit tests. Maven supports unit tests in the build life-cycle, running them as part of the build. This has saved me a few times.
The PMD plugin identifies duplicated code, and highlights areas that may need refactoring.
Once this is setup and becomes part of the normal build cycle, it basically takes care of itself, and you won't have to worry about doing large bi-annual audits/catch-up.
Many of the reports have threshold limits that can be configured to fail the build if breached, i.e. more than n% checkstyle errors, cause a build failure.
Maven also promotes a modular approach to building applications, this results in smaller more understandable and re-usable modules, as well as separation of concerns, i.e. separate modules for presentation and persistence layers. The main benefit that maven provides is managing the inter-dependencies between the modules.
This doesn't help you very much at the higher-level architecture layers though, so a complementary approach will be required to cover that dimension.
See some sample reports at this link
http://maven.apache.org/plugins/maven-dependency-plugin/project-reports.html
To help in the code level audit and probably in project health too one software that can help is SONAR... it's very simple to setup just some maven commands, comes with a lot of proven code standards like code quality, reusability, bad practices measurements and so on...
it Runs on your project SVN or CVS and generate a website with graphics represent past and current status of the metrics it's creating, so you can navigate the project data and keep track of the improvements or faults.
It also uses all those maven and maven plugins listed in the other answer like cobertura, find bugs etc...
http://www.sonarsource.org/
Just download and point to your Repo.
In addition to the lower-level code metrics and static analysis already mentioned, I'd add a tool like Structure101 to help analyze higher-level structure and dependencies. It can also help in refactoring the same.
Identifying clusters of dependencies can help determine if the app was written with separation of concerns and modularity in mind, and can help identify potential pain points when considering extension or modification.
Be sure to break it down into areas of concern and address them individually. Areas I can think of to consider are:
Conformance to specified requirements (hopefully these are specific)
Performance/scalability
Code quality (including conventions you want followed)
Test coverage
Plugin/library licenses
It looks like others have addressed items 3 and 4. Since you're asking the question now (presumably after you've received the product) 1 and 2 will probably have to be manual process unless you have automated functionality tests already written (or want to automate tests so you can check future versions of what you bought). 5 is an item that is sometimes overlooked but can be VERY important. You probably don't want GPL code hooked in if you're going to be reselling this software. You need to review the licenses of every library included and decide which ones are compatible with your goals.
To Understand your architecture, you can try JavaDepend it gives the possibility to query code with CQL, like SQL for database, with more than 82 metrics and many interactive views to go deep inside your design, architecture and implementation.
I have a series of eclipse projects that use a bunch of third party jars.
So many are included of different versions.
But I have noticed that some of these libraries, due to code changes over the time, are not used any more but the reference to the library is there.
Is there any plugin that shows the jar dependencies of each project and which I can remove safely?
JarAnalyzer can be used for this purpose.
I am not aware of any plugin or tool that helps in doing what you want to do. However, there may be rules or procedures that help to reach the final end: a reduced set of libraries that is needed and consistent.
I have found the the "Java API Compliance Checker" which allows to compare two versions of the same library. May help to reduce the number of the used libraries for the same purpose. I have not used it, so I cannot tell you about my experience.
Define if it is allowed to have the same kind of library in different version available. Depending on the environment, this may or may not allowed.
Incremental process to reduce the amount of libraries needed:
Remove one library each time from eclipse.
Look if compile errors result from that.
If yes resolve the compile errors.
When all are resolved, start your unit tests (you have unit tests, of course :-)) and see if any unit test breaks.
Do these steps for each library you want to remove.
At the end it could be worthwhile to look at a tool like ivy that allows you to manage the libraries explicitly. Or even switch to Maven which allows you the same.
Final remark: The usage of a library should be
decided by the architect of an application only and
documented in the architecture handbook together with the reasons for doing that.
Try open your Manifest file. You can edit and remove the dependency from there
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'm a junior developer and recently started working for a very small office where they do a lot of in-house development. I have never worked in a project that involved more than one developer or were as big and complex as these ones.
The problem is that they don't use all the tools available (version control, automated building, continuous integration, etc) to their full extent: mainly a project is one big project in eclipse/netbeans using cvs for version control and everything checked in (including library jars), they started using branching for the first time when I started doing branches for small tasks and merging them back. As the projects get bigger and more complex, problems start to arise with dependencies, project structure tied to an IDE, building can be a PITA sometimes, etc. It's hectic at best.
What I want is to set up a development environment where most of these problems will go away and I will save time and effort. I would like to set up projects in a manner independent of IDE used using version control (I'm leaning towards SVN right now), avoid dependency messes and automate building as much as possible.
I know that there are multiple approaches and tools for this and do not want to see a holy war started, I would really appreciate practical recommendations based on experience and what you have found to be useful when facing similar problems. All projects are Java projects and range from web applications to "generic" ones, and I use Eclipse most of the time, but also use Netbeans if needed. Thanks in advance.
You seem to be almost exactly in the point where the place I worked at was when I started there 1,5 years ago, only difference being that you've started toying with branches which is actually something we still don't do at my work but more about that later on in this answer.
Anyway, you're listing a very good set of tools which can help a small company and those work really nicely as subtopics so without further ado,
Version control systems
Most commonly small companies currently use CVS or SVN and there's nothing bad in that, in fact I'd be really worried if no version control was really used at all. However you have to use version control right, just having one won't make your life easier. We currently use CVS and are looking into Mercurial, but we've found that the following works as a good set of conventions when working with CVS (and I'd suspect SVN too):
Have separate users for all commiters. It's beyond valuable to know who commited what.
Don't allow empty commit messages. In fact if possible, configure the repository to reject any commits without comments and/or default comment. Initial commit for FooBarizer is better than Empty log message
Use tags to mark milestones, prototypes, alphas, betas, release candidates and final versions. Don't use tags for experimental work or as footnotes/Post-It notes.
Don't use branches since they really don't work if you're continuing on developing the application. This is mainly because in CVS and SVN branching just doesn't work as expected and it becomes an exercise in futility to maintain any more than two living branches ( head and any secondary branch ) over time.
Always remember that for the software company the source code is your source of income and contains all your business value, so treat it that way. Also if you have extra 70 minutes, I really recommend that you watch through this talk Linus Thorvalds gave at Google about git and (d)VCS in general, it's really insightful.
Automated builds and Continuous Integration environments
These are about the same actually. Daily builds is a PR joke and has little no resemblance to the state of the actual software beyond some very rudimentary "Does it compile?" issues. You can compile a lot of awful code noise that doesn't do anything, keeping the software quality up has nothing to do with getting the code to compile.
On the other hand unit tests is a great way to maintain software quality and I can with a bit of personal pride say that rigorous unit testing helps even the worst of the programmers to improve a lot and catch stupid errors. In fact there has so far only been a total of three bugs that code I have written has reached production environments and I'd say that in 18 months that's a pretty damn good achievement. In our new production code we usually have a instruction code coverage of +80%, mostly +90% and in one special case reaching all the way to 98%. This part is very lively field and you're better of Googling for the following: TDD, BDD, unit tests, integration tests, acceptance tests, xUnit, mock objects.
That's a bit of a lengthy preface, I know. The actual meat for all the above is this: If you want to have automated builds, have them occur every time someone commits and make sure there's a constantly increasing and improving amount of unit tests for production code. Have the continuous integration system of your choice (we use Hudson CI) run all the unit tests related to project and only accept builds if all the tests pass. Do not make any compromises! If unit tests show that the software is broken, fix the software.
Additionally, Continuous Integration systems aren't just for compiling code but instead they should be used for tracking the state of the software project's metrics. For Hudson CI I can recommend all these plugins:
Checkstyle - Checks if the actual source code is written in a way you define. Big part of writing maintainable code is to use common conventions.
Cobertura - Code coverage metrics, very useful to see how the coverage develops over time. Also keeping in line with the "source is God" mentality, allows you to discard builds if coverage falls below a certain level.
Task Scanner - Simple but sweet: Scans for specific tags such as BUG, TODO, NOTE etc. in your code and creates a list from them for everyone to read. Simple way to track short notes or known bugs which needs fixing or whatever you can come up with.
Project structure and Dependency Management
This is a controversial one. Basically everyone agrees that having an unified structure is great but since there's several camps with different requirements, habits and views to issue they tend to disagree. For example Maven people really believe that there's only one way - the Maven way - to do things and that's it while Ivy supporters believe that the project structure shouldn't be hammered down your throat by external parties, only the dependencies need to be managed properly and in an unified manner. Just that it's not left unclear, our company simply loves Ivy.
So since we don't use project structure imposed by external parties, I'm going to tell you a bit about how we got into what we got into our current project structure.
In the beginning we used individual projects for actual software and related tests (usually named Product and Product_TEST). This is very close to what you have, one huge directory for everything with the dependencies as JARs directly included in the directory. What we did was that we checked out both projects from CVS and then linked the actual project to the test software project in Eclipse as runtime dependency. A bit clunky but it worked.
We soon came to realize that these extra steps are completely useless since by using Ant - by the way, you can invoke Ant tasks directly in Hudson - we could tell the JAR/WAR building step to ignore everything by either file name (say, everything that ends with Test or TestCase) or by source folder. Pretty soon we converted our software project to use a simple structure two root folders, src and test. We haven't looked back ever since. The only debate we currently have is if we should allow for a third folder called spikes to exist in our standard project structure and that's not a very heated debate at all.
This has worked tremendously well and doesn't require any additional support or plugins from any of IDEs out there which is a great plus - number two reason we didn't choose Maven was seeing how M2Eclipse basically took over Eclipse. And since you must be wondering, number one reason for rejecting Maven was the clunkiness of Maven itself, endless amount of lengthy XML declarations for configuration and the related learning curve was considered a too big cost as to what we would get from using it.
Rather interestingly later on commiting to Ivy instead of Maven has allowed us to a smooth shift to do some Grails development which uses folder and class names as conventions for just about everything when structuring the web application.
Also a final note about Maven, while it claims to promote convention over configuration, if you don't want to do things exactly the way the Maven's structure says you should do things, you're in a world of pain for the aforementioned reasons. Certainly that's an expected side effect of having conventions but no convention shouldn't be final, there always has to be at least some room for changes, bending the rules or choosing the appropriate from a certain set.
In short, my opinion is that Maven is a bazooka, you work in a house and you ultimate goal is to have it bug free. Each of these are good on it's own and work even if you pick any two of them, but the three together just doesn't work.
Final words
As long as you have less than 10 code-centric people, you have all the flexibility needed to do the important decisions. When you go beyond that, you have to live with whatever choices you've made, no matter how good or bad they are. Don't just believe things you hear on the Internet, sit down and test everything rigorously - heck, our senior tech guy even wrote his bachelor's thesis about Java web frameworks just to figure out which one we should use - and really figure out what you really need. Don't commit to anything just because you may need some of the functionality it provides in distant future, pick those things that has the lowest possible negative impact to the whole company. Being the 10th person hired to the company I work at I can undersign everything in this paragraph with my own blood, we currently have 16+ people working and changing certain conventions would actually be a bit scary at this point.
Our development stack (team of 10+ developers)
Eclipse IDE with M2Eclipse and Subclipse/Subversive
Subversion for source control, some developers also use TortoiseSVN where Subclipse fails
Maven 2 for project configuration (dependencies, build plugins) and release mgmt (automatic tagging of releases)
Hudson for Continuous Integration (creates also snapshot releases with source attachments and reports)
Archiva for artifact repository (multiple repositories, e.g. releases and snapshots are separated)
Sonar for code quality tracking (e.g. hotspots, coverage, coding guidelines adherence)
JIRA for bug tracking
Confluence for developer wiki and communication of tech docs with other departments
Docbook for manuals (integrated into build)
JMeter for stress testing and long-term performance monitoring
Selenium/WebDriver for automated browser integration tests
Jetty, Tomcat, Weblogic and Websphere as test environments for web apps. Products are deployed every night and automated tests are run on distributed Hudsons.
Mailinglist with all developers for announcements, general info mails
Daily stand up meetings where everbody tells about what he's currently doing
This setup is considered standard for our company as many departments are using those tools and there is a lot of experience and community support for those.
You are absolutely right about trying to automate as much as possible. If your collegues start to see the benefits when aspects of the development phases are automated, they will be encouraged to improve on their own. Of course, every new technology gimmick ("tool") is a new burden and has to be managed and maintained. This is where the effort is moved. You save time e.g. when maven automatically performs your releases, but you will waste time on managing maven itself. My experience is that every time I introduced a new tool (one of the aboves), it takes time to be adopted and cared about, but in the end it will bring advantages to the whole team when real value is experienced - esp. in times of stress when the tools take over much of the work you would have to do manually.
A fine, admirable instinct. Kudos to you.
Part of your problem might not be solved using tools. I'd say that source code management needs some work, because it doesn't sound like branching, tagging, and merging is done properly. You'll need some training and communication to solve that.
I haven't used CVS myself, so I can't say how well it supports those practices. I will point out that Subversion and Git would be better choices. At worst, you should be reading the Subversion "red bean" book to get some generic advice on how to manage source code.
Personally, I'm not a Maven fan. I believe it's too heavyweight, especially when compared to Ant and Ivy. I'd say that using those with Cruise Control could be the solution to a lot of your problems.
You didn't mention unit testing. Start building TestNG and Fit tests into your build cycle.
Look into IntelliJ - I think its a better IDE than either Eclipse or NetBeans, but that's just me.
Best of luck.
Maven is great, however, it can have a fair bit of a learning curve, and it requires that the project fits a very specific file structure. If you have a big legacy project, it may be difficult to mavenize it. In that case, Ant+Ivy would do the same without the stringent requirements that maven has.
For build automation, Hudson is beyond awesome. I've used a couple different systems, but that is unquestionably the easiest to get set up and administer.
I recommend to use Maven for building your projects. Using Maven brigns value to the project, because:
Maven promotes convention over configuration what equals a good project structure
thanks Maven plugins eases generating projects for IDE's (Eclipse, Netbeans, Idea)
handles all dependecies and complete build lifecycle
faciliates projects modularization (via mulitimodule projects)
helps with releases/versions burden
improve code quality - easy integration with continous integration servers and lot of code quality plugins
Maven can be a bit daunting given its initial learning curve, but it would nicely address many of your concerns. I also recommend you take a look at Git for version control.
For project and repository management, I use trac with subversion.
Here's what i'm using right now, but i will probably switch a few parts (see the end of this post).
Eclipse as IDE with a few plugins : JADClipse (to decompile .class on the fly, pretty useful), DBViewer for a quick access to database through Eclipse, WTP (Web Tools Platform) integrated into Eclipse for running Tomcat 6 as a developement web server (pretty fast), Mylyn (linked with JIRA bug-tracker).
I'm too wondering about "IDE independant projects", right now we are all sticked on Eclipse - Eclipse project files (.project, .classpath, .settings) are even commited in the CVS repository (in order to have a project fully ready once checked out) - but with Netbeans, supported by Sun and running faster and faster with each release (and each new JRE version), the question isn't closed.
CVS for storing projects, with nearly no branches (only for patches).
I'm working on environment production with Oracle SGBDR but I'm using HSQLDB on my developement computer to make test and build and development process way faster (with the help of the open-source DDLUtils tool to ease database creation and data injections). Otherwise i use SQLWorkbench for quick BD tasks (including schemas comparison) or the Oracle (free) SQLDeveloper for some Oracle specific tasks (like investating sessions locks and so on).
Tests are only JUnit tests (either simple unit test cases or more complex test cases (nearly "integrations" ones), nearly always runing on HSQLDB to run faster.
My build system is Ant (launched from Eclipse) for various small tasks (uploading a war on a remote server for example) and (mainly) Maven 2 for :
the build process
the publishing of the released artefacts
the publishing of the project's web site (including reports)
launching tests campaigns (launched every night)
The continuous integration front-end is Luntbuild, and the front-end for the Maven repository is Archiva.
All this works. But I'm pretty disappointed by a few elements of this ecosystem.
Mainly Maven, it's just too time-consuming and i have a lot of griefs versus this tool. Conflicts dependencies resolution is a joke. Lot of XML lines in every POM.xml, redundant in every project (even with the help of a few POM roots). Plugins are way too inconsistent, buggy, and it's really difficult to find clear documentation explaining what has to be configured, and so on.
So i'm wondering about switching from Maven to ANT+Ivy. For what i've seen so far, it's seems pretty cool (there are various Conflict manager for the conflicts dependencies resolutions and you can even write your own conflict manager), there is no need to have an additionnal tool installed and configured (as ANT is running natively under Eclipse, whereas Maven needs a separate plugin - i've tried the 3 Mavens plugins by the way, and have found all the three of them buggy).
However Maven 3 is on its way, i'll give it a try but i don't expect it to be fundamentaly different from Maven 2.
Hudson would seem a better choice than Luntbuild, too, but this part won't be changed for the now.
And Subversion will probably replace CVS in a near future (even if i nearly don't have any trouble with CVS).
Lots of good advice here. I have just a few additions:
I think that, unlike the rest, an IDE is a personal tool, and each developer should have some freedom to select the one that works best for him. (For example, many love Eclipse, while I ditched it for NetBeans because Maven integration was, uh, problematic in Eclipse.)
I thought I was going to hate Maven, but now I get along with it fairly well. The main problem I have these days is finding out where the conventions are documented.
I would advise introducing tools one at a time. If you try to mechanize all aspects of software development at a by-hand shop in one stroke, there will likely be massive resistance. Make your business case and get agreement on one good common tool, or just get permission to set it up for your use but in a commonly-accessible way and let people see what it does for you. After a few of these, people will develop a habit of wondering how aspect X could be automated, so additional tools should be easier to introduce.
The single most best thing you can do without disrupting other people and their way of working is setting up hudson to watch the CVS repository for each of your project. Just doing that will give a central place to see cvs commit messages.
Next step is getting these projects to compile under Hudson. For Eclipse this typically means either switching to ant or - as we did - use ant4eclipse to model the existing eclipse build process. Not easy but very worthwhile. Remember to send out mails when the build breaks - this is extremely important. Ant4eclipse requires team project sets - introducing them in your organization Will make your colleagues happy the next time they need to set up a fresh workspace.
When you have a situation where your stuff builds properly whenever somebody commits changes then consider making that automatically built code the code to actually go to the customer. As it was built on the build server and not on a developers machine, you know that you can reproduce the build. That is invaluable in a "hey fix this ancient version" situation.
I have a Java project and internally it is dependent on asm jar. Strangely, I don't even know why my project somehow is dependent on this library (might be brought in by maven as a transitive dependency)?
Can anyone help me know why some one needs asm jar?
Thanks in advance !
EDIT:
Can you also mention for what purposes/use-cases one might need asm jar?
ASM is a bytecode manipulation framework (see this page for a nice introduction) and is used by many things performing... bytecode manipulation: frameworks using proxy generation and reflection (Spring, Hibernate, etc), mocking frameworks (EasyMock, JMock, etc), code analysis tools (PMD, Findbugs, etc). Actually, the ASM project maintains a list of users organized by category, check it out.
As mentioned by Vincent, if you are depending transitively on ASM, the dependency:tree goal or the dependency report (see the PMD and Findbugs links above for examples) can help to analyze the situation and to find out from where its coming from. But this won't take into account dependencies of maven plugins that you are using, only dependencies of your project.
Maven-2 requires asm.jar to compile and run the application.
Here for more information.
EDIT:
Due to the many possible usages of program analysis, generation and transfor-
mation techniques, many tools to analyze, generate and transform programs
have been implemented, for many languages, Java included. ASM is one of
these tools for the Java language, designed for runtime – but also offline – class generation and transformation. The ASM1 library was therefore designed to
work on compiled Java classes. It was also designed to be as fast and as small
as possible. Being as fast as possible is important in order not to slow down
too much the applications that use ASM at runtime, for dynamic class gener-
ation or transformation. And being as small as possible is important in order
to be used in memory constrained environments, and to avoid bloating the
size of small applications or libraries using ASM.
ASM is not the only tool for generating and transforming compiled Java
classes, but it is one of the most recent and efficient. It can be downloaded
from http://asm.objectweb.org. Its main advantages are the following:
1) It has a simple, well designed and modular API that is easy to use.
2) It is well documented and has an associated Eclipse plugin.
3) It provides support for the latest Java version, Java 6.
4) It is small, fast, and very robust.
5) Its large user community can provide support for new users.
6) Its open source license allows you to use it in almost any way you want.
Found from this pdf file. I am under the impression that along with Java EE 6 also came a built-in tool, ASM for class generation and transformation. The PDF gives you detail in greater depth about ASM.
Hope this helps.
What other dependencies does your project have ? I suspect one of the jars you've decided you require (e.g. Spring or Hibernate) itself requires asm.jar ?
It is possible to use the dependency plugin for Maven to see which library has asm as a dependency.
Our situation is as follows, but I'm curious about this problem in any situation.
We have a framework consisting of 4 projects:
beans
util
framework
web
We also have modules that need a version and depend on a version of beans and util.
Finally we have a customer project that consists of a specific version of the core projects and one or more modules.
Is there a standard way to version these projects?
What seems simple to me is becoming really complicated as we try to deliver releases to QA and then manage our ongoing development with the maintenance of the release (release = tag and possible branch).
I kind of prefer the following:
1.2.0 - major and minor versions + release.
1.2.1 - next release
1.2.0_01 - bug fix in 1.2.0 release (branch)
etc.
Any ideas?
We use major.minor.bugfix. A major release only happens for huge changes. A minor release is called for when there is an API change. All other releases are bugfix releases. There's definitely utility in having a build or revision number there too for troubleshooting, although if you've got really rigorous CM you might not need to include it.
Coordinating among the versions of all these projects can be done really well with help from tools like Apache Ivy or Maven. The build of one project, with its own version number, can involve the aggregation of specific versions of (the products of) other projects, and so your build files provide a strict mapping of versions from the bottom up. Save it all in [insert favorite version control tool here] and you have a nice history recorded.
I use {major}.{minor}.{buildday}.{sequential}. For Windows, we use the utilities stampver.exe and UpdateVersion.exe for .NET projects that handle that mostly automatically.
There are no standard version number systems. Common themes are to have a major, minor and build number, and occasionally a point number as well (1.2.2.1 for example, for version 1.2 point release 2 build 1). The meaning of the version numbers is highly flexible. A frequent choice is to have backwards compatibility between minor versions or point releases though.
Releases are probably best done by labeling a set of source controlled files as long as your source control allows this. Recreating a release is then as simple as syncing to the label and building, which is very useful :)
In the automated build system i'm currently using I version with Major.Minor.Build.X, where Build is every time we hit system test, and X is the last Subversion revision number from the repo the code is being built from. Seems to work quite nicely for Subversion as we can easily get back to the codebase of a particular build if the need arises.
I use a variation on the linux kernel version numbering system:
major.minor.bugfix
where even minor numbers indicate a somewhat stable release that may be distributed at least for testing, and odd minor numbers indicate an unstable/untested release that shouldn't be distributed beyond developers.
Where possible, I prefer to have projects versioned with the same build numbering, unless they are shared. It allows for more consistency between moving parts and it's easier to identify which components constitute a product release.
As workmad3 has stated, there's really no common rule for build numbers. My advice is to use something that makes sense for your team/company.
Some places I've worked at have aligned build numbering with project milestones and iterations,
e.g: Major = Release or Milestone, Minor = Iteration, Build = Build number (from the project start or from the start of iteration), Revision = If the build has to be rebuilt (or branched).
One of the most common conventions is major.minor.bugfix, with an additional suffix indicating a build number or pre-release designation (e.g. alpha, beta, etc.).
My team numbers builds according to project milestones - a build is handed over to our QA group at the end of a development iteration (every few weeks). Interim CI builds are not numbered; because we use Maven, those builds are numbered with a SNAPSHOT suffix.
Whatever you decide, be sure to document it and make sure that everyone understands it. I also suggest you document and consistently apply the release branching policy or it can quickly get confusing for everyone. Although with only 4 projects it should be pretty easy to keep track of what's going on.
You didn't mention if any of the projects access a database, but if any do, that might be another factor to consider. We use a major.minor.bugfix.buildnumber scheme similar to others described in answers to this question, with approximately the same logic, but with the added requirement that any database schema changes require at least a minor increment. This also provides a naming scheme for your database schemas. For example, versions 1.2.3 and 1.2.4 can both run against the "1.2" database schema, but version 1.3.0 requires the "1.3" database schema.
Currently we have no real versioning. We use the svn build number and the release date.
(tag name is like release_081010_microsoft e.g.)
Older Products use major.minor.sub version numbering
Major never changed
Minor changes on every release/featurerelease every 6 months.
Sub is everything which doesn't affect the feature set - mostly bugfixes.