Combine obfuscation settings in pom.xml with Obfuscation annotation

[i.pdf.dev]

I'm trying to combine obfuscation settings defined in pom.xml with the Obfuscation annotation to obfuscate some public methods while other public methods should remain unchanged.
If I have this combination:
a. source code:

public class Class1 {
    @com.yworks.util.annotation.Obfuscation(exclude = true)
    public void method1() {
    }
}

b. pom.xml

<rename>
    <keep>
         <class classes="public"/>
    </keep>
</rename>

Then all public methods are renamed except for method1 (it is what I expect)

But if I have this combination
a. source code:

public class Class1 {
    @com.yworks.util.annotation.Obfuscation(exclude = false)
    public void method1() {
    }
}

b. pom.xml

<rename>
    <keep>
         <class classes="public" methods="public"/>
    </keep>
</rename>

Then all public methods are kept, including method1 (I would expect method1 to be renamed according to the annotation).
Is this a bug or it is by design? If it is by design, could you indicate where in the source code should we change the evaluation of this condition for our particular use case so that method1 is renamed?

[Sebastian Müller]

It's by design and conceptually it will not work to force obfuscating some methods, but not others. E.g. if a method is an override, you cannot force it to be obfuscated in a subclass but keep it in the base class or interface.

[i.pdf.dev]

I understand, but our scenario is much simpler. We have a library that has a few public methods that are intended for library use only and these methods we want to rename. This is why we wanted to make our private changes. We could go the other way around, obfuscate all methods in pom.xml and exclude the "real" public methods using the Obfuscation annotation but this approach involves much more work.

[Sebastian Müller]

Can't you keep all your library members except for the ones you want to rename?

There is even an example for "obfuscating a library" in the docs. This works quite well, typically.

[i.pdf.dev]

We can do that, the problem is we want to keep 95% of the methods and only 5% to rename. This is why we wanted to go the other way around.

[Lennard Berger]

Why not use my_library.public.namespace and keep to keep all classes in that namespace, and put everything you want to obfuscate in my_library.private.namespace ?

[i.pdf.dev]

The problem is we have public classes that include both public API methods and internal public methods for library use only.

[Lennard Berger]

The problem is we have public classes that include both public API methods and internal public methods for library use only.

As Sebastian pointed out, this is pretty much an anti pattern and will be tricky in most obfuscation scenarios. So if you can, try refactor them out into public/private classes. I will close this ticket because it is technically possible / not a bug.