Comments Inline > Here is what I excpect for a reliable build system : > > - I want to build version X with maven plugins that > have been used when > I tagged the version X.
Plugin versions can be specified in the pom. project > build > plugins > plugin > version >In two years, I want those > plugins to be > available, even if they are full of bugs, just > because the build has > been validated when X tag has been created. I don't > want ANY plugin to > be updated on the fly. Is it possible ? At http://www.ibiblio.org/maven2 all the builds of various plugins and implementations/apis have been versioned. I suspect the same is true for most other repositories like codehaus. The only way to protect against someone changing an existing version, or removing it, is to download that version into the local maven repository, and check that version in with the build or create our own maven plugin repository, and keep the plugin versions there. So we should do this if we consider that version to be critical to that build, and we really really want to make sure we can come back and rebuild any time. If we check the version in with the build, we have to document that so that someone can restore it to a local maven repository. If apacheDS has its own plugin repository, then we just point maven there, and away we go. That repository could also be used by anyone to build specific versions of ADS. > > - I want to build version X with the jars that have > been used to create > the version. I don't want to change the pom.xml > files just because the > remote repository has disapeared or the server name > has been changed to > something different. I don't want that somebody - > for any good or bad > reason - has modified a pom.xml of any jar just > because he realized that > something were wrong when this jar has been pushed > on the maven repository. Same answer as above. We have to localize it. > That means we *must* have our own private local > repository with all the > jars used by a version tagged and stored on > subversion, and that we > *NEVER* download a jar from a remote repository. Yup - So we would just initialize the local repository - then set the offline attribute in settings.xml, so that maven does everything offline. > Remote repository > totally break the notion of reliable build. It's > against common sense Well - Personally - I have to say I love being able to add a dependency and have maven take care of the rest. I've never experienced anyone changing an existing version of a plugin or dependency api, thus breaking my build. Although you are right, we still need to buffer against that. Setting up a maven plugin repository is really easy though. > when you have products running in production and > that you need to figure > out what is going on for a user, and that you need > to recreate it's > environnment. > The remote repository concept is good when you want > to get some new > jars, but not for an old version. > I think what gets put on ibiblio stays there for a long time. We could check with them to see if they have some sort of version rotation policy. In the end the only way to really protect each build is to have a local repository with plugin and api dependencies in it, as well as the version of maven that was used for the build. > We also have some other disturbing points : > - maven should work offline by default. Set the offline attribute in settings.xml before firing up maven. > plugin available. Download ? [n]". Of course too, > this question should > be asked only once for a specific version. A > "upgrade-plugins" mode > should also be available. Settings.xml has a releases element that has an updatePolicy attribute. Here's what the doc says about it: updatePolicy The frequency for downloading updates - can be "always", "daily" (default), "interval:XXX" (in minutes) or "never" (only if it doesn't exist locally). And plugins should be > stored in the local > repository, and versionned in svn, like jars. > - Surfire should be improved to store errors in a > separate directory > than success. When you have something like dozens > tests in a directory, > this is painfull to check all of them to know which > ones have failed > (but this is a maven issue, not an apacheds problem > ;) I know that surefire is supposed to create a nicely formatted html report: http://maven.apache.org/plugins/maven-surefire-report-plugin/report-mojo.html I'd have to look and see precisely what it reports on though. > > May be we can use middle term solutions like storing > checksums of jars > in svn to avoid storing full jars, but, IMHO, jars > are not changing > every days, and we don't have thousands of them, so > I think this will > just means more work to save few mega bytes... That sounds like a really good idea! --- Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > Ok, guys, I think we have a recurrent problem with > builds. > > We need a build system that is reliable, > reproductible, and not only > for the last version, but for a tag that is 2 years > old. If I want to > build last year 0.8 version of apache ds, i should > be able to do so. > With maven, atm, this is totally impossible, because > repositories are > moving, plugins are moving, and this could break > everything. > > We have to find another way to build this project. I > am serious about > that. It's just not "maven is cr*p" or "ant is > better", is much more a > question of what should be done to be able to > guarantee that a simple > user check out the full project and build it on its > platform, any time, > anywhere, for any version. > > Here is what I excpect for a reliable build system : > > - I want to build version X with maven plugins that > have been used when > I tagged the version X. In two years, I want those > plugins to be > available, even if they are full of bugs, just > because the build has > been validated when X tag has been created. I don't > want ANY plugin to > be updated on the fly. Is it possible ? > > - I want to build version X with the jars that have > been used to create > the version. I don't want to change the pom.xml > files just because the > remote repository has disapeared or the server name > has been changed to > something different. I don't want that somebody - > for any good or bad > reason - has modified a pom.xml of any jar just > because he realized that > something were wrong when this jar has been pushed > on the maven repository. > That means we *must* have our own private local > repository with all the > jars used by a version tagged and stored on > subversion, and that we > *NEVER* download a jar from a remote repository. > Remote repository > totally break the notion of reliable build. It's > against common sense > when you have products running in production and > that you need to figure > out what is going on for a user, and that you need > to recreate it's > environnment. > The remote repository concept is good when you want > to get some new > jars, but not for an old version. > > Those two conditions are mandatory. If one of them > is missing, then we > should push a request to maven to fix something. If > it's not possible > before we release ADS 1.0, then we may consider > switching to another > build tool. > > We also have some other disturbing points : > - maven should work offline by default. I don't > know if there is some > options we can set in the configuration files to > allow this mode by > default ( and not have to type maven -o) > - if new versions of plugins are available, then > maven should ask if it > is allowed to download them, and not dowload them by > default (of course, > the default answer will be no, not yes : "version > x.y.z of surfire > plugin available. Download ? [n]". Of course too, > this question should > be asked only once for a specific version. A > "upgrade-plugins" mode > should also be available. And plugins should be > stored in the local > repository, and versionned in svn, like jars. > - Surfire should be improved to store errors in a > separate directory > than success. When you have something like dozens > tests in a directory, > this is painfull to check all of them to know which > ones have failed > (but this is a maven issue, not an apacheds problem > ;) > > May be we can use middle term solutions like storing > checksums of jars > in svn to avoid storing full jars, but, IMHO, jars > are not changing > every days, and we don't have thousands of them, so > I think this will > just means more work to save few mega bytes... > > So, now, we have some points we need to discuss : > - we don't have Maven active experts right now, and > may be some of you > would give us a hand to address those problems > - the need of a local repo, where all the jars are > stored, and > versionned, seems to me mandatory > - plugins should be - like jars - versionned > - offline mode must be the default > > Ok, this is my opinion. I'm sure that you may agree > on some points, and > disagree on others. I just want to start this > dicussion on the ML, as we > now have some more committers, and we need to find a > way to stabilize > the build before 1.0. > > Feel free to express what you think, and it can be > as radical as "Let's > move to ant + ivy". I think that some decision will > lead to a vote at > some point. > > wdyt ? > > Emmanuel > > begin:vcard > fn;quoted-printable:Emmanuel L=C3=A9charny > n;quoted-printable:L=C3=A9charny;Emmanuel > org:IKTEK > adr:;;13 rue Salomon de > Rotschild;Suresnes;;92150;France > email;internet:[EMAIL PROTECTED] > x-mozilla-html:FALSE > url:http://www.iktek.com > version:2.1 > end:vcard > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
