Исключить запутанный jar из папки lib с помощью ProGuard - PullRequest
Новая
       51

Исключить запутанный jar из папки lib с помощью ProGuard

2 голосов
/ 10 февраля 2020

Я использую proguard-maven-plugin в своем многомодульном проекте maven с весенней загрузкой. Я ни в коем случае не эксперт и все еще учусь использовать все функции, предоставляемые ProGuard, так что терпите меня. Зависимость ProGuard: 

<groupId>com.github.wvengen</groupId>
<artifactId>proguard-maven-plugin</artifactId>
<version>2.1.1</version>

Конечный продукт - это файл .jar, который зависит от успешно скрытого модуля с основными функциями. После компиляции и упаковки продукта в банку с maven его структура выглядит следующим образом (используя jd- gui -1.6.6 для проверки содержимого банки в продукте): 

BOOT-INF
|_classes
  |_com.my.package
    |_a(ObfuscatedModule package after obfuscation)
      |_b.class
      |_c.class
      |_...
    |_Main.class
  |_...
|_lib
  |_ObfuscatedModule.jar
    |_NonObfuscatedClass1.class
    |_NonObfuscatedClass2.class
    |_NonObfuscatedClass3.class
    |_...
META-INF
org.springframework.boot.loader

Поскольку точка запутывания заключается в скрыть модуль с основными функциями, я хотел бы также исключить из каталога lib внутри jar продукта. Изучив примеры proguard , я не нашел способ сделать это. Можно ли исключить или хотя бы замаскировать основной модуль .jar в /lib?

РЕДАКТИРОВАТЬ: я попытался обойти создание отдельной папки с зависимостями с помощью maven-shade-plugin, создав Uber JAR , При использовании он добавляет все зависимости к пути к классам, а затем плагин ProGuard используется для обфускации того, что необходимо скрыть. Структура проекта выглядит удовлетворительно, с зависимостями, добавленными в classpath и правильно скрытыми. Но когда я пытаюсь запустить затененную банку, я получаю следующую ошибку:

Ошибка: не удается найти или загрузить основной класс com.my.package.Main

Основной класс находится в банке, и я знаю, что он не связан с первоначальной проблемой, но я прибегнул ко всем возможным решениям, найденным в SO и inte rnet - не повезло.

1 Ответ

0 голосов
/ 11 февраля 2020

Итак, после небольшой борьбы я нашел решение своей проблемы. Во-первых, я добавил <scope/> из «предоставленных» ( ссылка на документы ) к нужным зависимостям из папки lib: 

<dependency>
      <groupId>com.myCompany</groupId>
      <artifactId>module_to_be_excluded</artifactId>
      <version>${project.version}</version>
      <scope>provided</scope>
    </dependency>

После этого я запустил mvn clean install и проверил вывод .jar, но зависимости все еще были найдены в папке lib. Недостающим элементом было добавление <excludeGroupIds>com.myCompany</excludeGroupIds> в spring-boot-maven-plugin внутри пом. xml модуля, который был запутан: 

<plugin>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-maven-plugin</artifactId>
          <fork>true</fork>
          <skip>false</skip>
          <profiles>dev</profiles>
          <excludeGroupIds>com.myCompany</excludeGroupIds>
        </configuration>
        ...

Причина, по которой исключаются модули с groupId = com.myCompany, заключается в том, что некоторые из модулей, которые разрабатываются, также запутываются (следовательно, тот же groupId). Нет никакого смысла в запутывании кода, который кто-то может легко проверить, в то же время находя эти необфусцированные баночки в папке lib.

...