There’s nothing wrong with the Findbugs plugin for Maven. If you want to scan sub-packages by using the onlyAnalyze option, simply end your package declaration with .-. The manual says so.

To prove either myself or the plugin at fault (though I always assume it’s the former!), I setup a small Maven project with the following structure:


pom.xml
src/
main/java/acme/App.java
main/java/acme/moo/App.java
main/java/no_detect/App.java


which is very simple!

The POM has the following findbugs configuration:

    <build>
        <plugins>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>findbugs-maven-plugin</artifactId>
                <version>2.4.0</version>
                <executions>
                    <execution>
                        <phase>verify</phase>
                        <goals><goal>findbugs</goal><goal>check</goal></goals>
                    </execution>
                </executions>
                <configuration>
                    <debug>true</debug>
                    <effort>Max</effort>
                    <threshold>Low</threshold>
                    <onlyAnalyze>acme.*</onlyAnalyze>
                </configuration>
            </plugin>
        </plugins>
    </build>

and every App.java has the following code with two obvious violations:


package acme;
import java.io.Serializable;

public static void main( String[] args )
{
ns.meh = "hehehe";// Vilation: unused
System.out.println( "Hello World!" );
}
}


Note that no_detect.App has the same content as above, but my expectation is that it wouldn’t be
evaluated by findbugs because I have the “onlyAnalyze” option set to acme.* which I assume would
evaluate acme.App and acme.moo.App and nothing else.

I now execute a mvn clean install to clean, build, test, run findbugs, package, install, which
produces the following findbugs report (snipped for brevity) and results in a build failure which is expected
because acme.App and acme.moo.App:


<BugInstance category='BAD_PRACTICE' type='SE_NO_SERIALVERSIONID' instanceOccurrenceMax='0'>
<ShortMessage>Class is Serializable, but doesn't define serialVersionUID</ShortMessage>
<LongMessage>acme.App is Serializable; consider declaring a serialVersionUID</LongMessage>
<Details>
<p> This field is never read.&nbsp; Consider removing it from the class.</p>
</Details>
<BugPattern category='BAD_PRACTICE' abbrev='SnVI' type='SE_NO_SERIALVERSIONID'><ShortDescription>Class is Serializable, but doesn't define serialVersionUID</ShortDescription><Details>
<BugCode abbrev='UrF'><Description>Unread field</Description></BugCode><BugCode abbrev='SnVI'><Description>Serializable class with no Version ID</Description></BugCode>

To summarise: only acme.App is analysed, acme.moo.App (bad) isn’t and neither is
no_detect.App (good).

I tried with two wildcards in the onlyAnalyze option but that produces a **successful build** but
with a findbugs error (Dangling meta character '*' etc).

I tried with onlyAnalyze set to acme.*,acme.moo.* which analyzes all the expected
classes (acme.App and acme.moo.App) which means it “works” but not as I expect; i.e. I have to explicitly declare all parent-packages for the classes I want to analyze: that could get large and difficult to maintain on a multi-module project!

Must. Keep. Trying.

At some point in the day’s coding I wanted to run my code standalone instead of in a REPL. I needed a main entry point to the various algorithms I was writing that was outside of unit tests, so I decided to use the “lein run” command to do it for me.

In order to get a program running via lein using a main method, you have to provide the namespace of the class to run. If you want a JAR produced that’ll have the Main-Class declaration in your MANIFEST.MF you also need to add :aot and :main namespace.here to your project.clj AND add (:gen-class) in the (ns) call of your desired .clj holding a -main method. Phew!

To re-cap, then:

• To run a .clj that has a -main method/function declared, add (:gen-class) to its (ns) call and then run lein run namespace.here
• To produce a JAR with lein, do the above and add :aot and :main namespace.here to your project.clj then run lein compile && lein uberjar

In picking up a new language I run through certain easy problems that help me tackle the necessities of learning the APIs for a particular language and picking up habits (both good and bad) that are idiomatic of the chosen tongue. So, I decided to document what I do to learn to code. You can read it on my wiki.

What is “SOA”?
Service Oriented Architecture is a means of exposing business services
separately from their platform and codebase in order to provide local
and/or remote invokation of said services through abstracted data types
and signatures.

Put simply: SOA allows you to talk to alternate platforms by removing
the bespoke or language-specific features and data types to a
higher/specified representation providing interoperability between
platforms without the need for their awareness of eachother.

As a real world example, an organisation can provide interoperation
between legacy and new systems by abstracting the manner of how they
talk and the underlying content: new code can use technologies like XML
to define the data and the corresponding types and the two systems can
work together through that abstraction. This scenario is commonplace
among business where different streams are responsible for systems and
so a common format for data interchange is necessary to allow the two to
co-exist separately.

SOA also provides a more modular approach to service integration: if a
web service can “proxy” requests from one system to another, the two can
change independently without the need for related changes to the
services themselves. Such a scenario – one of proxying – can encourage
an ecosystem of services allowing each to communicate with seemingly
unrelated counterparts through a common set of data types and methods.

Benefits of SOA
Typically, the “promises” of SOA are numerous.

SOA allows for system agility
As aluded to previously, the ability for bespoke systems – those written
for specific purposes in a language of choice – to communicate with each
other allows for greater flexibility and scalability with an
organisation’s data. For example, if you can have your sales systems
talking to your suppliers through an aggregation service to warn of
unusual sales volumes, out-of-stock items and so-on, you can better
support the volume of a growing business and provide real-time response
to customer needs.

Consider an organisation where a sales system cannot speak with the MI
to ascertain whether a customer on the phone holds an account with you.
Crazy, no? In scenarios like this where legacy, decades-old and
difficult to support systems hold the key to sales success but are the
hindrance to it, SLA can be leveraged to quickly and easily have the two
communicating and providing front-line departments with the information
they need.

SOA can encourage innovation
In the post-Google era, notions of service “mash-ups” are commonplace.
These newfound, new-age businesses popularised the developer by
harnessing open source technologies and building public-facing APIs: all
built on service oriented architecture. They encouraged interoperation
between seemingly unrealted entities which built a platform for
innovation and a revolution in the software industry.

If you reduce this scale and manage to accomplish this very nature
within an organisation, then new products and alternatives to existing
ones spring from innovative and organic attitudes from developers and
system integrators.

I’ve decided to have this alias in my .bashrc:

alias telinit="echo Do you really want to telinit this server?!"

Do you have lack of consistency and understanding how your software is built? Does this equal varying degrees of success – both in each build and in changing or adding new features to it – and lack of confidence from your developers?

Did you roll your own build process that’s "the best thing since sliced bread" but only a select few developers really know how to use it? Do you dedicate resource to tweaking or fixing your build scripts?

To put it another way: are all your developers building the software using the same scripts your continuous integration environment is using?

What’s Wrong with the Above?

I believe building software should not be a complex process. It should be rare for a developer to delve into the build system to tweak it.

I also believe that because there are common parts to building – source code, tests, packaging – that there is little need for a "shop" to be going it alone and building something vanilla just because they can.

Essentially, building software comes down to performing a few tasks regularly and consistently; a developer will need to build, test and package regularly. Rarely do they need to work on the build system (unless something’s broken…).

With this in mind, should developers therefore not be able to perform these tasks without thinking about it? Wouldn’t it be beneficial to us all – as an industry even – to be able to go anywhere and build most software the same way because the requirements for building doesn’t differ?

I’m not making a case for never "rolling your own", I’m merely trying to clarify that those who do may not need to do so. Granted, some scenarios warrant custom build scripts and the like.

The Ant Perspective

With Ant, building means code. It means logic and that invariably doesn’t get the same strictness and quality applied to it like your everday Java and its counterparts. This means the build scripts quickly become convoluted, poorly maintained due to a "get it working" attitude. Unless a good/strong developer is dedicated to maintaining and scaling the build scripts, the job gets shared around and each unique developer’s perspective warps the overall goal.

Most software building is just a set of tasks that are repeated for each build. Compile this. Package this. Distribute that. It doesn’t make sense to have a human do that: computers are here to do the mundane stuff.

The Maven Perspective

With Maven, you just provide metadata. The framework provides the logic in a consistent and predictable manner.Don’t you want developers to be concentrating on writing code: fixing bugs, implementing new functionality and improving the quality of the product.

Maven allows one to have artefacts produced properly, with correct structure, metadata and naming conventions, that mean a developer – or person – doesn’t have to think to do it. These artefacts are of production quality, always.

Consistency

Consistency means one does not have to think about how or what they’re going to do when it comes to the build process.

If you’re a foreman building me a house and I say "build it this way please" and hand you a 3000 page instruction manual on how the Tudors and Stuarts built their houses prior to the great fire of London, you don’t say "Yeah sure!" you recoil because years of history and experience has taught you otherwise.

Is it fair to say that developers need to spend time fixing bugs and implementing new features and not spending time tweaking the bugs in the build system? Would you be happy to pay for a plumber to spend time fixing his toolbox instead of correcting that leak? If this isn’t acceptable, then you can understand why businesses might not want to spend the time (money) correcting your poor house keeping.

Quality Across the Board

Consistency breeds quality. A scenario where best practice is common, reliable and well-established norms are instinct encourages going the extra mile to write better software. In contrast, an unreliable, poorly designed and maintained mode of practice breeds contempt. Building your software is part of all of this and is a contributor to success or failure.

I’m by no means saying "blame your tools", just that better-quality tools can contribute to improved output.

Environments are a Different Beast

Environments have numerous issues whereas development seems fine; "Works for me" is far too common a response for when someone has to investigate a problem in a given deployment target.

The big wins with Maven

• Consistency across the board. It shouldn’t matter where you go or what customer project you’re on, you build, deploy, package and distribute artefacts the same way. Imagine a situation where developers can go anywhere and "pick up where they left off": start developing within minutes.

• Junit testing – maven bakes testing from the beginning, which brings it to the developer’s mindset at the right points (i.e. always)

• Greatly simplifies build processes: it doesn’t become a matter of how, but when. Developers learn a simple set of commands that never changes

• Dependency management is excellent: simplifies set up of projects, developers can get up-and-running within minutes

• Packaging is excellent. Multiple formats supported, from JARs, EARs to Zip, TAR etc and it is not left to the understanding and implementation of the developer implementing the build script

• Industry recognised: we don’t have to have developers "get up to speed" because maven works the same everywhere, developers just remember a few goals to tell maven what to do: compile, clean, test, package and they’re ready to start coding

• Have your developers building code and understanding how it’s built, not programming by coincidence. Don’t be in a position where your developers are relying on their IDE to build and having a separate process entirely for your CI!

Oftentimes, I’ll need to copy my notes to somewhere: a wiki, this blog, or to put in an email. It’s at this point I need to quickly convert to my target format.

So, to satisfy the above, I wrote a wrapper script that takes a file name and corresponding target format for output (according to Pandoc):

#!/bin/bash
if [ $# -lt 2 ]; then
echo "Please provide a filename and output format compatible with pandoc"
exit 1
fi
pandoc -f latex -t $2 $1

Very simple. Like I said, take a file name and the pandoc output format and then pass it all to pandoc to convert the LaTeX original to a format of my choosing. Very handy!

It is often the case that aged software shops will have put in place aspects of their software that they’ll “revisit later on”, which then doesn’t happen.

It gets lost to the crowd of “more important things to do”.

One of the most common neglects I see is how a shop will build, deploy and distribute its software. At best their solution is amateur. It’s usually home-baked and rigged with esoteric and often superfluous tasks and features that are “necessary” due to some poor design decision made previously. The build system — be it continuous integration or some poor sod in the corner — has to do 30 different things, copy 11 thousand files, just to compile the few.

And so the problem persists; the rot festers; the software continues to be sub-par and so do the profit margins.

I feel that if you start from the ground-up, that you build consistently and efficiently then your software becomes such. If it is easy for a developer to build and deploy or distribute your software, it’s then easy for them to do their job. Any developer knows the pains they’ll go through day-to-day when making a change that requires a 15-minute rebuild and 5 minute deployment wait just to check the first name field doesn’t fall over on a null pointer.

With poor practice comes poor software comes poor profit.

So if you’re heading up a development shop and your developers are crying for a more efficient, simpler, consistent build process, then heed their recommendations and concerns. Let them spend the time and money streamlining how they work, because you’ll get reliability, efficiency and less coffee breaks if you do.

Would you pay for that shiny new tablet PC if it came packaged in A4 paper?

How disappointed do you feel with a product when you hold it and you “know” its build quality is poor.

Why is software any different?

You wouldn’t build a palace with breeze blocks.