Re: JSSE implementation in a public Maven repo?
On Mon, Jul 10, 2006 at 02:08:29PM -0500, Jeff Jensen wrote: > Thanks Dalibor. Do you know if the Jessie artifacts are in any public Maven > repos? I am not aware of any. You could follow the usual procedure and submit an artifact for inclusion on ibiblio, I believe there are RPMs and .debs containing jessie's JAR if you don't wnat to build the artifact from source. cheers, dalibor topic > > > Quoting Dalibor Topic <[EMAIL PROTECTED]>: > > > On Mon, Jul 10, 2006 at 12:21:47PM -0500, Jeff Jensen wrote: > > > Hi, > > > > > > I'm looking for a JSSE implentaton hosted in a public Maven repo. I have > > not > > > been able to find one. Obviously it must be an OS one, not Sun's or > > > IBM's. > > > > > > Can anyone advise of one? > > > > > > For example, anyone working with Jessie? > > > http://www.nongnu.org/jessie > > > > > > > It's currently used in any GNU Classpath VM as the JSSE implementation. > > > > FWIW, there is a Google SOC project for Jessie to update it to do SSL > > over NIO. See > > http://code.google.com/soc/gnu/appinfo.html?csaid=3F1821EB717AF23 for > > the details and Casey's status blog is at > > http://metastatic.org/text/Concern/category/hacking/summer-of-code/ > > > > cheers, > > dalibor topic > > > > > > > > - > > > 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] > > > > > > > > > - > 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]
Re: JSSE implementation in a public Maven repo?
On Mon, Jul 10, 2006 at 12:21:47PM -0500, Jeff Jensen wrote: > Hi, > > I'm looking for a JSSE implentaton hosted in a public Maven repo. I have not > been able to find one. Obviously it must be an OS one, not Sun's or IBM's. > > Can anyone advise of one? > > For example, anyone working with Jessie? > http://www.nongnu.org/jessie > It's currently used in any GNU Classpath VM as the JSSE implementation. FWIW, there is a Google SOC project for Jessie to update it to do SSL over NIO. See http://code.google.com/soc/gnu/appinfo.html?csaid=3F1821EB717AF23 for the details and Casey's status blog is at http://metastatic.org/text/Concern/category/hacking/summer-of-code/ cheers, dalibor topic > > - > 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]
Re: sun jars
On Thu, Oct 20, 2005 at 04:16:09PM +0200, Fabrizio Giustina wrote: > On 10/20/05, Dalibor Topic <[EMAIL PROTECTED]> wrote: > > On Thu, Oct 20, 2005 at 01:25:31PM +0200, Fabrizio Giustina wrote: > > > You will not believe it, but this is also required for standard dtds > > > and xsds (like the web.xml schema)... according to Sun any xml editor > > > which reads the xsd declaration in an xml file and tries to download > > > it for validation without prompting for the license could be > > > considered illegal?!? > > > > That's a new one. Got an URL ? > > I was referring to Eclipse. Just try using eclipse+webtools to open a > web.xml file and you will see the licence agreement popup (with the > full license, I don't know the actual URL on Sun website). I guess that's bug #104086 , #88260 and a bunch of others in the Eclipse bug tracker. cheers, dalibor topic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sun jars
On Thu, Oct 20, 2005 at 08:32:14AM -0700, Jason van Zyl wrote: > On Thu, 2005-10-20 at 04:10 -0700, Dalibor Topic wrote: > > > On a side note, any idea whether JSR 277 will be developped in an open > > fashion, with an open source RI, like the concurrency JSR was? > > That's up to the spec lead (Stanley Ho), but we are still designing so > no code has been written yet. I'll definitely try to convince Stanley to > open it up though. > thank you. And thanks a lot for your work on Maven, congrats to everyone on the 2.0 release! cheers, dalibor topic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sun jars
On Thu, Oct 20, 2005 at 01:25:31PM +0200, Fabrizio Giustina wrote: > Some more thoughts... > > The same problem with Sun licenses was recently addressed also by > Eclipse. They implemented a click-through mechanism where the user > must accept the sun license everytime a file is requested from a sun > server (an eclipse window containing a page from the sun website and > an eccept button is displayed). The same could be done for maven. No, please. Don't. That would screw up automated builds. For such a scheme gone bad, see NetBeans 3 build system, where you have to click through many licenses to get the IDE built. There was a super secret Sun internal way of working around that to make automated builds work, judging by the build scripts. Ugh. > You will not believe it, but this is also required for standard dtds > and xsds (like the web.xml schema)... according to Sun any xml editor > which reads the xsd declaration in an xml file and tries to download > it for validation without prompting for the license could be > considered illegal?!? That's a new one. Got an URL ? > Maybe somebody would came up with an unofficial repository outside > apache containing the sun jars and the above notice, of course > explaining he will immediately remove them if Sun will complain about > such use not contemplated in their not-so-clear license (emh, not a > suggestion, but maybe...) Well, two problems: redistribution without license is copyright violation, and that, if done for commercial purposes, can carry a few years of jail time and a hefty monetary penalty per violation in the USA. Not much fun, really, if you have a family to feed, or just care about your own future. If you don't care about your future, then chances are there a more interesting ways to destroy your life, than by violating other people's copyrights and paying up for it for the rest of your life. ;) Such lawsuits are standard procedure in the p2p field. Usually the $BIGCORPS win, and the people who lose don't like the results they end up with very much. The other problem is that if you don't have a license to redistribute the jars, people getting those jars from you don't have a license to use them, just like buying a Windows XP Pro CD for 3 USD on a flea market in Russia does not actually mean you actually have a license from Microsoft to use that copy of Windows XP Pro. ;) That can matter if say, a company C downloading the jars from you gets into a lawsuit with the $BIGCORP that owns the proprietary jars, and during the discovery process, it turns out that C is using $BIGCORPS's proprietary technology without license. Such a thing never looks good in court. cheers, dalibor topic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sun jars
On Wed, Oct 19, 2005 at 07:54:49PM -0400, Brill Pappin wrote: > Yah, its a bit of a gray area though... I could write a plugin that used > each of the libs in question in some way and distribute the plugin... the > user would then have it in the environment. > No, you can't. The license demands that your program adds significant and primary functionality to the proprietary code. A plugin does not cut it. Even if you managed to find a way, the BCL demands that you don't distribute additional software intended to replace any component of the proprietary software. The whole point of projects like Geronimo is to replace proprietary software components. They use Maven repos, too ;) The non-free licenses on proprietary software distributed by $BIGCORPS are not there by accident, they are there for a reason, each and every clause in them. The business model of selling non-free Java technology is based upon restricting access, use and redistribution of one's implemntation of said technology in order to get other $BIGCORPS wishing to employ that technology under better terms to pay up, or to pay for the right to implement their own compatible version, which they can license to themselves under better terms. The non-free licenses are made with other $BIGCORPS in mind wishing to sell proprietary software and to bundle other $BIGCORPS proprietary technology along with their proprietary software. So naturally, the licenses will be a bad fit for open source projects. But that's by design, and required for the business model of selling proprietary Java software. Sure, the $BIGCORPS could have different terms for other $BIGCORPS and for open source projects, but why should a $BIGCORP pay cold hard cash to get the same terms as a random open source project? :) See, you may be able to find a technical way to work aroudn the license, but the problem you are trying to solve is a social one, namely 'We make money selling our intellectual property, and you want us to give that money up !?'. Even if you found a way around it, the jars would be pulled, the license would be changed, and that would be the end of that technical solution. And it surely isn't for the lack of people talking to, say, Sun Microsystems [1]. I've watched a lot of people in the last five years in various projects boldly proclaim that they'll go talk to $BIGCRP to get some non-free Java software redistributed under nicer conditions. They have all failed, afaict by the licenses of most of Java technology not having changed much in the last five years. cheers, dalibor topic [1] Not wanting to single them out, other $BIGCORPS with proprietary software windmills have also had their share of folks running against them. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sun jars
On Wed, Oct 19, 2005 at 04:52:33PM -0700, Jason van Zyl wrote:
> On Thu, 2005-10-20 at 01:40 +0200, Tomasz Pik wrote:
> > On 19/10/05, Marcel Schutte <[EMAIL PROTECTED]> wrote:
> > > Couldn't someone from the maven development team ask Sun for their
> > > explicit permission to publish all these jars? As we say in Holland:
> > > 'Nee heb je, ja kun je krijgen' ('No you've got, yes you can get').
> >
> > Here's link to story:
> > http://maven.apache.org/project/sun-licensing-journey.html
> > In case if it disapear, here's the file in SVN repo:
> > http://tinyurl.com/dxjwy
>
> Yah, I gave up trying to get them to do anything. Too much of a waste of
> time as SUN didn't appear to have any interest in helping.
>
I believe that particular story ended in summer 2005 with Geronimo
writing their own Java Mail implementation from scratch as open
source software and going through the TCK for it. Judging by the news of
Geronimo passing the J2EE certification, it seems to have worked out,
where two years of talking about non-free licenses side-effects have
failed.
That seems to be a more effetive plan in general, than trying to get Sun
Microsytems to relicense their proprietary code base. See Geronimo, and
GNU Classpath projects for examples.
On a side note, any idea whether JSR 277 will be developped in an open
fashion, with an open source RI, like the concurrency JSR was?
cheers,
dalibor topic
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: sun jars
On Tue, Oct 18, 2005 at 03:05:06PM +0200, Nicolas De Loof wrote: > > I think the only legal way to build a download script would be to use a > console mode browser to follow the $BIGCORP download process. But I > don't think sun download process may be clean viewed on a console mode > browser. I don't think a download script would be illegal, actually. But using a download script may not result in a valid license for the downloaded jar file, due to the questionable formation of a contract in that case[1]. YMMV in your court of choice, and in general the $BIGCORP won't like a situation where their potential for excercising their restrictions is unclear wrt to your use of their non-free work. cheers, dalibor topic [1] Non-free licenses in general resemble contracts, and contracts require some form of acceptance to occur in order to be formed between two parties. In addition, without a valid contract with $BIGCORP, a download and use of their non-free works, puts you in a similar position wrt to legality of your use as grabbing random OS X vmware images of bittorrent: not really a 'best practice' for a business. :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sun jars
On Tue, Oct 18, 2005 at 02:15:53PM +0200, Arik Kfir wrote: > No, that's ok. The license prohibits you from *redistributing* the > JAR. As long as its for your own use, you're fine. Depends. In general, people writing non-free licenses make them click-wrap so that they can enforce the restrictions on use they came up with in court. Bypassing the click-wrap mechanisms may or may not result in a valid license for you, and is in general not seen as a good thing by the folks licensing the non-free code in the first place, since they'd have a harder time in court showing the consent agreement to the license, if they had to go there to enforce their restrictions on your use of their non-free work. For example, if $BIGCORP offers X.jar under a non-free click-wrap license, and your script downloads it and does all the clicking through, and then $BIGCORP finds out that you worked around their licensing arrangements, $BIGCORP can take you to court on the basis that you never agreed to their license, so you have no right to use their work (it's non-free by the explicit wish of $BIGCORP). Just because you can obtain someone's non-free work somehow (script, napster, bittorrent), does not mean the $BIGCORP will authorise its use without having established some form of a contract with you (rather than granting you a free for all license). In general, a $BIGCORP peddling in non-free software wants to be able to haul your ass into court if they see it fit, and they don't like the prospect of having to deal with 'uh, but the $INSTALLER script downloaded it all automatically, how am I supposed to know its license, which I never actually agreed to anyway?' claims in a court setting, if they desire to protect their valuable cash-cow restrictions on use/modifications/redistribution in court. Who should $BIGCORP sue then for damages if it turns out it can't enforce its license against some hypothetical 'evil-doers'? Should $BIGCORP sue the script developers?[1] :) cheers, dalibor topic [1] A lot of this has already played out in the p2p field anyway, where corporations have sued end users, distributors, distribution channels, etc, to protect and enforce their restrictions on use. See MGM vs. Grokster for an example of suing the script developers instead of the copyright violators and pushing it all the way through the supreme court of USA. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help using jikes with maven
Jack Carden wrote: > I'm new to maven and geronimo, but I like what I see here. > > I've now built geronimo-1.0.M4 for the first time with JDK 1.4.2 and maven > 1.0.2. > > I'm trying to configure my geronimo project to compile with jikes. I have > set in project.properties: > > maven.compile.executable=jikes > > maven.compile.verbose=true > > > > I used: > > maven -Djikes.class.path= > > > > jikes is getting invoked, but without the classpath setting. Here's the > error message: > > [javac] *** Semantic Error: You need to modify your classpath, > sourcepath, bootclasspath, and/or extdirs setup. Jikes could not find > package "java.lang" in: listed in jikes.class.path> > > > > Any help will be greatly appreciated. Please respond by email since I'm not > a subscriber. I am currently building (and whacking into shape) geronimo 1.0M4 on kaffe's cvs head, and all that kaffe internally does is to set build.compiler & friends for jikes, which works fine for me. cheers, dalibor topic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Al Robertson is out of the office.
Craig S. Cottingham wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 7, 2004, at 09:27, Brill Pappin wrote: Ok, this is annoying... can an account be disabled for a specific time period? - Brill Al Robertson wrote: I will be out of the office starting 05/06/2004 and will not return until 14/06/2004. I will respond to your message when I return. Let's just all go by his office (since he's obviously out for another week) and rearrange his stuff. The scary bit is that he *will* respond to all the messages when he returns. Picture that flood on the mailing list, when Al comments on everything posted in his absence :) cheers, dalibor topic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new idea on maven usage?
ter 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. ;) 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. Not being a gcj developer myself, I unfortunately don't know how well it copes with that sort of issues. You may want to ask on the gcj developer mailing lists. 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?
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: 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, 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-config
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?
zero-install website, their security concept is somewhat better, than your proposal ;) But as I'm not familiar with zero-install's limitations, I can't comment on how well it would work for java applications. In my opinion, though, zero-install tries to solve a harder problem wrt software distribution and management, since it explicitely wants to handle native code (among other types), whereas, if I understand Jason correctly, Maven would be focused on java artifacts alone. And why should not distributions not use java? they can you know, and if they do, they will also benifit. I don't think I ever said distributions should not use Java in this thread. I'm actually involved with bringing more Java applications into Debian Linux ;) If it happens that the project.xml file has dependencies that was NOT installed from the distribution installer (which can happen) it will gladly download it from the web (which can be the dependencies real webserver, OR the distributions webserver) See, that's the kind of integration that I'm thinking about. If Maven is to be used to distribute and manage software (on Linux), it needs to interface with native package management software to see what's already there, and request an installation if necessary (where you propose straight downloading). We're not that far apart, as you can see. This way we get a good package management for java applications that works the same on ALL plattforms, we can even use the exact same package management to build the sources,and I see not problem with that. That would be a nice thing, for sure. But I'm frankly more interested in having good package management on one platform, since I'd consider that enough of a challenge already, and doubt that it would work the same on all platforms, since a centralized repository could be overwhealmed by the work necessary to manage artifacts for all platforms. Now some people have said 'use a standard JDK', or 'use a standard platform', which pretty much proves my point. If it's too much work to support all possible platforms, the central Maven repository could only support a few, selected platforms. That's O.K., everyone does it, and it's all very reasonable. All I'm trying to do is to get you to realize the limitation of the approach you propose: it can not possibly work (untested) on all platforms. Now if you want tested and tried software, that's part of what distributors do. AND since the dependencies are calculated and SOLVED when the application starts, there is no problem at all deleting the entire repository to free up space (not so much used java-applications will therefore take no place) the maven repository can bee seen as the "cache" that exist in zero-install. as long as the jar-files exist on the internet, you still can run the application even after you delete all the required jar files... That assumes that resolving dependencies is all there is to software distribution ;) A lot of the hard work involved is in actually testing what you've got extensively and fixing the problems you find on the environments you support. Quite often, this additional level of quality assurance produces better results in those environments, than the original software/artifacts produced by the developers, and everyone profits. personally I think it is better to resolve the dependencies when running the application then at install time... I see no problem in having the distribution to use the maven system for the jar files, only benefits... Well, the major problem I can see is that it wouldn't integrate at all with native package management, so it becomes impossible to manage java software using Maven with the native package management tools. That sort of setup starts to get really messy when you have multiple-programming-language software (eclipse, java-gnome), which would on one hand depend on Maven for the java side of things, and on the other on native package management software for the native side of things (SWT, libgtk). If Maven and native package management don't integrate, chances are that you'll end up with a hosed combination that doesn't run eventually. BTW, thanks a lot for keeping the discussion focused on the technical aspects. cheers, dalibor topic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Réf. : Re: new idea on maven usage?
Hi Olivier, Olivier CHAMPAGNE wrote: Hello, In my current project (see my previous posts/questions for a light description), Maven is still used : 1. to build a system (a framework used by end-user's projects) uploaded on our intranet 2. to distribute and manage "software" during further framework' uses by projects from our intranet. I'm not arguing that there are *no* contexts where using Maven for software distribution and management makes sense. I've already mentioned Windows as an example, and a corporate intranet sounds like a reasonable context, too. I'm just arguing that as a general solution a centralized repository is inferior to a native package management solution on some platforms (mainly Linux) for a variety of reasons. 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. 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 ;) cheers, dalibor topic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new idea on maven usage?
Hi Rafal, Rafal Krzewski wrote: Dalibor Topic wrote: 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. Dude, you keep missing the point! Maven *is not* and does not *pose* itself to be a package management system! Dude, you must have joined late in the thread ;) It's about a hypothetical, novel idea to use Maven not just as a build system, but also to distribute and manage software. It's not a general criticism of Maven. It starts here http://article.gmane.org/gmane.comp.jakarta.turbine.maven.user/10502 and evolved into a discussion of how well Maven is suited for software distribution and management. The context is that novel idea, not Maven as it is. I'm arguing it's not, that it's an inferior solution compared to native package management and in the case of software management and distribution it would be beneficial to employ native packages of artifacts where available. All within the context of that novel idea. I see that we agree (though you may have misunderstood my intentions), and I pretty much agree with the rest of your post. I'm not arguing that Maven is concerned with platform-dependencies, nor am I arguing that it should be. That's not very necessary in the context of Maven as a build tool. But since the novel idea was about software distribution and management, not developement, I'm arguing with a lot of examples that platform-dependencies come into play when you deal with software distribution and management. I also questioned the implied notion of portability employed by some discutants, presenting real-world proof of 'pure java' not automatically implying being portable across platforms/runtimes/architectures. It is a tool to build java libraries. And to document them. It is not concerned with the fact of the resulting library being specific to a single platform/architecture or general. And from all that I can say from using it, it does the job as a build tool very nicely. This may be considered unfortunate, but it's not Maven's mission to provide remedy for this situation. There is demand in Java community for statically assembled applications, and Maven meets this demand. I fully agree. In that limited context, using Maven for software distribution and management makes sense, as all you have are big binary blobs. But in the context of general software distribution and management system, which was the novel idea, big binary blobs are not a great idea. ;) I'd certainly love to see Maven running on as many platforms as possible, and being as much platform agnostic in the way it operates as it is possible. I agree, and I'm as glad to help with testing, patches and bug reports as I'be been before. cheers, dalibor topic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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?
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 us
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 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 assumptio
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?
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?
ecking in artifacts into CVS is a bad idea. That's like checking in object files. Maven is changing that, finally. That's a good thing, and I applaud the Maven developers for that. Though, in my opinion, it could be an even better thing if we could get Maven to leverage the existing package management systems instead of just being a better "Napster for JAR files" ;)) cheers, dalibor topic [1] That I submitted a patch for to JIRA, btw, so if someone could review and check it in, I'd be very pleased ;) http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-1129 [2] and can't, since they are undocumented [3] I'm currently involved with cleaning up OpenOffice. No, you don't want to know ... ;) [4] http://www.kaffe.org [5] http://www.kaffe.org/~robilad/tomcat-4.1.29-screenshot.png [6] http://www.kaffe.org/~robilad/jboss-3.2.2-screenshot.png [7] http://www.debian.org/social_contract [8] http://www.debian.org/social_contract#guidelines [9] Hello, FOP! ;) But I now have got Batik and FOP developers to talk together about cooperating on some ImageIO functionality, which would remove a major blocker (JIMI). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new idea on maven usage?
e tool doesn't know about the specifics of my system, the applications don't know either. That sounds like a recipe for desaster in the long run. Let's say I update my java runtime to a new version because of a security problem that only occurs on my platform. I (and everyone else using applications on that platform that use Maven for distribution) have to manually check if all the applications still work. In a sane distribution system, the packager can do that work, and if necessary expose a conflict between an application and an specific runtime in the list of dependencies of the application. In the proposed system, everyone needs to do it all over. So I see many benefits to providing a "maven-execution" system that has the basic maven reopsitory handling and a couple of goals (start,stop,restart,check,) and these benefits are mainly not covered by an installer or webstart/jnlp) Both installers and webstart/jnlp are nieche solutions for distribution that don't meet the needs of modern operating systems. Legacy systems, like Microsoft Windows, that have no concept of package management, *may* profit from a Maven-based distribution system, but it would still be a nieche solution. On the other hand, using Maven for distribution makes the job much harder for those that package applications for und use applications on modern operating systems. See http://java.debian.net/index.php/What%20is%20required%20from%20upstream for a brief discourse on how to create packager-friendly releases of java software that is supposed to be packaged for linux distributions. It's part of a small wiki created by packagers of java applications for different Linux systems and free java runtime developers in order to find better ways to package java applications on unix systems[1]. cheers, dalibor topic [1] http://java.debian.net/index.php/CommonJavaPackaging - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
