[p4] Deployment files in Perforce or Maven?

[Jeff Jensen]

I suggest starting with none in Perforce and all in the Maven repo.  Over
time, you may find need to store one or more build artifacts in Perforce.  I
prefer the minimalist approach when one is not sure; that allows adding when
discovery occurs.

As for "...in your organization", I introduced Perforce and Maven into my
current customer about 1.5 years ago (I have prior experience with both).  I
setup all development builds to use only the internal Maven repo (setup
Proximity for that); this include continuous integration builds with
CruiseControl (CC just calls Maven to build).  Maven "snapshot" feature is
very useful for always using the latest build in the repo - the case with
ongoing development, but not for a release prep/codeline.

Initially, the build team *had* to put the releases in Perforce, and I
didn't argue.  With a recent situation change we went through, I took the
opportunity and was able to convince them to move them out.  It was not
needed in this situation and they "saw the light".


-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of
vegard.setrenes at telenor.com
Sent: Tuesday, January 09, 2007 9:36 AM
To: perforce-user at perforce.com
Subject: [p4] Deployment files in Perforce or Maven?

Hi,

In my department we use Perforce on all Java development, and we have been
following the "best practice" of not storing anything in the depot, other
than what's necessary to do a build. In other words, we don't check in
binary archive files like EARs and JARs.

The source code for one of our systems was imported from cvs one year ago.
We have some deployment scripts that depend on retrieving EARs and JARs from
dedicated deployment directories in the same old cvs. These scripts copy the
deployment files to multiple test or production servers.

To be able to finally get rid of the cvs base, we are looking for the best
way of keeping the deployment files. Should we use Perforce or a web based
Maven repository?

It is clear that we do not need all historic revisions of the files. We are
just looking for a good way to make them available for the automated
deployment scripts. So I guess we could specify the +S modifier for a
designated part of the Perforce depot. But ideally there should be a way to
keep just the N last revisions, making it possible for the deployment
scripts to do rollbacks. Is this possible without using the obliterate
command?

How do you organize your deployment files in your organization?

Thanks,

- Vegard

_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user