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 :-)
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)
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.
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.
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?
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.
And why should not distributions not use java? they can you know, and if they do, they will also benifit.
lets say that you have distribution XYZ, you want to install application ZYX that comes with the distribution (from the cd) application ZYX is a "mavenized" application therefore if maven was not installed maven will be installed at the same time. the installation of the package ZYX will then populate the maven repository with the jar files that the package need (for this example it depends on no other packages then it's own) it will also save down the project.xml file (this one could actually also be used to build the package if you have the ZYX-sources installed) and finally it will install an startup-script that will run "maven-run start" for that particulary project.xml file...
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)
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.
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...
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...
[1] http://zero-install.sourceforge.net/ /Christian
Dalibor Topic wrote:
Hi Christian,
Christian Andersson wrote:
well that is one possibility, but that system (building an installation set which have everything) does not take advantage of the fact that I might already have some "libraries" (jar files) installed/downloaded
This is where maven comes in, since if I start te application from maven, maven will look in the "local" repository first for the files, if they are not there it will download them, so If a person already has some jar files (ofr the correct version) he does not have to download them and therfore saving perheps precious network bandwidth and time.
Maven doesn't know about native package management on a platform, afaik. I may have already installed ant, tomcat etc. on my debian system using the debian package manager, for example. But as far as I understand the maven concept, it will still go off fetching ant's jars from the Internet, without caring about the operating system's package management, or its dependencies, and so on.
Using Maven as a way to circumvent package management on an OS is, to put it simply, a waste of my resources. Of course, for operating systems that have no package management (like Microsoft's products), using Maven to download the dependencies is a way to work around the deficits of the operating system.
It's still an ugly hack. On systems that do have sane package management, like most Linux distributions, it's a Bad Thing(TM), and leads to hard-to-manage software.
Let's say, for example, that there is a security bug in some jar file Buggy.jar, that is also distributed with Maven, that only is triggered on a hypothetical MLinux distribution. The distribution's packagers of Buggy.package can fix the problem, update the jar package for their distribution, and have all the applications depending on that jar tested and automatically fixed by upgrading the single package. Maven can not, if the problem and fix is distribution (or operating system) specific. Furthermore, there is no way for Maven to update all project.xml files that use the Buggy.jar, so all the applications relying on Maven for distribution of their jars are vulnerable until their developers release a new package, if they do it at all. On the other hand, packagers of a distribution can do that work.
The Maven does not, and can not really do the package and operating system specific work of all the packagers on those systems.
lets say that I make applications for persons to use, and I use some gui-objects provided from some other company. with maven (provided that the other company has their jar-files versioned and on the web) I don't have to distribute their jar-file with my application since maven downloads it, I have to do that with an installer or if I use jnlp.
The installer version can do some "optimisations based on the plattform,, but IF I use that, I have to make several installers based on which plattforms I let my application run on, but wirh java, I want them to be run on any plattform.
That sounds quite nice in theory. In practice, there are differences between platforms that matter, and need to be considered, like typical locations of libraries, where native libs go, how dependencies are resolved, etc. Using Maven to distribute applications is conceptually no different than just statically linking everything in a big binary blob. The only difference in practice is that you have to distribute the big binary blob written in C yourself, whereas if it's written in java Maven would do the fetching and linking of binary blobs for you.
Big binary blobs are so 80s ;) They don't work that well with modern systems.
I can also use the maven approach for starting the application from the init.d (if I use an unix type of plattform) or from a cron job. that will be hard with webstart/jnlp (but possible with an installer)
I'd assume that different linux distributions have already found ways to deal with running tomcat, for example, from their startup scripts. The maven approach would seem to circumvent that.
also with maven I can do some nifty update handling (similiar to webstart but more functional according to me) since all I have to do is to download the new project-xml file, stopp the application (maven stop) and then start it again (maven start) and it wpuld update ge application. webstart will update every time it starts the application since it checks the jnlp file, but an application that automaticly updates itself are usually discourraged by administrators (who knows what will be installed and when, I like to be able to controll when things gets updated).this is ofcourse also possible with an installer, but now it would be my application that would have to check for new versions etc, I have to "manually" build it inot my application.
In other words, all I have to do is to use some other tool to manage a part of my system. The tool doesn't know about the specifics of my system, the applications don't know either. That sounds like a recipe for desaster in the long run.
Let's say I update my java runtime to a new version because of a security problem that only occurs on my platform. I (and everyone else using applications on that platform that use Maven for distribution) have to manually check if all the applications still work. In a sane distribution system, the packager can do that work, and if necessary expose a conflict between an application and an specific runtime in the list of dependencies of the application. In the proposed system, everyone needs to do it all over.
So I see many benefits to providing a "maven-execution" system that has the basic maven reopsitory handling and a couple of goals (start,stop,restart,check,....) and these benefits are mainly not covered by an installer or webstart/jnlp)
Both installers and webstart/jnlp are nieche solutions for distribution that don't meet the needs of modern operating systems. Legacy systems, like Microsoft Windows, that have no concept of package management, *may* profit from a Maven-based distribution system, but it would still be a nieche solution.
On the other hand, using Maven for distribution makes the job much harder for those that package applications for und use applications on modern operating systems.
See http://java.debian.net/index.php/What%20is%20required%20from%20upstream for a brief discourse on how to create packager-friendly releases of java software that is supposed to be packaged for linux distributions. It's part of a small wiki created by packagers of java applications for different Linux systems and free java runtime developers in order to find better ways to package java applications on unix systems[1].
cheers, dalibor topic
[1] http://java.debian.net/index.php/CommonJavaPackaging
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
