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

Reply via email to