maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Andersson ...@ofs.no>
Subject Re: new idea on maven usage?
Date Tue, 03 Feb 2004 09:38:59 GMT
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 :-)

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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message