On 07.09.2010 09:56:00 Craig Ringer wrote: > On 7/09/2010 1:52 PM, Jeremias Maerki wrote: > > Well, Ivy has one fundamental problem in common with Maven that many regard > > as a great feature: the repository. Numerous times, I couldn't get a Maven > > build to complete successfully because some artifact was temporarily or > > permanently unavailable. > > First: I'd like to note that none of the following is meant to sound > like some kind of "ra ra ra you should use maven and only maven, maven > is the truth and the light". It's just a tool, and like all tools has > things it's good for and things it's not so good for.
I didn't take it that way. My apologies if I made that impression. I myself can't stand Maven. I can't speak for the whole FOP project. But see my last paragraph below for the reason I react so strongly when Maven is brought up. > That said, I've never had issues with remote repositories - I routinely > use sonatype nexus (jboss) repos, Central, java.net, and a couple of > private repositories. > > I guess it helps that once files are fetched by maven and cached in the > local repository, that's it. Unless you change a dependency's version or > use snapshot versions, there's no more network access. It wasn't always like this. Maybe they improved on it in later version. I distinctively remember when I tried to compile Cocoon during the hackathon at ApacheCon Ireland 2006. I've had at least four Cocoon committers at the table to help me and I still spent a whole day unsuccessfully trying to compile it. Every time I ran Maven it failed in a different place. Undoubtedly, Maven has improved since then, but if I watch my colleagues struggling with Maven in a webapp project today, I can basically just pity them. > There's always the option of doing the same thing you currently do with > ant - bundle copies of the dependencies in shipping versions or maintain > a separate "3rd pty dependencies" repo under version control. I guess I > don't really see the difference. That could solve the problem for users compiling the distribution but not those working off SVN. > Here I keep a common repo under version control, but that's mostly to > save download time on big files, and is exactly the same thing I do for > non-Maven resources like JDK snapshots. It would insulate me a bit from > transient failures in remote repositories, though. That's what I tried to do using Ivy. Sadly without luck. Ivy's resolver wasn't good enough and I didn't get help from the Ivy community. It was much easier to drop it than to try and fix the problem myself. Maybe Maven is better at this. Still, I prefer the flexibility of Ant with imports and macrodefs. > (I do wish that Maven would print a warning and use the last-downloaded > -SNAPSHOT version if it didn't have network access and snapshot updates > were enabled, though. It's the only area where connectivity requirements > do cause me issues.) > > > And how many times did a Maven/Ivy build > > download half the Internet just to build a small project? > > Generally only if it's misconfigured, or that small project uses > plugins/libraries with a lot of dependencies. In the latter case, you're > going to need to get them one way or the other. > > > My Eclipse's Maven and Ivy plug-ins are > > long uninstalled because of the trouble they caused. > > Aaah. I don't use Eclipse - and given the nature of my experences with > it when I've tried using it for something, I wouldn't be surprised by > problems. But even running "mvn eclipse:eclipse" didn't always give my a project setup that worked. :-( > I use NetBeans for most work, and the command line where convenient. > > I don't suppose you were relying on any SNAPSHOT version plugins or > libraries? Because if you were and you had snapshot updates enabled (the > default - unfortunately IMO) then I can certainly see it seeming like it > wants to download the internet whenever you run a build. Sometimes that could have been the case when working with third-party projects like Felix. But I think if you have to know such subtleties, that's a problem by itself if you're just trying to compile something. > > Another problem of an external repository is the lack of license > > management. ASF projects have clear requirements what kinds of > > dependencies are allowed. If you can't control transitive dependencies > > based on a license policy you're bound to run into a problem there. > > Now that can be a problem. Again, though, I'm not sure how different it > is to a 3rd party library you use bundling libraries of unknown > licensing as dependencies. Either way, you have to check. Yes, you have to check but you have everything under control locally and can then document the dependencies in a text file that makes it easy for users to verify a project against their own license policy. And a dependency upgrade will immediately show additional dependencies which gives you a trigger to check the licenses of the new depencendies, too. Glenn mentioned the license reporting feature of Maven. AFAIK, this is a fairly recent addition and I've had to realize that license information is still sketchy for many libraries. > release Maven artifacts won't change dependencies without a version > change, and you have to do that kind of checking whenever you update > anything, maven-based or not. That's true. > > I can check out (or extract) FOP and build at least a basic version > > locally with no outside connection. I like that and would like it to > > stay that way. > > The same is true with Maven. It doesn't have to try to download the > Internet, nor does it need 'net access for builds. I routinely do (re) > builds on my laptop while disconnected. > > I have the required artifacts in my local ~/.m2 repository already, and > that's all I need. If I was using an Ant project I'd have to have > obtained the required dependencies to put on the classpath somehow; same > deal. Whether I populate my ~/.m2 from Internet repositories, or check > out a private pre-populated maven repo from version control, I still > have to obtain it somehow. I guess that private pre-populated maven repo under version control sounds most appealing to me because it addresses my concerns. It's something similar to what I do in my private projects (with Ant). > That said, I do find that the way it doesn't tend to include most of the > core plugins in the initial Maven download - and therefore fetches them > when you first do a build - to be annoying. > > -- > Craig Ringer > > Tech-related writing at http://soapyfrogs.blogspot.com/ I guess we're in a "religious" dispute here, like PC vs. Mac. So we can't expect to reach a consensus. Anyway, I won't to stand in the way if something is added to FOP that can help some users. But I consider Maven viral as we're seeing here. Due to its inflexibility, projects are almost forced to adopt it to keep everyone happy, just because Maven can't include a simple JAR that is not in a repository. At least, that's what my colleague ran into. Jeremias Maerki
