| |||||||||||||
|
| |||||||||||||
Callaway: Chromium: Why it isn't in Fedora yet as a proper packageCallaway: Chromium: Why it isn't in Fedora yet as a proper packagePosted Dec 1, 2009 20:17 UTC (Tue) by Cyberax (subscriber, #52523)Parent article: Callaway: Chromium: Why it isn't in Fedora yet as a proper package
That's quite unfair to Java developers, because most of well-behaved Java projects now use Mavenized builds which utilize an explicit dependency tracking. With the central repository ( http://repo2.maven.org/maven2/ ) for most of artifacts.
(Log in to post comments)
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 0:28 UTC (Wed) by motk (subscriber, #51120) [Link]
... which is out of band of system package management, so java apps tend to be a great big warfile full of specific libraries anyway.
When maven can truly understand, say, rpm targets and can be plugged into a distro build system we'll be somewhere. It's getting there, but the world as it exists today has build-random-everything-in-a-jar as the standard methodology for java apps.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 3:56 UTC (Wed) by jameslivingston (subscriber, #57330) [Link]
You could just as easily say "When rpm can truly understand, say, maven goals and can be plugged into a java build system we'll be somewhere."
Just because java builds aren't done the same was as some linux distribution do them doesn't magically make it wrong.
The issue isn't the build system, it's that java libraries often don't provide the same API/ABI stability guarantees as a number of C libraries do. Exactly the same problem happens when C libraries don't provide those guarantees, such as ffmpeg, and there is a large amount of work dealing with that. The only difference is that not providing that guarantee is much more common in the java world.
There is also the issue of putting archives inside archives, but that is just how Java works and there are some good reasons it does work that way.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 7:56 UTC (Wed) by nim-nim (subscriber, #34454) [Link]
Java devs have been saying for years they didn't need to participate in the rpm/deb/linux package ecosystem and their way was better
How many java apps are widely used on Linux systems today?
How many persons will just reject java apps on sigh because they've tried the "java way" before and made their own opinion ?
How many php/python/etc apps were written because it was "just there" in the system and people didn't need to learn a "php" or "python" way of deploying apps to use it?
Looks like a huge *FAIL* to me
The only people that can use the "java way" are java developpers. Just developpers do not make an healthy ecosystem. Sysadmin, users, etc need to be part of it too and they care nothing about dev preferences.
PS If Java libs don't provide API/ABI stability guarantees that's also because:
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 8:28 UTC (Wed) by kragil (guest, #34373) [Link]
Java isn't _that_ special in this regard. Rails devs are even worse.
That said, I really hope Java apps will retreat to some enterprise niche I won't have any contact with. So I don't mind their unpopularity.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 13:52 UTC (Wed) by robilad (guest, #27163) [Link]
The number of packages with reverse deps on java-common in Ubuntu has gone from around 300 back in late 2006, to around 600 now.
I assume that the numbers for Fedora are similar.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 14:24 UTC (Wed) by nim-nim (subscriber, #34454) [Link]
Given enough resources and motivation you can package anything (hell, JPackage managed to get a working tomcat package back when half the stack was closed-box SUN jars that changed location and name every time SUN re-published them)
That does not mean some software does not make it as painful as pulling teeth.
Given Java's propensity for multiplying components 600 packages is not big at all. Java has a long, long, way to go.
PS I stand by the "efficient" claim. We live in an insanely competitive world, given the number of persons that dislike the Linux model, if theirs was so much better Linux distributions would be cloning their work instead of the reverse (hi OpenSolaris).
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 15:29 UTC (Wed) by robilad (guest, #27163) [Link]
Well, I think that, objectively speaking, Apple's AppStore has been a lot more efficient at providing an 'industrialized' software distribution channel then any mainstream Linux distribution up til now - many more apps served to many more users in a much shorter time frame.
Afaict, the centralized AppStore encourages the 'binary blob of made of stuff upstream made' model of software delivery over the 'set of interdependent binary blobs made of most of the stuff upstream made' delivery model centralized Linux distributions encourage.
It seems to work pretty well for its audience despite breaking such basic taboos of Linux package management. That hasn't escaped the attention of Linux distribution makers. So now many distribution makers are racing to provide their own AppStores.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 18:24 UTC (Wed) by nim-nim (subscriber, #34454) [Link]
I think the 'many more apps' could easily be disputed. What can not be disputed is that Apple relies on needing to support a small set of hardware. It is easy to make app distribution work when your hardware diversity is limited.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 18:46 UTC (Wed) by robilad (guest, #27163) [Link]
Apple announced over 100k applications being available in their store a few weeks ago:
http://www.apple.com/pr/library/2009/11/04appstore.html
I'm not aware of any Linux distribution that has that many packages, let alone applications.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 18:55 UTC (Wed) by nim-nim (subscriber, #34454) [Link]
In the Apple world, an "application" can be anything from Photoshop to an iphone screen that links to random web content.
Do you want to bet which kind of app makes the bulk of their numbers?
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 18:59 UTC (Wed) by robilad (guest, #27163) [Link]
Well, the quality of the content doesn't say anything about the quality of the distribution mechanism, and vice versa. We're still discussing distribution mechanisms here, right?
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 19:35 UTC (Wed) by nim-nim (subscriber, #34454) [Link]
It's not about the quality of the content, it is about the constrains it poses.
To take a real-world example, just because an army of bicycle postmen can deliver an astounding number of small letters in a city, does not mean they won't fare miserably as soon as you give them a big parcel,something to deliver long-distance, a container, or some refrigerated content, live animals, etc to distribute
So your comparison is ridiculous. I'm sure yourtube or "social" web sites could blow Apple numbers out of the water by counting the pictures, songs, or bits of javascript, they deliver to a large number of people of everyday. That does not make them examples to follow when assessing ways to distribute complex application ecosystems where multiple components interact with each other.
You can try to avoid dealing with the problem by bundling everything in one place (as Apple does, and SUN tried to with Java). It only does so far before the impedance mismatch between different un-cooperating binary bundles forces you to dedicate separate un-upgradable systems for every one of them (as is commonly seen in the Java world, where supposedly multi-purpose flexible app servers are usually dedicated to a few closely cooperating apps, as they can't cope with real diversity). It is highly ironic that you point out the Apple Appstore where this logic led to two special-purpose products, ipod and itune.
I suppose one could claim this model is "efficient" at the software level. It only multiplies your hardware needs many times over. Unsurprisingly, SUN and Apple are in the hardware business.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 20:48 UTC (Wed) by robilad (guest, #27163) [Link]
Do you have a link to some 'complex application ecosystem' distribution of JavaScript applications that has 100k apps?
I am not sure I can follow your 'Apple is in the hardware business' line of thought. You seem to believe that Apple designed their software distribution mechanism to force users to eventually buy an iphone/ipod for each application separately, multiplying their hardware needs many times over, if I understand you properly?
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 22:35 UTC (Wed) by nim-nim (subscriber, #34454) [Link]
I'm saying the "100k" apps Apple claim are
1. mostly trivial stuff, declined many times over to increase the advertising surface in the app store and get more customers
2. not a complex code ecosystem (unless you remove most of the content, and then the numbers don't look so good)
It is easy to inflate numbers when counting trivial apps (Palm did it a decade before Apple). A site like tesnexus is at ~ 30k (their latest mod today is 28515) that would all qualify as applications under Apple's definition. I hope you're looking hard at this new software power house
And yes, I claim Apple is very happy to foster habits where you by one device for music, one to telephone, etc even thoug most of the hardware inside is the same.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 22:48 UTC (Wed) by nim-nim (subscriber, #34454) [Link]
And just to show how pointless Apple brags are
1. there are almost 20k binary packages in Fedora x86_64 development version alone (about 19500) 2. Add the i386, ppc, etc package numbers 3. Add Fedora 1 to 12 packages 4. Add updates
Suddenly 100k does not look such a high number
And that was one Linux distribution. I could have inflated the numbers even more by counting its predecessor (Red Hat Linux), all its derivatives (OLPC, RHEL, EPEL, CentOS, Moblin, etc)
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 12:03 UTC (Thu) by robilad (guest, #27163) [Link]
Well, it may help to put that 100k number from November in context, that Apple was bragging about 85k apps in late September:
http://www.apple.com/pr/library/2009/09/28appstore.html
Thank you for looking up the Fedora package numbers. They are interesting, so let's play a bit with them. As we are comparing single, centralized distributions of upstream software here, I think it's more adequate to pick a single Fedora release - the one you provided numbers for.
As Fedora packages developer-oriented parts of an upstream separately, I'd assume that's around 10k upstream applications for the current distribution. For the sake of inflating Fedora's numbers, let's count libraries as applications, too.
For the sake of deflating Apple's numbers, let's apply the Pareto principle, and weed out 80% of the apps as trivial. That leaves 20k non-trivial apps in November, and 17k in late September.
Let's also assume that the Pareto principle does not apply to Fedora at all - everything that gets packaged into Fedora is a non-trivial labor of love, and so on.
Even with all that, Fedora is still quite a bit behind Apple's distribution in raw numbers. In particular, just the increase in non-trivial apps in Apple's distribution in the course of a couple of weeks is almost a third of all of all applications in Fedora.
I'd be very surprised if the growth of packages in Fedora is remotely close to that. So I think that maybe there is more then 'one true way' to implement 'industrialized', 'efficient' software distribution.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 12:56 UTC (Thu) by nim-nim (subscriber, #34454) [Link]
You continue to be disingenuous
Apple counts *all* apps, for *all* its systems (itune, iphone, etc)
So it is not fair to remove older releases, Apple counts them too
It is not fair to count only Fedora but not OLPC, Centos, RHEL, etc Apple counts different lines of products too
And lastly, Apple does not have the aggressive culling processes of a distribution like Fedora. Fedora worries about mirror space, Apple worries about getting the highest number count possible in press releases.
Yet, even given all this, Apple does not manage to equal the Fedora ecosystem alone.
So your chosen example nicely disproves your point.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 4, 2009 15:37 UTC (Fri) by robilad (guest, #27163) [Link]
"You continue to be disingenuous"
Well, thank you for your polite, respectful and informative words. You have eloquently convinced me, now I see that I was wrong all along.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Jan 7, 2010 21:27 UTC (Thu) by ceplm (subscriber, #41334) [Link]
Really the number of apps is not the point ... complexity is. Try to
understand all packages required when you install some substantial program (firefox, postgresql, eclipse-platform ...) and then compare them to (comparably) trivial tiny apps available for iPhone. Just pure numbers are absolutely meaningless.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 9, 2009 20:55 UTC (Wed) by leoc (subscriber, #39773) [Link] How many of those "apps" are anything other than a launcher for a web link? Also, as was pointed out in this item, the vast majority of available apps in the app store (as in 80% to 90%) are not really even maintained any longer. Considering the level of unprecedented hype that the iPhone and app store have received, you would expect the tail on this graph to be a little less flat.Ignoring things like application size and complexity, duplication of function, actual level of use, end user quality, and the heavy hand of Apple censorship makes your argument about it somehow being a model to 'copy' specious at best. If any Linux distribution ever does consider adopting such a broken and anti-developer model, I'd keep away from it with a 20 foot pole.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 3:21 UTC (Thu) by motk (subscriber, #51120) [Link]
False equivalence. Show me how a shiny webdav client that copies binary blobs has anything to do with a rich dependency management system like rpm/yum.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 12:34 UTC (Thu) by robilad (guest, #27163) [Link]
Both copy software provided as binary blobs with associated metadata from one central place to some other place.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 23:43 UTC (Thu) by motk (subscriber, #51120) [Link]
That's a little ... simplistic, shall we say. If you can't understand the difference between rich dependency management and a sexified webdav client then I don't know what to say.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 4, 2009 11:51 UTC (Fri) by Cyberax (subscriber, #52523) [Link]
Have you _ever_ used Maven?
It's much more than a 'webdav' client. For example, Maven can be used to build application, run tests, bundle it and then upload to a repository. With source code attachments, if desired.
Your assertion is like saying that 'APT just downloads some files' or 'dpkg just unpacks archives'.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 7, 2009 0:07 UTC (Mon) by motk (subscriber, #51120) [Link]
I've used maven, and quite like it! I was refering to the Apple app store, not maven in this case.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 15:49 UTC (Thu) by jschrod (subscriber, #1646) [Link]
Watch out your prejudices: with jpackage.org I can use RPM-packaged java components, including integration in Maven2.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 16:05 UTC (Thu) by nim-nim (subscriber, #34454) [Link]
I am well aware of JPackage. They do a wonderful job, but their life is not simplified at all by Java common practices (the same ones Tom Callaway complains of in his message)
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 4, 2009 7:08 UTC (Fri) by jameslivingston (subscriber, #57330) [Link]
That's right, as the Java and linux packaging practices don't mesh well together. It's not the fault of either side, it's just that they were developed independently with different goals, so just make it hard to mix the two.
There are some quite easy ways to make Java packaging fit with a distro's packaging system, it's just that it would violate most of their policies:
Of course your linux packagers will have a fit, because you're abusing their packaging system, but it works :)
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 4, 2009 8:53 UTC (Fri) by nim-nim (subscriber, #34454) [Link]
It only works in the fork and forget mode Java developpers are so found of (secrutity issues, who cares about security issues, didn't SUN promise me a language that voided them all?)
FFmpeg does *not* have an unstable API Posted Dec 2, 2009 12:36 UTC (Wed) by DonDiego (subscriber, #24141) [Link]
> The issue isn't the build system, it's that java libraries often don't
> provide the same API/ABI stability guarantees as a number of C libraries > do. Exactly the same problem happens when C libraries don't provide those > guarantees, such as ffmpeg,
All false claims to the contrary notwithstanding, FFmpeg has never had a volatile API. Please stop claiming otherwise.
FFmpeg does *not* have an unstable API Posted Dec 3, 2009 10:42 UTC (Thu) by alankila (subscriber, #47141) [Link]
So...why exactly did everyone seem to fork a copy of ffmpeg into their video players at some point of time, then?
FFmpeg does *not* have an unstable API Posted Dec 4, 2009 7:17 UTC (Fri) by jameslivingston (subscriber, #57330) [Link]
The people I've directly talked with who forked copies of ffmpeg into their projects would disagree.
Take another example: Gecko. While it has "stable" and "unstable" APIs, you can't (or couldn't, last time I checked) realistically embed gecko into your app without using API marked unstable. So for all practical purposes it has doesn't provide any real API stability.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 0:34 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
Nothing unfair about it. Whenever we run into Java programs, they are
typically very difficult to package due to the problems Spot is talking about. Apparently well-behaved Java projects are low in number still.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 1:21 UTC (Wed) by robilad (guest, #27163) [Link]
Is there a translation of what he is talking about into English? Bedazzler Jewels? Huh?
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 2:01 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
There are many issues but the most common one is bundling patched copies of other Java libraries in a single massive zip file with no attempt to even contact the developers of the libraries they have been patching with the excuse that they are too unique.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 10:09 UTC (Wed) by robilad (guest, #27163) [Link]
Is there a specific instance you're talking about? Searching the web for java+"we're too unique" gives me no useful hits among the one or two hits it finds.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 4:53 UTC (Thu) by Imroy (guest, #62286) [Link]
I've recently been looking for calendar/contact syncing software for my family network. Most of them appear to be Java based. Go look for "Funambol" and their 170M bundle which includes a Java 1.5 JRE (x86 only), Tomcat, and hsqldb. Or how about "Bedeworks" and their 225M "quick start package" with even more thrown in.
As a long time Linux (Debian) admin and Perl programmer, I look at this and can only say a huge WTF! I guess this is what happens when a language/environment is mostly used for developing private software inside companies and the like. The programmers see their software as being part of a "bundled" system, instead of simply being a component that works with other (separate) components.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 10:46 UTC (Thu) by alankila (subscriber, #47141) [Link]
I concede that adding a JRE to your software's package is stupid & shouldn't be necessary.
The reason why java apps do bundle a lot of software is generally to have a single file that can be downloaded, dumped on any system, and which then works if you just execute it. Java sort of solves the distributing problem, and the accepted solution is to simply package the entire world into one giant bundle. Where I'd draw the line is with including a runtime environment, though.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 12:24 UTC (Thu) by robilad (guest, #27163) [Link]
Well, sure, but that doesn't validate rahulsundaram's claim.
He is claiming that:
"bundling patched copies of other Java libraries in a single massive zip file with no attempt to even contact the developers of the libraries they have been patching with the excuse that they are too unique"
So: Are those copies patched? Are they delivered as a single zip file? Did they attempt to contact developers of the patched libraries? Did they claim that they are too unique?
The claims rahulsundaram makes should be easily verifiable for him by showing an instance of all that actually happening in the last year or two. After all, he claims that it's the 'most common one' among the issues spot is alluding to in his bizarre quote.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 4, 2009 1:31 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
Several people have given you many examples. You seem to ignoring them all. How about this, show us a few popular counter examples?
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 4, 2009 14:30 UTC (Fri) by robilad (guest, #27163) [Link]
Actually - no - all that I've seen so far has been highly amusing ranting about the oh so horrible ways of Java developers and a few pointers to some applications having large downloads. Nothing that actually confirms the very specific claims about Zip files, "we are too unique" etc. you have made.
Please back those claims up with references.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 4, 2009 15:29 UTC (Fri) by robilad (guest, #27163) [Link]
And I should point out that I'm interested in evidence to help me understand whether your translation of spot's words (thank you for doing that) is based on your actual, personal experiences packaging Java software for Fedora, or on a 'a friend of a friends once read on LWN ...' sort of experience ;)
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 5, 2009 7:31 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]
FYI, I maintain several packages for Fedora and Java software has usually
been a severe pain point. Freemind for example is still not in Fedora after several failed attempts because of problems like the one I noted. So yes, it is personal experiences I am talking about. Whats your experience?
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 6, 2009 12:20 UTC (Sun) by robilad (guest, #27163) [Link]
Thank you for your work on packaging in Fedora, and thank you for coming out with an example for your claim that Java developers claim that they are too unique, etc.
Rather then taking your claims at face value, I thought I'd see for myself. Not that I don't trust your authority, with you being a packager and all that, but I have not seen you post once to fedora-devel-java in the past 15 months, so I assume that is not your area of expertise. In particular, I can't find your name in the conversation in the Fedora bugzilla entry for freemind.
The last attempt in the Fedora package database that I can find is
https://bugzilla.redhat.com/show_bug.cgi?id=428413
It's a packaging attempt by Alex Leamas. A quick check on the freemind site confirms that he is not one of the freemind developers. That's not a good sign - the freemind source code tarball is larger then a megabyte, so understanding it in order to make significant modifications likely requires a significant investment in time.
In addition, Alec says:
"This is my first attempt to provide a package for Fedora...
Also, it's a java application. There is an obvious need for guidelines for java apps, hav'nt found any."
Attempting to package a large application in a domain where the distribution has no obviously findable guidelines as one's first package - what could possibly go wrong with that?
Then, after some initial work, some license issues are discovered by spot, and he says:
"Yeah, you are going to need to get upstream to resolve these license issues."
Now this could be the moment where the upstream shows uncooperative, and the oh so horrible ways of Java developers are unmasked. Amusingly enough, that's not what the bug says - it says nothing at all about the packager communicating with the upstream and reporting back how that went. So one has to search for it and finds an upstream developer say:
http://www.mail-archive.com/freemind-developer@lists.sour...
"I change the licence of my file soon and have a look at the others."
I tried hard to figure out how one could possibly take that to mean "we're too unique". I don't see it - to me that sounds like a Java upstream bending over backwards to help with licensing changes to ease the packaging into Fedora. Quite a different picture in reality then being painted here by spot & rahulsundaraman, apparently.
But, as I said, no word about that in the bug report.
So, why does the packaging attempt, unsurprisingly, eventually fail?
"file bindings.jar is the result of a compilation of a xml file which defines the interface. It might be impossible to get this compilation, involving JAXP API:s to work.
When rebuilding jaxme and running the compiler I run into problems since the source xml file contains constructs not supported by the jaxme xsd compiler. It might be possible to walk around this, but I don't know enough about the JAXP interfaces to do this, at least not now."
Translation to English: Because the prospective Fedora packager doesn't know enough about the software he's trying to package.
But that's not the only reason, there is also
"Even worse, current CVS sources shows that freemind now uses Sun's JAXB suite to handle this. It does support all constructs, but it is at best GPLv2 only. And it does not build for me, some kind of config problem."
JAXB is, of course, part of the Java SE 6 platform, so it's in IcedTea, OpenJDK 6, etc. It's dual licensed under CDDL 1.0 & GPLv2 with the Classpath Exception. No one of Fedora's licensing experts catches that mistake, and asks the prospective first-time packager to try using IcedTea or OpenJDK instead.
So it all predictably ends with:
"My first attempt to submit a package has, for now, failed.
The main reason is that recent code (after 0.0.9Beta15) has became heavy
So, the legal reasons come down to Fedora's experts not bothering to check the first-time packager's assumptions about licensing of an upstream dependency and fix his mistake.
The technical reasons come down to the lack of prospective packager's technical prowess with the upstream codebase, and its dependencies. On a meta-level, attracting contributors for the jobs they don't have a chance of doing well is a failure in Fedora's recruiting & mentoring process.
Through the whole effort, the upstream project does not claim that they're too unique, apparently. There is nothing in the bug report indicating that the bundled libraries were patched and the upstream refused to send their patches further upstream, either, even though rahulsundaraman claims that is the most common issue.
So for someone familiar with Java development, the sweeping statements about Java developers made by rahulsundaraman & spot looks more like playing on a bias for the purpose of blame shifting to the upstream for inadequacies in Fedora's processes, recruiting & mentoring in the area of packaging Java applications.
What has happened since?
"Could this be reopened? The latest Freemind release candidates (I've tried 0.9.0-RC3 and RC4) work just fine with the OpenJDK VM supplied with Fedora 10 (java-1.6.0-openjdk-1.6.0.0-15.b14.fc10.i386"
"Please file a new review request and mark this bug as
No duplicate marked so far.
There has been a freemind package in Debian since 2004.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 6, 2009 13:39 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
Btw, there are several review failed review requests. You just managed to pick one. Feel free to research others and the long history of JPackage or Eclipse or any major Java software.
Spot maintains the largest number of packages in Fedora and nim-nim has been very involved with JPackage before. I have personal experiences which tell me the same thing. If you don't want to disagree with everyone's expertise, be my guest.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 6, 2009 15:36 UTC (Sun) by robilad (guest, #27163) [Link]
I looked at freemind because you told me it backed up your claims. I didn't pick a project at random to make you look bad.
There is only one review request for freemind in the Fedora bugzilla as far as I can tell. I'd appreciate a pointer to a review request that shows that the freemind upstream is shipping patched libraries and refusing to upstream their patches with the excuse that 'we're too unique', as you imply.
But maybe you meant to point me to another package, and made a typo, or something. Would you please be so kind to point me to the failed review request for Fedora 12 that backs up your sweeping claims about Java developers?
What is the ratio of the review requests failing for Fedora-specific reasons like freemind vs. those failing for the reasons you attribute to Java developers in general in Fedora 12? Since you make the claim that it's the majority of cases, it should be trivial for you to back that up, right?
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 6, 2009 15:47 UTC (Sun) by robilad (guest, #27163) [Link]
My apologies for asking you to back something up you didn't literally say - you did not claim it was problem in the majority of cases, you said it was the 'most common one'. I'm curious how common it actually was for Fedora 12.
Is there a query for the Fedora bugzilla that lets me see those most common cases for Fedora 12?
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 7, 2009 1:43 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
You continue to attribute claims that I did not make to me. I must ask you to stop doing that. I said, the most common problem with Java software is that they bundle copies of other Java software often with patches (to avoid dealing with dependencies). I did not say it is the most common problem in Fedora or Fedora 12.
A simple query on bugzilla doesn't return such information. Feel free to talk to package maintainers with some significant experience in maintaining packages for a large distribution and they would likely have noticed similar patterns. So would have the security teams of such distributions. You can also talk to folks involved with JPackage.
It was much more difficult a few years back
http://www.linuxjournal.com/article/7413
Red Hat's involvement with OpenJDK/IcedTea and other Java software has helped here and atleast some upstream projects have gotten better over a period of time as well, notably Eclipse. Some of it is a mismatch between tools. One effort to tackle the problem is at http://fedoraproject.org/wiki/KojiMavenSupport
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 7, 2009 18:26 UTC (Mon) by xkahn (subscriber, #1575) [Link] I usually try not to reply to a thread until I've read all of it, but look at Alfresco. Here's a page where the Fedora project tried to create a package:
You can see that Alfresco bundles a large number of JARs and that some of them have "_patched" in their name. And this is a package with a reasonably large company backing it! Alfresco themselves mention this as a problem: http://forums.alfresco.com/en/viewtopic.php?f=8&t=11744
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Jan 7, 2010 22:44 UTC (Thu) by ceplm (subscriber, #41334) [Link]
Just to add one more example which you would ignore, I have tried to
package OpenFire for Fedora (http://www.igniterealtime.org/downloads/download-landing.... file=openfire/openfire_src_3_6_4.tar.gz, 48.81 MB) and after couple of days of attempts I just gave up ... not only that the tarball contained JRE, it also contained many many other packages (couple of database connectors, couple of building tools like ant, and others ... did they really need their own fork of ant, or did they just dump their working directory to the tarball?).
When discussing this with the upstream programmers, and arguing with the
Another example, I have really liked the idea of blueMarine
Could you actually show me one large Java project, which has proper tarball
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 9:44 UTC (Wed) by nim-nim (subscriber, #34454) [Link]
He talks about broken ecosystems such as Java where there is no industrialized efficient way to make code flow from creator to distributor to user.
As a result it is easier for someone deep down in the distribution chain to fork code and make bastardised zombie private copies of someone else's code than to try to make the original code authors aware of the problem, have them fix the original component (the years of closed black-box SUN stewardship didn't help either), and wait for the fixed copy to flow downwards.
I wrote bastardized because such local changes are rarely tested except for a very specific use case (so they usually break as soon as you try to use the fork for something else) and zombie because after the initial fork the local developer rarely bothers trying to follow upstream changes and just freezes his version.
Of course since bastardized zombie is not something customers and bosses would approve of, it is presented in glowing self-flattering terms by the person who forked the code (cheap Bedazzler jewel bling that shines but is still crap).
Projects like maven that make their primary use case "download specific file with checksum X for location Y, and hide it from other apps so they don't have to be coordinated" contribute to this vicious circle by making it even easier to access local forked code copies, and removing the few remaining incentives to have code fixed (properly) at the source.
Linux packaging systems push every app to use the same component versions and declare non conflicting identifiers. It is an intentional choice to fight short-term forking temptations, make people work with each other, and promote virtuous circle practices.
Chromium is walking down the well-known old short-term private fork road to hell. It can not be packaged in distributions because their tools and organisations were designed to oppose this kind of practice (many people claim this is misguided angelism; none of those ever managed to build a successful system the size of current Linux distributions).
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 12:27 UTC (Wed) by robilad (guest, #27163) [Link]
None of that seems Java specific to me.
Open source enables the existence of more then one redistributor, and allows them to take matters into their own hands. And, in practice, they do. The long tail of open source production will only get longer with better, distributed tools making fork-n-forget easier, in my opinion. Regardless of the programming language used to produce the open source software in question.
The embedded Linux world is a good counterexample to your claim - there is nothing Java specific about the forked and forgotten vendor kernels. I somehow doubt that blaming that on some made up 'C developer mentality' would get much support on LWN.
So, let's take your argument half-seriously and try to apply it, tongue-in-cheek, to Linux distributions.
Linux distributions, for example, rarely package applications in the 'pristine' upstream form, regardless of the programming language used to write those applications. Instead they often make local changes called patches. The patches they make are typically tested on the distribution they are made for, and not, say, on Microsoft Windows, Mac OS X, or some other operating system the upstream project may chose to run on for whatever weird reason. They often freeze their local, forked version of upstream software for years during a release cycle and present those versions in glowing self-flattering terms as 'enterprise' releases. Projects like Linux package managers make their primary use case to download specific files with checksums from some remote location to put it on the user's system so that it doesn't have to be coordinated with whatever mechanisms applications use to implement similar functionality.
Using your rationale, we should call Linux distributions 'cheap' for doing all those things.
I disagree - the Linux packaging model works. I think it works because there is an acceptance among its users for a centralized distribution model where software flows through distributors to them, and it has evolved tools, policies and, in particular, taboos to make it all more or less work. Whether the Linux software distribution model is 'industrialized' and 'efficient' is, in my opinion, debatable.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 21:07 UTC (Wed) by nevyn (subscriber, #33129) [Link]
> Linux distributions, for example, rarely package applications in the
> 'pristine' upstream form,
You obviously have a different definition of "rarely" or "pristine" than
[snip]
If a distribution did all those things, without co-ordinating with upstream
All sane distributions "enterprise" or otherwise, do the vast majority of
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 22:21 UTC (Wed) by robilad (guest, #27163) [Link]
I'm not aware of any 'enterprise' Linux distribution that comes with the pristine upstream kernel, without any patches, over its entire support period. I may be wrong, of course - I'd appreciate a pointer in that case.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 3:08 UTC (Thu) by motk (subscriber, #51120) [Link]
That's dissembling - the kernel is a special case, and of course all distros rebase to the latest and greatest whenever they can.
The whole javacentric development/distribution model is just indefensible in 2009. I guess it's a natural outcome of a language that was designed for portable devices, but the community should know better by now.
I do in fact love some java apps - the entire Atlassian suite springs to mind - but I do wish they could make the things build natively instead of requiring a 300M download of hundreds of bundled libs.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 11:07 UTC (Thu) by robilad (guest, #27163) [Link]
OK. If the kernel is a special case, what about glibc? Which enterprise distribution ships glibc without any patches applied over its support time? Or gcc, if glibc is too special?
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 23:50 UTC (Thu) by motk (subscriber, #51120) [Link]
Examples?
There is tight coupling between distribution glibc maintainers and the core glibc developers. As kernel+glibc is pretty much the core of a given linux system, I'd argue that yes, this is a special case also.
You're dissembling again - you can hardly compare glibc or the kernel to tens of thousands of random library snapshots bundled up in apps, never to be seen again until something explodes.
It's just laziness at this point - bundling up a selection of stuff that you've managed to finagle into working, declaring it 'finished', and then chucking it over the fence.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 4, 2009 15:11 UTC (Fri) by robilad (guest, #27163) [Link]
Well, I think that's the whole point - developers patch third party code because they have their own good reasons. Or so they believe. ;)
From the perspective of a platform provider, like a distribution, having control over what goes into the platform, and being able to tweak it to assemble one's platform built on own software along with various third party components into a coherent whole is a really good thing.
From the perspective of an application provider, being able to do the same is a good thing for pretty much the same reasons.
It's where the two worlds are forced to coexist that the conflicting interests collide. Blaming the conflicting interest on a particular programming language is quite short sighted, though - the ISVs struggling to get native code packaged for Linux across distributions are fighting with the same impedance mismatch between the interests of the platform provider and their own, and of course the regular 'language-specific dependency system sucks because it doesn't play well with my package manager' provides another set of evidence for that conflict - whether that's Ruby Gems, Python Eggs, or Maven.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 4, 2009 16:18 UTC (Fri) by nevyn (subscriber, #33129) [Link]
I can't work out if you are trolling (badly), or are really failing to
understand what everyone is trying to tell you. Being optimistic I will, probably stupidly, try again:
1. Changing code from "your upstream" isn't great, but does have to be done
2. If you do #1 without contacting your upstream, or (less often) directly
3. As a corollary to #2, if you are a significant portion of upstream then
4. As a corollary to #3, if you are just backporting patches from upstream
...Java code (and Chromium) are doing #2, and "enterprise Linux" are #4 in
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 6, 2009 14:37 UTC (Sun) by robilad (guest, #27163) [Link]
"I can't work out if you are trolling (badly), or are really failing to
understand what everyone is trying to tell you."
Thank you for your kind words, I appreciate your help in helping me understand what everyone is trying to tell me. If it helps, I think that your argument is sound - I just disagree that it in practice distribution developers really act very differently from Java developers.
Your basic claim here is that Java developers in general engage in activity #2, whereas other developers, in particular developers of distributions, don't. So, let's see if that claim is true.
In another thread, rahulsundaraman mentioned the troubles to package freemind in Fedora. I find that example slightly ironic, in light of the claim above:
https://bugzilla.redhat.com/show_bug.cgi?id=428413
After some struggling, the prospective packager decides to do some more radical changes on the upstream sources:
"Swinging the machete this way means to remove all export/import functionality from Freemind. However, the core functionality create, edit, open & save works fine, as does the browser applet. Plan to add some plugins later, if/when this package is approved."
None of the Fedora reviewers objects to the packaging technique of 'swinging the machete' to remove major functionality of the upstream application, or asks if the prospective packager coordinated that action with the upstream - after all, the upstream may prefer not to see users of its app struggling with a heavily locally patched version that lacks certain features, and see it more worthwhile to work on a long term solution instead.
Nothing in the bug report shows that such coordination took place, or that the first-time packager was encouraged by the reviewers to follow such basic rules of packaging upstream code.
Is that really a failure of the upstream to communicate with their upstreams, or is it a failure of the Fedora downstream to communicate their heavy, local patch attempts to the upstream?
From looking at the bug report, it seems like a case of the latter. No communication at all with the upstream is mentioned in the bug report, fwiw, and none of the Fedora reviewers seems to think that could be something worth pointing out in the bug report, which is rather surprising given the scope of the proposed machete swinging to get the application packaged.
So, I'd disagree, based on the attempt to package Freemind for Fedora, that Fedora packagers don't do #2.
Whether Java developers in general follow the same engineering practice of machete swinging, is an interesting question. From what I can see in the open source Java world today, the answer is 'not any more'. ;)
I have been following different packaging efforts in this space for a little while, so I know how hard it was to package Java libs & apps back in the last century. With the arrival of OpenJDK in distributions a year or so ago, this has become much simpler, due to the existence of a full, working implementation to build upon, and at the same time, because of the gradual move of many Java upstream projects towards Maven, Ivy and other forms of declarative dependency management.
Maven has been a thorny issue for many distributions, because it by default resolves the dependencies using repositories on the Internet. In the last year, both Fedora & Ubuntu have made significant progress on getting maven to be 'distribution-friendly', so that it can be used for building packages.
So I'd expect to see a lot more Java upstream packaging attemps in Fedora in the coming years - and that's why I'm interested in finding out whether the problems spot alludes to are indeed structural to the 'annoying' ways Java upstreams work today, as you imply, or are simply caused by a lack of technically competent communication between the Fedora downstream and the Java based projects that are being packaged. If the case is actually the latter, then the 'bah, stupid Java upstreams don't know anything about software development' mindset would seem to be harmful to improving Fedora in the long run.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 6, 2009 16:55 UTC (Sun) by nim-nim (subscriber, #34454) [Link]
> After some struggling,
Thank you for the some. Good way to paper over multiple recursive build and legal problems which seem to be the norm as soon as you lift a typical java bundle lid. Bugzilla is not a blog people only write a few lines here for hours of work.
Swinging the machete is highly unusual for non-Java packages. For Java packages, well, packagers are human too and there is a limit over which they give up or swing the machete. No one is going to spend multiple hours writing long bug reports when upstream does not care a nit (as evidenced by the dismal quality of their source release)
FYI I spend 4 years of my time packaging Java stuff at JPackage (non trivial packages such as tomcat, which have been copied almost all rpm-based distributions) and am still on their admin list, which is experience enough to have some idea of what the average Java source looks like. (I won't claim I was particularly good or inspired, except strangely enough there was no one better asking to take my place). I have been following different packaging efforts in this space for more than a little while. It takes 4 or 5 Java people to make 10% of the progress one person does naturally in other languages. There is such a legacy of forks, non-cooperative reinventing of the wheel, and other bad practices people always try to invent ways not to fix them because as soon as they realise the huge problem pile they want to forget it. Maybe SUN will manage to break the vicious circle with Java 1.7. It will have to release it first however. Also it needs to attain J2EE status before people start to take notice of it (ie it is years away). There is too much money in Java right now to make a purge easy, lesser languages at least have no illusion they must strive for the best to survive.
In more than a decade of packaging I've only encountered once a non-java package which was as rotten to the core as the average java package is (argyllcms).
And the problem never was technical (one could have done clean Java releases with make or ant a long time ago) but 100% cultural. JPackage antedates projects like maven yet maven developers quickly ignored all the early feedback JPackage gave them as soon as they realised it went contrary to the usual Java developper (bad) habits.
This is how bad the situation is.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 11, 2009 0:23 UTC (Fri) by gwg (guest, #20811) [Link]
> In more than a decade of packaging I've only encountered once a non-java
> package which was as rotten to the core as the average java package is (argyllcms).
Nothing like slandering someone in passing, eh ?
Lets see, ArgyllCMS is about 6M of source (it's got a way
Actual users of Argyll appreciate that it installs and runs
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 11, 2009 6:52 UTC (Fri) by nim-nim (subscriber, #34454) [Link]
And I should have added in all fairness that ArgyllCMS's upstream tried to fixed some of those problems when notified, which is more that can be said about the average Java project.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Jan 7, 2010 22:53 UTC (Thu) by ceplm (subscriber, #41334) [Link]
You obviously never tried to package Amaya ;). Oh well, one of the biggest
perpetual source of frustration and disappointment.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 4, 2009 16:57 UTC (Fri) by nim-nim (subscriber, #34454) [Link]
The theory is that the same pressures apply to all languages and they all suck equally.
The practice is that given the same constraints as every one else, Java developers fare a *lot* worse than others and make life a *lot* harder for their distributors.
You can check this easily by asking integrators from *any* Linux or BSD distribution
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 6, 2009 13:12 UTC (Sun) by robilad (guest, #27163) [Link]
"The practice is that given the same constraints as every one else, Java developers fare a *lot* worse than others and make life a *lot* harder for their distributors.
You can check this easily by asking integrators from *any* Linux or BSD distribution"
Ok. Let's take that claim seriously and check the fedora-devel-java mailing list. If the packagers were facing extremely uncooperative upstreams of the kind rahulsundaraman claims to exist, there surely should be no lack of traffic about it on that mailing list, right?
I have not found a single post on the fedora-devel-java mailing list in the last year complaining that a Java upstream is claiming to be too unique and refusing to upstream their own local patches further. If the claim about Java developers being exceptionally uncooperative in that regard is factual, it should be no problem for its makers to produce evidence on fedora-devel-java backing it, right?
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 6, 2009 13:52 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
Wrong. Review requests are processed via bugzilla. Not in mailing lists. Looks like you are going to a great extend to avoid facing the fact that Java software has for a very long time sucky to package. It is common practise for Java software to bundled binary Jar files of other software. Go look at the source code for Eclipse or JBoss or ANY major Java software. Come back when you have done this analysis.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 6, 2009 17:20 UTC (Sun) by robilad (guest, #27163) [Link]
"It is common practise for Java software to bundled binary Jar files of other software."
Indeed. But you claimed that Java developers were rather special in that regard, afaict. You may be surprised to find out that bundling one's dependencies is not a practice limited to Java developers. If you look around the free software world carefully, you'll find that native cross-platform applications like Firefox embed their dependencies as well, and so on. This whole article is about the native application Chromium. No Java in there at all, afaict.
In the Firefox example, let me pick a dependency recently meantioned on LWN: jemalloc. It is the default malloc on FreeBSD, but you will have a hard time finding it packaged on Fedora. You'll find it's in the upstream sources, and if you look carefully, you'll find that Fedora even carries a local patch for jemalloc in Firefox: http://cvs.fedoraproject.org/viewvc/F-12/xulrunner/mozill... .
I'll have to leave it to you to decide whether that local change is good or bad engineering practice depending on the programming language background of the packager creating it ;) I tend to assume that Fedora packagers have at least as good reasons for the local changes they make to the dependencies of their project as well as anyone else has for their local changes in their projects.
Anyway, there is a bit of a difference from the perspective of a packager between bundling binary jars of one's dependencies coming from upstream projects (you communicate, strip & recursively replace dependencies with packaged versions), and your general claim that Java developers modify their bundled dependencies locally, and refuse to share their changes with the upstream claiming that they are too unique.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 7, 2009 1:22 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
"Indeed. But you claimed that Java developers were rather special in that regard, afaict"
No. I did not. It is quite clear that it is not because this news story is not about a Java app. Java software is quite common and hence used often as an example but there are other offenders as well such as web apps. Java developers merely tend to make the problem worse because they continue to believe that they can ignore platform integration and just pass zip files holding large binary blogs of dependencies (with patches that have not been pushed to upstream) to users and JVM will take care of everything.
Unfortunately, it is not a simple problem space and their approach creates difficulties for integrators such as package maintainers. They have been ignoring this problem quite often although this appears to be changing over time.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 10:53 UTC (Thu) by alankila (subscriber, #47141) [Link]
I'm a bit puzzled at how it can be so difficult to package something which works if you decompress a .tar.gz to a directory, cd there and execute the program contained therein?
I have seen Debian (and Ubuntu) people trying to package new versions of eclipse and it took several years to go from 3.2.3 to 3.5.1 and the last time I tried their package it still had something broken in it, like java content assist didn't work at all. Oops!
So how can it be that a simple dumb extract of a .tar.gz is a better, more working approach than all this effort spent on packaging which:
a) is apparently so difficult that it doesn't get done for years and years;
I think part of the problem with a) was that they insisted on using GCJ originally, when Java wasn't free software and openjdk didn't exist. GCJ is not a good java implementation, so that added extra difficulties along the way.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 20:52 UTC (Thu) by nim-nim (subscriber, #34454) [Link]
Java "solves" dependency problems by stuffing everything in a single huge blob. Apart from the terrifying waste of resources, that means you hit a wall as soon as you need to make two such bundles talk to each other. They only work in isolation (that made the fortune of SOA ESB and EAI sellers: hardware is getting so fast you need VMWare and friends to cut it in useful slices, and at the same time java enterprise "solutions" can not coexist on the same server and need dedicated software to help them to talk to one another)
Packaging complex stuff like eclipse is very hard because you need to re-discover all the component interdependencies that have never been properly documented by upstream (when they still know what they are)
However, modular design and packages is how Linux scales from embedded to mega-clusters.
Interestingly, the JVM itself has been managed by SUN using the big blob no dep tracking model (can not deploy dependencies, so need to put every important lib in the jvm to deploy it). As a result, the JVM is cracking at the seams, and Java 1.7 is getting forever to get done (with "interesting" release history such as open sourcing early java 1.7 code, downgrading it to java 1.6, blowing up this work by releasing new java 1.6 versions that add new closed code to the mix, etc, etc)
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Feb 4, 2010 19:40 UTC (Thu) by ceplm (subscriber, #41334) [Link]
I was still around Debian (couple of years ago) when there was a serious security bug found in libz (compression library behind gzip and many many other programs). Suddenly all Debian maintainers were running around and finding more and more copies of libz in source trees of their applications (heck, even kernel had one for ppp). Something which would couple of lines fix in one package, was a month long disaster which took a lot of time and effort. I remember it well as a lesson why this "Java" (not limited to Java) approach is completely insane and irresponsible. Are you sure that Google fixed that security bug in (say) libpng which was discovered last week?
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 2:16 UTC (Wed) by mmcgrath (guest, #44906) [Link]
> That's quite unfair to Java developers, because most of well-behaved Java projects now use Mavenized builds which utilize an explicit dependency tracking.
The whole concept behind java is to completely ignore the operating system instead using a jvm. Which sounds great when one java developer is talking to another but when a sysadmin like myself tries to use java, I end up having to learn a completely new package management system.
Not only that, but I now have additional upstream vendors and for java apps that aren't using maven and have bundled a bunch of libraries into their app I have to track each library to ensure it they're not vulnerable.
Java isn't wrong for doing this, but it is completely contrary to the way an admin does their normal work. This fundamental difference provides several conflicts for me which is why after two jobs having java apps forced on me I chose not to use them at my current job.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 3:06 UTC (Wed) by ncm (subscriber, #165) [Link]
"Java isn't wrong"
I had to stop reading there.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 3:10 UTC (Thu) by motk (subscriber, #51120) [Link]
>The whole concept behind java is to completely ignore the operating system instead using a jvm.
Well, it was, but since they gave up the entire sandbox idea and started using native system calls etc they now have the worst of both worlds.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 11:20 UTC (Wed) by buchanmilne (subscriber, #42315) [Link] That's quite unfair to Java developers, because most of well-behaved Java projects now use Mavenized builds which utilize an explicit dependency tracking. With the central repository ( http://repo2.maven.org/maven2/ ) for most of artifacts. As quite an experienced software packager, I tried to package a Java application which uses Maven. In 2 hours of figthing, I could not get Maven to *not* dynamically check for newer Java and/or Maven dependencies, even if the dependencies were already satisfied on the system. This means, it will be impossible to get the software through a well-architected (meaning, repeatable without any external factors) package building system (such as the ones that Fedora, Mandriva, and OpenSUSE use). So, I gave up, and used an alternative application. It is quite apparent that Maven focuses on developer priorities (IOW, making it easy to build a big ugly compiled mess you can put in a tarball) and not about a clean build process that allows re-using existing software on systems with multiple java applications.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 2, 2009 20:50 UTC (Wed) by oblio (guest, #33465) [Link]
If you already have everything locally, mvn --help is close, and it says:
-o,--offline Work offline -npu,--no-plugin-updates Suppress upToDate check for any relevant registered plugins
Using -o turns off any updating. So there's your problem solved right there.
I work daily with this stuff, it has a certain purpose. Enterprise build system, for Java applications. Nothing more, nothing less. It's definitely not going to replace RPM or DEB, which are mostly user/admin oriented package managers. Maven is oriented much more toward builds.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 3:14 UTC (Thu) by motk (subscriber, #51120) [Link]
That's not the point - you wouldn't reasonably use maven as a package manager for a system. The ideal use case would be for, say, rpmbuild to get a tarball, point it at a suitable maven environment, and then package the resulting fileset.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 7:24 UTC (Thu) by nim-nim (subscriber, #34454) [Link]
Enterprise build system? Not
Enterprises have proxies that gate access to the internet. Guess what happens when you drop Internet-happy maven inside their gated Network? It takes about 1 hour before someone asks to remove this hobbyist tool that thinks the Internet is free for use and replace it with real "Enterprise" tools.
maven works for Apache developers that do not like Linux developers and have a faint notion of Enterprise needs. Put it in anyone else's hand and he'll complain at you about the inadequacy of the thing.
Callaway: Chromium: Why it isn't in Fedora yet as a proper package Posted Dec 3, 2009 13:18 UTC (Thu) by oblio (guest, #33465) [Link]
Not sure what this reply is about. The fact that Maven gets stuff from the internet or that its proxy support is poor?
If it's:
It does have inadequacies, like the XML config syndrome, the complexity of its configuration, it's lack of proper support for OSGi.
Could you please present a real "enterprise build system" for Java? Just curious ;)
PS: The fact that the system can be abused and that Maven allows artefacts to specify dependencies on random servers on the internet is part of the "rope to hang effect". Some people need more rope, some people don't need any :)
|
|
||||||||||||
