topic Re: How to do a good proof of concept in Alfresco Archive

How to do a good proof of concept

huima — Wed, 11 Aug 2010 22:03:06 GMT

Hi all,I finally understand the value of Alfresco and how to use it. It only took a project where I have had to work with Liferay's content management and see how it is built. In the project specification requires more than Liferay easily provides out of the box, which means we need to do developmen

Re: How to do a good proof of concept

mrogers — Thu, 12 Aug 2010 13:43:43 GMT

Thanks for posting that.

Re: How to do a good proof of concept

huima — Mon, 23 Aug 2010 23:54:41 GMT

Small progress report and notes for others, if interested.

I initially intended to use alfresco distribution from maven repo at http://maven.alfresco.com/nexus/content/repositories/public/. However the 3.3 snapshot ( community war ) that I got from there had problems, compared to the distributed war from Alfresco download-pages. Therefore I chose to take the war from Alfresco distribution and put it into local maven repository for dependency management.

As the maven project has the war as a dependency, the overlay feature puts the Alfresco war as the base and copies all my files from my project on top of the alfresco war, allowing me to automatically either override Alfresco configurations or just put them nicely in alfresco/extension directory - as well as compile and distribute my own code alongside Alfresco in singe war. With maven configuration I could also exclude individual files from Alfresco, for example replace spring version to newer version or something similar. As Alfresco uses slf4j - I could exclude log4j from the war and replace it logback, which is used in all my other projects.

To be able to compile my own code, I have following dependencies in my project:

        <dependency>
            <groupId>org.alfresco</groupId>
            <artifactId>alfresco-repository</artifactId>
            <version>3.2</version>
            <classifier>community</classifier>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>org.alfresco</groupId>
            <artifactId>alfresco-mbeans</artifactId>
            <version>3.2</version>
            <classifier>community</classifier>
            <scope>provided</scope>
        </dependency>

As they are marked as 'provided' they are used only during compile time, but when packaged and deployed - classes from Alfresco war are used. At the moment I have dependency to 3.2 as it seemed that proper 3.3 versions were not available ( could be my mistake too ).

I am really, really exited about finally doing real work on top of Alfresco and having it fit into my workflow just nicely. Without having to bother with large SDKs or custom ant build-scripts. I get everything right here to my project with just few dependency lines added to the POM. When I have extra energy and time, I could write a complete tutorial to encourage new users to try and get into Alfresco development.

Jeff Potts' book has been an excellent resource into the world of Alfresco, though the book is a heavy read if you are not actually doing development work at that moment. Alfresco 3 Content management implementation is better in describing Alfresco features from the top, where as Jeff's book is excellent developer manual - when you already know your way around Alfresco. I'm going to order the Professional Alfresco book from Wrox too, just to see whether how it fits in with rest of the books - and whether it would be a good compromise between overview of Alfresco and description of technical architecture… something that could be given to new programmers / techies / architects to hand as an introduction into the world of Alfresco.

I am really excited about Alfresco now and looking forward utilizing these experiences and skills also in future projects. With my good skills and experiences in development with Spring Framework and other components that make Alfresco I feel really good even while digging down into the code. It is clear, easy to understand and compared to numerous other projects it is exceptionally well documented. Just by looking at the code you can tell that there has been professionals at work.

And that is… just excellent.

Re: How to do a good proof of concept

dayre — Wed, 01 Dec 2010 18:56:28 GMT

Hi Huima !

I share your enthusiasm for Alfresco. I'm very impressed with the API and the architecture decisions made. Meeting some of the developers at the NY DevCon in Nov reinforced my initial impressions about Alfresco. There are some very talented people working on this project and it really shows in the end product. I haven't felt this much excitement over a piece of software and it's potential in a long time.

I'm building my alfresco.war from a particular SVN release from Alfresco's subversion repo. I've been trying to think of the best way to customize my distribution, and looking at simple configs (shared/classes etc..) or using AMP's/Jars… i'm thinking a war overlay may be better for us as this is essentially what the AMPs do anyways and i find it conceptually cleaner. So the path i'm planning on taking at the moment is:

1) svn export a suitable release from the Alfresco subversion repo
2) check this into our organizations local SVN
3) ant incremental-webclient-tomcat (just looking at alfresco.war at the moment…)
4) deploy this alfresco.war to our organizations local maven repo (along with the other jars, using the scripts from here as a guide: http://code.google.com/p/maven-alfresco-archetypes/wiki/MaintainYourRepo)
5) using the war overlay method to create a new customized war, similar to what you are doing

Thanks for posting your proof of concept here, it helped to validate my course of action.

d

Re: How to do a good proof of concept

huima — Thu, 09 Dec 2010 12:54:56 GMT

Thanks for posting your proof of concept here, it helped to validate my course of action.

d

Great to hear.

We have continued on this path now, though as a base we are now using released community versions instead of SVN. We have liked the overlay method compared to AMP's as we need to do *sigh* some modifications to core Share files in some places, instead of extending them.