Вопросы для определения знаний Maven

Ответ 1

По моему мнению, "консультант Maven" должен:

• Хорошее понимание того, как Maven отличается от других инструментов построения, таких как Ant (Maven предоставляет "lingua franca" для управления проектами).
• Хорошее понимание принципов Maven: соглашения по конфигурации, макет по умолчанию, соглашения об именах, философия инструмента (один первичный вывод для каждого проекта).
• Хорошее понимание того, как работает Maven: от того, откуда идут конвенции (супер POM), жизненные циклы (основной, чистый, сайт), фазы, как плагины привязаны к фазам, влияние упаковки, и т.д.
• Знайте, какие профили и как их можно использовать для работы с разными средами, как их запускать.
• Знать, как использовать плагины, как их настроить, как подключить их к сборке maven.
• Узнайте, как работают репозитории, разница между локальными и удаленными репозиториями, каковы зависимости SNAPSHOT.
• Узнайте, как решаются зависимости, какие транзитивные зависимости, как их контролировать, какие области зависимостей, как использовать dependencyManagement.
• Знать, как реализовать проверки работоспособности кода, необходимые плагины (Checkstyle, PMD и плагины Findbugs), как реализовать различные типы тестов (единицу, интеграцию, функционал), как измерить охват, когда сбой сборки, когда сообщать.
• Знать, как настроить maven в корпоративной среде (используя общий репозиторий, настроить CI, компанию POM).
• Знайте, как обращаться с расширенными сценариями упаковки (с плагином сборки)
• Узнайте, как обрабатывать развертывание, различные протоколы, плагин развертывания, плагин выпуска, разрешение SNAPSHOT.
• Знайте, как настроить сборку Maven для проекта Java EE, как настроить сборку нескольких модулей, какие модули необходимы, как протестировать в среде разработки, как обрабатывать производственную среду.

Кто-то, у кого есть эти навыки, должен поставить вас на правильный путь (и, скорее всего, это достойный опыт Maven).

Ответ 2

Здесь есть много хороших вопросов, особенно те, которые предлагаются Pascal Thivent. Однако я задал бы другой вопрос:

Q: В чем разница между агрегацией и наследованием в Maven?
A: У вас может быть короткое объяснение здесь.

Ответ 3

Я бы предложил вам подумать о том, что вы хотите сделать с Maven, или почему вы хотите представить его в своих проектах. Возможно, спросите своего босса за его причины/цели при введении Maven.

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

Примеры 1
Цель: улучшить общее качество кода в проекте.

Вопрос: Как мы можем использовать Maven для улучшения нашего общего качества кода в проектах.

Возможный ответ: у Maven есть несколько подключаемых модулей, чтобы заставить /meassure качество кода в проектах, мы могли бы интегрировать их в наши скрипты почти мгновенно. (например, checkstlye, pmd, cobertura, xradar...)

Примеры 2
Цель: создание сценариев автоматического развертывания для нескольких целевых сред.

Вопрос: Как мы можем использовать Maven для автоматического развертывания артефактов в нескольких целевых средах.

Возможный ответ: мы могли бы использовать плагины Maven для развертывания (например, Cargo) и использовать профили maven для обработки нескольких конфигураций.

a.s.o.

Ответ 4

Я бы спросил:

• Опишите, что такое практика SCM?
• Опишите вашу идеальную инфраструктуру Maven (сервер, репозитории, CI, плагины, соглашения и т.д.)?

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

ИЗМЕНИТЬ

Maven - всего лишь одна часть общей стратегии управления конфигурацией программного обеспечения (SCM). Хороший консультант должен знать детали входа и выхода, но также знать, как он вписывается в общую картину. Так же, как вы ожидаете, что консультант Java EE будет экспертом в Java, но должен знать, что значит предоставлять корпоративное приложение клиенту.

В компании, в которой я работал, у нас был парень, ответственный за SCM, который был автором Maven. И его взгляд был более широким, чем "просто" maven. Он отвечал за создание продуктивной сборки, конфигурации и выпуска. Два примера:

• Мы были жестко кодированы номер версии в Java-коде, чтобы отображать ее в диалоговом окне "about" наших настольных приложений. Большую часть времени мы забыли изменить его после выпуска, что привело к несоответствию между фактическим номером выпуска и диалогом - большая проблема для интеграторов на месте. Это была плохая практика. Затем он установил что-то, чтобы номер выпуска в Maven был правильным в файле manifest и научил нас читать файл manifest с Java, чтобы гарантировать совпадение.

• Когда вы выпустили модуль, он написал script, чтобы не только создать приложение, но и закрыть соответствующую версию в системе билета (JIRA) и нажать заметки о выпуске в вики.

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

Ответ 5

Вот вопросы, которые я задал бы:

• Как бы вы применяли JDK6 для группы проектов?
• Как бы вы применяли конкретная версия плагинов?
• Каковы некоторые причины, по которым вы будет использовать сборку для сборки банки а не плагин jar?
• Опишите процесс освобождения Проект Java EE, состоящий из EJB, WAR файл и две служебные банки.
• Сколько репозиториев должно сервер внутреннего хранилища серверов и почему?
• Как бы вы структурировали проект POM, состоящий из N дочерних проектов, чтобы их можно было легко использовать в Eclipse?

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

Ответ 6

Если у вас есть роскошь, я предлагаю, чтобы консультант приходил на место в течение дня, дайте ему/ей существующий проект java, над которым вы работаете, и попросите его "mavenize" для вас. На следующий день сядьте с ним/им и попросите их объяснить, как скомпилировать, и построить банку (или войну).

Или, может быть, они придут на собеседование с проектом maven, чтобы продемонстрировать. Он должен скомпилировать и, по крайней мере, построить банку/войну, imo. Если они могут запускать модульные тесты, разверните их в tomcat, интегрируйте их с любой из различных фреймворков, таких как gwt, hibernate, spring и т.д., А затем еще лучше.