автовырезалка

автовырезалка v03.4

Нет прав для скачивания
1,111
47
420
Оставлять idea папку вполне нормальная практика. В последних версиях идейки она прям просит это.
Оставить gradle папку мне было важно ввиду того что там конфигурация gradle wrapper
 
7,099
324
1,509
А если у нас разные версии идеи? Тогда может получиться не очень
 
1,159
38
544
Ув. тов. @JustAGod, в моем коде есть набор классов, предназначенный для тестирования мода на этапе разработки. Я держу их в модуле main в виде отдельного пакета. Могу ли я при помощь вашей вырезалки убирать их из бинарника при билде обфусцированного мода, но оставлять при запуске в IDE?
 
1,159
38
544
Развертывание и настройка сделаны уж очень сложно. Я уверен что вырезалку можно подключать проще.
 
2,505
81
397
Ув. тов. @JustAGod, в моем коде есть набор классов, предназначенный для тестирования мода на этапе разработки. Я держу их в модуле main в виде отдельного пакета. Могу ли я при помощь вашей вырезалки убирать их из бинарника при билде обфусцированного мода, но оставлять при запуске в IDE?
Нужно добавить третью сторону, пометить этой аннотацией пакет и не включать её в серверный и клиентский билд.
 
2,505
81
397
Было бы прикольно засунуть этот плагин в какой-нибудь maven rep.

Непонятно зачем нужны primalSides. Фраза "стороны, которые идут по-умолчанию " мне ни о чём не говорит. Типа в primalSides указываются все возможные стороны, а в targetSides стороны из primalSides, которые останутся после билда? А почему нельзя просто указать аннотации, которые должны быть вырезаны? Без вот этого всего.

Было бы прикольно иметь дефолтную настройку. Явно переопределять classesCache скорее всего никому не понадобится, поэтому почему бы не оставить аргумент по-умолчанию? Если такая фича есть, то круто. Билды по-умолчанию тоже можно было бы генерировать, потому что в 99% случаев будет конфиг именно из примера. И разве classesDirs нельзя определить в рантайме? По крайней мере, если брать классы из tasks.compileJava.destinationDir, то там будут и классы джавы, и классы котлина.
 
1,159
38
544
1,111
47
420
Непонятно зачем нужны primalSides. Фраза "стороны, которые идут по-умолчанию " мне ни о чём не говорит. Типа в primalSides указываются все возможные стороны, а в targetSides стороны из primalSides, которые останутся после билда? А почему нельзя просто указать аннотации, которые должны быть вырезаны? Без вот этого всего.
Это все к тому же вопросу про то как вырезать классы при любом билде и не только.
Это штука в обычной ситуации, скорее всего, никому не понадобится, но рассмотрим случай, который образовался на одном проекте.
Там внезапно появилось 3 стороны в одном моде: сервер, клиент и бэкенд. Изначально 3ей стороны не было, и поэтому логично было, что классы, не помеченные ни одной аннотацией, не подлежали вырезанию, но все изменилось.
Сделано было все так, что при билде бэкенда нужно было веразать весь код, который к нему не относился. Ни у кого не было желания помечать каждый класс аннотацией со сторонами клиент и сервер. Проще было пометить пару папок, что мол они должны быть на бэкенде. Таким образом выходит, что при таком кейсе primalSides просто таки необходимы.
По крайней мере, если брать классы из tasks.compileJava.destinationDir, то там будут и классы джавы, и классы котлина.
Хз с каких пор так. Лично я собаку съел на этом, када вонюче жава 9 не хотела компилироваться из-за разных модуль пазов. Но вапще я могу сделать жавовское место компиляции по дефолту, да.

Явно переопределять classesCache скорее всего никому не понадобится, поэтому почему бы не оставить аргумент по-умолчанию?
угу согласен

илды по-умолчанию тоже можно было бы генерировать, потому что в 99% случаев будет конфиг именно из примера.
Не совсем понимаю как это сделать красиво.

Было бы прикольно засунуть этот плагин в какой-нибудь maven rep.
Да я уже давно думаю над этим. Никада такого не делал и потому для меня это пока немного рокет саенс. Находил какие то платные штуки, но для такого я слишком жмот, сорри. Разберусь после 13го вопщем то(мун)
 
1,159
38
544
7,099
324
1,509
Никада такого не делал и потому для меня это пока немного рокет саенс. Находил какие то платные штуки, но для такого я слишком жмот, сорри.
Попробуй jitpack.io
 
1,111
47
420
Я могу помочь тебе с этим, если есть желание
Да я и сам разберусь, скорее всего.
Попробуй jitpack.io
Кажется, эта штука умеет только с гитхабом работать, а у меня есть навязчивое желание остаться именно на гитлабе(мун)
 
7,099
324
1,509
Все пашет
1560350014300.png
 
1,111
47
420
а ну прекрасно тогда лол
надо б провести рефакторинг шоб заработало
 
1,200
37
237
JitPack тру вариант.

Но я видел статью, где из гит репозитория делали мавен репозиторий :yoba:
 
1,111
47
420
JustAGod обновил(а) ресурс автовырезалка новой записью:

Интересные штуки

- Добавлена возможность вырезания отдельного кода в методах
- Теперь методы наследуют стороны тех методов, которых они перегружают
- Добавлены дефолтные значения многим параметрам конфига

Узнать больше об этом обновлении...
 
1,111
47
420
Ну вопщем то да(мун)
Больше я не буду выкладывать сюды обновы zip архивом. Мне кажется так никому не удобно, и намного проще с жит пака скачать. Мне не нравится только то, что я не могу менять версию, не загружая зип архив, но это для меня не критично так что пихуй.

Так вот, собственно, о самой обнове. Теперь вырезалка может удалять отдельный код, который завернут в лямбду. Чтобы это все заработало, нужно добавить в конфиг куттера следующее:
Gradle (Groovy):
    invokes("lambda.Invoke") {
        server {
            sides = [serverSide]
        }
        client {
            sides = [clientSide]
        }
    }
Где
lambda.Invoke - это класс, в котором присутствуют методы, которые принимают лямбду своим единственным параметром
Gradle (Groovy):
server {
    sides = [serverSide]
}
- название метода и стороны, на которых его вырезать не нужно. Ни в коем случае не думайте, что имя server тут хоть что-нибудь значит. Чувствуйте себя свободно в выборе названия.
Gradle (Groovy):
client {
    sides = [clientSide]
}
То же самое только пример для клиента

Теперь чуть-чуть про костыли,которые тут пришлось применить.
Класс должен выглядеть вот так
Java:
public final class Invoke {

    public static void server(ServerInvoke r) {
        r.run();
    }

    public static void client(ClientInvoke r) {
        r.run();
    }
}
Из важного: обязательно нужно заводить свой функциональный интерфейс для каждой стороны, каждый метод обязательно должен быть статичным и содержать только один аргумент.
Мне все равно на код внутри каждого из этих методов. Тут можете чувствовать себя свободно(мун)
Как это собственно применяется

Java:
        Invoke.server(() -> System.out.println(""));
        Invoke.server(System.out::println);
        Invoke.server(new ServerInvoke() {
            @Override
            public void run() {
                System.out.println();
            }
        });
        Invoke.client(() -> System.out.println("Lol"));
При билде клиента все вызовы Invoke#server, сам Invoke#server и все лямбды, которые в него суются будут удалены.
Пожалуйста, не пытайтесь класть лямбду в переменную, а после сувать ее в метод. Я почти полностью уверен, что это никогда не сработает.

В общем то я понимаю, что настройка может показаться весьма не простой, но я напоминаю, что пример вы всегда можете посмотреть у меня в репо.

Еще хочу сказать, что эта штука, по моему, весьма нестабильна. И, если вы юзаете jitpack и вам не особо нужно вырезание лямбд, я бы вам посоветовал использовать версию 9206ea49 как пока наиболее стабильную. Конечно любые баг репорты я буду стараться закрывать как можно быстрей, но все же.
 
Сверху