Re: new idea on maven usage?
Hi Maczka, Maczka Michal wrote: Why would you like to ever recompile java sources when you have jars? I can think of a few reasons to do it: a) You've made a (necessary) modification to the sources (security patch, bug fix, performance improvement, new feature, etc.). If you've got the sources, you might as well use them ;) b) The JAR doesn't meet your needs, but can be built to meet your needs with some specific build properties, like enabling the use of some feature due to known presence of some other artifact. Ant does this a lot, for example, afaik. c) The 'default' JAR is too big, you just want the core functionality. Think of embedded systems, for example. d) The toolchain used in the build has a bug that shows up in the generated artifact. This happens ocassionally, I've been recently bitten by the compiler used to create Eclipse's JARs generating bytecode that violates the Virtual Machine Specification 2nd Edition. e) You want to insert additional steps in the build process to verify the integrity of the result. External verifiers, static analysis tools, etc. f) Licensing issues. The JAR may contain code that you don't want (or can't) distribute, but which can be stripped out. Think of (L)GPL code being avoided in JARs on Apache.org. g) Adding debugging information. Obvious, I guess. h) Targetting a different JDK version. Like building applets for use with JDK 1.1 runtimes with a 1.4.2 SDK. i) Targetting a 64bit or 32bit system (Javac in JDK 1.5 has switches for this, but I don't know for sure what they do). And so on. I always that the latest proven trend is to distribute appliction as byte code and to let VM do optimisation. At least this is what Microsoft is doing with .NET and soon (in few years) most of the application for MS Windows will be run using CLR VM. IMHO this is a way to go and what Gentoo Linux does is simply for people who like to have a hobby and have a lot of time for it. I see it as a 'culture clash' between pragmatism and idealism. The Windows culture does not see much of a point in having source code available, the value is in the binaries. If things don't work, you wait for the vendor to fix them, use something else, or cry. I'd assume that open source is seen as a cute way to collaborate to produce better binaries faster. Binaries work most of the time, so tinkering with source is a waste of time. The free software culture does not see much point in having binaries, the value is in the sources. Given the free availability of tools to rebuild the artifacts and the free availability of associated build scripts, it is often easy to do the build yourself (on systems like Gentoo or Fink, that are deeply rooted in the 'source code is more useful then binary philosophy', your experience may vary on other systems). Binaries work most of the time, but that's just a nice byproduct of people spending time tinkering with the sources. You're encouraged to do the tinkering, to learn and and to adapt the progams to your needs. The pragmatic approach is great when you need something fast. The idealistic approach is great when you need something that can be customized according to your needs and can grow along with your needs. Both approaches have their value, despite the ocassional zealous flame-war on newsgroups. ;) On the other hand, Gentoo is not unique with the 'everything from source' concept. Other successful projects, like Fink (which brings a lot of value to the Unix part of MacOSX), do the same. Nor do those types of systems remain purely devoted to providing just the sources. Fink offers many pre-built binaries for easy download for those users that don't want to build the binaries themselves. I think Gentoo does that too, for the base packages, at least. So systems like Debian, Gentoo, or even Fink don't assume that one approach will fit all, but provide a combination of the pragmatic and the idealistic approach: binaries for those that want them, sources for those that want them. Some people are still believing that compilation to native code can increase the performance. This is simply not true. Some of the reasons are nicely explained here: http://www.idiom.com/~zilla/Computer/javaCbenchmark.html Actually, it shows that compilation to native code *can* increase the performance. It *doesn't necessairly always have to*, but it can, depending on the code, compilers, etc. It shows that for some applications, Sun's JDK can run equivalent code faster than a native counterpendant. For others, it still can't. Maybe it will one day, though, I don't know. OTOH, some people still prefer jikes to javac because of speed. ;) If you want to recompile for other reason - to improve start-up time of JVM please note that: a) start-up of JVM time it's getting better and better and with shared instnace of JVM it will be also improved Sure. Native compilers also keep getting better and better. We all win, one way or another.
Re: new idea on maven usage?
On Sat, 2004-02-07 at 09:54, Dalibor Topic wrote: Hi Maczka, Maczka Michal wrote: Why would you like to ever recompile java sources when you have jars? I can think of a few reasons to do it: a) You've made a (necessary) modification to the sources (security patch, bug fix, performance improvement, new feature, etc.). If you've got the sources, you might as well use them ;) In most cases as far as Maven goes this would be done by the project. Whoever found the problem would supply the patch, the project would build a new JAR and deploy it. b) The JAR doesn't meet your needs, but can be built to meet your needs with some specific build properties, like enabling the use of some feature due to known presence of some other artifact. Ant does this a lot, for example, afaik. There is no conditional compilation in Maven, it leads to unmaintainability. The evidence clearly shown in the history of the Turbine project where optionally compiled modules fell into disuse. c) The 'default' JAR is too big, you just want the core functionality. Think of embedded systems, for example. Again, this is something would probably work with a project if you want this to be a standard release. d) The toolchain used in the build has a bug that shows up in the generated artifact. This happens ocassionally, I've been recently bitten by the compiler used to create Eclipse's JARs generating bytecode that violates the Virtual Machine Specification 2nd Edition. e) You want to insert additional steps in the build process to verify the integrity of the result. External verifiers, static analysis tools, etc. f) Licensing issues. The JAR may contain code that you don't want (or can't) distribute, but which can be stripped out. Think of (L)GPL code being avoided in JARs on Apache.org. g) Adding debugging information. Obvious, I guess. h) Targetting a different JDK version. Like building applets for use with JDK 1.1 runtimes with a 1.4.2 SDK. i) Targetting a 64bit or 32bit system (Javac in JDK 1.5 has switches for this, but I don't know for sure what they do). And so on. These are all things that either: 1) You would work with the project by supplying patches in order to make a standard release of something, or 2) You would just build it yourself to modify it, and people do this all the time but you don't need an OS specific packager for this, you just need Maven. I always that the latest proven trend is to distribute appliction as byte code and to let VM do optimisation. At least this is what Microsoft is doing with .NET and soon (in few years) most of the application for MS Windows will be run using CLR VM. IMHO this is a way to go and what Gentoo Linux does is simply for people who like to have a hobby and have a lot of time for it. I see it as a 'culture clash' between pragmatism and idealism. There's nothing stopping you from building from sources. You certainly don't need an OS specific packager for that. The Windows culture does not see much of a point in having source code available, the value is in the binaries. If things don't work, you wait for the vendor to fix them, use something else, or cry. I'd assume that open source is seen as a cute way to collaborate to produce better binaries faster. Binaries work most of the time, so tinkering with source is a waste of time. The free software culture does not see much point in having binaries, That simply isn't true if you include most users of OSS to be part of the culture. Most users will take binaries guaranteed. the value is in the sources. Given the free availability of tools to rebuild the artifacts and the free availability of associated build scripts, it is often easy to do the build yourself (on systems like Gentoo or Fink, that are deeply rooted in the 'source code is more useful then binary philosophy', To my mind this is not the practice of your typical user of OSS Java software. Users will gladly take binaries. your experience may vary on other systems). Binaries work most of the time, but that's just a nice byproduct of people spending time tinkering with the sources. You're encouraged to do the tinkering, to learn and and to adapt the progams to your needs. Again, you're implying something that isn't pure Java. In the vast, vast, majority of cases users don't need to tinker with anything. The JAR just works. The pragmatic approach is great when you need something fast. The idealistic approach is great when you need something that can be customized according to your needs and can grow along with your needs. Both approaches have their value, despite the ocassional zealous flame-war on newsgroups. ;) Both are supported in Maven and in fact it is far, far easier with Maven to build from sources in a known way than with things like Ant or Make. On the other hand, Gentoo is not unique with the 'everything from source' concept. Other
Re: Réf. : Re: new idea on maven usage?
Dalibor Topic wrote: I'm not arguing that it doesn't make sense in *all* contexts, I'm arguing that it's not a *silver bullet* in all contexts. Who told you that Maven is a silver bullet in all contexts? My impression is that there is a lot of (rightful! it's a cool piece of software) excitement, but little discussion of limitations of the new idea, so I'm playing an advocatus diaboli in this case ;) ... using massive amounts of bandwidth, and pissing the hell out of certain people. My advice is that you should start a project concerned with running Java software using libraries managed with platform specifc package managers , state your cause there, and go on discussing this with the people that are interested. What you are doing now is an abuse of Maven mailing list IMO. R. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Réf. : Re: new idea on maven usage?
Hi Rafal, Rafal Krzewski wrote: ... using massive amounts of bandwidth, and pissing the hell out of certain people. My advice is that you should start a project concerned with running Java software using libraries managed with platform specifc package managers , state your cause there, and go on discussing this with the people that are interested. What you are doing now is an abuse of Maven mailing list IMO. Thanks for the hint, I'll shut up now. I'm sorry for abusing the Maven mailing list, I didn't realize that I was doing that. I also hope people who have felt offended by my posts will accept my public apologies, I certainly didn't mean to harm. cheers, dalibor topic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Réf. : Re: new idea on maven usage?
On Fri, 2004-02-06 at 11:50, Dalibor Topic wrote: Hi Rafal, Rafal Krzewski wrote: ... using massive amounts of bandwidth, and pissing the hell out of certain people. My advice is that you should start a project concerned with running Java software using libraries managed with platform specifc package managers , state your cause there, and go on discussing this with the people that are interested. What you are doing now is an abuse of Maven mailing list IMO. Thanks for the hint, I'll shut up now. I'm sorry for abusing the Maven mailing list, I didn't realize that I was doing that. I also hope people who have felt offended by my posts will accept my public apologies, I certainly didn't mean to harm. You didn't do any harm and I doubt anyone is offended. We're glad to know about the efforts of Linux packagers, you just have to understand that we are primarily interested in having a mechanism that works indentically across the board on all platforms. As soon as Maven employs platform specific mechanisms we've lost what we consider to be the most compelling reason to use Maven. cheers, dalibor topic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new idea on maven usage?
Hi Christian, 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
Re: new idea on maven usage?
Hi John, John Casey wrote: Maven is a perfectly suited package management tool for its native language: Java. If you find some project which _happens_to_be_ built in a non-portable way, why not just throw up your own maven repository, and add a piece to the default build.properties, placing your repository first in the list to check for dependencies? You can then distribute this file with the distro in question, and everyone will be happy. I That's a nice idea, thanks. Dion proposed something similar, and it seems that it could be a way to make Maven play along with native package management. Joerg has discussed that aproach with gentoo developers, afaik. don't understand why it has to turn into such a ground-shifting change. While it's definitely not perfect, a very simple patch to maven (to remove the Base64 encoder dependency) will accommodate everything you've mentioned in your emails, Dalibor. You must have joined us in the middle of the discussion. That was a different thread. Maven's small portability problems that prevent the CVS from working on kaffe are unrelated to this thread. This thread is about a new idea of using maven for software management and distribution. There is nothing kaffe-specific in that idea, it's not even mine ;) cheers, dalibor topic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new idea on maven usage?
Hi Jason, 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
Re: new idea on maven usage?
Hi Joerg, Jörg Schaible wrote: Hi Dalibor, Well, but even for this purpose a system like Maven (or Maven-wagon) does meet the need of Java developers and users. See, I fully understand your point (writing Gentoo ebuilds for Java apps myself), but this is not a specific problem with Maven or its technology. We also have Avalon-Merlin around (a kind of Enterprise Application Framework) already using the same idea with compatible repo to Maven (although not sharing it for some reason). We have Eclipse downloading plugins and their updates on the fly and the new 3.0M6 uses for this functionality an OSCI-based platform. Meanwhile I have seen other people stating to use this technology for their own applications too. So, it seems this automated mangement and distributions of applications has a lot of interest within the (Java) community and solves a basic problem and will be eventually become commodity. I bet, that you'll not able to change this movement. I'm neither trying nor would I want to change a movement. I've stated in a couple of posts in this thread that I can imagine contexts in which using Maven for software distribution is adequate. I'm arguing it's not an all-encompasing solution it;s made out to be, though. I'm trying to find ways to produce a best-of-both-worlds approach for Linux alone, as that's what I'm working with. In order to be able to do that, I'm asking questions and the answers I've been getting seem to indicate that everyone could profit from a little more education on the issues involved. I'm educating people on the portability of Java code, they are educating me on Maven's internals, and I appreciate the discussion very much. So you better hope that there will be not more of this kind of technology developed and something like Maven-wagon gets standard. At least for Maven you are able to set the repository to a local directory, that you can stuff with symlinks to the native libs at various locations. I don't see any other working solution. Maybe you can enhance the download technology with a platform-specific mechanism, that will automatically use the native build system, but that's clearly out of the focus of this community as Jason already stated. Java WebStart is already 'standard', i.e. included with Sun's JDK. I'm still waiting for the flood of WebStart enabled applications, though ;) Maven is a nice build tool, and all that. As Jason said, he doesn't want to care about platform specific aspects. That's fine. Other people do, though, in order to deliver audited, tested and integrated applications on those platforms. I'd like to figure out a way to make their job easier. That's all. cheers, dalibor topic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new idea on maven usage?
Hi Jason, 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
Re: new idea on maven usage?
Hi John, John Casey wrote: being the BSD's and Debians of the world. The problem with BSD is that they don't even port the JVM quickly enough to be considered relevant. The BSDs are not supported by Sun. Sun's JDK code is not open source, so they are not allowed to just take it, port it and distribute it. Read the fine license of Sun's source code releases ;) I'll skip the flame-fest invitation of how relevant BSDs are. It doesn't matter if they are relevant to you, it matters if they are relevant to their users ;) If you don't consider them to be relevant, Maven can hardly claim to be truely 'cross-platform and just works out of the box'. More like 'cross-platform and just works out of the box (on a few selected platforms)' ;) Which is what I've been saying all along ;) If we tried to program strictly for BSD, we'd all still be stuck on JDK 1.3. As for Debian, from what I've heard it's a nice system, but you can't make sweeping, generalized statements about package managers when this is nearly the only relevant example. In short, the result of my experience with dependency management in most package management software has been increased blood pressure and (I'm sure) a shortened life span. Obviously, I'm no expert, but I believe I can take a fair crack at representing the masses. ;) Package management is not meant as a passtime for the masses, but to make the work easier for system administrators. ;) Debian is not the only nice system out there. I've heard very nice things about gentoo's 'source only' package management, for example. But this is not the proper forum to discuss package management systems. The thread is about using maven for package management, and I'm arguing that it's not suited for it. Is maven the right thing to use for managing native code? Probably not, at least by itself. Definitely not. It may be O.K. for whatever environment Maven developers decide to use, but it would fail horribly on others. Fetch GNU libtool, read the sources, and weep ;) Even building dynamic libraries in C and C++ is very painful and platform specific, don't get me started about managing different versions of dynamic native libraries on the same system. People are building Linux distributions for embedded systems that use uClibc insted of GNU libc. Maven would need to host all possible combinations of native-library * compiler-version * libc-type * libc-version and that's just for starters. I haven't even mentioned the different configuration flags available for native libraries at compile time. Down that centralized path lies insanity. ;) Does it have an appreciable advantage for most users over 99% of the dependency management field? OH, Hell yes. When 99% of the field has no dependency management at all (i.e. Windows), that's hardly that surprising, isn't it ? ;) I'd be interested in what Maven can offer that a native package manager (say dpkg) can not. cheers, dalibor topic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new idea on maven usage?
Maven is a perfectly suited package management tool for its native language: Java. If you find some project which _happens_to_be_ built in a non-portable way, why not just throw up your own maven repository, and add a piece to the default build.properties, placing your repository first in the list to check for dependencies? You can then distribute this file with the distro in question, and everyone will be happy. I don't understand why it has to turn into such a ground-shifting change. While it's definitely not perfect, a very simple patch to maven (to remove the Base64 encoder dependency) will accommodate everything you've mentioned in your emails, Dalibor. -john On Wed, 2004-02-04 at 16:42, Jason van Zyl wrote: On Wed, 2004-02-04 at 16:02, Dalibor Topic wrote: 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. 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'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. 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. 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. 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. 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. 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,
Re: new idea on maven usage?
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
Re: new idea on maven usage?
As an addendum: I've looked at how to best integrate Maven with the Gentoo Linux packaging system, and come to the conclusion that at this point, it is easiest to circumvent it completely. Our current prototype approach is patching the build.xml most maven-based project supply to not fetch missing packages, and have the ebuild (Gentoo-specific build script for a given package) manually symlink (or otherwise resolve) the jar files for these external packages into the appropriate lib/ dir before starting building. However, I must readily confess that I have not put the time into investigating writing a different package-resolution plugin for Maven (if that's possible). At any rate, as the basic premise for Gentoo is to compile everything from source code at installation, to enable/disable optional features and allow installation-time patching by the user, we will never avail ourselves of the pre-built maven repository (on ibiblio), since packages there do not come with sources (which I find a bit strange; all other relevant binary-distro systems I've seen, have source packages too). So in summary, Maven is unsuitable for Gentoo, because 1) It downloads packages on its own accord at build time, circumventing our packaging system. 2) The packages in the Maven repository are missing sources (and build.xml-files). The good thing about maven-enabled projects is that it is easy to figure out their external dependencies, which eases the job of packaging projects tremendously. Kind regards, Karl T - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: new idea on maven usage?
-Original Message- From: Karl Trygve Kalleberg [mailto:[EMAIL PROTECTED] Sent: Monday, February 02, 2004 10:52 AM To: Dalibor Topic Cc: Maven Users List; Jan Schulz; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: new idea on maven usage? As an addendum: I've looked at how to best integrate Maven with the Gentoo Linux packaging system, and come to the conclusion that at this point, it is easiest to circumvent it completely. Our current prototype approach is patching the build.xml most maven-based project supply to not fetch missing packages, and have the ebuild (Gentoo-specific build script for a given package) manually symlink (or otherwise resolve) the jar files for these external packages into the appropriate lib/ dir before starting building. However, I must readily confess that I have not put the time into investigating writing a different package-resolution plugin for Maven (if that's possible). At any rate, as the basic premise for Gentoo is to compile everything from source code at installation, to enable/disable optional features and allow installation-time patching by the user, we will never avail ourselves of the pre-built maven repository (on ibiblio), since packages there do not come with sources (which I find a bit strange; all other relevant binary-distro systems I've seen, have source packages too). So in summary, Maven is unsuitable for Gentoo, because 1) It downloads packages on its own accord at build time, circumventing our packaging system. 2) The packages in the Maven repository are missing sources (and build.xml-files). Why would you like to ever recompile java sources when you have jars? I always that the latest proven trend is to distribute appliction as byte code and to let VM do optimisation. At least this is what Microsoft is doing with .NET and soon (in few years) most of the application for MS Windows will be run using CLR VM. IMHO this is a way to go and what Gentoo Linux does is simply for people who like to have a hobby and have a lot of time for it. Some people are still believing that compilation to native code can increase the performance. This is simply not true. Some of the reasons are nicely explained here: http://www.idiom.com/~zilla/Computer/javaCbenchmark.html If you want to recompile for other reason - to improve start-up time of JVM please note that: a) start-up of JVM time it's getting better and better and with shared instnace of JVM it will be also improved b) more and more of the modern applications ( e.g eclipse, idea, maven) are distributed as small kernels which are loading plugins. And AIIK the compilation to native code can't help much in such cases. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new idea on maven usage?
Karl Trygve Kalleberg [EMAIL PROTECTED] wrote on 02/02/2004 08:52:29 PM: So in summary, Maven is unsuitable for Gentoo, because 1) It downloads packages on its own accord at build time, circumventing our packaging system. Did you look at using the jar override feature of Maven? 2) The packages in the Maven repository are missing sources (and build.xml-files). Some of them don't have a build.xml file to start with. Maven is not ant. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: new idea on maven usage?
There may one day be a bridge to adapt Maven's repository to native
systems for things like distributions but when a project
creates a Maven
POM they expect it to work for people developing on all
platforms. They
aren't concerned about platform specifics and this has never
really been
the concern of Maven insofar as development goes.
I don't have much experience with native liblaries but I think that at least
maven should be able to help people who are using liblaries like SWT
(there is quite a lot of them).
In maven-artifact I solved this problem by introducing special artifact
type: native
With possiblity of defining repository layout per both artifact type and
platform in place type native
can be mapped to following layouts:
native=${groupId}/native/linux/${artifactId}-${version}.so
or
native=${groupId}/native/windows/${artifactId}-${version}.dll
Michal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: new idea on maven usage?
Hi Michal,
Maczka Michal wrote on Monday, February 02, 2004 9:25 AM:
I don't have much experience with native liblaries but I
think that at least maven should be able to help people who
are using liblaries like SWT (there is quite a lot of them).
In maven-artifact I solved this problem by introducing special
artifact type: native
With possiblity of defining repository layout per both
artifact type and platform in place type native
can be mapped to following layouts:
native=${groupId}/native/linux/${artifactId}-${version}.so
or
native=${groupId}/native/windows/${artifactId}-${version}.dll
This will definately not work. You cannot rename the native libraries! At least for
Windows you will not even have the possibility for a symlink. Have a look at Sun's
jai. For Windows they provide an executable and two different dlls. I would propose
something like
native=${groupId}/native/windows/${artifactId}-${version}/*.*
Regards,
Jörg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: new idea on maven usage?
Hi Mazka,
Maczka Michal wrote:
There may one day be a bridge to adapt Maven's repository to native
systems for things like distributions but when a project
creates a Maven
POM they expect it to work for people developing on all
platforms. They
aren't concerned about platform specifics and this has never
really been
the concern of Maven insofar as development goes.
I don't have much experience with native liblaries but I think that at least
maven should be able to help people who are using liblaries like SWT
(there is quite a lot of them).
In maven-artifact I solved this problem by introducing special artifact
type: native
With possiblity of defining repository layout per both artifact type and
platform in place type native
can be mapped to following layouts:
native=${groupId}/native/linux/${artifactId}-${version}.so
There is more than one cpu-type linux runs on, and these tend to be
mutually incompatible. Where does that come into play? You wouldn't want
arm-linux binary C libraries attempting to use i386-linux SWT libraries ;)
cheers,
dalibor topic
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: new idea on maven usage?
-Original Message-
From: Jörg Schaible [mailto:[EMAIL PROTECTED]
Sent: Monday, February 02, 2004 10:18 AM
To: Maven Users List
Subject: RE: new idea on maven usage?
Hi Michal,
Maczka Michal wrote on Monday, February 02, 2004 9:25 AM:
I don't have much experience with native liblaries but I
think that at least maven should be able to help people who
are using liblaries like SWT (there is quite a lot of them).
In maven-artifact I solved this problem by introducing special
artifact type: native
With possiblity of defining repository layout per both
artifact type and platform in place type native
can be mapped to following layouts:
native=${groupId}/native/linux/${artifactId}-${version}.so
or
native=${groupId}/native/windows/${artifactId}-${version}.dll
This will definately not work. You cannot rename the native
libraries!
You can. You are confusing naming convention used for versioning files
in the repository with the usage of the artifacts outside the repository.
Artifact kept in the repository don't necessarily need to be
named in the same way when they are used by the applications/projects.
Smart plugins can rename them if this will be needed
At least for Windows you will not even have the
possibility for a symlink. Have a look at Sun's jai. For
Windows they provide an executable and two different dlls. I
would propose something like
For me two different dlls = two different dependenies.
Michal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: new idea on maven usage?
-Original Message-
From: Dalibor Topic [mailto:[EMAIL PROTECTED]
Sent: Monday, February 02, 2004 10:27 AM
To: Maven Users List
Subject: Re: new idea on maven usage?
Hi Mazka,
Maczka Michal wrote:
There may one day be a bridge to adapt Maven's repository to native
systems for things like distributions but when a project
creates a Maven
POM they expect it to work for people developing on all
platforms. They
aren't concerned about platform specifics and this has never
really been
the concern of Maven insofar as development goes.
I don't have much experience with native liblaries but I
think that at least
maven should be able to help people who are using liblaries like SWT
(there is quite a lot of them).
In maven-artifact I solved this problem by introducing
special artifact
type: native
With possiblity of defining repository layout per both
artifact type and
platform in place type native
can be mapped to following layouts:
native=${groupId}/native/linux/${artifactId}-${version}.so
There is more than one cpu-type linux runs on, and these tend to be
mutually incompatible. Where does that come into play? You
wouldn't want
arm-linux binary C libraries attempting to use i386-linux SWT
libraries ;)
I think it will be doable via the proper parameterisation (more params) and
interpolation of layout e.g.
native=${groupId}/native/${platform}/${arch}/${artifactId}-${version}.so
Michal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: new idea on maven usage?
Hi Michal,
Maczka Michal wrote:
I think it will be doable via the proper parameterisation (more params) and
interpolation of layout e.g.
native=${groupId}/native/${platform}/${arch}/${artifactId}-${version}.so
Looks much better to me. There are still some interesting issues,
though. Let's talk about dynamic libraries written in C++. Different C++
compilers can produce incompatible libraries, since the name mangling is
not specified in the C++ standard. So you need to differentiate
generated binaries accroding to the compiler, and its version, too.
For example, if you try to link a C++ .so compiled with g++ 2.95 to a
C++ .so file compiled with g++ 3.2, you will have massive problems.
cheers,
dalibor topic
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: new idea on maven usage?
Maczka Michal wrote on Monday, February 02, 2004 11:26 AM: At least for Windows you will not even have the possibility for a symlink. Have a look at Sun's jai. For Windows they provide an executable and two different dlls. I would propose something like For me two different dlls = two different dependenies. Well, no: jai/bin: checkmmx.exe mlib_jai.dll mlib_jai_mmx.dll jai itself will test for MMX support and use the appropriate one. Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new idea on maven usage?
On Sun, 2004-02-01 at 21:52, Dalibor Topic wrote: Hi Jason, Jason van Zyl wrote: There may one day be a bridge to adapt Maven's repository to native systems for things like distributions but when a project creates a Maven POM they expect it to work for people developing on all platforms. They aren't concerned about platform specifics and this has never really been the concern of Maven insofar as development goes. In my experience (with getting different programs to run on free runtimes), things never work out of the box on all platforms, usually. For example, Maven has an ugly dependency on a sun.* class[1]. Thus Maven in CVS breaks on java runtimes that don't [2] implement sun.* classes. A lot of other java code makes unwarranted assumptions about its runtime [3]. Writing portable java code is probably as hard as writing portable C code. Well, there are certainly can be a few quirks but a comparison between free runtimes that are so far behind currently used specifications, or not even compliant, and JVMs that most people use isn't really relevant in most cases. The unwarranted assumptions you speak of are things that are present in non-compliant JVMs. While I certainly agree with you that [1] can easily be remedied you are the first and probably only person to catch [1]. While it's nice having things like Kaffe and Jaguar they are not products that people reach for first when developing with Java. I would like to use Kaffe but in the few times I've tried it's been a world of hurt. But I will certainly fix [1], that's not really a big deal. If I understand you correctly, are you saying that for development purposes Maven should be leveraging platform specific repositories? Yes, if such repositories are available. Otherwise it becomes quite hard to rebuild maven applications from source to verify their integrity, i.e. that they haven't been tampered with. No, that's simply not true. How would using an OS repository over Maven's own repository help with this in any way shape or form? All the information necessary to build the project is available in the POM. So all you need to do is get your hands on the POM and you could very easily make a tool to build a project. As far as I understand the concept, Maven uses JARs and provides a method for downloading them from a central repository. For systems putting a high priority on security, downloading binaries may not be good enough. Fair enough, though the policy that we will be instituting will incorporate a level of security with binaries that most people will be comfortable with. You may want to be able to rebuild everything from scratch, in order to be able to apply a quick source code patch for a security problem for example, and be able to put it all back together. So what advantage would a native package manager have over Maven doing this? I agree with you 100% that Java applications that are packaged up should surely be available in the form of packages that work on various systems. I mailed the JPackage group long, long ago and gave them a heads up on what was going on in Maven land and there was no interest. As far as I can tell, there is a lot of interest now between the various java application packaging projects in the Linux world for cooperation between each other. It took a while until free java runtimes like kaffe [4] caught up, and started to become suitable platforms to run current jakarta [5] (or other) applications [6] on. Ok, but I still don't see why Maven would benefit at all from trying to use an OS specific repository when we have a non-OS specific repository. Then there is a lot more cooking than JPackage. Naoko and RHUG are RedHat's efforts to use gcj to create very fast native executables and libraries from java applications and libraries. Costin Manolache here at Apache has played with things like Ant and Tomcat to produce binaries with GCJ and unless things have changed drastically in the recent past there really wasn't much of a difference in speed other than startup time. Not to say that these things aren't interesting but the JVMs people typically use are fast enoug. Then there is Gentoo Linux, that takes the ability to rebuild from source to the max. And so on. Building from source is not a problem, all the information you need is present in the POM. I assume that long, long ago people weren't as aware of Maven, as they are now. Maven is getting close to 1.0, after all, and has received some well-deserved attention lately ;) The whole power behind Maven is leaving things up to the project offering their work. Leaving the production and deployment up to the project. While it's obviosly quite clever to leave the production to the project ;), I have some doubts about deployment. Platform specific constraints may exist, that a project is not aware of. Java developers don't want to care about Platform specific
Re: new idea on maven usage?
Hi Jason, thanks a lot for taking the time to reply so quickly. Jason van Zyl wrote: On Sun, 2004-02-01 at 21:52, Dalibor Topic wrote: In my experience (with getting different programs to run on free runtimes), things never work out of the box on all platforms, usually. For example, Maven has an ugly dependency on a sun.* class[1]. Thus Maven in CVS breaks on java runtimes that don't [2] implement sun.* classes. A lot of other java code makes unwarranted assumptions about its runtime [3]. Writing portable java code is probably as hard as writing portable C code. Well, there are certainly can be a few quirks but a comparison between free runtimes that are so far behind currently used specifications, or not even compliant, and JVMs that most people use isn't really relevant in most cases. The unwarranted assumptions you speak of are things that are present in non-compliant JVMs. 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. ;) That's why kaffe says quite prominently that it's not Java on it's web page on http://www.kaffe.org. Nevertheless, it runs quite a few java applications quite alright ;) The unwarrented assumptions (i.e. unportable java code) are breaking applications even under compliant JVMs, as can be seen in a rather famous apache.org project, Ant. Citing from the announcement of Ant's 1.5.4 release: (1) With JDK 1.4.2 Sun has changed the entry point for javah, therefore Ant 1.5.3's javah task doesn't work on JDK 1.4.2 anymore. See http://nxnw.org/pipermail/sw-announce/2003-August/000181.html for details. To me, that's a clear case of unwarranted assumptions: assuming that sun.something.javah.something.else is an entry point to a javah tool implemented in java. The JDK API docs explicitely discourage programmers from using the sun.* packages directly. The JDK tool documentation makes no statement in which language javah is written. It's an assumption that leads to unportable java code, that (obviously) didn't work on some compliant, certified JVMs. While the free runtimes definitely lack a lot of features found in currently used JDKs, a lot of problems I encountered in getting applications to run on free runtimes was caused by that sort of sloppy programming style. So it can be argued, in my opinion, that getting those applications to run on free runtimes, actually results in useful bug fixes, and better applications. While I certainly agree with you that [1] can easily be remedied you are the first and probably only person to catch [1]. While it's nice having things like Kaffe and Jaguar they are not products that people reach for first when developing with Java. I would like to use Kaffe but in the few times I've tried it's been a world of hurt. But I will certainly fix [1], that's not really a big deal. One of the very frequently reported bugs for a while last autumn for Xerces was a hardcoded reference to a sun.* class for character conversion. I took part in the discussion of resolving the bug after stumbling over it while I was making eXist run with kaffe. It took quite a few duplicate bug reports to show Xerces developers that something should be done about it, as various people seem to have been quite keen on running Xerces with alternative runtimes, but were bitten by this bug. Eventually, after a couple of months, it was fixed, afaik. In my opinion, Xerces has gained from free runtime users and developers' participation in the development process, just like these users and developers have gained a working Xerces again for their platforms. I guess we can both quickly agree that the solution to [1] to use the jakarta commons-codec package is a better solution for a variety of reasons for a jakarta project, than to rely on an undocumented, unspecified class for that functionality. 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. And there we are again in the 'unwarranted assumptions' case: the JDK docs do say something about a tools.jar file in the 'How Classes are found section', but they fail to name the classes present there, since they are in a sun.* package, i.e. 'forbidden' territory. So tools.jar is rather useless, if one writes his Java programs strictly according to the JDK docs. There is no reason to include it, that can be deduced from the JDK docs. Whatever assumptions Maven makes about tools.jar, these assumptions are hardly backed up by the JDK documentation. Or I failed to find it, in which case I'd
Re: new idea on maven usage?
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. That's why kaffe says quite prominently that it's not Java on it's web page on http://www.kaffe.org. Nevertheless, it runs quite a few java applications quite alright ;) The unwarrented assumptions (i.e. unportable java code) are breaking applications even under compliant JVMs, as can be seen in a rather famous apache.org project, Ant. Citing from the announcement of Ant's 1.5.4 release: (1) With JDK 1.4.2 Sun has changed the entry point for javah, therefore Ant 1.5.3's javah task doesn't work on JDK 1.4.2 anymore. See http://nxnw.org/pipermail/sw-announce/2003-August/000181.html for details. To me, that's a clear case of unwarranted assumptions: assuming that sun.something.javah.something.else is an entry point to a javah tool implemented in java. The JDK API docs explicitely discourage programmers from using the sun.* packages directly. The JDK tool documentation makes no statement in which language javah is written. It's an assumption that leads to unportable java code, that (obviously) didn't work on some compliant, certified JVMs. 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. While I certainly agree with you that [1] can easily be remedied you are the first and probably only person to catch [1]. While it's nice having things like Kaffe and Jaguar they are not products that people reach for first when developing with Java. I would like to use Kaffe but in the few times I've tried it's been a world of hurt. But I will certainly fix [1], that's not really a big deal. I guess we can both quickly agree that the solution to [1] to use the jakarta commons-codec package is a better solution for a variety of reasons for a jakarta project, than to rely on an undocumented, unspecified class for that functionality. There are a boatload of encoders lying around. I used one of them :-) 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. And there we are again in the 'unwarranted assumptions' case: the JDK docs do say something about a tools.jar file in the 'How Classes are found section', but they fail to name the classes present there, since they are in a sun.* package, i.e. 'forbidden' territory. So tools.jar is rather useless, if one writes his Java programs strictly according to the JDK docs. There is no reason to include it, that can be deduced from the JDK docs. Whatever assumptions Maven makes about tools.jar, these assumptions are hardly backed up by the JDK documentation. Or I failed to find it, in which case I'd appreciate an URL ;) I'd like to use Maven, and you'd like to use Kaffe, so I'm sure we can find a common ground there, and a good solution. If I understand you correctly, are you saying that for development purposes Maven should be leveraging platform specific repositories? Yes, if such repositories are available. Otherwise it becomes quite hard to rebuild maven applications from source to verify their integrity, i.e. that they haven't been tampered with. No, that's simply not true. How would using an OS repository over Maven's own repository help with this in any way shape or form? All the information necessary to build the project is available in the POM. So all you need to do is get your hands on the POM and you could very easily make a tool to build a project. Usually OS repositories can be rebuilt from source (if the license permits so). There is
Re: new idea on maven usage?
Just my 2-cents, but... I can definitely say that if maven went to an OS-specific repository with packages (rpm, etc.) I'd stop using it so fast it would make your head spin. The current state of packaging software on most projects today seems to range from non-existent (Windows) to poor (RedHat, et al) with outliers being the BSD's and Debians of the world. The problem with BSD is that they don't even port the JVM quickly enough to be considered relevant. If we tried to program strictly for BSD, we'd all still be stuck on JDK 1.3. As for Debian, from what I've heard it's a nice system, but you can't make sweeping, generalized statements about package managers when this is nearly the only relevant example. In short, the result of my experience with dependency management in most package management software has been increased blood pressure and (I'm sure) a shortened life span. Obviously, I'm no expert, but I believe I can take a fair crack at representing the masses. ;) Is maven the right thing to use for managing native code? Probably not, at least by itself. Does it have an appreciable advantage for most users over 99% of the dependency management field? OH, Hell yes. As for its deficiencies, I believe a tiny introduction of execution hooks (as in, post-bootstrap, pre-*-execution) would definitely allow plugin development to address them all. Please, oh please, to anyone in charge who may be listening, don't let maven go the way of the RPM. It's too good of a product on its own to lose its technology in an uninstallable mess. Thanks for listening. :) -john On Mon, 2004-02-02 at 11:19, 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. That's why kaffe says quite prominently that it's not Java on it's web page on http://www.kaffe.org. Nevertheless, it runs quite a few java applications quite alright ;) The unwarrented assumptions (i.e. unportable java code) are breaking applications even under compliant JVMs, as can be seen in a rather famous apache.org project, Ant. Citing from the announcement of Ant's 1.5.4 release: (1) With JDK 1.4.2 Sun has changed the entry point for javah, therefore Ant 1.5.3's javah task doesn't work on JDK 1.4.2 anymore. See http://nxnw.org/pipermail/sw-announce/2003-August/000181.html for details. To me, that's a clear case of unwarranted assumptions: assuming that sun.something.javah.something.else is an entry point to a javah tool implemented in java. The JDK API docs explicitely discourage programmers from using the sun.* packages directly. The JDK tool documentation makes no statement in which language javah is written. It's an assumption that leads to unportable java code, that (obviously) didn't work on some compliant, certified JVMs. 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. While I certainly agree with you that [1] can easily be remedied you are the first and probably only person to catch [1]. While it's nice having things like Kaffe and Jaguar they are not products that people reach for first when developing with Java. I would like to use Kaffe but in the few times I've tried it's been a world of hurt. But I will certainly fix [1], that's not really a big deal. I guess we can both quickly agree that the solution to [1] to use the jakarta commons-codec package is a better solution for a variety of reasons for a jakarta project, than to rely on an undocumented, unspecified class for that functionality. There are a boatload of encoders lying around. I used one of them :-) 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
Re: new idea on maven usage?
On Mon, 2004-02-02 at 12:07, John Casey wrote: Just my 2-cents, but... I can definitely say that if maven went to an OS-specific repository with packages (rpm, etc.) I'd stop using it so fast it would make your head spin. Which is how I think most would feel. To go from something that we have full control over, the repository and the mechanism in which the artifacts are used, to something where we are at the mercy of the OS is not a reasonable. The current state of packaging software on most projects today seems to range from non-existent (Windows) to poor (RedHat, et al) with outliers being the BSD's and Debians of the world. The problem with BSD is that they don't even port the JVM quickly enough to be considered relevant. If we tried to program strictly for BSD, we'd all still be stuck on JDK 1.3. As for Debian, from what I've heard it's a nice system, but you can't make sweeping, generalized statements about package managers when this is nearly the only relevant example. In short, the result of my experience with dependency management in most package management software has been increased blood pressure and (I'm sure) a shortened life span. Obviously, I'm no expert, but I believe I can take a fair crack at representing the masses. ;) Definitely. Most folks developing with Java do so because they don't want to have to use anything platform specific. Is maven the right thing to use for managing native code? Probably not, at least by itself. Right, I think that if you are mixing Java and native code then a plugin can be written that cooperates with the underlying OS. Or a series of plugins where each one deals with a particular OS. Or not use Maven at all if it doesn't suit. Does it have an appreciable advantage for most users over 99% of the dependency management field? OH, Hell yes. As for its deficiencies, I believe a tiny introduction of execution hooks (as in, post-bootstrap, pre-*-execution) would definitely allow plugin development to address them all. Please, oh please, to anyone in charge who may be listening, don't let maven go the way of the RPM. Have no fear :-) It's too good of a product on its own to lose its technology in an uninstallable mess. Thanks for listening. :) -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new idea on maven usage?
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
Re: new idea on maven usage?
On Sun, 2004-02-01 at 18:59, 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. This has always been the case with Java development as the currently reigning defacto standard is Ant which has no concept of a repository at all. There may one day be a bridge to adapt Maven's repository to native systems for things like distributions but when a project creates a Maven POM they expect it to work for people developing on all platforms. They aren't concerned about platform specifics and this has never really been the concern of Maven insofar as development goes. If I understand you correctly, are you saying that for development purposes Maven should be leveraging platform specific repositories? I agree with you 100% that Java applications that are packaged up should surely be available in the form of packages that work on various systems. I mailed the JPackage group long, long ago and gave them a heads up on what was going on in Maven land and there was no interest. The whole power behind Maven is leaving things up to the project offering their work. Leaving the production and deployment up to the project. Could you not leverage the repository to make your platform specific packages for those that wanted to use platform specific packagers? I only use Linux and I honestly never use JPackage packages. As I mentioned above I doubt many people do simply because Ant doesn't have a repository concept, people usually checked artifacts into CVS. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new idea on maven usage?
Hi Jason, Jason van Zyl wrote: There may one day be a bridge to adapt Maven's repository to native systems for things like distributions but when a project creates a Maven POM they expect it to work for people developing on all platforms. They aren't concerned about platform specifics and this has never really been the concern of Maven insofar as development goes. In my experience (with getting different programs to run on free runtimes), things never work out of the box on all platforms, usually. For example, Maven has an ugly dependency on a sun.* class[1]. Thus Maven in CVS breaks on java runtimes that don't [2] implement sun.* classes. A lot of other java code makes unwarranted assumptions about its runtime [3]. Writing portable java code is probably as hard as writing portable C code. If I understand you correctly, are you saying that for development purposes Maven should be leveraging platform specific repositories? Yes, if such repositories are available. Otherwise it becomes quite hard to rebuild maven applications from source to verify their integrity, i.e. that they haven't been tampered with. As far as I understand the concept, Maven uses JARs and provides a method for downloading them from a central repository. For systems putting a high priority on security, downloading binaries may not be good enough. You may want to be able to rebuild everything from scratch, in order to be able to apply a quick source code patch for a security problem for example, and be able to put it all back together. I agree with you 100% that Java applications that are packaged up should surely be available in the form of packages that work on various systems. I mailed the JPackage group long, long ago and gave them a heads up on what was going on in Maven land and there was no interest. As far as I can tell, there is a lot of interest now between the various java application packaging projects in the Linux world for cooperation between each other. It took a while until free java runtimes like kaffe [4] caught up, and started to become suitable platforms to run current jakarta [5] (or other) applications [6] on. Then there is a lot more cooking than JPackage. Naoko and RHUG are RedHat's efforts to use gcj to create very fast native executables and libraries from java applications and libraries. Then there is Gentoo Linux, that takes the ability to rebuild from source to the max. And so on. I assume that long, long ago people weren't as aware of Maven, as they are now. Maven is getting close to 1.0, after all, and has received some well-deserved attention lately ;) The whole power behind Maven is leaving things up to the project offering their work. Leaving the production and deployment up to the project. While it's obviosly quite clever to leave the production to the project ;), I have some doubts about deployment. Platform specific constraints may exist, that a project is not aware of. A small example: Debian is one of the huge Linux distributions. It has a lot of users and a vital developer community. Among other nice things, Debian has a Social Contract [7] and an associated set of software guidelines [8]. Those software guidelines make specific requirements on licensing of software that comes with debian. So some applications may need to be split into free and non-free parts in order to get into debian. Some Jakarta projects [9], for example, have dependencies on non-free software that make it quite hard to put them in the form in which they are released by their developers into debian. They need to be 'sanitized' first. This is just a small example of platform-specific adaptations being necessary. Putting the burden for them on the project is not very helpful in the short run, I think. Could you not leverage the repository to make your platform specific packages for those that wanted to use platform specific packagers? Well, there is more to packaging than downloading the binaries ;) You should also want to be able to verify the integrity of the files, to rebuild the binaries if necessary, to uninstall no longer needed packages, to update packages, etc. Maven is a useful build tool. It's also a very nice site-generation system, and probably a few more things that I haven't caught up reading about yet. OTOH, it's not a replacement for a package management system like rpm, urpmi, or dpkg, as far as I can tell. I think there is some room for cooperation (and interesting dialogue) between the various java packaging projects and Maven developers. They all try to solve the 'satisfying dependencies' problem, for example. I only use Linux and I honestly never use JPackage packages. As I mentioned above I doubt many people do simply because Ant doesn't have a repository concept, people usually checked artifacts into CVS. Well, one of the things we both can agree upon very easily is that checking in artifacts into CVS is a bad idea. That's like checking in object
Re: new idea on maven usage?
Trygve Laugstøl wrote: On Thu, 29 Jan 2004 11:36:43 -0500, Mark R. Diggory [EMAIL PROTECTED] wrote: True, true. That is another option. Maybe theres others. I can imagine generating other OS specific package installers too. (RPM, bin, XPI, sh, InstallSheild, msi ...). A plugin or series of plugins devoted to building such installers using maven and its repository resources. -Mark There are several such plugins on the maven-plguins.sf.net site: * http://maven-plugins.sourceforge.net/maven-runtime-builder-plugin * http://maven-plugins.sourceforge.net/maven-deb-plugin * http://maven-plugins.sourceforge.net/maven-rpm-plugin The runtime plugin builds a runtime consisting of a lib catalog witha all dependencies and .bat and .sh shell wrappers. It's a very bad idea, in my opinion, if it completely circumvents the native OS packaging with respect to resolving dependencies. There is a ton of reasons why the packager of a dependency for an OS can make a more suited component to depend on than the generic jar file downloaded off ibiblio.org/maven. Security, OS-specific patches, configuration file locations, handling of multiple runtimes, ... cheers, dalibor topic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new idea on maven usage?
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. I know that webstart/jnlp can do this for me, IF I provide all the jar files requested (webstart cannot use unsigned jar files, nor jarfiles with different persons) and it would still not use already downloaded jar files from other programs. 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. 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) 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. 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) /Christian Trygve Laugstøl wrote: On Thu, 29 Jan 2004 11:36:43 -0500, Mark R. Diggory [EMAIL PROTECTED] wrote: True, true. That is another option. Maybe theres others. I can imagine generating other OS specific package installers too. (RPM, bin, XPI, sh, InstallSheild, msi ...). A plugin or series of plugins devoted to building such installers using maven and its repository resources. -Mark There are several such plugins on the maven-plguins.sf.net site: * http://maven-plugins.sourceforge.net/maven-runtime-builder-plugin * http://maven-plugins.sourceforge.net/maven-deb-plugin * http://maven-plugins.sourceforge.net/maven-rpm-plugin The runtime plugin builds a runtime consisting of a lib catalog witha all dependencies and .bat and .sh shell wrappers. -- Trygvis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: new idea on maven usage?
Christian Andersson wrote on Wednesday, January 28, 2004 7:16 PM: Hi there, I think I have a new idea on how to use maven, not just as a build system. Maybe you'll find this interesting: http://blogs.codehaus.org/projects/maven/archives/000268_maven_wagon_has_landed.html :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new idea on maven usage?
True, true. That is another option. Maybe theres others. I can imagine generating other OS specific package installers too. (RPM, bin, XPI, sh, InstallSheild, msi ...). A plugin or series of plugins devoted to building such installers using maven and its repository resources. -Mark Ethan Rider wrote: Pardon my interjection, but if the problem domain is restricted to java files, wouldn't JNLP be the technology to leverage here? - Original Message - From: Mark R. Diggory [EMAIL PROTECTED] Date: Wednesday, January 28, 2004 4:24 pm Subject: Re: new idea on maven usage? Novel Idea, I think Ant might be a lighter starting point. In fact you could do something like the ant-plugin to generate an ant build.xml that starts the whole process. If the user has ant installed, they can just run your script, otherwise, you could package it with just enough of the ant classes that it would be light and simple to execute from within a jar file. %jar foo-start.jar -Mark Christian Andersson wrote: Hi there, I think I have a new idea on how to use maven, not just as a build system. anyway, what I thought of is the following. I want to use some sort of minimalistic version of maven to start my applications, this way I do not have to distribute any of my jar files, or any of the external jar files, and I can also get a version controled handling of the execution. what would be needed to use this. project.xml remove all the build stuff add information on which class to run and if it should be threaded maven includes no plugins and only 2 goals start to start the applikation (if the application is threaded maven will exist after start but the application still running) stop to stop the application (if it was started threaded) If I have maven-starter locally installed all I would need was to download the project.xml file and type maven start this would then download everything that was needed (if not previously downloaded) and start the applikation. In a sence it is sort of a webstart system, but the jar files does not have to be on the same server, nor signed, etc... we could ofcourse demand some security in this so that jar files hae to be signed, etc and that users have to agree to the signature (much like webstart) but I think this could be better then webstart, since this could also work with server applications... anyway it is just an idea! /Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu --- -- 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] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new idea on maven usage?
Pardon my interjection, but if the problem domain is restricted to java files, wouldn't JNLP be the technology to leverage here? - Original Message - From: Mark R. Diggory [EMAIL PROTECTED] Date: Wednesday, January 28, 2004 4:24 pm Subject: Re: new idea on maven usage? Novel Idea, I think Ant might be a lighter starting point. In fact you could do something like the ant-plugin to generate an ant build.xml that starts the whole process. If the user has ant installed, they can just run your script, otherwise, you could package it with just enough of the ant classes that it would be light and simple to execute from within a jar file. %jar foo-start.jar -Mark Christian Andersson wrote: Hi there, I think I have a new idea on how to use maven, not just as a build system. anyway, what I thought of is the following. I want to use some sort of minimalistic version of maven to start my applications, this way I do not have to distribute any of my jar files, or any of the external jar files, and I can also get a version controled handling of the execution. what would be needed to use this. project.xml remove all the build stuff add information on which class to run and if it should be threaded maven includes no plugins and only 2 goals start to start the applikation (if the application is threaded maven will exist after start but the application still running) stop to stop the application (if it was started threaded) If I have maven-starter locally installed all I would need was to download the project.xml file and type maven start this would then download everything that was needed (if not previously downloaded) and start the applikation. In a sence it is sort of a webstart system, but the jar files does not have to be on the same server, nor signed, etc... we could ofcourse demand some security in this so that jar files hae to be signed, etc and that users have to agree to the signature (much like webstart) but I think this could be better then webstart, since this could also work with server applications... anyway it is just an idea! /Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu --- -- 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]
