i am trying to obfuscation for my spring boot project but it only does it for main class not other classes would you pleasehelp
Hi @Pedram_Ezzati !
You could take a look at this example Spring Boot project, it should get you started proguard/examples/spring-boot at master Ā· Guardsquare/proguard Ā· GitHub
thanks so much can we also have exmapl for maven because our project are base on maven
We donāt have any official Maven plugin but this project maintains a plugin that is up-to-date with the latest ProGuard: GitHub - wvengen/proguard-maven-plugin: ProGuard Maven plugin that supports modularised ProGuard packages
Hi all,
Regarding the end result, is there any difference at all between using ProGuard via Gradle or using ProGuard as an stand-alone once the .jar is created?
It looks more clear to me that, while experimenting, could be simpler to have it separated, so I can compare the obfuscation result with the original content.
So, rewording the questionā¦ can I take the content of build.gradle in its ātask proguardā and use it in my
proguard config file? Or is there anything else to bear in mind?
Hi @jordi
Thereās nothing fundamentally different about running ProGuard via Gradle or standalone.
Since in Gradle you have the full power of Gradle + Groovy (or Kotlin) programming language and access to things like dependencies you can do things like
libraryjars sourceSets.main.compileClasspath
Standalone, you would instead write
-libraryjars /path/to/libraryjar1.jar
-libraryjars /path/to/libraryjar2.jar
-libraryjars /path/to/libraryjar2.jar
You can add a printconfiguration 'standalone.pro
line to the Gradle task and itāll print the full configuration including the library jar lines. This can be useful for moving from Gradle task to standalone.
In the Spring Boot example, there are also dependencies between the tasks. So running proguard
task will trigger some other tasks.
Hi all,
Following the Gradle example as a pattern for my config in a Spring Boot application, Iām facing 2 main issues. I will put them separated in 2 mails, as I think that are not related.
First thing is that I had to strip out my spring boot jar. Iām unable to find a way to tell proguard that this is not a ādefaultā jar and that the content begins on BOOT-INF/classes and not in the root.
Same applies for libraries, that were self-contained on BOOT-INF/lib. So I moved the libs out of the jar into a dir which I referenced in the config.
Up to this respect, my config contains:
-verbose
-injars test.jar
-outjars out.jar
-libraryjars <java.home>/lib/rt.jar
-libraryjars ./lib
When I run it, Iām getting a long list of Note entries ending like this:
Note: duplicate definition of library class [javax.servlet.WriteListener]
Note: duplicate definition of library class [module-info]
Note: duplicate definition of library class [module-info]
NNote: duplicate definition of library class [module-info]
Note: there were 520 duplicate class definitions.
(ProGuard Manual: Troubleshooting | Guardsquare)
Of course I went into the ./lib dir to check for dupes, but Iām unable to locate any. Any clue whatās wrong with the way to identify those dupes?
In the same previous content, when starting the application, I get the error detailed below.
As per the error, it looks to me that when Spring is dealing with its beans, doesnāt like those to have the same name (of course, I might be wrong and the problem be another one).
Looking at the 2 original classes, both have annotations to be managed as Spring beans.
This is the config Iām using:
-keepattributes Annotation
-keepdirectories
-keepclassmembers class * {
@org.springframework.beans.factory.annotation.Autowired *;
@org.springframework.context.annotation.Bean *;
}
-useuniqueclassmembernames
#-flattenpackagehierarchy
As you can see, I tried some combinations of using keepdirectories and flatternpackagehierarchy, but without much success.
I guess that ideally Iād like to generate non-repeated names.
Any suggestions?
ā¦ [main] ERROR 858 Application run failed
org.springframework.beans.factory.BeanDefinitionStoreException: Failed to parse configuration class [.]; nested exception is org.springframework.context.annotation.ConflictingBeanDefinitionException: Annotation-specified bean name āaā for bean class [.c.a] conflicts with existing, non-compatible bean definition of same name and class [.i.a]
at org.springframework.context.annotation.ConfigurationClassParser.parse(ConfigurationClassParser.java:181)
at org.springframework.context.annotation.ConfigurationClassPostProcessor.processConfigBeanDefinitions(ConfigurationClassPostProcessor.java:315)
at org.springframework.context.annotation.ConfigurationClassPostProcessor.postProcessBeanDefinitionRegistry(ConfigurationClassPostProcessor.java:232)
at org.springframework.context.support.PostProcessorRegistrationDelegate.invokeBeanDefinitionRegistryPostProcessors(PostProcessorRegistrationDelegate.java:275)
at org.springframework.context.support.PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(PostProcessorRegistrationDelegate.java:95)
at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:705)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:531)
at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:142)
at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:775)
at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:397)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:316)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:1260)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:1248)
at ..main(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:48)
at org.springframework.boot.loader.Launcher.launch(Launcher.java:87)
at org.springframework.boot.loader.Launcher.launch(Launcher.java:50)
at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:51)
Caused by: org.springframework.context.annotation.ConflictingBeanDefinitionException: Annotation-specified bean name āaā for bean class [.c.a] conflicts with existing, non-compatible bean definition of same name and class [.i.a]
at org.springframework.context.annotation.ClassPathBeanDefinitionScanner.checkCandidate(ClassPathBeanDefinitionScanner.java:348)
at org.springframework.context.annotation.ClassPathBeanDefinitionScanner.doScan(ClassPathBeanDefinitionScanner.java:286)
at org.springframework.context.annotation.ComponentScanAnnotationParser.parse(ComponentScanAnnotationParser.java:132)
at org.springframework.context.annotation.ConfigurationClassParser.doProcessConfigurationClass(ConfigurationClassParser.java:287)
at org.springframework.context.annotation.ConfigurationClassParser.processConfigurationClass(ConfigurationClassParser.java:242)
at org.springframework.context.annotation.ConfigurationClassParser.parse(ConfigurationClassParser.java:199)
at org.springframework.context.annotation.ConfigurationClassParser.parse(ConfigurationClassParser.java:167)
Hi @jordi ,
Unfortunately, ProGuard does not have any concept of Spring Boot jars and there isnāt currently anyway to configure it to work with the BOOT-INF/classes
files.
Itās the reason for extracting and repacking the classes in the Gradle example: proguard/build.gradle at master Ā· Guardsquare/proguard Ā· GitHub
For the duplicates, maybe you have the same classes in the lib
folder as in the injar
?
For your second question - are you able to provide a sample project showing the problem?
Hi there,
Iām just playing again with it, and trying the Spring Boot from Gradle.
Is it my config or is the Spring Boot example old and not compatible with Gradle 7?
Iām getting this error: Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
and when running with --warning-mode all
Iām getting lots of:
Property āconfigurationFilesā is not annotated with an input or output annotation. This behaviour has been deprecated and is scheduled to be removed in Gradle 7.0. See Authoring Tasks for more details.
Thanks
HI @jordi , ProGuard 7.0.1 ProGuardTask isnāt compatible with Gradle 7. 7.1.0-beta2 has a fix for this but there is a potential problem with optimizations in beta2 at the moment. You can try that and see if it works for you, maybe use -dontoptimize
if optimizations cause a problem.