Mavenizing Digital Asset Manager (or any other app)

Hey, all. I've been playing around with getting DAM to a place where we can use Maven to do build and deploy. This involved putting a bunch of jars into a local Maven repository (using Artifactory) and setting up the dependencies to make it easy for other developers on my team to use this process.

I was wondering if anyone else has tried this? Does anyone at Documentum use a Maven process? It would be extremely convenient if Documentum would establish a Maven repository for developers to point to (the know the dependencies much better than I do). Does anybody have any thoughts on this?

Find more posts tagged with

Comments

mszurap

Hi,

I've been using ANT for building customized DAM application. Why do you want to move to Maven? For example if you set up everything, and a new version of DAM comes out, you need to import / rebuild the whole web application which you had, getting the right jars are not enough - and anyway, you don't need to know the dependencies between them.

I don't think EMC would ever publish it's CVS/SVN or maven repository, not even for it's partner's developers.

Mark Davidson

I've not tried Maven yet but the idea of a standard build process for Documentum development definitely appeals.

vladimir.hr

Hi,

I've tried to mavenize development of Documentum methods for java method server. And yes, I had to put all jars into local server manually (and create "pseudo" libraries like dctm-5.3sp1.jar which had transient dependency to other jars).

I would also like to have maven repository from Documentum. Always we create new project or new developer comes to our team he has to install or copy all jars.

I see in maven good way how to standardize build process.

david.matheson

Much can be written on Ant vs. Maven in general, but I'll give you my personal reasons for wanting to switch. As the developer that maintains our build processes, Ant builds are becoming a bit of a pain. Often they have not been written by me, so they don't follow a standard structure, and everything must be done manually (write the initialization target, write the compilation target, write the packaging target, write the deployment target). Maven enforces a standard structure and removes the manual target-writing. The other thing is the dynamic library management. With Ant, developers find a new library, write code that depends on it, check the library into source control (not nice, binaries in source control), then perhaps update the library version when a new one comes out. The rest of the team can easily lose track of what version of a library is being used. Maven solves this problem quite elegantly.

If there were a standard Maven repository for this stuff, a new version of DAM would come out and some libraries would have their versions updated, but others would not. Take a look at All-MB.jar. I quick compare on my local seems to indicate that it hasn't changed between 5.3SP6 and 6.5SP1. What did change would be explicitly denoted in the dependencies section of a library's POM. A developer could simply update the dependency in their project's POM and see what falls out when they build. You would have to grab the updated web application files (jsps, xmls, etc.), but that's not difficult.

You don't need to know the dependencies, you can just throw everything in your Maven repository under com.documentum and let the developers on your team have a POM that contains 50 or 60 dependencies. It's a bit nicer to explicitly state that dfc.jar depends on jaxb-api.jar and jaxb-impl.jar. That way if a developer is writing a simple DFC application, instead of a DAM customization, they can simply put dfc down as a dependency and let Maven do the rest.

Since DAM 6.0, everything is packaged in the WAR, so getting the right jars IS basically enough. You just need the structure to match what the exploded WAR looks like. I'm not asking EMC to let us access it's source control repository, as they don't give us access to source in any fashion. They give us the compiled libraries and the rest, though. This would just be delivering things that they already give us access to in a more convenient manner. They could password protect the repo using the same authentication source as Powerlink, or whatever. Really I'm just curious to see if they use it internally.