why don't you automate the build process by cruise control and let the team
test that out?

On Thu, May 22, 2008 at 10:19 PM, Richard Chamberlain <
[EMAIL PROTECTED]> wrote:

> Oh I see.
>
> How about having a release branch for each of your projects? Then you
> wouldn't have to worry about specifying a svn number for each project.
> A parent project could still work as they could do a multi-module build,
> which builds each project in turn.
>
> Rich
>
> -----Original Message-----
> From: Chris Helck [mailto:[EMAIL PROTECTED]
> Sent: 22 May 2008 17:11
> To: Maven Users List
> Subject: RE: Certification build question
>
> Rich,
> It's very common for corperations to implement this sort of thing. It
> helps ensure that the products can be rebuilt from the source code, and
> that helps certain audit/security processes. In any case, this is what
> my company does, and they pay me every two weeks.
>
> I do what you suggest for internal and informal releases of test tools
> and report generators.
>
> -Chris
>
> -----Original Message-----
> From: Richard Chamberlain [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 22, 2008 12:00 PM
> To: Maven Users List
> Subject: RE: Certification build question
>
> Why do the team need to build your application? Can you not give them a
> built version for them to test?
> If you can do this, have an application project that depends on all the
> components that you use. Configure the assembly plugin to zip all the
> dependencies into a kit. You can then tell them to pick up this version
> of the application from the repository and test it.
>
> Hope I understood correctly.
>
> Regards,
>
> Rich
>
> -----Original Message-----
> From: Chris Helck [mailto:[EMAIL PROTECTED]
> Sent: 22 May 2008 16:14
> To: Maven Users List
> Subject: Certification build question
>
> Hi,
> We have multiple components and applications. When I hand an application
> over to our certification team to build I need to tell them which (if
> any) dependent components they need to build. So every release I have
> provide specific instructions of the form:
>      From SCM get this label, build with mvn
>      From SCM get another label, build with mvn
>      and so on.
>
> The certification team hates this. They'd like to build the application
> the same way on every release. The certification team doesn't care about
> low level components, and don't have any way to test them directly.
> Perhaps they should, but that is beside the point.
>
> So my question is how to handle this?
>
> Regards,
> Christopher Helck
>
>
> **********************************************************************
> This communication and all information (including, but not limited to,
> market prices/levels and data) contained therein (the "Information") is
> for informational purposes only, is confidential, may be legally
> privileged and is the intellectual property of ICAP plc and its
> affiliates
>  ("ICAP") or third parties. No confidentiality or privilege is waived or
> lost by any mistransmission. The Information is not, and should not  be
> construed as, an offer, bid or solicitation in relation to any
> financial instrument or as an official confirmation of any transaction.
>  The Information is not warranted, including, but not limited, as to
> completeness, timeliness or accuracy and is subject to change  without
> notice. ICAP assumes no liability for use or misuse of the  Information.
> All representations and warranties are expressly  disclaimed. The
> Information does not necessarily reflect the views of  ICAP. Access to
> the Information by anyone else other than the  recipient is unauthorized
> and any disclosure, copying, distribution or  any action taken or
> omitted to be taken in reliance on it is prohibited. If  you receive
> this message in error, please immediately delete it and all  copies of
> it from your system, destroy any hard copies of it and  notify the
> sender.
> **********************************************************************
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> **********************************************************************
> This communication and all information (including, but not limited to,
>  market prices/levels and data) contained therein (the "Information") is
>  for informational purposes only, is confidential, may be legally
>  privileged and is the intellectual property of ICAP plc and its
> affiliates
>  ("ICAP") or third parties. No confidentiality or privilege is waived or
>  lost by any mistransmission. The Information is not, and should not
>  be construed as, an offer, bid or solicitation in relation to any
>  financial instrument or as an official confirmation of any transaction.
>  The Information is not warranted, including, but not limited, as to
>  completeness, timeliness or accuracy and is subject to change
>  without notice. ICAP assumes no liability for use or misuse of the
>  Information. All representations and warranties are expressly
>  disclaimed. The Information does not necessarily reflect the views of
>  ICAP. Access to the Information by anyone else other than the
>  recipient is unauthorized and any disclosure, copying, distribution or
>  any action taken or omitted to be taken in reliance on it is
> prohibited. If
>  you receive this message in error, please immediately delete it and all
>  copies of it from your system, destroy any hard copies of it and
>  notify the sender.
> **********************************************************************
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
cheers,

- a

Reply via email to