[p4] Deployment files in Perforce or Maven?

[Helck, Christopher]

Hi Vegard,

We get by with a maven repository on an internal web server. If you
trust that the web server is being backed up correctly than you should
be ok. There are good reasons to put your maven repo into Perforce too.
A common example is where a certification group wants to perform
controlled builds -- typically they don't want to go to a development
web server and just grab a file.

I believe the common way to do this is to have a script that
periodically syncs Perforce with your maven repository. The script needs
to put new or changed repository files into Perforce, and to extract
(sync) updated from Perforce.

Some of this depends on if you're actually using maven or not.

"Best practices" need to be taken with a grain of salt. It certainly
makes sense to save the artifacts of some builds, and a logical place to
save them is Perforce. I believe the real issue is keeping the artifacts
separate from the source.

I don't follow what you mean by rollbacks. I've assumed that the
artifacts include the version number in their filenames (ala maven). Are
your build scripts pulling specific versions of a file? Like foo.jar#4 ?

Regards,
Christopher Helck



 

-----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 6:47 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

 
Thank you for being part of it.
 
The information contained in this e-mail is confidential. This e-mail is intended only for the stated addressee.  If you are not an addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. if you have received this e-mail in error, please inform us immediately and delete it and all copies from your system.

EBS Dealing Resources International Limited. Registered address: 2 Broadgate, London EC2M 7UR, United Kingdom. Registered number 2669861.

EBS Dealing Resources, Inc, registered in Delaware. Address: 535 Madison Avenue, 24th Floor, New York, NY 10022, USA, and One upper Pond road, Building F - Floor 3, Parsippany, NJ 07054, USA.

EBS Dealing Resources Japan Limited, a Japanese Corporation. Address: Asteer Kayabacho Bldg, 6th Floor, 1-6-1, Shinkawa, Chuo-Ku,  Tokyo 104-0033, Japan.