Spring boot config

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

1 Like

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.
(https://www.guardsquare.com/proguard/manual/troubleshooting#duplicateclass)

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?