thanks a lot for the quick and insightful reply!
Jason van Zyl wrote:
On Wed, 2004-02-04 at 16:02, Dalibor Topic wrote:
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 suits my needs well, thanks a lot for developing on it.
I hope you are not taking my comments about what I consider to be an inferiority of Maven compared to other solutions in one, still mostly hypothetical use context (we're in this new idea - software distribution and management thread, remember?) as personal insult. I'm not asking you to fight any fights, for skin samples, etc, I'm interested in discussing what I consider to be limitations of the new-idea approach, and in your insightful comments.
I hope to gain better understanding through such discussion where this very cool software is going and how Linux distributions can cooperate with Maven developers on creating a better way of distributing and managing java libraries and applications on Linux, specifically. Better hopefully meaning 'even better than with Maven alone'.
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.
Well, saying that platform specific package management mechanism are irrelevant doesn't magically make them so ;) They are about using software (for users) and distributing and managing software (for administrators).
I'm not saying that Maven can not be used for those things, I'm saying that better solutions exist for some platforms, and that it would be nice to have Maven somehow integrate with them.
The premise being that Maven as a software distribution and management mechanism is a solution for all platforms, I've presented many arguments why a centralized repository would not be well suited for such a task. I've also tried to argue that non-portable java software is more common than some dicutants assume, and provided lots of examples where pure java does not imply portability, some of which have become java folklore (double-check-locking). Therefore, my argument goes, in order to have a higher chance of working software on a platform, one should not rely on download of untested components from a centralized repository, but rely on the work of people familiar with that platform that results in tested and tried packages for that platform.
This could involve platform-specific repositories. As far as I have understood the discussion so far, Maven supports that, which would solve a few of the problems.
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.
I don't think I ever asked you to give up on ibiblio.org/maven in this discussion !?
You, as a Maven *developer*, don't have to know anything about a specific OS. That's what the *distributors* (i.e. packagers) are for. Different tasks with different roles involve different people with different skills.
>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.
After many years of *running* Java applications on a variety of platforms, I think you can consider yourself very lucky. For example, one of current funnies with using the JDK atm seems to be the buggy default JAXP parser implementations that come with it, so that it's necessary for some applications to use -bootclasspath to override the defaults. Not the startup scripts, the core (yay, pure java!) libraries.
Then of course, there is the problem that Sun doesn't really suport any Linux distribution beside a handful listed here http://java.sun.com/j2se/1.4.2/system-configurations.html so that running Sun's JDK on (for example) Mandrake, Debian, Gentoo is not supported by Sun. And more often than not, in my experience, the download from Sun doesn't work that well on those platforms, i.e. it happily crashes. Google for Sun+JVM+NPTL for a lot of recent fun with Sun's JDK.
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.
I've argued that there are problems when you don't deal with platform-specifics, you've argued that there are problems when you do. I guess it's a classical 'pick your poison' setup ;)
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?
Maven developers shouldn't have to deal with package management specifics at all. Just put the sources for all artifacts in the repository along with the binaries and build scripts, so that the binaries can be recreated if necessary.
Mind you, some licenses demand that anyway. I've seen that the ibiblio repository hosts GPLd artifacts, you may wnat to check clause 3 of the GPL for details.
The packaging is the work of distributors. The way I understand the maven concept, they could in theory write a Maven plugin for their distributions that would interact with the native package management, ignore the ibiblio.org repository and everyone would be happy.
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.
For the people suffering from those problems it would be ;)
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.
Ant doesn't contain any native code. It calls a specific java class in a sun.* package to run Javah. Read the fine announcement ;)
Oh, and it's been biting Maven users: http://java2.5341.com/msg/43973.html
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.
What is a 'typical' Java developer? A 'standard' JDK?
These are not rehtorical questions, they are there to show you that it would be hard to do a good job supporting all possible platforms and types of developers from a central repository. You'd need to make concessions.
That's OK. I'd only like you to realize that you'd be making concessions, and to be clear about that to your users and yourself.
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.
I agree. You didn't mention matters of courtesy before though ;)
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.
Sure. That's why most distributions have their own bug trackers, where the packagers sort bug reports into distribution specific, and general problems. The general problems are usually fixed together with the upstream (i.e. the original developers), the distribution specific ones together with the distribution developers.
So chances are you won't find out about the bug, until it's clear that it's a bug in Maven.
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?
Because sun.* classes don't work in general. Please read http://java.sun.com/products/jdk/faq/faq-sun-packages.html for information from Sun about why it's not possible to have a portable program while using sun.* classes. I'm not making it up, it's a very educational read.
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.
Sun does consider them to be a problem. I believe they have a little more weight in saying what constitues the Java API ;)
So any code linking directly to sun.* is unportable, according to Sun.
Since Maven's central repository only distributes binary JARs, I'd have a hard time pointing which JARs specifically are unportable. But since some Maven developers must have put them there in the first place, I believe they are in a much better condition to answer your question than I am. ;)
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.
As I've explained, that's not good enough. There is a lot more thought necessary to write portable Java code than to expect that using Sun's or IBM's JDK (which can differ slightly in their class library implemenations, by the way) will make it portable somehow automagically.
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.
I thought Maven was a volunteer driven project. If it's not, then my compliments for your generous contributions to the world of open source software. In my experience, some volunteer based projects can get quite far. Others fail. There is no ultimate guarantee Maven will be still around next year.
Maven can work the same way, even on the few selected platforms with just the Sun JDKs installed, but that doesn't matter if the artifacts, which are distributed though it, don't do it due to unportable Java code. I've showed you examples, I've showed you a Maven user being bitten by an JDK upgrade.
To me, the new idea looks like trying to apply the golden hammer anti-pattern. I wish you luck, but I remain reserved that it will work that well on any platform other than latest Sun's JDK on Windows XP (or whatever platform-runtime combination Maven developers tend to prefer over others).
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?
I'm not trying to do flip over Maven. Please, let's keep the discussion on technical terms, and away from the realms of speculation.
The integration interfaces could be maintained by distributions, since they are distribution specific. Basically, Maven's dependency resolution mechanism would need to be patched in a distribution specific way to fulfill dependencies by mapping them to a distributions' packages, and asking the distribution's package manager to install them.
How feasible would that be with a maven plugin?
cheers, dalibor topic
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
