You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Chris Helck <Ch...@us.icap.com> on 2008/05/22 17:14:11 UTC
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
Posted by Jerome Lacoste <je...@gmail.com>.
On 5/22/08, Chris Helck <Ch...@us.icap.com> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Certification build question
Posted by Stephen Connolly <st...@gmail.com>.
or use hudson as it's easier to setup and maintain
On Sat, May 24, 2008 at 1:32 PM, Arun Kumar <pg...@gmail.com> 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 <
> richard.chamberlain@caplin.com> 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:Chris.Helck@us.icap.com]
> > 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:richard.chamberlain@caplin.com]
> > 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:Chris.Helck@us.icap.com]
> > 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: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> > **********************************************************************
> > 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: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
>
> --
> cheers,
>
> - a
>
Re: Certification build question
Posted by Arun Kumar <pg...@gmail.com>.
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 <
richard.chamberlain@caplin.com> 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:Chris.Helck@us.icap.com]
> 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:richard.chamberlain@caplin.com]
> 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:Chris.Helck@us.icap.com]
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> **********************************************************************
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
cheers,
- a
RE: Certification build question
Posted by Richard Chamberlain <ri...@caplin.com>.
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:Chris.Helck@us.icap.com]
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:richard.chamberlain@caplin.com]
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:Chris.Helck@us.icap.com]
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
**********************************************************************
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Certification build question
Posted by Chris Helck <Ch...@us.icap.com>.
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:richard.chamberlain@caplin.com]
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:Chris.Helck@us.icap.com]
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
**********************************************************************
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Certification build question
Posted by Richard Chamberlain <ri...@caplin.com>.
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:Chris.Helck@us.icap.com]
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org