Menu ▾ ▴

Remove dependency to GPL licensed java-getopt

General Discussion
Thomas Weinschenk
2015-01-14
2015-01-16

  • Thomas Weinschenk

    Thomas Weinschenk - 2015-01-14

    The converter uses the GPL licensed library java-getopt to do some command line parsing.
    If I don't use the command line I am still "suffering" from the GPL dependency. In my opinion it would make sense to separate the "core" library and the command line processing.

    What do you think?

    Regards,
    Thomas

     

    • Lochrann

      Lochrann - 2015-01-16

      Hi Thomas,

      Thanks for your interest in this program – I really appreciate that.
      I reckon that a core library should have the fewest possible number of dependencies.
      The skeleton jar you talk about would probably have one unique dependency with commons-logging (instead of three at present) which sounds good.
      At the outset I wanted the converter to remain as simple as possible and that meant for me to offer one unique multi-purpose downloadable library at a time to keep the Sourceforge page as straight as possible.
      It might sound kind-of simplistic model - not to say primitive - but I have a special concern for non-programmers who might be interested in the library and who might get confused by several downloadable jars in a row (even though I don’t even know if non-programmers will ever be interested in such a tool).
      If I'm not mistaken you don't use the command line interface and java-getopt-1.0.13.jar happens to remain unused on your platform. Hum - it's 56K only of wasted bytes – is this worth the effort?..
      Anyway I guess soon or later someone will most certainly complain about conflicts that the dependencies create with other local jars (for instance a collision between commons-logging-1.1.3.jar and another local commons-logging library).
      An uber-jar would do the trick I guess, but a core jar like the one you suggest would certainly alleviate that collision risk for those who are only interested by a plain Java interface (but wouldn't completely suppress the risk because of commons-logging I imagine).

      Hum - maybe a custom Maven assembly making it possible for programmers to generate the core library plus another one to generate an uber-jar, and both of them shipped in a supplemental.zip file for experts to download with the next version?

      OK, OK, you got it, I push your idea on next version's ToDo list [V1.1.0 not expected before the next alignment of the 9 planets I'm afraid - Time flies by so quickly].

      Regards,
      Laurent

       

Log in to post a comment.