One Jar should default to silent operation
Status: Beta
Brought to you by:
simontuffs
Menu
▾
▴
#69 One Jar should default to silent operation
Since One Jar is a wrapper around another application, it should work unobtrusively and silently in the background. It should only start logging to stdout if and when the verbose flag is set in a properties file or in a system property. Currently, the one-jar.silent flag can be set true in the one-jar.properties file when it is placed at the top-level of the target jar; however, One Jar announces before implementing the policy that it is "loading properties from one-jar.properties." I request that this message, too, be silent.
If no flag is added, One Jar logs all over stdout.
Also, I would like to ask that System.out.println be removed from Exception catch blocks throughout the code.
Boot.java line 317 starts the method initializeProperties and logs the loading/merging operations. The code can be fixed by moving the log statement below the calls to "properties.load(is)." In other words, log that it just happened, ala "Loaded properties from ...", etc.
I'd second the comment about silent operation by default. I too worked around the 0.97.1 version verbosity by setting one-jar.silent=true, and I too have the single [Boot] log line show up.
The "simple" fix I made is to patch one-jar and reduce the log level of the property loading statements to FINE. (I needed a custom build to be able to work around the issue in patch #9 anyway.)
(And I set the one-jar.silent=true property in a top-level properties file to suppress the rest.)
Last edit: Mark Sinke 2013-09-20
hey Mark: thanks so much for these contributions. I have some other patches that I need to integrate: time to get off my *** and finish 0.98...
simon.
Except, that doesn't take care of the System.out.println statements. And, I looked at the patch. There appears to be nothing in there regarding logging levels.
I did not want to pollute the class loading StackOverflowError patch with the logging change. For your convenience I added the patch I made at https://sourceforge.net/p/one-jar/patches/10/
Hello,
Even though the last update is several months old, I second that. Silent mode should be the default.
It is the only nitpick I have towards an otherwise great package. I use it with the gradle-onejar-plugin (https://github.com/rholder/gradle-one-jar) which works really great, but this one feature is the one I really miss.
This one is really really irritating me. One of my most common use cases for one-jar is for packing up small little utilities that I want to be able to run from the command line. All these log messages make it nearly impossible to distinguish the output from the tool. FYI... lots of folks are struggling with this.
http://stackoverflow.com/questions/3662659/one-jar-remove-verbose-warning-information-on-application-load
Note:
viewed 2533 times
https://github.com/rholder/gradle-one-jar/issues/15
Last edit: Gus Heck 2014-07-06
I'd welcome anyone to step up and become a committer on one-jar, I don't have the time I'd like to have to spend on keeping it alive. It would be great to have just one collaborator, more would be better. I'm open to suggestions.
I guess that's only fair :) it is open source. Not sure if can commit myself to anything beyond a patch or a vote for Mark's patch. The fact you are still on CVS is something of a negative for me in this. I haven't used it for anything significant since 2005 (when the company I was at migrated to subversion). I don't have a machine with it installed (not that hard to fix, but...). You might consider migrating to git or at least subversion if you are looking to attract helpers.
Ok, patches don't get much simpler than this :) Hope you can get it in there soon. The info level logging that is the current default can still be obtained by passing
-Done-jar.info=trueLast edit: Gus Heck 2014-07-07
I was considering migrating to SVN for a long time, but now a move to GitHub would make most sense. And that indicates a significant rework of the build tools and unit tests, so it wouldn't be a minor effort. One thing I've been noting is that there is now a good equivalent to one-jar built into the Eclipse framework, so I'm wondering if investing more time in one-jar makes sense.
I'll let you and others guide me on this, I would like to make one more round of effort if it would be useful to people.
Oh there absolutely is value in maintaining this in my opinion. (and possibly this discussion should move out of this issue.) IDE's should never be part of the build process. Automated builds are a key agile practice, and even if you could automate the IDE, that's like using the death star to zap mosquitoes around your barbecue... The "unpacks itself" type packaging systems just plain stink in that they crap on your filesystem. This system does seem to run into issues with class loading sometimes (i.e issue 73), but as those issues are dealt with this moves towards being the ideal way of deploying a java app. I've never understood why sun/oracle has never built something like this into java. Cobbling together classpaths is one of the crappiest aspects of java (IMHO). When I found this project I literally let out a "whoop" of joy (luckily I was at home). Having looked at the code I do agree that there is some room for cleaning up the build system, and perhaps beginning to update to use generics etc. I haven't seen where (if) you declare an intended level of support for java versions at the source/binary levels? (I haven't hunted through the build yet). Oh and as a side note, I have on my machine a version of the repo converted to a git repo now. The conversion isn't that hard to do (though I've done nothing to validate it other than run the build for the one-jar directory).
Last edit: Gus Heck 2014-07-07
Any chance we'll have an official GitHub repo anytime soon?
This of course is in no way official, but I had to fix another problem I ran into, so...
https://github.com/nsoft/uno-jar
FWIW, I've now fixed a couple more things and revamped the build in the above fork to use gradle and published to maven central. Simon, you're totally invited to join my repo a maintainer, and we can move back to the one-jar name if you are willing to release it under a pure MIT or Apache 2.0 license rather than your customized license. The fact you trademarked One-JAR and included that trademark in the license notice that must be reproduced is awkward. Since you hold the copyright for the original, only you have the power to release the old stuff under a new license that corrects these issues.
You'll notice I had to deep 6 a bunch of tests to get things running. I'd be estatic if someone wants to work on resurecting some of those, though I think the SDK concept needs to fade away. One advantage of the switch to UnoJar name, is it strips away back compatibility concerns, so things that were of questionable utility vs their complexity can be left in the vcs history...