On 10/13/2012 01:20 PM, Konstantin Boudnik wrote:
On Sat, Oct 13, 2012 at 11:19AM, Roman Shaposhnik wrote:
On Sat, Oct 13, 2012 at 6:01 AM, Steve Loughran <[email protected]> wrote:
yes, we seem to agree on that
http://steveloughran.blogspot.co.uk/2012/04/pythonium-or-why-is-there-no-javash.html
I honestly don't understand what the problem is. For quite
complex projects like Jenkins, Gradle, Logstash, etc I've seen
the approach of fat jars turning out the best of both worlds:
$ java -jar jenkin.jar
and you're done.
I have managed to follow the same approach with a fat ass enterprise server
that we do for Hadoop analytics in Karmasphere. The whole jazz is being
bootstrapped exactly as you pointed out. And the "fat.jar" in our case is
pretty fat at about 160MB or so.
And I am quite happy and can attest first hand that it works great! And the
deployment is sooooooo simple ;) - no nonsense with OS specific packages,
start-up scripts, etc.
It is not because it is easy that it is efficient. What you are winning
in convenience is lost in:
* Dependencies management. Now you are on the hook for keeping track of
updates for every single one of your dependencies. This applying also
transitively
* Integration with the system (documentation, automatic start on boot,
integration with logging facilities or puppet...).
* Duplication. Doing a fat jar is nothing special to java. static
linking can be done for natives as well.
* Audit and patching for security issues. As a user, I cannot easily
patch and rebuild parts of your application. Maven and co also don't
have much in the way of signing releases or publishing source artefacts
(am talking about real sources, not the src jar)
* So if you need to publish a minor updatem I sorts of mean I need to
re-download 160MB.
Note that, I am also going the fat jar for some of my applications and
find this appropriate. But the fat jar approach would not fly for a system.
Sure, you can try to tweak classpath, and garbage collection options, etc.
But why? Besides, there's plenty of options to the python executable
that can also be tweaked -- but once again for the use case we're talking
about -- shell replacement -- why would you do that?
I guess there's an issue of startup time -- bash/python seem to
startup a few sec. sooner, but it hasn't bothered me, honestly.
Yup, considering the benefits of a consistent and speedy development the few
percentage points of bootstrap time are non-essential to say the least.
And all I can say about the story below is "It is beautiful" (in a voice of
Russel Peters).
Cos
Agreed. Scripts don't have to be in bash/python/perl.
Note also that if you need an IDE, maven (or other tool of your choice),
it's not a script anymore.
Thanks,
Bruno
