#69 One Jar should default to silent operation

open
nobody
None
5
2014-07-07
2013-03-28
IngyHere
No

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.

Discussion

  • IngyHere
    IngyHere
    2013-03-28

    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.

     
  • IngyHere
    IngyHere
    2013-03-28

    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.

     
  • Mark Sinke
    Mark Sinke
    2013-09-19

    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.

     
  • Mark Sinke
    Mark Sinke
    2013-09-20

    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
  • P. Simon Tuffs
    P. Simon Tuffs
    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.

     
  • IngyHere
    IngyHere
    2013-09-21

    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.

     
  • Mark Sinke
    Mark Sinke
    2013-09-23

    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.

     
  • P. Simon Tuffs
    P. Simon Tuffs
    2014-07-07

    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.

     
  • Gus Heck
    Gus Heck
    2014-07-07

    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.

     
  • Gus Heck
    Gus Heck
    2014-07-07

    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=true

     
    Last edit: Gus Heck 2014-07-07
    Attachments
  • P. Simon Tuffs
    P. Simon Tuffs
    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.

     
  • Gus Heck
    Gus Heck
    2014-07-07

    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