Management in business and organizations is the function that coordinates the efforts of people to accomplish goals and objectives using available resources efficiently and effectively. read more at WikiPedia

  • Quite interesting read even for all of us who are still not manager..

    Arguably the most powerful and effective managers in the world, these men have one thing in common – they owe their management acumen and success not to fancy business degrees from the hallowed portals of Harvard and Yale, but to plain old, not-so-common, common sense.

    In short, the tricks you learned as a child when you first embarked on an entrepreneurial endeavor with your own lemonade stand, still hold good in today’s cutthroat business world.Read more HERE
  • funny.manager

  • apache_maven

    It is not unusual in a project to have a huge number of third party artifacts and Plug-in. Apache Maven help you keep track of them, along with their transitive dependencies.

    But how do you know when a new version of an artifact is available?  This is where the Maven Versions plug-in come hand in.

    The Versions Plug-in is used when you want to manage the versions of artifacts in a project's POM.

    By running

    mvn versions:display-dependency-updates

    in any Apache Maven project or modules, you’ll get for example (we have a lot of 25 Maven modules, here is only one presented as an example, the list being too long)

    [INFO] --------------------------------------------------------------------------------------------------
    [INFO] Building Unnamed - com.innoveo:skye-services-api:jar:2.2.0-M-06
    [INFO] --------------------------------------------------------------------------------------------------
    [INFO] The following dependencies in Dependency Management have newer versions:
    [INFO]   junit:junit............................................. 4.4 -> 4.8.1
    [INFO]   log4j:log4j......................................... 1.2.15 -> 1.2.16
    [INFO]   org.springframework:spring...................... 2.5.6 -> 2.5.6.SEC02
    [INFO]   org.springframework:spring-test............... 2.5.6 -> 3.0.4.RELEASE


    It is not always an easy task to update some core components or 3rd party libraries in a complex software, as it may introduce some regressions, incompatibilities..

    At least thanks to this Versions plug in, you are aware that they may be something newer to try. What this plug in do not report is why you may want to update some artifacts libraries:

    • Do I have to use the latest version x.y.z because of  security issues?
    • Will i get more performances by updating to x.y.z?
    • New Version x.y.z resolve bug xxxx, will I have other annoying issues?

    In all the above case, you are on your own, but this is not the scope of this plug in. You’ll have anyway to

    1. Carefully decide which library can be updated,
    2. Match it to your software roadmap,
    3. Have enough confidence in your test suite (unit test, BDD, integration tests) and testing team,
    4. Communicate with your customer (for security issues in 3rd party library)
    5. .. and the list goes on

    The Versions Plug-in has a lot of interesting goals.

    Some are also updating values across all pom.xml for you.

    • versions:update-parent updates the parent section of a project so that it references the newest available version. For example, if you use a corporate root POM, this goal can be helpful if you need to ensure you are using the latest version of the corporate root POM.
    • versions:update-properties updates properties defined in a project so that they correspond to the latest available version of specific dependencies. This can be useful if a suite of dependencies must all be locked to one version.
    • versions:update-child-modules updates the parent section of the child modules of a project so the version matches the version of the current project. For example, if you have an aggregator pom that is also the parent for the projects that it aggregates and the children and parent versions get out of sync, this mojo can help fix the versions of the child modules. (Note you may need to invoke Maven with the -N option in order to run this goal if your project is broken so badly that it cannot build because of the version mis-match).
    • versions:lock-snapshots searches the pom for all -SNAPSHOT versions and replaces them with the current timestamp version of that -SNAPSHOT, e.g. -20090327.172306-4
    • versions:unlock-snapshots searches the pom for all timestamp locked snapshot versions and replaces them with -SNAPSHOT.
    • versions:resolve-ranges finds dependencies using version ranges and resolves the range to the specific version being used.
    • versions:set can be used to set the project version from the command line.
    • versions:use-releases searches the pom for all -SNAPSHOT versions which have been released and replaces them with the corresponding release version.
    • versions:use-next-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the next release version.
    • versions:use-latest-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the latest release version.
    • versions:use-next-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the next -SNAPSHOT version.
    • versions:use-latest-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the latest -SNAPSHOT version.
    • versions:use-next-versions searches the pom for all versions which have been a newer version and replaces them with the next version.
    • versions:use-latest-versions searches the pom for all versions which have been a newer version and replaces them with the latest version.
    • versions:commit removes the pom.xml.versionsBackup files. Forms one half of the built-in "Poor Man's SCM".
    • versions:revert restores the pom.xml files from the pom.xml.versionsBackup files. Forms one half of the built-in "Poor Man's SCM".

    The easiest way to live dangerously is to try to update all 3rd parties in one shot by issuing

    mvn versions:use-latest-versions

    but that’s another story :-)

  • A very funny article, on free electron, a sort of nerdor geek, worth the read :-)

    The Free Electron is the single most productive engineer that you’re ever going to meet. I have not even provided a definition and I’m guessing a person has already popped into your mind that fits the bill. 


    A Free Electron can do anything when it comes to code. They can write a complete application from scratch, learn a language in a weekend, and, most importantly, they can dive into a tremendous pile of spaghetti code, make sense of it, and actually getting it working. You can build an entire businesses around a Free Electron. They’re that good.

    Free Electron Got’chas:
    » There are two classes of Free Electrons. Sr. Electrons and Jr. Electrons. Both have similarly productivity yields, but the Senior versions have become politically aware. 

    Read the full article HERE

  • I forgot to blog about this presentation at JAZOON 2008, but I did never forget the added value of this plugin. It is not currently in Apache Maven  core but will for sure find its way as an official plugin one day, since it solve elegantly a common problem: technology management

    Maven does not know the concept of an artifact life cycle. Such life cycle status information would allow to extend the dependency management in a new dimension. One could declare whether certain dependencies are actually allowed/forbidden/restricted to be used in a project, enabling effective technology management.

    Currently a plugin is available to achieve this goal:The AssertDepend plugin. It work by adding metadata, additional xml files in artifact group directory.

    The AssertDepend plugin is a Maven extension to perform effective technology management. The plugin checks at build time against lifecycle states defined in metadata on remote repositories in order to inform the developer about inappropriate technology usage (dependency enforcement). Based on a flag the build would either fail or print a warning.

    Technology management benefits and means

    The capability to manage dependencies and technologies on a mature level is essential for software organizations of a certain size. Technology management becomes a key discipline and must be introduced in a careful way to allow for mutual benefits among its stakeholder including developer, management, and customers.

    Artifact lifecycle management

    To perform effective technology management, you should keep the number of approved artifacts as small as possible. You cannot remove artifacts from the repository if you want to sustain reproducible builds. Therefore, each artifact in the repository should be marked with a corresponding lifecycle state.

    The proposed main states are (but the plugin is not limited, you can create your own)

    • approved
    • prohibited
    • investigating

    With these states, it solve elegantly the following use cases.

    Scenario 1: Flawed versions
    It turns out that my-app-1.4.2.jar contains a serious security issue and is therefore flawed. Clients of this JAR should actually switch to a newer version my-app-1.4.3.jar which fixes the bug and which is safe to use.

    Scenario 2: Decommissioning
    Let's assume that my-app-1.4.2.jar is not supported anymore and projects should actually switch to a new release stream

    Scenario 3: Restricted usage
    Consider a library which has a restricted set of client projects, e.g. only certain projects are allowed to depend on a specific artifact.


    Artifact lifecycle metadata must be placed in a file named maven-artifact-lifecycle.xml in the corresponding group directory. For instance, if you want to define lifecycle information for struts, the corresponding metadata file is located here: struts/struts/maven-artifact-lifecycle.xml

    This plugin can be downloaded at