10 Replies Latest reply: Mar 30, 2012 1:55 AM by Brian Dinneen RSS

Build process for Documentum applications

david.matheson

Hi, all.  I just submitted my talk topic for EMC World 2010: our build process.  If anyone wants to share their build process here, I would appreciated it.  I am interested in (our tools in perentheses):

 

  1. Your IDE (Eclipse)
  2. Your source control (TFS)
  3. Your build script tool (Maven + Ant)
  4. Your bug tracking (HP Quality Center)
  5. Your integration pieces (Teamprise, Mylyn + QcMylyn)
  6. Continuous Integration, Y/N? (Yes, TFS handles it)

 

 

Dave

  • 1. Re: Build process for Documentum applications
    Laurence Hart

    Thanks for submitting!

     

    I'll reach out to some of my teams and other I know to see if I can get them to submit what they do.  Oh, and I'll probably write mine up as well.

     

    -Pie

  • 2. Re: Build process for Documentum applications
    ukdavo
    1. IDE - Eclipse
    2. Source control - Subversion or whatever the client supplies
    3. Build tool - Ant
    4. Your bug tracking - various, normally what the client supplies (Excel, Test Director, etc)
    5. Your integration pieces - none
    6. Continuous Integration - Hudson & Cruise Control

     

    We try to use JUnit, Cobertura, etc. I'd personally like to see dependency management being introduced via Ivy or Maven.

  • 3. Re: Build process for Documentum applications
    david.matheson

    Thanks, Davo!  I introduced Maven into our mix, but it was done manually, putting the Documentum jar files in a local library repo.  Here are some questions for you:

     

    • What does your project structure look like in Eclipse?  Is it basically Eclipse's JEE template (ProjectName/src, ProjectName/WebContent)?
    • Are you using WTP or are you deploying to the container outside of Eclipse?
    • Do you guys have a basic Ant script template, or does it change from project to project?
    • Do you use the new headless composer to script and automate content server changes (BOFs, type changes, etc.)?

     

    The integration pieces I was asking about refers to what plays well with what.  Can your developers check out/in of source control from within their IDE, for example?  Do they run the build from within the IDE?  Does the build script apply a label to the code in source control?

     

    Most importantly, what would you change about your build process?  What are the pain points?  I appreciate the feedback!

     

     

    Dave

  • 4. Re: Build process for Documentum applications
    sakaleatEMC2

    Hi Team,

    Has anyone yet replied/answered this post?

    I also has same questions as David has perticularly in following configuration:

    1. IDE - Eclipse
    2. Source control - ClearCase
    3. Build tool - Maven2
    4. Your bug tracking - HP Quality Center
    5. Your integration pieces - none
    6. Continuous Integration - Hudson

     

    Can your developers check out/in of source control from within their IDE, for example?  Do they run the build from within the IDE?  Does the build script apply a label to the code in source control?

     

    Thanks,

     

    SAK

  • 5. Re: Build process for Documentum applications
    david.matheson

    Hi, Sak.  I haven't had too many people reply.  I quick look around shows that there's a ClearCase plugin for Eclipse (although I don't use ClearCase, so I can't vouch for it):

     

    http://sourceforge.net/projects/eclipse-ccase/

     

    There's the Maven plugin for Eclipse, which I use and really like:

     

    http://m2eclipse.sonatype.org/

     

    There's the Mylyn plugin for Eclipse, for which there is an HP Quality Center connector:

     

    http://sourceforge.net/projects/qcmylyn/

     

    We are going to be using this soon in our environment.  We have tested it with Eclipse 3.5.1 and QC 10, it works well.

  • 6. Re: Build process for Documentum applications
    phdctm

    Hi David,

     

    Same here, we are likely to go for Maven. Previously with version 5.3 we used CVS with projects templates that we'd copy/paste.

    We'd define some dependencies after all with the inclusion of DFC for instance.

    But nothing great to automatize and systematize the publication (we'd like to go for montlhy Documentum updates).

     

    I'm searching for more information on best practices to well implement the Maven process for our team (10 persons to develop).

    We'd like also to include extra products from EMC into this schema (we have some SAP archivelink conf, BPM, C6 D2, etc) that'd benefit from source consolidation. It's a shame that there is no good guide from EMC to cover this change !

     

    Philippe

  • 7. Re: Build process for Documentum applications
    david.matheson

    Hi Phillippe,

     

    I've done some more work on our build process.  I'm incorporating Maven's release plugin into the process, and I wrote an Ant task, calling headless Composer, that I call from Maven to automate SBO/TBO deployment.  If you want to discuss this, I'd be interested, just shoot me a message.  I'm still working out the kinks of how to make this the most useful for my team.

     

    There doesn't seem to be much guidance on an overall build process (I used https://community.emc.com/docs/DOC-4705 to help build my Ant task).  I've been at this a few years and most of it has been trial and error.  Always interested to talk about it.

     

     

    Dave

  • 8. Re: Build process for Documentum applications
    Brian Dinneen

    Please forward me details on Maven + DFC and/or Maven + Composer.... or even other Maven like tools... did someone mention Ivy? This is one of two areas that I want to improve on for my next project. No.2 would be Cruise Control Hudson building and deploying my dars.

     

    This week (Jan 2011) I tweaked my batch scripts for building and deploying Composer projects to be called from Hudson. Dropping the Hudson war onto Content Server Jboss allows for deployments without a hard coded password.

     

    For last 4 years, I have generally been the one on the project team to take an interest in and enforce source code quality, control, layout, build and deployment.

     

    This is what I have been using

     

    1. Your IDE (Eclipse)
    2. Your source control (SVN, eclipse plugins, windows explorer plugin (tortoise), command line)
    3. Your build script tool (Ant)
    4. Your bug tracking (Trac)
    5. Your integration pieces (?Mylyn)
    6. Continuous Integration, Y/N? (N, scripted deployment of wars, dars, api and dql scripts)
    7. Release packages (a) XX.ContentServer, b) XX.ApplicationServer, c) XX.Sources)
    8. Code maintance (use Eclipse tools, code formatter, organise imports, and sort members)

     

    It depends on the client, and if they supply code management infrastructure or if I/team I work with supply it.

     

    this is what I would like to get to

    1. Your IDE (Eclipse)
    2. Your source control (SVN, eclipse plugins, windows explorer plugin (tortoise), command line)
    3. Your build script tool (Maven + Ant)
    4. Your bug tracking (Trac)
    5. Your integration pieces (?Mylyn, plugin for Eclipse)
    6. Continuous Integration, Y/N? (Hudson)
    7. Release packages (a) XX.Repository, b) XX.ApplicationServer, c) XX.Sources)
    8. Code maintance (use Eclipse tools, code formatter, organise imports, and sort members, Find Bugs)

     

    Project folder structure, usually evolves a for each project.... I have gone away from one megalithic project to multiple sub projects. However if the customisation effort is small then its is simpler to have just one project.

     

    For webtop customisation projects, I keep the sources separate from running webtop. Ant scripts are used to copy over the changes.

     

    As my code is delivered to a client in release packages, see 7, I put anything that goes to the client into folder "trunk/sources" and use other root level folders for info (e.g. excel spreadsheets with env details) "sources/infra" or tools "sources/tools", "sources/recievedfromclient".

     

    I have svn command line client installed on the Release build server and have Ant tasks to execute "svn log" and "svn info"....

    • "svn log" output files goto into a folder called "Release Notes".... hence I do not manually write release notes, except for very high level managers. For custom webtop, the release files go into the root of the web app, so they can be access via URL... hence very easy to see what SVN revision was this release built on
    • "svn info" files goto "Release Notes" folders or for one client in their custom webtop, into "WEB-INF/classes" and a customisation to "Help->About" displays the svn revision number as the application build number!!!

     

    After using the tools in item 8 for a while, I now find it really annoying to have to maintain java code with line breaks past 80chars....

  • 9. Re: Build process for Documentum applications
    Jerry Silver

    This thread has been moved to the Documentum Developer Community.

     

    We're trying to encourage all technical discussions to be posted to either the Documentum Support Forums or or the Developer Community.  Please read Guidelines for Documentum Community Participation for further guidance.

     

    Thanks,

     

    Jerry

  • 10. Re: Build process for Documentum applications
    Brian Dinneen

    Mark has put together a nice project and readme for a DCTM Multiple Composer project layout with Maven and Jenkins

    http://code.google.com/p/dctm-multi-module/wiki/HowItWorks