On Sun, 2004-02-01 at 21:52, Dalibor Topic wrote: > Hi Jason, > > 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.
Well, there are certainly can be a few quirks but a comparison between free runtimes that are so far behind currently used specifications, or not even compliant, and JVMs that most people use isn't really relevant in most cases. The unwarranted assumptions you speak of are things that are present in non-compliant JVMs. While I certainly agree with you that [1] can easily be remedied you are the first and probably only person to catch [1]. While it's nice having things like Kaffe and Jaguar they are not products that people reach for first when developing with Java. I would like to use Kaffe but in the few times I've tried it's been a world of hurt. But I will certainly fix [1], that's not really a big deal. > > 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. No, that's simply not true. How would using an OS repository over Maven's own repository help with this in any way shape or form? All the information necessary to build the project is available in the POM. So all you need to do is get your hands on the POM and you could very easily make a tool to build a project. > 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. Fair enough, though the policy that we will be instituting will incorporate a level of security with binaries that most people will be comfortable with. > 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. So what advantage would a native package manager have over Maven doing this? > > 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. Ok, but I still don't see why Maven would benefit at all from trying to use an OS specific repository when we have a non-OS specific repository. > 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. Costin Manolache here at Apache has played with things like Ant and Tomcat to produce binaries with GCJ and unless things have changed drastically in the recent past there really wasn't much of a difference in speed other than startup time. Not to say that these things aren't interesting but the JVMs people typically use are fast enoug. > Then there is Gentoo > Linux, that takes the ability to rebuild from source to the max. And so on. Building from source is not a problem, all the information you need is present in the POM. > 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. Java developers don't want to care about Platform specific constraints, or non-compliant JVMs generally. > 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. Again, these are things that you can suggest projects adhere to but these are not things you can force projects to do. > 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. Again, why are you trying to make Java developers think of platform specific issues. These are in fact the things that we want to avoid. > > 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. Well, why do assume that we don't want the same thing? We in fact do, but we want something that is not specifically targeted at one particular OS. Having use an OS specific repository might possibly be an option but I would never advocate it being the default. That's just not going to happen. > 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. That's not something we ever tried to solve. And I'm willing to bet it's something the vast majority of Java developers don't think about because they don't use Java packages bundled up in RPMs or the like. > 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. Yes, but we are trying to do it in non-platform specific way. > > 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. Yes, but that was generally the practice before Maven came along. No large segment of the Java developer population was using native Java packages are probably still aren't and probably won't in future I would wager. > 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" ;)) What benefit is there to general, non-platform specific development in using OS specific repositories of Java packages? We are obviously coming from different ends of the spectrum but I'm not convinced there is any benefit at all. If Maven had to deal with Linux type packaging systems, which are numerous, and ports like systems on BSD and then Windows and whatever else that would nullify the essential benefit of Maven which is to make cross-platform development easier. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
