Что такое project sdk

Что такое project sdk

Generally, SDKs are global. It means that one SDK can be used in multiple projects and modules. After you create a new project and define an SDK for it, you can configure modules in this project to inherit its SDK. You can also specify an SDK for each module individually. For more information, refer to Change module SDK.

Supported SDKs

Define an SDK

Configure global SDKs

Set up a project SDK

If the necessary SDK is already defined in IntelliJ IDEA, select it from the SDK list.

Set up a module SDK

If the necessary SDK is already defined in IntelliJ IDEA, select it from the Module SDK list.

If you want a module to inherit a project SDK, select the Project SDK option from the Module SDK list.

Java Development Kit (JDK)

To develop applications in IntelliJ IDEA, you need a Java SDK (JDK). A JDK is a software package that contains libraries, tools for developing and testing Java applications (development tools), and tools for running applications on the Java platform (Java Runtime Environment — JRE).

The JRE can be obtained separately from the JDK, but it’s not suitable for application development, as it doesn’t have essential components such as compilers and debuggers.

The bundled JRE is used for running the IDE itself, and it’s not sufficient for developing Java applications. Before you start developing in Java, download and install a standalone JDK build.

Due to the changes in the Oracle Java License, you might not have the rights to use Oracle’s Java SE for free. We recommend that you use one of the OpenJDK builds to avoid potential compliance failures.

In IntelliJ IDEA, you can download a JDK package right from the IDE, or you can manually download the necessary JDK distribution and define it in the IDE.

For a manual download, use any available distribution that you like, for example:

If you don’t know which distribution to choose, and you don’t have specific requirements that instruct you to use one of the existing distributions, use Oracle OpenJDK.

Set up the project JDK

If the necessary JDK is already defined in IntelliJ IDEA, select it from the SDK list.

Apply the changes and close the dialog.

If you build your project with Maven or Gradle, refer to Change the JDK version in a Maven project and Gradle JVM selection respectively for more information on how to work with JDKs.

Configure SDK documentation

You can add SDK documentation to IntelliJ IDEA so that you can get information about symbols and method signatures right from the editor in the Quick documentation popup.

You can also configure external documentation by specifying the path to the reference information online. External documentation opens the necessary information in a browser so that you can navigate to related symbols and keep the information for further reference at the same time.

Specify SDK documentation paths

To view external SDK documentation, configure the documentation URL first.

Select the necessary SDK version if you have several SDKs configured, and open the Documentation Path tab on the right.

Apply the changes and close the dialog.

Access SDK documentation offline

If you work offline, you can view external documentation locally.

Download the documentation package of the necessary version.

The documentation package is normally distributed in a ZIP archive that you need to unpack once it is downloaded.

For example, you can download the official Java SE Development Kit 14.0.1 Documentation and unzip it.

Select the necessary JDK version if you have several JDKs configured, and open the Documentation Path tab on the right.

Apply the changes and close the dialog.

When the documentation is configured, you can open it in the editor.

Источник

Что такое IDE и SDK? «Страшные» термины простыми словами

Современному человеку нередко приходится сталкиваться с различными малопонятными терминами из мира компьютеров, даже если он никогда не занимался и не планирует заниматься программированием.

Пусть даже вы хотите сосредоточиться исключительно на вопросах бизнеса, взвалив всю нагрузку по созданию приложений для вашей компании на разработчиков, некоторое понимание совершаемых ими действий будет совсем не лишним. Ранее мы уже рассматривали такие понятия, как API и Webhook. На этот раз хотелось бы раскрыть тему SDK и IDE.

Что такое IDE?

Термин IDE расшифровывается как Integrated Development Environment или «интегрированная среда разработки» (в русском языке иногда используется аббревиатура ИСР). Это набор инструментов, позволяющих создавать приложения. Иными словами, если говорить очень просто, то IDE – это программа, в которой создаются другие программы.

Изначально, на заре развития компьютерной техники, программисты записывали код на бумаге, после чего его вводили в ЭВМ при помощи перфолент или перфокарт (кстати, и то и другое также изготовлялось из бумаги). Одна малейшая ошибка могла привести к неработоспособности программы. Со временем, когда вычислительная техника достигла определённого уровня развития, появилась возможность редактирования кода прямо на экране терминала. А несколько позже появились и средства, позволяющие набирать текст программы на экране, избегая «бумажной волокиты».

IDE – это не специализированные текстовый редактор!

На самом деле, это куда более сложный инструмент. Сама по себе среда разработки обычно включает в себя и специализированный текстовый редактор, «заточенный» для работы с кодом. Но для полноценного программирования этого, конечно же, недостаточно.

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

По факту же современные IDE включают в себя множество самых разнообразных инструментов, призванных решать те или иные задачи. Например, там могут присутствовать инструменты для визуальной разработки, позволяющие буквально «нарисовать» программу, используя для этого специальный графический редактор.

Самые первые IDE имели простой (даже скажем больше, примитивный) текстовый интерфейс. Затем появились и решения с графическим интерфейсом. Некоторые современные среды разработки отличаются высокой сложностью, и подчас просто чтобы разобраться в них, даже опытному разработчику необходимо сначала прочитать соответствующую документацию.

Какие сегодня существуют IDE

Современные IDE могут быть бесплатными или платными. Существуют также и условно бесплатные решения. В последнем случае среду разработки можно просто скачать в Сети и тут же начать использовать. Но при этом она будет иметь ряд ограничений. Например, в бесплатном варианте популярная среда разработки IntelliJ IDEA позволит работать только с Java, в то время как оформление подписки откроет доступ к ещё целому ряду языков программирования.

Тут уместно будет привести несколько примеров популярных IDE (в алфавитном порядке):

Естественно, что это только некоторые примеры. По факту же количество IDE в мире значительно больше.

Какой IDE самый лучший?

Сам по себе вопрос некорректный. На сегодняшний день в мире существует немало самых разнообразных IDE, предназначенных для решения самых разных задач. И выбор зависит от разных факторов, из которых самым главным является список стоящих перед программистом задач.

Например, если планируется создавать программные продукты для экосистемы Apple, то вполне логичным выглядит решение воспользоваться таким решением, как XCode. Разработчики под Windows нередко используют Visual Studio. А среди пишущих на языке программирования Python популярность завоевала среда разработки PyCharm. Список примеров можно продолжать.

Влияет также и то, насколько опытным является разработчик. Так, новичка вполне может удовлетворить среда разработки Code::Blocks – с открытым кодом, для разных платформ, простая и нетребовательная к ресурсам, предназначенная для тех, кто пишет на C, C++ или Fortran (да, этот динозавр всё ещё используется, причём довольно активно). Однако целый ряд ограничений делает невозможным применение данного решения в сложных проектах, профессионалам оно точно не подойдёт.

Немалую роль могут сыграть и личные предпочтения. Например, человеку может банально не понравиться внешний вид среды разработки. Иными словами, можно посоветовать разработчику использовать ту или иную IDE, в зависимости от стоящих перед ним задач, но назвать однозначно самую лучшую – невозможно.

Что такое SDK и чем он отличается от API

Как показывает практика, понять термин SDK новичку бывает несколько сложнее, нежели описанный выше IDE. Нередко также возникают сложности с пониманием различий между SDK и API. И действительно, эти термины часто используются вместе. Но синонимами они при этом не являются!

Простая расшифровка термина – Software Development Kit, набор средств разработки – мало что объясняет. Попробуем объяснить всё максимально простым языком (для начала рекомендуем ознакомиться с нашим материалом про API, если вы ещё не сделали этого ранее).

Итак, SDK – это набор средств, при помощи которого разработчики могут создавать программное обеспечение под самые разные платформы. Данный набор может включать в себя самые разнообразные инструменты (утилиты, библиотеки, драйверы, документацию, фрагменты готового кода и многое другое), позволяющие писать и внедрять приложения. При этом SDK включает в себя и API (а иногда и сразу несколько), который используется для взаимодействия с платформой, под которую и пишется софт.

Простыми словами про SDK

Представьте себе дом, к которому подведена электрическая проводка, для которой существует подробная спецификация (описание). Вот данная спецификация и является API. А SDK – это набор инструментов и комплектующих, позволяющий вам создавать самые разнообразные приборы, которые вы потом сможете подключать к этой электрической сети. То есть описание сети (платформы, для которой мы пишем приложения) важно, но одним только этим описанием для создания приборов не обойтись.

Приведём и другой, более «программистский» пример. Так, язык программирования, который используется при написании программы, можно представить себе как API. А в качестве SDK при этом будут выступать инструменты для написания и отладки кода.

Конечно же, оба этих примера очень поверхностны, их задача – лишь передать суть. По факту же, для глубокого понимания таких понятий, как SDK и API необходимо обладать специальными знаниями и опытом. Иначе говоря, быть разработчиком.

Откуда берётся SDK

Набор средств разработки предоставляется создателем платформы, заинтересованным в том, чтобы под неё создавались приложения. Обычно его можно просто скачать из интернета, нередко бывает и так, что SDK распространяется совершенно бесплатно. Это делается для того, чтобы заинтересовать сторонних разработчиков в использовании платформы, убедить их создавать приложения для неё.

Но SDK могут быть предназначены исключительно для внутреннего применения и недоступны для сторонних разработчиков. В таком случае программист получает доступ ко всему необходимому лишь после трудоустройства в контору, создавшую платформу.

Часто SDK имеют лицензию, с которой нужно считаться при написании приложений. Например, проприетарные наборы не подходят для создания программ с открытым кодом.

Порой первая буква в аббревиатуре SDK меняется для того, чтобы сделать название более близким к тому, для чего именно создавался данный набор. Например, DDK или Driver Development Kit – набор средств, предназначенный специально для написания драйверов устройств. Впоследствии компания Microsoft пошла ещё дальше, заменив термин DDK на WDK – Windows Driver Kit. Или другой пример – JDK или Java Development Kit. В данном случае речь идёт о наборе средств разработки для языка Java.

Apix-Drive — универсальный инструмент, который быстро упорядочит любой рабочий процесс, освободив вас от рутины и возможных денежных потерь. Опробуйте ApiX-Drive в действии и убедитесь, насколько он полезен лично для вас. А пока настраиваете связи между системами, подумайте, куда инвестируете свободное время, ведь теперь его у вас будет гораздо больше.

Источник

Доступные пакеты SDK

Доступны следующие пакеты SDK:

Можно также создать собственный пакет SDK и распространять его с помощью NuGet.

Файлы проекта

Чтобы указать пакет SDK, который содержится в NuGet, добавьте версию в конец имени или укажите имя и версию в файле global.json.

Другим способом указания пакета SDK является элемент Sdk верхнего уровня.

На компьютере Windows файлы Sdk.props и Sdk.targets можно найти в папке %ProgramFiles%\dotnet\sdk\[версия]\Sdks\Microsoft.NET.Sdk\Sdk.

Предварительная обработка файла проекта

Включения и исключения по умолчанию

Ошибки сборки

Если вы явным образом определите любой из этих элементов в файле проекта, скорее всего, произойдет ошибка сборки NETSDK1022 с примерно таким сообщением:

Чтобы устранить такую проблему, выполните любое из следующих действий:

Если вы хотите указать файлы, которые нужно публиковать вместе с приложением, для этого можно по-прежнему использовать привычные механизмы MSBuild (например, элемент Content ).

Неявные директивы using

Неявные директивы global using добавляются для проектов, которые используют один из следующих пакетов SDK:

Директива global using добавляется для каждого пространства имен в наборе стандартных пространств имен, в зависимости от конкретного пакета SDK для проекта. Эти пространства имен по умолчанию показаны в следующей таблице.

Неявные ссылки на пакет

При необходимости можно отключить неявные ссылки на пакеты с помощью свойства DisableImplicitFrameworkReferences и добавить явные ссылки только на необходимые платформы или пакеты.

События сборки

Настройка сборки

Пользовательские целевые объекты

Чтобы добавить пользовательские целевые объекты или свойства сборки, нужно поместить файлы в форме

.props (например, Contoso.Utility.UsefulStuff.targets ) в папку build проекта.

Источник

SDK тебе, SDK мне, SDK всем! Как делать SDK и зачем это нужно

Наша компания делает сервис для хранения и обработки данных с промышленных устройств (насосы, буры и прочая промышленная техника). Мы храним данные наших клиентов и предоставляем функционал для их анализа: построение отчетов, графиков и еще много чего.

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

И тогда мы поняли, что лучшим решением в данной ситуации будет разработать SDK и предоставлять его клиенту. Сразу же начал искать лучшие практики и рассуждения на тему разработки SDK и сильно удивился — в рунете об этом практически ничего нет, а в басурманских интернетах очень мало информации и она разрознена. Ну что ж, задача понятна, обдумана и реализована.

Пора определяться

Начнем с того, что определим, что такое SDK и зачем он может быть нужен.

SDK (от англ. software development kit) — комплект средств разработки, который позволяет специалистам по программному обеспечению создавать приложения для определённого пакета программ, программного обеспечения базовых средств разработки, аппаратной платформы, компьютерной системы, игровых консолей, операционных систем и прочих платформ. SDK использует преимущества каждой платформы и сокращает время на интеграцию.
…
Инженер-программист обычно получает SDK от разработчика целевой системы.

Что ж, логично. Простыми словами, SDK — это пакет библиотек, для того, чтобы клиент мог легко и быстро начать работать с вашей системой (в данной статье речь пойдет про наш сервис, но всё изложенное в статье применимо и к другим видам SDK) или выполнять однотипные действия.

Но, как и у любого подхода, у «Пути SDK» есть как преимущества, так и недостатки.

Преимущества

Высокая скорость интеграции нового клиента — вашим клиентам нужно писать меньше кода.

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

Предсказуемость поведения — использование одних и тех же библиотек приводит поведение систем к определенному стандарту, что сильно облегчает поиск и устранение ошибок и уязвимостей.

Качество кода — много где любят экономить на тестировании (жалко бюджета, горят сроки и прочие причины). Понятно, что в реальном мире покрыть тестами все участки проекта это учень трудоемкая задача. Но качественно протестировать все модули SDK, а затем использовать их — это путь повышения процента покрытия тестами, что приведет вас к снижению количества ошибок.

Документация — тот же сценарий, что и с тестами. Покрыть документацией весь проект достаточно проблематично. Переиспользование модулей SDK повышает процент покрытия документацией, что снижает порог вхождения новых сотрудников в проект и вообще помогает по жизни.

Все преимущества, по сути, это следствия самого главного — мы очень качественно пишем код один раз, а затем его переиспользуем.

Недостатки

Высокие требования к качеству кода SDK — следствие главного преимущества. Ошибка в SDK породит ошибки во всех системах, его использующих.

Установка ограничений — SDK — это набор библиотек для реализации стандартных сценариев. Иногда разработчики SDK полагают, что кроме реализации одного из предусмотренных сценариев клиенту ничего не потребуется, что клиенту проще сделать все с нуля самостоятельно, чем строить пьедестал из костылей для SDK.

Dependency hell и обновления — при расширении функционала (например, кастомизации решения под конкретного клиента), вы выпустите новую версию библиотеки. Но существуют зависимости, различные наборы версий библиотек у разных клиентов, и нужно очень тщательно следить за обратной совместимостью или строгим версионированием.

Когда SDK действительно нужен

У вас есть несколько стандартных сценариев, которые реализуются заново из раза в раз — собственно, наш случай.

Внутренние разработки — в разных проектах вы используете системы логирования, конфигурирования систем, работу с HttpRequest, БД, файлами? Выработайте внутренний SDK — набор библиотек для внутреннего использования. Вы в любой момент можете расширить функционал SDK, но скорость разработки новых проектов, процент покрытия тестами и документацией вырастет, а порог вхождения новых разработчиков снизится.

Когда SDK скорее всего будет лишним

Сценарии использования не определены или постоянно меняются — оставьте реализацию кастомных решений клиентам и помогите им. Не надо городить вундервафлю, которая будет только мешать. Очень актуально для молодых компаний и стартапов.

Вы не умеете делать качественно — у меня для вас плохая новость: пора учиться. Но отдавать кривое решение клиенту это очень, очень неправильно. Клиентов надо уважать, в конце концов.

Итак, мы определились, что такое SDK, с его преимуществами и недостатками и когда он нам нужен. Если после этого вы поняли, что SDK действительно нужен — приглашаю вас встать на «путь SDK» и разобраться, а каким он должен быть и как его, черт подери, делать?

«А вы любите Lego?» — Модульность

Представим все возможные сценарии использования SDK (вы же уже определились, зачем он вам нужен, правда?) и сделаем по библиотеке на сценарий. Чем не выход? Но это плохой подход, и так мы делать не будем. А будем так:

Например, с учетом специфики задачи, нам необходимо, чтобы вся логика задавалась из конфигов. Реализуем модуль работы с конфигами (чтения, записи, обновления, валидации и обработки конфигураций) и будем использовать его во всех остальных модулях.

А для реализации стандартных сценариев мы действительно сделаем модули — этакие «управляющие» модули, каждый из которых реализуют один конкретный сценарий, используя другие модули того же SDK. Таким образом для реализации стандартных сценариев клиент должен лишь подключить управляющий модуль сценария (а он сам подтянет все зависимости), а для реализации нестандартных — используем базовые модули, так же переиспользуя код.

Именно этим обусловлено то, что SDK не должен быть одной библиотекой (хотя очень хочется, понимаю. Ведь когда весь SDK в одной библиотеке, можно забыть о зависимостях и всем, что с ними связано), а быть комплектом библиотек. Дополнительным плюсом данного подхода будет уменьшение «веса» программы клиента — он будет тянуть тяжеловесный SDK, а подтянет только необходимые модули.

Но не стоить плодить модули как попало, ведь чем больше модулей, тем больше головной боли от их зависимостей! Т.е. важно правильно разбить логику на модули, соблюдая баланс между решением «все в одном» и «на каждую функцию свой модуль».

«А что, так можно было?!» — Универсальность

Предоставьте клиенту различные интерфейсы для работы с вашей библиотекой. Приведу пример:

Если предоставить только синхронную версию, то при реализации асинхронного приложения клиент вынужден будет делать асинхронные обертки вашего синхронного метода. Если предоставить только асинхронную версию — ситуация похожа. Дайте клиенту и то и другое и он скажет вам спасибо.

Приятным плюсом будут дженерики. Например, у нас есть класс для работы с конфигурациями, реализующий методы упаковки конфига в строку, загрузки конфига из файла и т.д. Конфигурация конкретного модуля будет наследоваться от нашего базового класса, но для работы с новым классом нам необходимо также предоставить методы распаковки.

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

«Родитель 1, Родитель 2, Дети[ ]» — Именование

Что самое трудное в работе программиста? Выдумывать имена для переменных.

И тем не менее… Правильное именование модулей, классов, свойств и методов сильно помогут тем, кто будут с вашим SDK работать. Пример, не требующих комментариев:

Kinect 2.0 SDK example

Всё ясно из названий классов и методов. А если есть автодополнение кода в вашей IDE, то зачастую можно и в документацию не заглядывать, если и так все понятно.

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

Документация, в SDK, как правило, проста и лаконична. Она обычно делится на две части: Tutorial — пошаговый курс в стиле “Построим город за 10 минут” и раздел Reference — справочник по всему, что можно сделать с помощью данного SDK.

Мы выбрали самый простой путь — summary + articles. Мы добавляем Xml атрибуты для методов и классов, которые светятся в intellisense как подсказки. Используя Docfx мы строим документацию по этим атрибутам и получаем подробную и удобную документацию, которую дополняет статьями, описывающими сценарии использования и примеры.

«— Чтобы чисто было! — Как я буду вилкой-то чистить?» — Тестирование

Что можно сказать про тестирование в рамках обсуждения SDK… Must have! Лучшим решением будет TDD (несмотря на то, что я негативно отношусь к данному подходу, в данном случае я решил использовать именно его). Да, долго. Да, нудно. Но зато в будущем вы не повеситесь от постоянных падений SDK на стороне и следствий этого падения.

Основной сок ситуации заключается в том, что отдавая SDK клиенту вы теряете контроль: вы не можете быстро пофиксить ошибку, сложно эту самую ошибку найти, да и выглядеть в такой ситуации вы будете достаточно глупо. Поэтому — тестируйте. Тестируйте лучше. И еще раз. И, на всякий случай, протестируйте ваши тесты. И тесты тестов. Так, что-то я увлекся, но важность тестирования SDK, надеюсь, понятна.

«Жертва, которая не могла противостоять своему прошлому, была поглощена им» — Логи

Поскольку вы отдаете SDK сторонней компании, в следствие чего теряете контроль над ситуацией, в случае ошибки (на этапе тестирования вы все-так решили «и так сойдёт», да?) вас ждет достаточно долгий и болезненный процесс поиск этой самой ошибки. Именно тут вам на помощь придут логи.

Логируйте все, абсолютно все, а в случае возникновения ошибки запросите у вашего клиента логи. Таким образом вы сэкономите много времени и сможете не потярять лицо перед клиентом.

«Alarm! Achtung! Attention!» — Ошибки

Долго размышляя на тему ошибок я пришел к интересному выводу — ни один метод в вашем SDK не должен отдавать ошибку, не описанную в документации. Согласитесь, очень неприятно, когда вы подключаете стороннюю библиотеку для работы с HttpRequest, а она вываливает на вас какой-нибудь NullPointerException и StackTrace, который уводит в недра библиотеки. И вам приходиться погружаться в эти самые «недра», пытаясь понять, насколько глубока кроличья нора, и в чем, собственно, проблема.

Поэтому я предлагаю следующее решение — декларируйте закрытый список возможных исключений и документируйте их. Но, т.к. нельзя быть увереннным, что вы предусмотрели все, оберните метод в try-catch, а пойманную ошибку — в задекларируему. Например, ConfigurationException, который будет содержать InnerException — пойманную ошибку. Это позволит стороннему разработчику поймать все возможные ошибки, но в случае чего быстро разобраться в чем дело.

Версии или «как не укусить себя за хвост»

Во избежание проблем в будущем крайне рекомендую использовать строгое версионирование. Выберете подходящую вам систему построения версий и используйте ее. Но если новая версия библиотеки не имеет обратной совместимости — это необходимо указать. Как это разруливать — думать вам. Но подумать об этом точно стоит.

«Паровозик, который смог» — Deploy

Необходимость актуальности документации и версий порождают требование к корректности деплоя. В своем решении мы используем следующее решение (костыли, но работают).
Когда надо выпустить нвый релиз, разработчик дергает bat’ник с указанием номера релиза, а затем батник:

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

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

«-А так можешь? — Фигня. Смотри как надо!» — Примеры & toolkit

Заключение

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

Спасибо за прочтение, буду рад вашим комментариям. Надеюсь, эта статья будет для вас полезной.

Источник