Hi, everyone. I'm new to this list, and learning maven. On September 1 there was a thread about reproducing Maven builds, and the thread petered out. I have the same question. The thread is below, after my sig. The last comment was that you should be able to just keep a copy of your localRepository and use that to re-create a build at any time in the future. Well, that's what I thought, too, but it does not seem to be true. With the repository setup we have here, I end up with snapshots of plugins, and those snapshots are not recognized as valid by maven. For example, I end up with a 2.2.1 snapshot of maven-clean-plugin. Maven for some reason wants version 2.1 of maven-clean-plugin and the build fails if I give it the repository (the localRepository from a previous successful build) that has only the snapshot. Is there an established or recommended method with Maven to ensure that a current build can be reproduced bit-for-bit at some time in the future? e.g. when a customer reports a bug and we need to re-create the software for patch purposes? Should we avoid snapshots? Is there anything else to avoid? I have another question, which is about snapshots and releases. The example of the master POM shows a <releases> element and a <snapshots> element. I'm wondering about the semantics of those. thanks, Marilyn Sander ======================================================================= Well run "mxn -X deploy" and you should get all plugins used up to and including deploy goal. Assuming all your plugins are bound to a proper lifecycle phase, they should all show up in that list.
Another good component (imo) in guaranteeing a reproducable build is a Corporate Maven repo and proxy. But yes, a copy of the local repo in your user home directory should be sufficient. Wayne On 9/1/06, Scott Tailor <[EMAIL PROTECTED]> wrote: > Thanks for the tip. But doesn't "mvn -X install" only show you the > plugins you are using when running install? > > Assuming one can get a complete list of plugins and their versions, does > that mean all I needed is the maven-2.0.4.zip file, a copy of the local > repository, and the project's pom files (with the locked down plugin > versions) to be able to reproduced the same build I have today three > years from now? > > /Scott > > > -----Original Message----- > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Geoffrey De Smet > Sent: den 1 september 2006 10:44 > To: [email protected] > Subject: Re: Reproducing maven builds versus auto updating maven. > > Lock down all your plugin versions. > <plugin> > <groupId... > <artifactId... > <version>2.0-beta5</version> > ... > > Since I 've done that I experience it as being much much more in control > > over the build process. When a new plugin is released, I change the > version and test it locally first before committing it. > > Do a mvn -X install to find out which plugins you're using. > > Scott Tailor wrote, On 2006-09-01 10:23 AM: > > I recently gave a quick hands on introductions to Maven (v2) at the > > company I'm currently consulting at. The company is now interested in > > testing maven out in a project. There are two major and related > concerns > > I have though with using maven: > > > > > > > > 1. Maven updates itself at a regular basis. Occasionally an update > > seems to break maven. It has happened once to me, but I know of > another > > person who says it has happened more than once. I assume there is a > way > > to tell maven not to update itself, correct? If so, how? > > 2. Another problem is if we use maven to build an application > > today, and then two years need to come back to the code and make > > changes, how can we be sure we can still build it? How do we preserve > > the build environment for each maven project? > > > > > > > > Any help/info greatly appreciated. > > > > /Scott > > > > > > -- > With kind regards, > Geoffrey De Smet >
