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>
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.)
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>
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
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
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>
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
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).
Ticket moved from /p/freemarker/bugs/421/
Ticket moved from /p/fmpp/feature-requests/30/