Christian Andersson wrote:
Hi Dalibor
I'm sorry for not commenting inline but at the top, but my answers intersect so much that commenting inline would just not look good :-)
That's fine with me. I'm interested in having a good technical discussion and learning more about Maven and less in the proper quoting style ;)
Well, it is true that it does not use any OS specific (or distribution specific) package management, but that is what I like, and also what I'm after, I personally do not want to build and debian .deb package, or an Redhat RPM package, or even an madrake rpm package (even though i use mandrake) that would restrict my software to much, since after all I want it to be used on any platform that has java (although, I do need java >= 1.3)
I fully understand that. As a software developer, I don't want to care either about the specifics of some platform's software management. The good thing is, I don't have to. The packaging work is usually done by the people developing those platforms (Cooker for Mandrake), who can try out my code on their specific environments, and often report back with bugs, suggestions and patches.
For example, on kaffe.org, we only distribute the latest versions of kaffe as source code, and leave the packaging work and creation of binaries to the distributors. We know best about our code, they know best about their platforms. They can actually test my code on those platforms, where I often lack access to their platforms. Or when was the last time you fixed your software on a Cray? ;)
and personally I have had a hard time finding java packages that use debian/redhat/mandrake/etc/etc package formats.. most of the time I need to download the jarfiles myself.
Which is what the JPackage, Debian, Gentoo and RedHat java developers & packagers want to change, thus our common java packaging effort was born, to learn from each other's mistakes and come up with something better.
I know that Jpackage.org exist and it tries to make those distribution specific packages for us, but they can't make it for all platforms (for example, I do not think they produce installers for windows)
And I have had other problems with the Jpackage distribution.
Obviously they can't make packages for all platforms, like windows. But they are not even trying, or pretending their packages would run unmodified on windows.
They are trying to make the best effort for their targetted environments, which is Linux distributions using RPM based package management. Instead of a 'one-size-fits-all' they make the best effort to test, fix and package java applications for their supported environments. See http://www.rpmfind.net//linux/RPM/mandrake/9.2/contrib/jpackage/SRPMS/ant-1.5.4-2jpp.src.html for an example. Since the ant build, for example, builds some parts of ant depending on what JDK version it is built on, assuming that one ant.jar fits all is simply wrong.
Note also the interesting entry here:
* Mon Mar 10 2003 Henri Gomez <[EMAIL PROTECTED]> 1.5.2-3jp
- rebuilt with IBM SDK 1.3.1 since there was zip corruption when built
with jikes 1.18 and IBM SDK 1.4.Any idea with which JDK and which compiler this http://www.ibiblio.org/maven/ant/jars/ant-1.5.2.jar was built? If any patches were applied? If it suffers from one of the problems fixed by JPackage project?
Don't get me wrong, Maven's centralized repository of common parts is very useful in development of java software. But it's of rather limited use for distribution of software, since it would be based on the assumption that a central repository fits all.
You also assume that the packages comes with the distribution, what if they dont? what if they only comes from some other organization, one that for example is not open source, but provides free binaries, what about them? should not they be able to provide it with ease to all java plattforms?
If they don't there is usually a very good reason why they don't, i.e. licensing terms. Neither does Maven provide these binaries, try downloading JIMI uisng Maven for example. It will tell you to go download it from Sun. So much for ease. ;)
Free (as in beer) binaries sometimes come under licensing terms that limit their distribution, so they can not legally be distributed to third partys without infringing on the rights of the copyright holders.
There are ways around that, JPackage has nosrc packages, debian has 'installer' packages, etc. All these ways necessarily do the same as Maven does in the case where the artifact doesn't exist in the respository: they tell you to go somewhere else.
I came "up" with this idea when reading about zero-install [1], unfourtunally I do not think that zero-conf would work so good with java-applications, however maven does alsmost the same thing as zero-install.
Judging by the zero-install website, their security concept is somewhat better, than your proposal ;) But as I'm not familiar with zero-install's limitations, I can't comment on how well it would work for java applications. In my opinion, though, zero-install tries to solve a harder problem wrt software distribution and management, since it explicitely wants to handle native code (among other types), whereas, if I understand Jason correctly, Maven would be focused on java artifacts alone.
And why should not distributions not use java? they can you know, and if they do, they will also benifit.
I don't think I ever said distributions should not use Java in this thread. I'm actually involved with bringing more Java applications into Debian Linux ;)
If it happens that the project.xml file has dependencies that was NOT installed from the distribution installer (which can happen) it will gladly download it from the web (which can be the dependencies real webserver, OR the distributions webserver)
See, that's the kind of integration that I'm thinking about. If Maven is to be used to distribute and manage software (on Linux), it needs to interface with native package management software to see what's already there, and request an installation if necessary (where you propose straight downloading). We're not that far apart, as you can see.
This way we get a good package management for java applications that works the same on ALL plattforms, we can even use the exact same package management to build the sources,and I see not problem with that.
That would be a nice thing, for sure. But I'm frankly more interested in having good package management on one platform, since I'd consider that enough of a challenge already, and doubt that it would work the same on all platforms, since a centralized repository could be overwhealmed by the work necessary to manage artifacts for all platforms.
Now some people have said 'use a standard JDK', or 'use a standard platform', which pretty much proves my point. If it's too much work to support all possible platforms, the central Maven repository could only support a few, selected platforms. That's O.K., everyone does it, and it's all very reasonable.
All I'm trying to do is to get you to realize the limitation of the approach you propose: it can not possibly work (untested) on all platforms.
Now if you want tested and tried software, that's part of what distributors do.
AND since the dependencies are calculated and SOLVED when the application starts, there is no problem at all deleting the entire repository to free up space (not so much used java-applications will therefore take no place) the maven repository can bee seen as the "cache" that exist in zero-install. as long as the jar-files exist on the internet, you still can run the application even after you delete all the required jar files...
That assumes that resolving dependencies is all there is to software distribution ;)
A lot of the hard work involved is in actually testing what you've got extensively and fixing the problems you find on the environments you support. Quite often, this additional level of quality assurance produces better results in those environments, than the original software/artifacts produced by the developers, and everyone profits.
personally I think it is better to resolve the dependencies when running the application then at install time...
I see no problem in having the distribution to use the maven system for the jar files, only benefits...
Well, the major problem I can see is that it wouldn't integrate at all with native package management, so it becomes impossible to manage java software using Maven with the native package management tools. That sort of setup starts to get really messy when you have multiple-programming-language software (eclipse, java-gnome), which would on one hand depend on Maven for the java side of things, and on the other on native package management software for the native side of things (SWT, libgtk). If Maven and native package management don't integrate, chances are that you'll end up with a hosed combination that doesn't run eventually.
BTW, thanks a lot for keeping the discussion focused on the technical aspects.
cheers, dalibor topic
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
