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

[JustAGod]

Оставлять idea папку вполне нормальная практика. В последних версиях идейки она прям просит это.
Оставить gradle папку мне было важно ввиду того что там конфигурация gradle wrapper

 

[hohserg]

А если у нас разные версии идеи? Тогда может получиться не очень

 

[Icosider]

Оставить gradle папку мне было важно ввиду того что там конфигурация gradle wrapper

У тебя её нет в репе

 

[JustAGod]

А если у нас разные версии идеи? Тогда может получиться не очень

нет все норм
там xml и оно может спокойно пропускать неизвестные
если же у тебя ну очень старая, то просто удали

 

[JustAGod]

У тебя её нет в репе

теперь есть

 

[RareScrap]

Ув. тов. @JustAGod, в моем коде есть набор классов, предназначенный для тестирования мода на этапе разработки. Я держу их в модуле main в виде отдельного пакета. Могу ли я при помощь вашей вырезалки убирать их из бинарника при билде обфусцированного мода, но оставлять при запуске в IDE?

 

[will0376]

но оставлять при запуске в IDE

Так никто и не убирает ничего в ИДЕ. вырезалка только при билде вырезает...

 

[RareScrap]

Развертывание и настройка сделаны уж очень сложно. Я уверен что вырезалку можно подключать проще.

 

[Dahaka]

Ув. тов. @JustAGod, в моем коде есть набор классов, предназначенный для тестирования мода на этапе разработки. Я держу их в модуле main в виде отдельного пакета. Могу ли я при помощь вашей вырезалки убирать их из бинарника при билде обфусцированного мода, но оставлять при запуске в IDE?

Нужно добавить третью сторону, пометить этой аннотацией пакет и не включать её в серверный и клиентский билд.

 

[Dahaka]

Было бы прикольно засунуть этот плагин в какой-нибудь maven rep.

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

Было бы прикольно иметь дефолтную настройку. Явно переопределять classesCache скорее всего никому не понадобится, поэтому почему бы не оставить аргумент по-умолчанию? Если такая фича есть, то круто. Билды по-умолчанию тоже можно было бы генерировать, потому что в 99% случаев будет конфиг именно из примера. И разве classesDirs нельзя определить в рантайме? По крайней мере, если брать классы из tasks.compileJava.destinationDir, то там будут и классы джавы, и классы котлина.

 

[RareScrap]

Было бы прикольно засунуть этот плагин в какой-нибудь maven rep.

Категорически согласен. Включать сорцы вырезалки в проект нет никакого желания

 

[JustAGod]

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

Это все к тому же вопросу про то как вырезать классы при любом билде и не только.
Это штука в обычной ситуации, скорее всего, никому не понадобится, но рассмотрим случай, который образовался на одном проекте.
Там внезапно появилось 3 стороны в одном моде: сервер, клиент и бэкенд. Изначально 3ей стороны не было, и поэтому логично было, что классы, не помеченные ни одной аннотацией, не подлежали вырезанию, но все изменилось.
Сделано было все так, что при билде бэкенда нужно было веразать весь код, который к нему не относился. Ни у кого не было желания помечать каждый класс аннотацией со сторонами клиент и сервер. Проще было пометить пару папок, что мол они должны быть на бэкенде. Таким образом выходит, что при таком кейсе primalSides просто таки необходимы.

По крайней мере, если брать классы из tasks.compileJava.destinationDir, то там будут и классы джавы, и классы котлина.

Хз с каких пор так. Лично я собаку съел на этом, када вонюче жава 9 не хотела компилироваться из-за разных модуль пазов. Но вапще я могу сделать жавовское место компиляции по дефолту, да.

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

угу согласен

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

Не совсем понимаю как это сделать красиво.

Было бы прикольно засунуть этот плагин в какой-нибудь maven rep.

Да я уже давно думаю над этим. Никада такого не делал и потому для меня это пока немного рокет саенс. Находил какие то платные штуки, но для такого я слишком жмот, сорри. Разберусь после 13го вопщем то(мун)

 

[RareScrap]

Никада такого не делал и потому для меня это пока немного рокет саенс

Я могу помочь тебе с этим, если есть желание

 

[hohserg]

Никада такого не делал и потому для меня это пока немного рокет саенс. Находил какие то платные штуки, но для такого я слишком жмот, сорри.

Попробуй jitpack.io

 

[JustAGod]

Я могу помочь тебе с этим, если есть желание

Да я и сам разберусь, скорее всего.

Попробуй jitpack.io

Кажется, эта штука умеет только с гитхабом работать, а у меня есть навязчивое желание остаться именно на гитлабе(мун)

 

[hohserg]

Все пашет

 

[JustAGod]

а ну прекрасно тогда лол
надо б провести рефакторинг шоб заработало

 

[MJaroslav]

JitPack тру вариант.

Но я видел статью, где из гит репозитория делали мавен репозиторий :yoba:

 

[JustAGod]

JustAGod обновил(а) ресурс автовырезалка новой записью:

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

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

Узнать больше об этом обновлении...

 

[JustAGod]

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

Так вот, собственно, о самой обнове. Теперь вырезалка может удалять отдельный код, который завернут в лямбду. Чтобы это все заработало, нужно добавить в конфиг куттера следующее:

    invokes("lambda.Invoke") {
        server {
            sides = [serverSide]
        }
        client {
            sides = [clientSide]
        }
    }

Где
lambda.Invoke - это класс, в котором присутствуют методы, которые принимают лямбду своим единственным параметром

server {
    sides = [serverSide]
}

- название метода и стороны, на которых его вырезать не нужно. Ни в коем случае не думайте, что имя server тут хоть что-нибудь значит. Чувствуйте себя свободно в выборе названия.

client {
    sides = [clientSide]
}

То же самое только пример для клиента

Теперь чуть-чуть про костыли,которые тут пришлось применить.
Класс должен выглядеть вот так

public final class Invoke {

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

    public static void client(ClientInvoke r) {
        r.run();
    }
}

Из важного: обязательно нужно заводить свой функциональный интерфейс для каждой стороны, каждый метод обязательно должен быть статичным и содержать только один аргумент.
Мне все равно на код внутри каждого из этих методов. Тут можете чувствовать себя свободно(мун)
Как это собственно применяется

        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 как пока наиболее стабильную. Конечно любые баг репорты я буду стараться закрывать как можно быстрей, но все же.