On Wed, 2004-02-04 at 16:02, Dalibor Topic wrote: > I fully understand that you have to prioritize your schedule to fix the > bugs that affect the most users, like any other OSS project with limited > ressources. > > But that clearly shows why Maven wouldn't make for a good software > packaging mechanism to me: you'd have to settle for what works for most > people. Now, what works for most people will not work for a minority. > When they come to you to fix their problems you may not be able to, due > to more pressing bugs on more popular platforms. I foresee a lot of > 'Just use Sun - but Sun doesn't shine on my platform' flamewars down > that road.
I honestly don't get that riled up about it. I fight the fights I can but I'm not going to spend my life battling Sun. I fight them by choosing not to use their APIs where I can. As far as Maven goes you can send us patches and we will apply them to make Maven work with Kaffe. I personally don't care whether anyone uses Maven or not. Obviously I would like it if they did but it's no skin off my back. You'll see from any history of discussions that involve me that I'm not very dogmatic. If Maven doesn't suit your needs, use whatever you like. > It's not very clear to me why you'd want to do the work of system > integrators and distributors instead of spending that time improving > Maven. I don't think you really understand what Maven is about. It's about development in Java for Java developers. Platform OS packaging mechanisms are irrelavent essentially. What you are asking of us is to relinquish control over the repository that Maven users are accustomed to and hand that over to people making packages for a specific OS. That simply isn't reasonable because that immediately requires us to know about specific OS in order for Maven to work the way it does now. That is just not going to happen. > Maybe you don't see a difference between software development, > software distribution, and software management. I do, so let me try to > explain it ;) > > When you look around at UNIX programs as they are shipped in Linux > distributions, or BSDs, or commercial UNIX implementations, most of them > are customized by the distributors in order to make them fit in better > into the platform. Of course there is POSIX, but in the real world, > still everyone feels the need to be able to make (often necessary) > changes to produce a better package than the original developers did (or > can do, in case of small platforms) and they often succeed. > > If I understood your arguments correctly, you seem to think that such > platforms-specific adaptations are unnecessary with java applications > and libraries. In my experience, that is not true, as soon as you move > away from the setup the original developers used for developement and > testing, even for java applications. The hidden, unwarrented assumptions > only start to show where the code is used in an environment that breaks > them. After many years of writing Java applications I have not found many great difficulties running Java applications on different platforms. Most problems have been with platform specific startup scripts. Maven having to deal with the innumerable inconsistencies of all the existing package managers would make Maven nearly impossible to use in my estimation and would lose all of what makes it attractive to use. I have honestly never used a JDK that comes in a package. I download the JDK and use it in the same way on the different platforms I deploy the application on. > >>Usually OS repositories can be rebuilt from source (if the license > >>permits so). There is also the need to be rebuildable from source in > >>order to apply bug fixes to the source code, or other patches. > > > > > > Ok, I still don't see what stops you from using Maven to do this. Which > > is what it's for and then use the packaging tool after Maven has done > > its job. > > Nothing, if I understand your explanation about how Maven works correctly. > > The thing is, I'd like to (have Maven) pick up the platform specific > adaptations and fixes, instead of the generic binary/sources from the > upstream. I'd also like versioning of dependencies, integration with > native package management, etc. See for example > http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/custom-guide/ch-rpm.html > for a description of what a package management tool can do, and what the > design principles behind it are. I see Maven (or actually the POMs) as a > tool that might be useful in the package management of Java > applications, but not as replacement for native package management. We don't want native package management, that's the whole point I think you're missing here. We do not want to have to deal with the platform at all. There would be widespread, immediate and problems if Maven had to deal with platform specifics. How would you propose that we deal with the variances of every platform specific packager? Say all of here were Windows users and knew nothing about Linux platforms? What are we supposed to do rely on packages to make everything? > > That's fine but I meant more for standard development practices where > > people work with native Java. What benefit is there is using packages > > installed by an OS specific packager as opposed to using artifacts from > > Maven's repository. We don't have a single OS native artifact in the > > repository as far as I know. > > The artifact from Maven's repository may not work on the system, so an > OS-native replacement may be necessary. Huh? Maven's repository has all pure Java artifacts. For the number of problems that might occur it is not worth interacting with native packaging systems in my estimation. > Take for example any ant-1.5*.jar artifact from Maven on JDK 1.4.2 and > the Javah task will not work, according to the Ant 1.5.4 release > annoucement. No, ant 1.5.4 was not on ibiblio.org/maven today ;) The example involves native code does it not? Javah? I don't really find that a compelling reason to use native package management systems. > > We don't create artifacts that are platform specific. As I said I don't > > think we have a single one and I would like to keep it that way. If > > packagers want to build from what's there or build from sources and do > > whatever with them then that's great. But for example I wouldn't endorse > > the use of a Maven binary compiled with gcj and I doubt many projects > > would want you making native binaries of their projects without their > > knowledge. > > I think it depends on how you define platform specific. If we can agree > that the runtime is a part of the platform description, then I'm quite > positive that ibiblio.org/maven distributes quite a few platform > specific artifacts. The platform is the OS for which there is a standard JDK. Period. So I don't think you'll find many artifact in ibiblio that aren't usable by your typical Java developer. > Whether the original developers endorse a native binary or not, doesn't > mean that people can't do it, if the licensing terms permit it and are > followed in the process. Of course they can, it's a matter of courtesy to inform the project what's been done with their code. > See http://people.redhat.com/gbenson/naoko/ and > http://sources.redhat.com/rhug/ for examples. That's the beaty of open > source development to me. > > I'm not aware of any OSI certified open source license that requires me > to report back to the original authors what I'm doing with their code as > long as I follow the license terms. ;) Not a requirement, a simply courtesy. As I would not like to see a report of Maven not working on platformX and then find out they were using a something created with GCJ. > > packages. There is no argument there from me. But as far as pure Java > > development goes I would never encourage the use of native packages. > > That's O.K. I wouldn't ask for that ;) > > The problemaic thing is that, as I've tried to show with quite a few > examples that you decided to nip in the bud, is that a lot of supposedly > pure java code, is in fact using unwarranted assumptions about its > runtime, and the platform it's running on. How is assuming the use of a standard JDK on different platforms erroneous? You think it's reasonable to use a native package management system because sun.* classes don't work on Kaffe? > You may not realize it, but > maven's ibiblio.org repository is also distributing platform-dependant > code, despite that the code written in java, and not in C. What code is that exactly? My assumption is the use of a standard JDK on a give platform. I don't consider sun.* classes to be a problem for example. > Claiming that the JARs in Maven's repository are somehow more suited for > running on a specific platform where they may never have been tested at > all, rather than native packages which have gone through a quality > assurance process by the distributors and have been verified to work, > (or fixed on the specific platform,) doesn't make much sense to me, as a > *user*, and even less, as an *administrator*. This entirely defeats the whole purpose of Java. We rely on JDKs kicked out by Sun or IBM where we don't have to worry about these things. > Maven's concept of > centralized distribution of binaries makes sense makes sense to me as a > *developer*, though. And of course, it probably works great where > developer == administrator == user [1] ;) We have lots of normal users who aren't administrators. That's the beauty of Maven. You don't need to know anything about a native package manager for example. I can take Mr Developer who is used to Windows, put him on a RedHat box with Maven and he doesn't need to know squat about RPM. If you could provide seemless integration with the OS specifics then I might consider it but I know that's not even a remote possibility given the state of packaging mechanism. Who would do the work of assuring the that things would work as easily as they do now? I'm telling you now that no one would and things would fall into complete disarray. There isn't a snowballs chance in hell that volunteers would be able to spare the time needed required to do this task. But fortunately for us we don't have to worry about this because Maven works the same way on every platform that provides a standard JDK and that's the best we can ask for. You're not going to convince of flipping Maven over to using native packaging systems but I would be curious to know how you would propose we use native packaging systems. How would you go about even maintaining the N interfaces we would require to take artifacts from the OS specific repository? > cheers, > dalibor topic > > [1] Windows, I guess. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
