Re: Broken by design
Download from the internet was one of my biggest "fear" as well as versions of underying poms/jars could change which would affect reproducibilty. Additiionally, download from internet could mean you might not be able to build at all if some external site cound not be reached or someone else released a bad version of something. Happily, with a locally maintained artifacory which is configured to not automatically look for newer versions we do not have these types of problems (any more). Regards, Gord On Fri, Aug 14, 2009 at 1:26 PM, wrote: > I must admit the "download the internet" effect is true: everybody can see it > when running Maven for the first time on a computer. > Is that really a problem? IMHO no: > - for personal use, this is done only once (and my ADSL line is fine) > - for corporate use, a repository manager is really welcome, yes > > The most problematic thing in this post is build reproducibility: yes, build > reproducibility is crucial, Maven team knows it. > Maven builds are reproducible. > > But back in '2007: people discovered that build reproducibility was not free, > since you had to define a version in your pom for *every* plugin, even those > that you even don't imagine it's really defined in a plugin > (maven-clean-plugin, for example). The myths of a 5-ligns pom.xml being > sufficient, or auto-update of plugins being a kewl feature, were broken ;) > Yes, this was learned the hard way by many people at that time... > > Later, in Maven 2.0.9, default plugins versions were added in Maven core, so > that even a 5-ligns pom.xml gives a reproducible build: if you stick with a > precise Maven version, you'll get the same build. It's not the best way of > ensuring reproducible build, explicitely defining your plugin version is > still better, but it works. > For more information, see [1] Maven 2.0.9 release notes. > > > HTH > > Hervé > > > [1] http://maven.apache.org/release-notes-older.html > > - Mail Original - > De: "Todd Thiessen" > À: "Todd Thiessen" , "Maven Users List" > > Envoyé: Vendredi 14 Août 2009 14h55:57 GMT +01:00 Amsterdam / Berlin / Berne > / Rome / Stockholm / Vienne > Objet: RE: Broken by design > > > >> We have had some problems with build reproduciblity though. >> But it was because of downloading artifacts. > > Sorry... I meant so say here... It was NOT because of downloading > artifacts... > > Bah. Friday morning... Brain is still not in gear ;-). > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Broken by design
I must admit the "download the internet" effect is true: everybody can see it when running Maven for the first time on a computer. Is that really a problem? IMHO no: - for personal use, this is done only once (and my ADSL line is fine) - for corporate use, a repository manager is really welcome, yes The most problematic thing in this post is build reproducibility: yes, build reproducibility is crucial, Maven team knows it. Maven builds are reproducible. But back in '2007: people discovered that build reproducibility was not free, since you had to define a version in your pom for *every* plugin, even those that you even don't imagine it's really defined in a plugin (maven-clean-plugin, for example). The myths of a 5-ligns pom.xml being sufficient, or auto-update of plugins being a kewl feature, were broken ;) Yes, this was learned the hard way by many people at that time... Later, in Maven 2.0.9, default plugins versions were added in Maven core, so that even a 5-ligns pom.xml gives a reproducible build: if you stick with a precise Maven version, you'll get the same build. It's not the best way of ensuring reproducible build, explicitely defining your plugin version is still better, but it works. For more information, see [1] Maven 2.0.9 release notes. HTH Hervé [1] http://maven.apache.org/release-notes-older.html - Mail Original - De: "Todd Thiessen" À: "Todd Thiessen" , "Maven Users List" Envoyé: Vendredi 14 Août 2009 14h55:57 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: RE: Broken by design > We have had some problems with build reproduciblity though. > But it was because of downloading artifacts. Sorry... I meant so say here... It was NOT because of downloading artifacts... Bah. Friday morning... Brain is still not in gear ;-). - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Broken by design
> We have had some problems with build reproduciblity though. > But it was because of downloading artifacts. Sorry... I meant so say here... It was NOT because of downloading artifacts... Bah. Friday morning... Brain is still not in gear ;-). - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Broken by design
> I can remember other > colleagues telling my "Damn, I spend the last day resolving a > maven problem...". Before Maven, I would spend just as much, if not more time, fighting with builds. As for the link you provided, I think there is some truth to it. But in my view the pros far out way the cons. So ya sure Maven may need to download artifacts a lot. But because everything is modular, very rarely do you need to compile a lot of code. This greatly speeds up build times. So overall, we have seen our build times actually decrease when we went to Maven, not increase. And having a local repo manager does solve most of the issues discussed on that blog (in my view anyway). Contrary to what the author states. We have had some problems with build reproduciblity though. But it was because of downloading artifacts. I believe, although I have not confirmed, is that a plugin is behaving differently on Windows than it does on Linux. But I wouldn't say this is a core Maven issue and conclude that Maven is "broken by design". I would say the design is very sound. My 2 cents... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Broken by design
Hi, while I was searching for a Perl plugin for maven, I found this link in interesting discussion: http://fishbowl.pastiche.org/2007/12/20/maven_broken_by_design/ Since this is quite old, I guess this was already discussed on this list. I am interested if there are solutions for the mentioned problems. At first maven looks like an attractive girl. But I've got a little idea that this girls is gonna get real "bitchy" once put a ring on her finger and live together. What I'm trying to say is, the idea behind maven is promising. But maybe you end up dealing with maven repository and resolution issues as well as plugin version issues instead of working on your project. I can remember other colleagues telling my "Damn, I spend the last day resolving a maven problem...". I especially have concerns about the reliability and repeatability issues. Transitive resolving is a really helpful, but it would be nice if you could do it just once and then have everything on your internal repository, frozen within a version and not having maven touching it again... And if you need to reproduce an earlier version, you just need to check out that particular version and have everything together instead of maven starting to search for plugins again. Any comment is appreciated! Jan - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
