SVN, Eclipse, Spring

– Spring framework is great. No, seriously. If you are stuck, there is a lot of useful tutorials on the net, but if you prefer a hard copy, my choice is the ‘Spring in action’.

– If you use SVN on Windows, I recommend TortoiseSVN as my client of choice. It seamlessly integrates into Windows explorer and very light-weight.

– Subclipse suxxxx big time. The only thing I use it for is to commit changes directly from Eclipse, and I don’t do that often.

– It seems that a quick-and-dirty way to store Eclipse projects is to commit entire .metadata. Looks like WTF to me.

9 thoughts on “SVN, Eclipse, Spring

  1. Правильный способ хранить Eclipse-овские java-вские проекты в VCS – это использовать maven и плагин maven-eclipse к нему. Т.е. в репозитории хранить maven-овский проект, а в эклипсовский превращать командой “mvn eclipse:eclipse”. Или у тебя не Java-проекты?

  2. Java, java.
    Да, если у тебя maven build. Дело в том, что половина кода была под ant, четвертинка – сделана прямо в Еклипсе, а еще четвертинка – в мавене. Потом фаундер переделал три четверти кода прямо под эклипс, а я свою четвертинку так в мавене и держу. Founder категорически против антов и мавенов, а мне проще подстроиться, чем убеждать его, что мавен гораздо удобнее стандартного джаба билдера Эклипса.

    Кроме того, если каждый раз генерить проект заново через subclipse или mvn eclipse:eclipse, теряется всякая мелкая удобная хрень типа run configurations & custom build paths.

    Не могу тебе передать, как меня эти потери достали уже. А при сохранении .metadata – договорились использовать общий путь с:\ВасяПупкин – и вуаля.

  3. Ну, если фаундер категорически против – тогда конечно. Но миграция с анта на чистый эклипс – это всё равно что-то странное. Зачем?

    Потери run configurations и т.д. – это да, неудобно. Не знаю, как на Eclipse (я с ним достаточно мало работал), а на IDEA обходил это тем, что не генерил проект полностью с помощью “mvn idea:idea” (который вызывает три действия – project, module и workspace), а исполнял только “mvn idea:project”, “mvn idea:module”, т.е. без “mvn idea:workspace”. А так как IDEA хранит свои run/debug configurations как раз в workspace (*.iws), то всё было отлично.

    А пути, хранимые в VCS должны быть только относительные :-) Если необходимо использовать абсолютные пути (например для указания, куда установлена какая-нибудь тулза), то они должны прописываться на конкретной машине – либо в глобальном конфиге, либо в переменных окружения.

    PS. Но это ещё что – я тут недавно закончил бороться с системой сборки одного проекта, где надо было последовательно выполнять следующие действия (после выкачивания из CVS(!)): 1) установить cygwin; 2) прописать в переменных окружения путь до проекта(!); 3) собрать с помощью идеи пару модулей; 4) выполнить ant-task; 5) запустить несколько bash-скриптов(!) (для этого и был нужен cygwin). Перевёл всё это на ant (с грозным обещанием мигрировать потом на maven %-)) и теперь для сборки проекта нужно только запустить один ant-task и всё. И такое счастье наступило, что ты не поверишь :-). Сейчас ещё наконец-то мигрируем с CVS на что-нибудь более человеческое (я продвигаю mercurial ;-)) – и наступит вообще полная нирвана :-).

  4. Вот такой вот дядя :)

    А чем mercurial хорош? Я с ним не работал ни разу.

  5. Да я знаю, что относительные. Попробуй это еклипсу сказать.

  6. Про mercurial вот неплохой обзор – http://www.developers.org.ua/archives/author/piranha/ . Это если на русском – на английском, понятно, гораздо больше, но навскидку не скажу :-)

    Если вкратце, то плюсы DVCS вообще: 1) быстрый checkout/update; 2) возможность организации цепочки репозиториев с code review на каждом уровне (и вообще возможность организовать любой рабочий процесс); 3) с локальным репозиторием гораздо больше возможностей для локальных экспериментов; 4) меньшая зависимость от сети – многие операции её вообще не требуют; 5) более грамотно сделанный branch/merge – так как это базовая операция в DVCS, то и сделать её надо было на отлично.
    Плюсы конкретно Mercurial по сравнению с Git – 1) нормальная архитектура (я как узнал, что git – это по сути набор shell-скриптов – чуть в осадок не выпал) и как следствие более лёгкое портирование на другие системы, в частности на windows (git для windows есть только в составе cygwin, ну или нестабильная версия на базе msys); 2) TortoiseHg; 3) удобный, легко запускающийся (hg serve), не требующий никаких пререквизитов web-интерфейс.

    Ну а вообще – http://www.google.com/search?q=mercurial bazaar git ;-)

  7. Хорошо пишеш, молодец.
    зы. Статья понравилась. Самому что ли завести блог? :) Давно хочу, да как то руки не доходят.

Leave a Reply

Your email address will not be published. Required fields are marked *