indiWiz.com

[2009-12-03] Updated for new Maven repository.

Thanks to Ganesh Gembali and Velrajan for helping me with this post.

One thing I hate about Alfresco is it’s SDK. I hate to learn new methodologies and configurations specific to new software. When it comes to developing Alfresco modules and extensions, it was difficult to do it without configuring Alfresco SDK. But that is history

Alfresco Maven Archetypes

I will discuss the steps I followed to configure a new Alfresco module project using Maven Alfresco AMP Archetype.

Step 1: Configuring Alfresco Repositories

Add the following repositories to your Maven configuration:

<repositories>
    <repository>
        <id>alf-public</id>
        <url>http://maven.alfresco.com/nexus/content/repositories/releases</url>
    </repository>
</repositories>
<pluginRepositories>
    <pluginRepository>
        <id>alf-public-plugin</id>
        <url>http://maven.alfresco.com/nexus/content/repositories/releases</url>
    </pluginRepository>
</pluginRepositories>

Step 2: Using archetype:generate to generate a new project structure

mvn archetype:generate \
  -DarchetypeCatalog=http://maven.alfresco.com/nexus/content/repositories/releases/alfresco-archetype-catalog.xml

Actually the above code did not work in our proxy environment (I have configured Maven for Proxy usage correctly). So I saved the alfresco-archetype-catalog.xml to local filesystem and referenced it thus:

mvn archetype:generate \
  -DarchetypeCatalog=file:///home/subhash/alfresco-archetype-catalog.xml

The application quizzes you about artifactId, groupId, package name and version. Give the details. It will create the project directory.

Step 3: Placement of files

The following table will help you understand where to place your source files. The third column (AMP path) describes the path where the source file will be packaged inside the AMP. The fourth column (Deployment Path) the path where the file will be installed inside Alfresco deployment.

Step 4: Configuring Alfresco Dependencies

As an example, our module depended on alfresco-webscript-framework and alfresco-core APIs:

<dependency>
        <groupId>org.alfresco</groupId>
        <artifactId>alfresco-webscript-framework</artifactId>
        <version>3.2r</version>
        <classifier>community</classifier>
        <scope>provided</scope>
</dependency>
<dependency>
        <groupId>org.alfresco</groupId>
        <artifactId>alfresco-core</artifactId>
        <version>3.2r</version>
        <classifier>community</classifier>
        <scope>provided</scope>
</dependency>

Two things to note:

• The <classifier> element is needed. The Jar files in the repository is named as {artifactId}-{version}-{classifier}.jar
• Always give the scope as provided. This ensures Alfresco Jars do not get bundled with your AMP.

What happens when two respectable enterprise Java scalability providers (Ehcache and Terracotta) join together? I am eager to witness the interesting time ahead! Get the news here.

There are some Cultural differences to consider before recruiting a techie in India. The first thing in the minds of the Indian middle class:

A Job is a labor which is performed to earn a living.

This is different from what a good programmer views his Job as: a passion which he cannot live without.

This attitude of impassionate living without any risk taking ability has generated a generation of civil servants, doctors and software engineers whose lives are not worth living. They are just mechanical money making machines just operating. Not living. When recruiting, beware of this class. Once you recruit them, they will bring duress and boredom into the workplace. They will kill the creativity and innovation that can happen.

Does any of these sound familiar:

1. Pay less salary than developers
2. Demote “bad programmers” to QA
3. Force manual testing
4. Disallow use of testing software

All these are signs of decay.

I found this interesting link listing the most interesting Firefox plugins.