Menu

#115 Proguard Compatibility

undecided
open-accepted
nobody
None
5
2014-12-18
2014-12-17
No

I am using Proguard to make a single "uber" jar with all of the dependencies in it yet trimmed to only include the class, methods, members, etc. that I need.

FreeMarker has a lot of dependencies to build the code. I am amazed that these same dependencies aren't required for run time. Because of these build dependencies, Proguard requires the dependencies for scanning. This requires that I add a ton of dependencies into my Maven script. How do I avoid adding 30+ dependencies yet get Proguard examine all of the dependencies?

This may seem like a Proguard question. I assure you that it is not. Other projects which have dependencies are included without issue.

I can workaround the issue by adding -dontwarn property to Proguard configuration. This is highly not recommended by Proguard.

Here's a sample Maven plugin tag...

  <plugin>
    <groupId>com.github.wvengen</groupId>
    <artifactId>proguard-maven-plugin</artifactId>
    <version>2.0.8</version>
    <executions>
      <execution>
        <id>proguard</id>
        <phase>package</phase>
        <goals>
          <goal>proguard</goal>
        </goals>
      </execution>
    </executions>
    <configuration>
      <proguardVersion>5.0</proguardVersion>
      <injar>${project.build.finalName}.jar</injar>
      <outjar>MyProgram.jar</outjar>
      <obfuscate>false</obfuscate>
      <options>
        <option>-dontnote</option>
        <option>-dontoptimize</option>
        <option>-keep public class com.company.team.project.Main {public static void main(java.lang.String[]);}</option>
        <option>-keep public class com.company.team.project.datamodel.**    {public *** get*();}</option>

        <option>-keepclassmembers enum *
        {
          public static **[] values();
          public static ** valueOf(java.lang.String);
        }
        </option>
      </options>
      <libs>
        <lib>${java.home}/lib/rt.jar</lib>
      </libs>
    </configuration>
  </plugin>

Discussion

  • Dániel Dékány

    Surely there would be much less such "dynamic" dependencies if FreeMarker was consisting of a lean core module (a jar) and then a freemarker-serlvet module (another jar), a freemarker-jython module (yet another jar), etc. At least now that we have Maven and a few other advancements in the Java world. But due to backward compatibility we have to live with this legacy for a while. So, just tell Proguard to shut up when it processes freemarker.jar... these are all optional dependencies, as it's stated in the documentation. You only need to care about those that are present in your project regardless of FreeMarker. (If you have any backward compatible ideas for improving Proguard compatibility, don't hesitate to tell it.)

     
    • Nathan Reynolds

      Nathan Reynolds - 2014-12-17

      Splitting the modules would require that you bump the version to 3.0.0.
      Those that adopt 3.0.0 would expect such disruptive changes (see
      http://semver.org/).

      On the other hand, I wonder if you specified in the pom.xml that FreeMarker
      has all of these dependencies if that would satisfy Proguard.

      -Nathan

      From: "Dániel Dékány" [mailto:ddekany@users.sf.net]
      Sent: Wednesday, December 17, 2014 12:11 PM
      To: [freemarker:bugs]
      Subject: [freemarker:bugs] #421 Proguard Compatibility

      Surely there would be much less such "dynamic" dependencies if FreeMarker
      was consisting of a lean core module (a jar) and then a freemarker-serlvet
      module (another jar), a freemarker-jython module (yet another jar), etc. At
      least now that we have Maven and a few other advancements in the Java world.
      But due to backward compatibility we have to live with this legacy for a
      while. So, just tell Proguard to shut up when it processes freemarker.jar...
      these are all optional dependencies, as it's stated in the documentation.
      You only need to care about those that are present in your project
      regardless of FreeMarker. (If you have any backward compatible ideas for
      improving Proguard compatibility, don't hesitate to tell it.)


      [bugs:#421] http://sourceforge.net/p/freemarker/bugs/421 Proguard
      Compatibility

      Status: open
      Group: undecided
      Created: Wed Dec 17, 2014 06:24 PM UTC by Nathan Reynolds
      Last Updated: Wed Dec 17, 2014 06:24 PM UTC
      Owner: nobody

      I am using Proguard to make a single "uber" jar with all of the dependencies
      in it yet trimmed to only include the class, methods, members, etc. that I
      need.

      FreeMarker has a lot of dependencies to build the code. I am amazed that
      these same dependencies aren't required for run time. Because of these build
      dependencies, Proguard requires the dependencies for scanning. This requires
      that I add a ton of dependencies into my Maven script. How do I avoid adding
      30+ dependencies yet get Proguard examine all of the dependencies?

      This may seem like a Proguard question. I assure you that it is not. Other
      projects which have dependencies are included without issue.

      I can workaround the issue by adding -dontwarn property to Proguard
      configuration. This is highly not recommended by Proguard.

      Here's a sample Maven plugin tag...

      <plugin>
      <groupid>com.github.wvengen</groupid>
      <artifactid>proguard-maven-plugin</artifactid>
      <version>2.0.8</version>
      <executions>
      <execution>
      <id>proguard</id>
      <phase>package</phase>
      <goals>
      <goal>proguard</goal>
      </goals>
      </execution>
      </executions>
      <configuration>
      <proguardversion>5.0</proguardversion>
      <injar>${project.build.finalName}.jar</injar>
      <outjar>MyProgram.jar</outjar>
      <obfuscate>false</obfuscate>
      <options>
      <option>-dontnote</option>
      <option>-dontoptimize</option>
      <option>-keep public class com.company.team.project.Main {public
      static void main(java.lang.String[]);}</option>
      <option>-keep public class com.company.team.project.datamodel.*
      {public *** get
      ();}</option></options></configuration></plugin>

          <option>-keepclassmembers enum *
          {
            public static **[] values();
            public static ** valueOf(java.lang.String);
          }
          </option>
        </options>
        <libs>
          <lib>${java.home}/lib/rt.jar</lib>
        </libs>
      </configuration>
      


      Sent from sourceforge.net because you indicated interest in
      https://sourceforge.net/p/freemarker/bugs/421/
      https://sourceforge.net/p/freemarker/bugs/421

      To unsubscribe from further messages, please visit
      https://sourceforge.net/auth/subscriptions/
      https://sourceforge.net/auth/subscriptions

       
  • Dániel Dékány

    Yes, that's why it can't be done easily. And such a version should come with a few other bigger changes too, which are also waiting to happen. (Modularization is on the list BTW, but there are more important issues in the queue, so I don't know when will that happen.)

    You mean adding these the to the pom.xml as optional dependencies, and hoping that won't break anything (it shouldn't in theory, but then, I can't know if how will various tools react). Well, if you try that, we will see. The list of dependencies is in ivy.xml (https://github.com/freemarker/freemarker/blob/2.3-gae/ivy.xml). As you will see, it's quite scary, as we have dependencies on multiple versions of the same thing, and some exotic dependencies that might as well missing from the central repo...

     

    Last edit: Dániel Dékány 2014-12-17
    • Nathan Reynolds

      Nathan Reynolds - 2014-12-17

      I am glad to hear modularization is on the list. I guess let this bug serve
      as a small boost to the priority of modularization.

      -Nathan

      From: "Dániel Dékány" [mailto:ddekany@users.sf.net]
      Sent: Wednesday, December 17, 2014 4:38 PM
      To: [freemarker:bugs]
      Subject: [freemarker:bugs] #421 Proguard Compatibility

      Yes, that's why it can't be done easily. And such a version should come with
      a few other bigger changes too, which are also waiting to happen.
      (Modularization is on the list BTW, but there are more important issues in
      the queue, so I don't know when will that happen.)

      You mean adding these the to the pom.xml as optional dependencies, and
      hoping that won't break anything (it shouldn't in theory, but then, I can't
      know if how will various tools react). Well, if you try that, we will see.
      The list of dependencies is in ivy.xml
      (https://github.com/freemarker/freemarker/blob/2.3-gae/ivy.xml). As you will
      see, it's quite scary, as we have dependencies on multiple versions of the
      same thing, and some exotic dependencies that might as well missing from the
      central repo...


      [bugs:#421] http://sourceforge.net/p/freemarker/bugs/421 Proguard
      Compatibility

      Status: open
      Group: undecided
      Created: Wed Dec 17, 2014 06:24 PM UTC by Nathan Reynolds
      Last Updated: Wed Dec 17, 2014 07:10 PM UTC
      Owner: nobody

      I am using Proguard to make a single "uber" jar with all of the dependencies
      in it yet trimmed to only include the class, methods, members, etc. that I
      need.

      FreeMarker has a lot of dependencies to build the code. I am amazed that
      these same dependencies aren't required for run time. Because of these build
      dependencies, Proguard requires the dependencies for scanning. This requires
      that I add a ton of dependencies into my Maven script. How do I avoid adding
      30+ dependencies yet get Proguard examine all of the dependencies?

      This may seem like a Proguard question. I assure you that it is not. Other
      projects which have dependencies are included without issue.

      I can workaround the issue by adding -dontwarn property to Proguard
      configuration. This is highly not recommended by Proguard.

      Here's a sample Maven plugin tag...

      <plugin>
      <groupid>com.github.wvengen</groupid>
      <artifactid>proguard-maven-plugin</artifactid>
      <version>2.0.8</version>
      <executions>
      <execution>
      <id>proguard</id>
      <phase>package</phase>
      <goals>
      <goal>proguard</goal>
      </goals>
      </execution>
      </executions>
      <configuration>
      <proguardversion>5.0</proguardversion>
      <injar>${project.build.finalName}.jar</injar>
      <outjar>MyProgram.jar</outjar>
      <obfuscate>false</obfuscate>
      <options>
      <option>-dontnote</option>
      <option>-dontoptimize</option>
      <option>-keep public class com.company.team.project.Main {public
      static void main(java.lang.String[]);}</option>
      <option>-keep public class com.company.team.project.datamodel.*
      {public *** get
      ();}</option></options></configuration></plugin>

          <option>-keepclassmembers enum *
          {
            public static **[] values();
            public static ** valueOf(java.lang.String);
          }
          </option>
        </options>
        <libs>
          <lib>${java.home}/lib/rt.jar</lib>
        </libs>
      </configuration>
      


      Sent from sourceforge.net because you indicated interest in
      https://sourceforge.net/p/freemarker/bugs/421/
      https://sourceforge.net/p/freemarker/bugs/421

      To unsubscribe from further messages, please visit
      https://sourceforge.net/auth/subscriptions/
      https://sourceforge.net/auth/subscriptions

       
  • Dániel Dékány

     
  • Dániel Dékány

    I move this over to feature requests then. It's not really a bug, but an inconvenience coming from an old design decision (one big monolithic artifact instead of multiple smaller modules).

     
  • Dániel Dékány

    Ticket moved from /p/freemarker/bugs/421/

     
  • Dániel Dékány

    Ticket moved from /p/fmpp/feature-requests/30/

     
  • Dániel Dékány

    • status: open --> open-accepted
     

Log in to post a comment.

MongoDB Logo MongoDB