Apply Obfuscate4e obfuscation on a real-life Eclipse RCP project

[GoogleCodeExporter]

Prior to release 0.8 the obfuscation has to be reviewed/tested using a 
real-life RCP application 
(maybe RSSowl).

Original issue reported on code.google.com by schoobidoo on 3 Nov 2009 at 9:31

[GoogleCodeExporter]

I've been using Obfuscate4e for a few months with our RCP application and it 
works
fine as long as we modify the generated proguard.cfg file to include generic 
keep
statements.

I entered an issue already for this on sourceforge, the ability to configure a
generic block of configuration statements to be applied to every generated
configuration file.

Basically we need to preserve RMI files, serializable, the members inside any 
class
that extends org.eclipse.gef.tools.AbstractTool (reflection is used in GEF), 
etc.
I understand these requirements will change for every RCP application, that's 
why we
need to define a generic block of statements to include.

Original comment by dcende...@gmail.com on 2 Dec 2009 at 11:33

[GoogleCodeExporter]

To comment on my previous comment:

I downloaded the latest source code and saw there is a "keep" section now at 
the end
of the proguard.cfg file. It is nice, however I'd prefer if it could be defined 
as a
global template in a global property page.

The reason is simple, if we find we need to keep some other type of class, we 
have to
manually update our plugins (about 50), while having a common configuration 
would be
easier (It doesn't happen that very often I must say).

But I understand other people might prefer the per-project keep section, so 
maybe
having 2 sections: 1 per project keep and 1 copied from the global config would 
suit
everyone.

Not a big problem, just a nice thing to add if time permit!

Original comment by dcende...@gmail.com on 2 Dec 2009 at 12:54

[GoogleCodeExporter]

The problem (IMHO) problem is that every plugin has to be self-contained during 
PDE build. (the plugin 
references other plugins as jar on the classpath but it does not rely on some 
kind of infrastructure plugins 
that provide a kind of product configuration at build time. Means: You can not 
easily provide a configuration 
fragment that is included by every plugin. The plugin can be used in different 
products/features/environments and a deployer has to be sure that the plugin 
operates the same way in 
every context.

We could think of a set of templates that are included into proguard.cfg when 
the file is created. Maybe that 
helps? But these templates have to be maintained manually once the proguard.cfg 
file is created.

PS: We think about some custom actions in the context menu of a class that 
permits to create other exclude 
statements (e.g. if the class is an interface then exclude all classes that 
implement this interface inside this 
project). But that are future plans.

Another plan might be to create an editor that permits to efficiently edit all 
proguard configurations within a 
workspace (thats just an idea ;)

Original comment by schoobidoo on 2 Dec 2009 at 2:03

[GoogleCodeExporter]

I understand what you mean, but I think it could be possible with the following:

- Global configuration defined within a property page in eclipse
- Create the proguard.cfg file -> The global config is put in the file
    So We have:
   #########
      Plugin generated config
   #########
      Plugin keep section (always kept as is)
   #########
      Global config section (always written from global config)
   #########
- When we re-generate the config, the global config section is written each time

It makes it easier to modify the global config, we change it once and then we 
could
select all projects, right-click and generate the config for all of them. (See 
issue 6)

I'm a bit busy these days but I'll try to find some time and submit a patch.

Original comment by dcende...@gmail.com on 3 Dec 2009 at 3:00

[GoogleCodeExporter]

Yes, this is really possible. The user needs to know that if he changes the 
workspace preferences then his 
modifying his active plugins as well (if he is using the automatic builder 
feature). So there should be a 
confirmation dialog if an exiting file is modified.

A patch? Yeah. A patch is very welcome ;)

Original comment by schoobidoo on 3 Dec 2009 at 3:08