[p4] Deployment files in Perforce or Maven?

[Slava Imeshev]

That's an interesting point. 
 
Being in software build automation and management for awhile 
I strongly suggest keeping *all* product dependencies in Perforce. 
 
The main problem with the external dependency repositories is that
they introduce an additional maintenance point that makes reproducing
builds practically impossible

The only realistic way to reproduce a build that has ever gone outside 
of a build box while an external dependency repository is in picture is to 
make snapshot  backups of that repository in sync with a state of the codeline 
at the build time. Bullet and foolproof implementations of such process 
remain to be seen. External dependency repositories make 
multi-codeline product development plain dangerous.
 
One may argue that adoption of tools like maven grows but if you 
look closer it is mainly in open source area where a [scary] practice
of "releasing from the tip" is common, and past states are not important 
because of no need to support past releases, nor reproducible.
 
Comparing to the above Perforce capabilities such as speed and ease 
of  use, and practically free disk storage and network bandwidth,
storing and managing dependencies in Perforce depots is simple, 
transparent and *very* robust. I strongly recommend this.
 
I'd guess there world be other opinions. Mine one has grown from
multiple client engagements and painful customers' experience. The 
recent one is just a month old when we had to untangle mess created 
by use of a "local repository". A customer discovered that they haven't 
had a clean build for about 6 months after the maven "repository" "glitched".
"Latest" "clean" build was picking up a "snapshot" dependence 
that was gone long ago from the code.
 
As we touched this topic, I also recommend keeping the dependencies
along with codeline, not in a separate "dependencies" codeline, i.e.
a well-organized codeline IMHO should look like:
 
//depot/product_version_1/3rdparty
//depot/product_version_1/src
//depot/product_version_1/bin
//depot/product/3rdparty
//depot/product/src
//depot/product/bin
 
and *not* like this:
 
//depot/3rdparty
//depot/product_version_1/src
//depot/product_version_1/bin
//depot/product/src
//depot/product/bin
 
Just my 2c...
 
Regards,
 
Slava Imeshev
vimeshev at viewtier.com
www.viewtier.com
 
 
 
 
----- Original Message ----- 
From: "Jeff Jensen" <jeffjensen at upstairstechnology.com>
To: <perforce-user at perforce.com>
Sent: Tuesday, January 09, 2007 7:37 PM
Subject: Re: [p4] Deployment files in Perforce or Maven?

> 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
> 
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user