Nicolas Mailhot wrote:
I'm done with this. The result is available at:
It says final version is forthcoming. I was afraid to make edits just yet. And I would like to see each point numbered and lettered so that they can be easily refered to. Like we could say, ``this is a violation of IIa'', for example.
Anyway, it's interesting to see how many of these principles that maven violates. The funny thing is that I assume the developers of maven think that they are alleviating some of these problems when, IMO, it is just more of the same thing.
I'm worried that the consensus is that more and more projects will be moving from ant to maven. I admit to not being very experienced with maven, so someone else who is more familiar should offer some more comments. But, from my point of view:
1.) Maven looks a heck of a lot more complicated then a simple build.xml.2.) Although the name, ``version'', and some kind of URL of the archive is listed, you actually have no idea at all what version is even in the maven repository as names and versions are still different than the original software in a lot of cases.
3.) Maven projects tend to need an additional build sanbox, and an existing maven repository, and the maven repository obviously gets around the operating system's package manager, and thus, this only seems good (if at all), on operating systems which have no package manager.
4.) One does not have the facilities locally to even build a maven project.5.) Full internet access is required, and potentially unlimitied bandwidth. Watching a maven project download some 20 jars, 15 of which I already have on my system is a little painful since I'm dealing with a bandwidth limit.
6.) Due to the versioning meachanism in maven, I am not sure how the CLASSPATH can be honored.
Specifically important to some large projects are the points that:1.) If you have several subprojects each using different jars, wouldn't it be better to have them all share the same vesions of their dependencies?
2.) Bundling jars becomes crufty and potentially bugridden. Sometimes projects die, and there is no way even to get the source code of these jars without, say, decompiling them, and even then, versions of Java may tend to be incompatible, and decompilers are not perfect. And in projects like the Eclipse Project, we see multiple copies of the same jar, or different versions of the same jar *in the source archive*. What a maintenance nightmare.
3.) Projects tend to assume the layout of the filesystem, and sometimes don't even honor the CLASSPATH. If you're lucky, the local jar directory is added with a wildcard. If not, the packager has to make sure he gets even the names exactly right, and every project likes to name their jars something different.
Anyway, maven, seemingly creates large fragmentation within projects. A large database of different and incompatible jars, instead of a single, coherent version. Moreover, downloading every archive in a repository from the internet is insane, but I also dread the fact that we may have to mimic a maven repository in JPackage, and this doesn't sound fun at all. RPM (or dpkg or whatever) was already doing that job for us.
-- Sincerely, David Walluck <david@anti-microsoft.org>
Attachment:
signature.asc
Description: OpenPGP digital signature