Jason van Zyl wrote:
On Mon, 2004-02-02 at 10:39, Dalibor Topic wrote:
Hi Jason,
thanks a lot for taking the time to reply so quickly.
Compliancy to JDK APIs is a seal of approval given out by Sun for passing the TCK. Since the TCK is not available under a free software or open source license, it's hard for free implementations to claim compatibility with JDK APIs, without risking to get sued anyway. ;)
They are available to OSS projects, we have licenses for many of them here at Apache. The folks working on it here have worked long and hard to get them for us but I'm sure you too can gain access to them.
As far as I can see it as an outsider, Apache is in a somewhat special love-hate relationship with Sun. Neverthless, Apache members have done a lot to open the process up, and that's great.
But its still impossible for an OSS project to get a copy of the JDK 1.4.2 TCK, under non-discriminating terms, for example. If you have information to the contrary, I'd be glad to hear about it.
I don't think many people use sun.* packages. What's in Maven is vestigal and can certainly be fixed. I actually fixed it in the component based version of Maven last night when you mentioned it in your post.
Great! Thank you very much! I don't see any comments from you on http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-1129 though, so maybe we should discuss the fix there. Dion explained that my fix broke the bootstrap, so I assume yours doesn't ;) Send me an e-mail when it's in the CVS so that I can give it a go on kaffe.
Unfortunately, in my experience, I see a lot of code using sun.* packages. For example, taking the freshly released ant 1.6.1 beta 1:
bash-2.05a$ grep -r import . | grep sun
./src/main/org/apache/tools/ant/taskdefs/email/UUMailer.java:import sun.misc.UUEncoder;
./src/main/org/apache/tools/ant/taskdefs/optional/image/Image.java:import com.sun.media.jai.codec.FileSeekableStream;
I can't say how many projects have this sort of problems, but from my experience in getting software to run on kaffe, there is a lot of unportable java code written by programmers not aware of their assumptions out there. I'm currently involved with an effort to clean up OpenOffice, and it's no fun. In fact, some Linux distributions ship OpenOffice with Java code disabled or ripped out, since it's so heavily tied to Sun's JVM.
My most interesting problem with Maven and Kaffe combo so far was the tools.jar reference in the forehead.conf file, as maven-1.0rc1 wouldn't start up with it. Since Sun's tools.jar is distributed under a very restrictive license, Kaffe (and other free runtimes) can't ship it, so that any code which wants to mess with tools.jar is bound to fail.
This is certainly something we can fix, but you have to keep in mind that 99% of folks are going to download a Sun or IBM JDK and consequently won't have that problem. There aren't many people more into OSS then I am but you have to pragmatic about these things. You have a simple patch I believe for the tools.jar problem so no biggie but ultimately we only have so much time and will more than likely focus on general usage patterns which unfortunately rarely includes Kaffe.
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.
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. 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.
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.
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.
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 ;)
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.
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. 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. ;)
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. 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.
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*. 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] ;)
cheers, dalibor topic
[1] Windows, I guess.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
