Jason van Zyl wrote:
There may one day be a bridge to adapt Maven's repository to native systems for things like distributions but when a project creates a Maven POM they expect it to work for people developing on all platforms. They aren't concerned about platform specifics and this has never really been the concern of Maven insofar as development goes.
In my experience (with getting different programs to run on free runtimes), things never work out of the box on all platforms, usually. For example, Maven has an ugly dependency on a sun.* class[1]. Thus Maven in CVS breaks on java runtimes that don't [2] implement sun.* classes. A lot of other java code makes unwarranted assumptions about its runtime [3]. Writing portable java code is probably as hard as writing portable C code.
If I understand you correctly, are you saying that for development purposes Maven should be leveraging platform specific repositories?
Yes, if such repositories are available. Otherwise it becomes quite hard to rebuild maven applications from source to verify their integrity, i.e. that they haven't been tampered with.
As far as I understand the concept, Maven uses JARs and provides a method for downloading them from a central repository. For systems putting a high priority on security, downloading binaries may not be good enough. You may want to be able to rebuild everything from scratch, in order to be able to apply a quick source code patch for a security problem for example, and be able to put it all back together.
I agree with you 100% that Java applications that are packaged up should surely be available in the form of packages that work on various systems. I mailed the JPackage group long, long ago and gave them a heads up on what was going on in Maven land and there was no interest.
As far as I can tell, there is a lot of interest now between the various java application packaging projects in the Linux world for cooperation between each other. It took a while until free java runtimes like kaffe [4] caught up, and started to become suitable platforms to run current jakarta [5] (or other) applications [6] on.
Then there is a lot more cooking than JPackage. Naoko and RHUG are RedHat's efforts to use gcj to create very fast native executables and libraries from java applications and libraries. Then there is Gentoo Linux, that takes the ability to rebuild from source to the max. And so on.
I assume that long, long ago people weren't as aware of Maven, as they are now. Maven is getting close to 1.0, after all, and has received some well-deserved attention lately ;)
The whole power behind Maven is leaving things up to the project
offering their work. Leaving the production and deployment up to the
project.
While it's obviosly quite clever to leave the production to the project ;), I have some doubts about deployment. Platform specific constraints may exist, that a project is not aware of.
A small example: Debian is one of the huge Linux distributions. It has a lot of users and a vital developer community. Among other nice things, Debian has a Social Contract [7] and an associated set of software guidelines [8]. Those software guidelines make specific requirements on licensing of software that comes with debian. So some applications may need to be split into free and non-free parts in order to get into debian.
Some Jakarta projects [9], for example, have dependencies on non-free software that make it quite hard to put them in the form in which they are released by their developers into debian. They need to be 'sanitized' first.
This is just a small example of platform-specific adaptations being necessary. Putting the burden for them on the project is not very helpful in the short run, I think.
Could you not leverage the repository to make your platform specific
packages for those that wanted to use platform specific packagers?
Well, there is more to packaging than downloading the binaries ;)
You should also want to be able to verify the integrity of the files, to rebuild the binaries if necessary, to uninstall no longer needed packages, to update packages, etc.
Maven is a useful build tool. It's also a very nice site-generation system, and probably a few more things that I haven't caught up reading about yet. OTOH, it's not a replacement for a package management system like rpm, urpmi, or dpkg, as far as I can tell.
I think there is some room for cooperation (and interesting dialogue) between the various java packaging projects and Maven developers. They all try to solve the 'satisfying dependencies' problem, for example.
I only use Linux and I honestly never use JPackage packages. As I mentioned above I doubt many people do simply because Ant doesn't have a repository concept, people usually checked artifacts into CVS.
Well, one of the things we both can agree upon very easily is that checking in artifacts into CVS is a bad idea. That's like checking in object files.
Maven is changing that, finally. That's a good thing, and I applaud the Maven developers for that. Though, in my opinion, it could be an even better thing if we could get Maven to leverage the existing package management systems instead of just being a better "Napster for JAR files" ;))
cheers, dalibor topic
[1] That I submitted a patch for to JIRA, btw, so if someone could review and check it in, I'd be very pleased ;)
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-1129
[2] and can't, since they are undocumented
[3] I'm currently involved with cleaning up OpenOffice. No, you don't want to know ... ;)
[4] http://www.kaffe.org
[5] http://www.kaffe.org/~robilad/tomcat-4.1.29-screenshot.png
[6] http://www.kaffe.org/~robilad/jboss-3.2.2-screenshot.png
[7] http://www.debian.org/social_contract
[8] http://www.debian.org/social_contract#guidelines
[9] Hello, FOP! ;) But I now have got Batik and FOP developers to talk together about cooperating on some ImageIO functionality, which would remove a major blocker (JIMI).
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
