New Plugin: licensing-maven-plugin

Ever wanted to know what licenses your dependencies (and their dependencies) are using? Maybe you work for a company that wants to sell their source code so you're wanting to avoid the GPL (and AGPL)? I've got the plugin for you!

I mentioned a while back that the build process at my day job had been declared bankrupt. Well, it's doing much better now; what used to be a multi-day process where you were never quite sure if it was working 100% now takes less than an hour (including data population). We're quite happy about that part.

Along the way we started looking at some of the other bits that fit more into release management; one of them was a "licensing report". This report listed most of our dependencies and which open source license they were in. Instead of hacking at the old scripts, we decided to let Maven take over and handle providing licensing and dependency information.

So with a rough idea of what we wanted to do, I put together the Licensing Maven Plugin. It has a few handy features:

1. Transitively aggregate licensing information of dependencies of child modules in multi-module reactors (or in English, it works the way you would expect it to on multi-module builds).
2. Coalesce license names (so "Apache License, Version 2.0", "Apache 2.0" and "ASLv2.0" can all be reported as "The Apache Software License, Version 2.0").
3. Fail builds if a dependency is only available under a disliked license.
4. Exempt artifacts under disliked licenses from failing the build.
5. Manually declare licenses for dependencies that fail to provide their own.

It's hosted on central, so give it a whirl:

mvn org.linuxstuff.maven:licensing-maven-plugin:1.5:aggregate

You'll see a truckload of warnings go by, and when it stops, you'll have a target/aggregated-third-party-licensing.xml file (yes, I know it's not nicely formatted yet).

If you'd like some more details, checkout the licensing-maven-plugin README.

Syndicated 2012-01-09 07:54:00 (Updated 2012-01-09 08:41:16) from Idcmp

New Plugin: licensing-maven-plugin

Ever wanted to know what licenses your dependencies (and their dependencies) are using? Maybe you work for a company that wants to sell their source code so you're wanting to avoid the GPL (and AGPL)? I've got the plugin for you!

I mentioned a while back that the build process at my day job had been declared bankrupt. Well, it's doing much better now; what used to be a multi-day process where you were never quite sure if it was working 100% now takes less than an hour (including data population). We're quite happy about that part.

Along the way we started looking at some of the other bits that fit more into release management; one of them was a "licensing report". This report listed most of our dependencies and which open source license they were in. Instead of hacking at the old scripts, we decided to let Maven take over and handle providing licensing and dependency information.

So with a rough idea of what we wanted to do, I put together the Licensing Maven Plugin. It has a few handy features:

1. Transitively aggregate licensing information of dependencies of child modules in multi-module reactors (or in English, it works the way you would expect it to on multi-module builds).
2. Coalesce license names (so "Apache License, Version 2.0", "Apache 2.0" and "ASLv2.0" can all be reported as "The Apache Software License, Version 2.0").
3. Fail builds if a dependency is only available under a disliked license.
4. Exempt artifacts under disliked licenses from failing the build.
5. Manually declare licenses for dependencies that fail to provide their own.

It's hosted on central, so give it a whirl:

## NOTE: If you're reading this early Saturday morning (07-Jan-2012), central may not have synced 1.5 yet.
mvn org.linuxstuff.maven:licensing-maven-plugin:1.5:aggregate

You'll see a truckload of warnings go by, and when it stops, you'll have a target/aggregated-third-party-licensing.xml file (yes, I know it's not nicely formatted yet).

If you'd like some more details, checkout the licensing-maven-plugin README.

Syndicated 2012-01-08 07:54:00 (Updated 2012-01-08 07:56:46) from Idcmp

Hello Developers, look at your code.

Hello developers, look at your code, now back to me, now back at your code, now back to me. Sadly, your code isn't me, but if it stopped collecting tech debt and you started making time for technical quality it could smell like me. Page down, back up. Where are you? You're at an interface with the code that your code could smell like. What's in your hand, back at me. I have it, it's an oyster with two different implementations to that thing you have an API for. Look again, the implementation is now secure and scalable. Anything is possible when your code has no smells. I'm on a horse.

Syndicated 2011-12-14 09:03:00 (Updated 2011-12-17 07:26:00) from Idcmp

A Patentable Idea

A quick post that if someone were to come up with a "USB Charger Condom" that I could plug into those free charging stations (or into my phone) which acted like an application layer proxy for my phone and prevented the charging station for giving anything more than power and not access anything on my phone that I'd gladly use one, and I'd make everyone I know use one too.

Syndicated 2011-11-01 15:37:00 (Updated 2011-11-01 15:37:05) from Idcmp

Real Reasons Developers Leave Jobs

While I'm still working on improving my commenting skills, I've also started trying to ponder how to write software in company with high developer turnover.

You see, I've always said that software reflects the team that writes it.  If you have a team of people who are seriously experienced at writing stored procedures and OSGi, you can expect that the software they write will use that.  On the flip side, a team who knows JavaScript and CSS, asked to write the same software will write something completely different. So, given an environment that has higher turnover, how does someone design a system that embraces and survives?

While I was researching about turnover, I found a survey on why developers left their current positions (or rather, why they would leave their current position).

Syndicated 2011-09-27 04:50:00 (Updated 2011-09-27 04:50:31) from Idcmp