Skip to content

jdoka/resource-generator-plugin

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

4 Commits
 
 

Repository files navigation

Build Manager Plugin для генерации JNDI ресурсов

Проект создавался в учебных целях:

1.Разобраться как устроен программный API различных build manager-ов.
2.Разобраться как устроен программный API различных VCS.
3.Научиться работать с механизмом Java SPI.
4.Научиться настраивать ресурсы на различных контейнерах.

Плагин полезен для того чтобы хранить все JNDI ресурсы проекта в одном месте. Это место - билд файл проекта.

Как использовать gradle-plugin

Пример gradle.build

buildscript {
    repositories{
        mavenLocal()
        maven {
            url "http://..."
        }
    }
    dependencies {
        classpath "..."
    }
}
repositories {
    mavenLocal()
    maven {
        url "http://..."
    }
}

apply plugin:  'ru.dvd.devops.jndi-resources'

jndiResources {
    outputDir = "."
    printDiffRequired = true
    serverName = 'Jetty'
    jndi {
        dataSource {
            name = "jdbc/db"
            description = 'Доступ к БД'
            username = 'db_user'
            password = 'password'
            url = 'jdbc:oracle:...'
            driver = 'com.oracle.Driver'
        }
        connectionFactory {
            name = "jms/monitoringCF"
            url = "tcp://localhost:61616"
            description = 'Фабрика соединений с брокером очередей мониторинга'
        }
        queue {
            name = "jms/monitoringQueue"
            description = 'Очередь мониторинга'
            target = "Q.MONITORING"
        }
    }
}

Теперь запускаем таску

./gradlew generateJndiResources

и в файле jetty.xml появится раздел конфигурации с перечисленными ресурсами, а в файле diff.xml появится дифф по ресурсам относительно последнего теггированного коммита.

В репозитории имеется плагин для gradle и для maven(todo: maven-дореализовать).
Пока поддержка сервера - только Jetty, vcs - только git. Для поддержки других контейнеров(напр. Tomcat) или vcs(напр. svn) нужно подложить соответствующую написанную реализацию в classpath - все заработает автоматически(см. документацию spi).

Расширение функционала

Так, например, если ожидается использовать плагин для проектов svn, то необходимо:
1.Написать собственную реализацию интерфейса VcsOperations.
2.Упаковать в jar по правилам spi(https://docs.oracle.com/javase/tutorial/sound/SPI-intro.html)
3.Поместить данный jar в classpath плагина.
Больше ничего делать не нужно - плагин определит, под управлением какой vcs находится проект и соответствующим образом будет с ним работать. Если плагин обнаружит что он не умеет работать с текущей vcs, фича printDiffRequired = true будет проигнорирована. Аналогично функциональность плагина расширяется и в части поддержки новых серверов - отличие только в том, что автоматически плагин сервер не определит(это на подумать), поэтому в конфиге таски прописывается имя сервера.

Releases

No releases published

Packages

No packages published