Как мне выложить свой репозиторий?

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

Само приложение имеет два компонента - достаточно стандартное веб-приложение Java, которое взаимодействует с базой данных, и компонент бэкэнда, также Java, который опрашивает базу данных и запускает длительные задачи обработки на основе того, что он находит - по сути, БД. используется в качестве очереди. Код разбит на три пакета:

  1. org.blah.common - код, такой как DAO, который используется веб-приложением и серверной частью
  2. org.blah.webapp - веб-приложение; это зависит от org.blah.commonи строит в .war файл.
  3. org.blah.backend - бэкэнд процесс; это зависит от org.blah.commonи строит в tar-файл, содержащий jar и несколько скриптов.

Я также хотел бы получить другие части конфигурации Tomcat и Apache в SVN.

Прямо сейчас все три пакета находятся в SVN под src dir, и есть сценарий ant с разными целями, которые создают разные части. Это все немного неаккуратно - свойство svn: ignore стало довольно большим, и не сразу видно, что скрипты в одном каталоге связаны с кодом в каком-либо пакете ниже srcв то время как те в другом для запуска и остановки кота.

Меня привлекает стандартная раскладка каталогов maven, но я раньше этим не пользовался. Я придумал это:

common/
    src/
        main/
            java/
            resources/
        test/
            java/
            resources/
    target/    # Not checked in
        common.jar
webapp/
    src/
        main/
            java/
            resources/
            webapp/
        test/
            java/
            resources/
    target/    # Not checked in
        webapp.war
backend/
    src/
        main/
            java/
            perl/
            resources/
        test/
            java/
            resources/
    target/    # Not checked in
        backend.tar
infra/
    tomcat/
        bin/
        conf/
    apache/
        bin/
        conf/
db/
    tables/
    procs/
    triggers/

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

Так:

  • Кажется ли это разумным способом размещения хранилища? Есть ли что-нибудь, что может сбить меня с толку?
  • Будет ли это очевидно для новичков в приложении?
  • Будет ли это совместимо с Maven, если я решу использовать его? (Я знаю, что теоретически вы можете заставить maven работать с любым макетом, но я считаю, что они рекомендуют стандарт по причине.)
  • У IDE будут какие-то проблемы с этим? (В зависимости от того, на каком компьютере я работаю, я использую intellij или eclipse. Другие члены моей команды - у которых нет мнения по этому поводу - используют netbeans.)

3 ответа

Решение
  • Кажется ли это разумным способом размещения хранилища? Есть ли что-нибудь, что может сбить меня с толку?

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

  • Будет ли это очевидно для новичков в приложении?

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

  • Будет ли это совместимо с Maven, если я решу использовать его? (Я знаю, что теоретически вы можете заставить maven работать с любым макетом, но я считаю, что они рекомендуют стандарт по причине.)

Кажется, что он почти полностью совместим с Maven (за исключением того, что я уже говорил, но это не проблема). И да, очевидно, что проще, если вам не нужно изменять конфигурацию Maven и использовать соглашения по умолчанию. Обратите внимание, что вы можете настроить сборку Maven параллельно сборке Ant для плавного перемещения.

  • У IDE будут какие-то проблемы с этим? (В зависимости от того, на каком компьютере я работаю, я использую intellij или eclipse. Другие члены моей команды - у которых нет мнения по этому поводу - используют netbeans.)

Прошло много времени с тех пор, как я не импортировал проект Ant в одну из этих IDE, но я думаю, что все они должны быть в состоянии справиться с этим макетом (на 100% уверен при использовании Maven). Лучший способ ответить на этот вопрос, конечно же, провести тестирование:)

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

Кроме этого я не вижу никаких проблем с этим макетом. За исключением каталога tomcat, это стандартная раскладка maven.

Единственная проблема, с которой я столкнулся src каталоги, которые будут иметь исходный код внутри, а не как макет выше. Однако я думаю, что это способ мышления, который я мог бы преодолеть довольно быстро, особенно в Eclipse.

Другие вопросы по тегам