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]
Re: How to inherit dependencies for compile+tests but not package them in the build ?
On Sat, May 24, 2008 at 7:18 AM, Fabien Coppens <[EMAIL PROTECTED]> wrote: > Ok a basic solution would be to copy-paste all those provided-scoped library > dependencies into the Poms > of all projects that have a dependency on Persistence, but that is > cumbersome and error prone. Would the new 'import' scope in Maven 2.0.9 help with this? http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to inherit dependencies for compile+tests but not package them in the build ?
Yes I've tired that, but if that dummy module has a provided or test scope, the problem is the same : the dependencies are lost to transitivity. Stephen Connolly wrote: You could have a second (dummy) module that depends on persistence, has all it's dependencies, and then just add that as either scope provided or test to the modules that you need On Sat, May 24, 2008 at 4:11 PM, Fabien Coppens <[EMAIL PROTECTED]> wrote: Yes, but doesn't that mean adding the list of build exclusions to each and every project that has a dependency on Persistence (because they are each being tested and built sperately by different teams) ? It's as cumbersome as adding the whole list of dependencies with "provided" scope in each of those modules; Bryan Loofbourrow wrote: I have several modules that have a dependency on a PERSISTENCE module. Said Persistence module has a bunch of dependencies on jars of scope "provided" because they will actually be available directly in the app server's out-of-the-box libraries. My modules that depend on Persistence need to see the libraries that Persistence declares in its Pom, both for compilation and for tests (UTs are run outside of the app server), BUT since those jars are declared with scope "provided" in the Persistence module's Pom, the command line build fails << I can see how "provided" is of limited usefulness in this situation, being non-transitive. So why not use "compile" scope and filter those jars out when you build your deployable war/ear? - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.24.1/1463 - Release Date: 5/23/2008 3:36 PM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to inherit dependencies for compile+tests but not package them in the build ?
You could have a second (dummy) module that depends on persistence, has all it's dependencies, and then just add that as either scope provided or test to the modules that you need On Sat, May 24, 2008 at 4:11 PM, Fabien Coppens <[EMAIL PROTECTED]> wrote: > Yes, but doesn't that mean adding the list of build exclusions to each and > every > project that has a dependency on Persistence (because they are each being > tested and built > sperately by different teams) ? It's as cumbersome as adding the whole list > of dependencies > with "provided" scope in each of those modules; > > > Bryan Loofbourrow wrote: > > I have several modules that have a dependency on a PERSISTENCE >>> module. >> Said Persistence module has a bunch of dependencies on jars of scope >> "provided" because >> they will actually be available directly in the app server's >> out-of-the-box libraries. >> My modules that depend on Persistence need to see the libraries that >> Persistence declares >> in its Pom, both for compilation and for tests (UTs are run outside of the >> app server), BUT since >> those jars are declared with scope "provided" in the Persistence module's >> Pom, the command line >> build fails << >> >> I can see how "provided" is of limited usefulness in this situation, >> being non-transitive. So why not use "compile" scope and filter those >> jars out when you build your deployable war/ear? >> >> >> - >> 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] >> >> >> >> >> >> > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
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 mistra
Re: how to import multi module maven project to eclipse?
oliver.maven wrote: > i want the imported project to be viewed in hierachy structure as one > whole project and each module also can be regarded as one maven project. Eh, maven-eclipse-plugin -> submodules as maven projects m2eclipse -> one hierachical project in eclipse. You have to choose which you prefers Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to inherit dependencies for compile+tests but not package them in the build ?
Yes, but doesn't that mean adding the list of build exclusions to each and every project that has a dependency on Persistence (because they are each being tested and built sperately by different teams) ? It's as cumbersome as adding the whole list of dependencies with "provided" scope in each of those modules; Bryan Loofbourrow wrote: I have several modules that have a dependency on a PERSISTENCE module. Said Persistence module has a bunch of dependencies on jars of scope "provided" because they will actually be available directly in the app server's out-of-the-box libraries. My modules that depend on Persistence need to see the libraries that Persistence declares in its Pom, both for compilation and for tests (UTs are run outside of the app server), BUT since those jars are declared with scope "provided" in the Persistence module's Pom, the command line build fails << I can see how "provided" is of limited usefulness in this situation, being non-transitive. So why not use "compile" scope and filter those jars out when you build your deployable war/ear? - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to inherit dependencies for compile+tests but not package them in the build ?
>> I have several modules that have a dependency on a PERSISTENCE module. Said Persistence module has a bunch of dependencies on jars of scope "provided" because they will actually be available directly in the app server's out-of-the-box libraries. My modules that depend on Persistence need to see the libraries that Persistence declares in its Pom, both for compilation and for tests (UTs are run outside of the app server), BUT since those jars are declared with scope "provided" in the Persistence module's Pom, the command line build fails << I can see how "provided" is of limited usefulness in this situation, being non-transitive. So why not use "compile" scope and filter those jars out when you build your deployable war/ear? - 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]
How to inherit dependencies for compile+tests but not package them in the build ?
Hi all. I have several modules that have a dependency on a PERSISTENCE module. Said Persistence module has a bunch of dependencies on jars of scope "provided" because they will actually be available directly in the app server's out-of-the-box libraries. My modules that depend on Persistence need to see the libraries that Persistence declares in its Pom, both for compilation and for tests (UTs are run outside of the app server), BUT since those jars are declared with scope "provided" in the Persistence module's Pom, the command line build fails (the build actually works in Eclipse because the M2Eclipse plugin apparently ignores the scope for compilation, because I see all the jars in the maven dependancies in Eclipse, but I'm straying from the point here). Ok a basic solution would be to copy-paste all those provided-scoped library dependencies into the Poms of all projects that have a dependency on Persistence, but that is cumbersome and error prone. If anyone has a better idea, I'm a taker. Fabien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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. I
Re: convert a maven project and xslt:transform
are you looking for something like this: mvn exec:java -Dexec.mainClass=org.apache.xalan.xslt.Process ? if yes, then may be you can configure a mvn command in eclipse that will execute the above to generate the xsl... sorry if i misunderstood. On Thu, May 22, 2008 at 9:22 PM, Mansour <[EMAIL PROTECTED]> wrote: > Thank you Javier, but how do I perform the transformation ? > or in other words, in order to execute a transformation using xalan, I need > to do this: > java org.apache.xalan.xslt.Process -xsl myxsl.xsl -in in.xml -out out.xml > > How do I get this done from maven ? I have figured it using > xsl-maven-plugin, but I am interested in knowing if there's another way. > > Thank you. > > > Javier Diaz wrote: > >> Hi: >> >> First step is to create a pom for your project. Then add xalan as a >> dependency, for example: >> >> >> xalan >> xalan >> 2.7.0 >> compile >> >> >> And that should be enough. >> >> Regards, >> >> Javier >> >> Mansour wrote: >> >>> Hello: >>> I have been using maven for few month. I use it through eclipse plugin >>> and only for getting the dependencies for the projects. Now I think I need a >>> little more of maven. I have a project that has an xslt transformation. This >>> project is NOT a maven project. I checked the source out of svn and >>> attempted to run the transformation. However, it turned that xalan is not >>> installed on this machine. I have not installed a jar file since I started >>> using maven. It does everything I need from downloading the file to adding >>> it to the classpath. I thought maven can help here in getting the >>> transformation done. >>> I googled http://mojo.codehaus.org/xslt-maven-plugin/transform-mojo.htmlbut >>> no example. Can someone give the steps to run this transformation? and >>> possibly convert the project to maven? >>> >>> I have checked this http://maven.apache.org/plugins/ and couldn't find >>> anything related to xslt. >>> >>> >>> >>> - >>> 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] >> >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- cheers, - a
