Пока останется. Но зачем делать на connect если forge секьюрней

Но там видно будет. Может они цены разные сделают. Хз

Я понял так, что Connect останется уделом больших и сложных аддонов, если так можно сказать. А Forge - для более местечковых штук. Ну и вроде как они декларируют его как "снижающий уровень входа в разработку"

Я не так понял. Я так понял что enterprise говорит что connect не безопасный и поэтому появился forge

Ну может. Вот цитата их просто: We know that not all use cases lend themselves to the Forge model. Remote-hosted apps, like those built on our Connect framework, aren’t going anywhere – they’re part of the same future that we envision for our cloud ecosystem.

Вот отсюда - https://www.atlassian.com/blog/announcements/introducing-forge

Мне кажется, что connect станет бессмысленным. Потому что если нет, то народ будет девелипить один адон уже для трех экосистем

А это как то не очень

Коллеги, добрый день! возникла необходимость добавить в джире интерцепторы (перехватчики) на action. у кого-нибудь есть пример\ссылка на то, как это можно сделать в джире? я нагуглил только явадоки, но из них не очень понятно, как это работает именно в джире

буду очень благодарен

надо сделать класс, который будет экстендить нужный экшн, а потом добавить его в atlassian-plugin, указав в alias исходный экшн

спасибо большое, попробую

если имеется ввиду переход, не проще сделать листенер?

Нет. Есть http запрос на сервер, который возвращает данные. Но он возвращает лишние данные, мне нужно их фильтровать. На клиенте, насколько я искал, это сложно сделать. Появилась мысль обрезать ответ на сервере, возможно с помощью servlet filter

Привет, чат.
Спасибо, что ты есть. Ниже нестатья на хабре про "Java API vs SIL"
Надо мне было написать интегру Jira&whatever. А SIL тут уже был и  оказывается, в последних своих версиях он поддерживает http методы: может отправлять данные, а с помощью вызова скриптов через web позволяет получать и готовить данные, т.е. расширять Jira REST API по сути. Вместе с другими плюшками, имхо, плагин позволяет покрыть основные задачи жизнедеятельности среднего по размерам динозавра. Обработку экзотической логики можно вывести на стороний веб-сервис на питоне. Во всяком случае, я пока так делаю, и какбудтоработает: 100 строчек, ~100 юзеров конкретного модуля.
Рядом лежит историческая интеграция через бд созданная, видимо, заклинанием atlas-run. Это почти все что я о ней пока понимаю.
В связи с этим вопрос:
Why not? В каких случаях в 2020 году используют Java API и плагинописательство в повседневных задачах(не пишем Structure то бишь)? Секюрность, перформанс, независимость от cprime, поддержка кастомных исторических плагинов?
П.с. Кто не без греха - киньте аргументированной помидоркой

Если можешь не писать - не пиши

Так, помню, говорил Заратустра

Когда пишешь на Java, ты:
- в первую очередь практикуешь очень популярный энтерпрайз ЯП
- изучаешь устройство продукта atlassian
- не зависишь от плагина чужой компании, для работы твоего кода нужна только сама система
- можешь распространять свое решение на маркетплейсе (даже простую мелочь для удобства)
- имеешь одно место - плагин - со всей логикой, а не кучу мелких файлов sil, groovy etc
- имеешь юниттесты, CI и вот это все

А в целом да, можешь не писать,  не пиши. Но у тебя на основе вот таких мелких скриптов образуется некая логика обособленного продукта - банально удобнее держать все его исходники в одном месте.

Другими словами, сил холодный скил. Если только жира одмин с инстансом, где этот плагин, то гуд. Если нет, то лучше трогать универсальные штуки.