Кем занят порт?

For Yosemite (10.10) and El Capitan (10.11) and macOS Sierra (10.12):

sudo lsof -iTCP -sTCP:LISTEN -n -P

Сравнение Flyway и Liquibase

http://stackoverflow.com/a/37411404/1499445

I already used both tools and so, in view, these are the main differences.

Flyway

1. Easy to configure - you just need a folder location and keep a name syntax V1__file.sql,...
2. SQL-based, but you need to write the right syntax of your specific database engine (Mysql, DB2,...)
3. Is Java based so adding custom configuration to clean, execute etc. is easier.

Liquibase

1. Need a main file "changelog" to keep track of all executed changesets.
2. Is XML based, so you need to use specific liquibase tags to create SQL code. This is perfect to migrate your code to a different DB engine: you won't need to change anything, and just the DB driver will tell liquibase how to translate from XML tags to the right SQL syntax.
3. If you use the sql tag from liquibase, then you won't take advantage of point 2, so it would be better to use Flyway instead.
4. Liquibase provides a jar to migrate an existing DB to all needed XML files automatically, so you don't need to work manually on them. Quite useful.

Now it is up to you to decide what you need for your project, whether you need to migrate to a different DB engine in the future etc.

Чем управляет dependencyManagement?

Секция управляет решением споров версий зависимостей, которые в проекте не явные, а подтянулись как зависимости зависимостей.

Dependency mediation очень часто не подходит как готовое решение зависимостей.

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

Пример

Проект:
- Зависимость1
- Зависимость2

Зависимость1:
- Подзависимоть11 -> Подзависимоть111-> Общаязависимость(версия: 2)

Зависимость2:
- Подзависимоть21 -> Общаязависимость(версия: 1)


Значит в результате у нас в проекте окажется версия 1.


Иногда это совсем не подходит, и тогда и приходит на выручку секция:

<dependencyManagement<
....
</dependencyManagement>

В ней мы явно можем определить нашей общей зависимости необходимую версию. И вообще все версии вложенных и прямых зависимостей определить здесь.

Чудесная коцепция BOM ( bill of materials) - ведомость материалов. По которой мы в нашем проекте создаем артефакт типа pom, который содержит все версии артефактов, которые мы собираемся использовать по проекту(в разных его модулях). И такой артефакт мы указываем в в секции dependencyManagement под скоупом import(такой скоуп можно указывать только на артефакты pom). По сути BOM содержит только dependencyManagement секцию и не содержит секции dependencies - этот артефакт не приносит никаких реальных зависимостей, а только определяет версии для тех, которые мы будем подтягивать в наших модулях.