Re: Certification build question
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
Re: Certification build question
or use hudson as it's easier to setup and maintain On Sat, May 24, 2008 at 1:32 PM, Arun Kumar [EMAIL PROTECTED] wrote: 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
Re: Certification build question
On 5/22/08, Chris Helck [EMAIL PROTECTED] wrote: 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. From my experience, the reproduceability problems can happen from various factors, but most of them will be detected by using a build server. Some will still go throught: e.g. that can easily happen with maven 2.0.x when using non versionned plugins in the POMs. Happened to me again today: http://jira.codehaus.org/browse/MNG-3594 If you really want to double check things, you should do it in a different manner, and compare the results. That's what back up systems do for critical systems. But that is very costly. It is certainly possible to have one build server monitoring the CSM and another trying to reproduce the builds e.g. from information found in the released POMs and artifacts. That's a lot of trouble for not much gain to my point of view. Except if you work for the NASA :) One simple idea: use 2 build environments, one for your development team, one from your 'secure' team. Build all the time, and compare the produced artifacts (maybe using some sort of checksums). Make sure each artifact contains enough information (e.g. make it include the revision number the artifact was built from). Another idea: add a build server to rebuild your past tagged project. That's particularly useful for long lived branches. Always add a build triggered by time instead of just commits. Finally make sure that any tool used in the build, from the SDK to the zip tool, has a locked down version number, and a check that ensures potential problems are detected early. Make your build tool write those versions in the log. And keep your build logs. Jerome - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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. **
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]
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]
RE: Certification build question
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
