Maven2::Part #4

Управление зависимостями (Dependency Management)

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

Maven::Part #3

Multimodule projects

каждый pom.xml файл описывает build workflow для одного проекта, в конечной фазе которого мы имеем один артефакт установленный в локальный и удаленный репозитарий. однако Maven позволяет легко и удобно работать с многомодульными проектами. при этом задача управления зависимостями между внешними библиотеками и между модулями внтури проекта полностью решается самим Maven.

Maven2::Part #1

Maven build workflow

полный список фаз Maven build workflow можно найти в документации. за каждую фазу отвечает какой-нибудь плагин из группы org.apache.maven. каждый из плагинов, кроме цели по-умолчанию, как правило умеет еще много полезных вещей. поэтому даже для стандартных плагинов нужно и важно читать документацию. встраиваться в ту или иную фазу довольно просто

...
 <plugin>
   <groupId>com.mycompany.example</groupId>
   <artifactId>maven-touch-plugin</artifactId>
   <version>1.0</version>
   <executions>
     <execution>
       <phase>process-test-resources</phase>
       <goals>
         <goal>timestamp</goal>
       </goals>
     </execution>
   </executions>
 </plugin>
...

Важно: все кастомные цели вызываются в конце выполнения указанной фазы. т.е. если перед фазой package необходимо что-то сделать с ресурсами, то для этой цели фаза должна быть prerare-package, а не package

отдельно следует отметить фазы цикла package, install и deploy.
package -- фаза, когда происходит сборка артефакта. стандартные плагины, для сборки артефактов, входящие в поставку Maven, умеют собирать jar, war, ear, ejb, rar, shade. каждый из сборщиков умеет класть внутрь архива необходимые ресурсы и раскладывать их по необходимым местам автоматически.
install -- фаза, когда собранные на этапе package артефакты проекта устанавливаются в локальный репозитарий. плагин создает каталоги группы и версии, копирует в созданную структуру артефакт и генерирует необходимую метаинформацию
deploy -- фаза, когда проинсталлированные в локальный репозитарий артефакты, переносятся в удаленный репозитарий. тут важно отметить, что Maven следит за обновлениями удаленных репозитариев автоматически. так что для того, чтобы обновить какой-то модуль для удаленной команды, необходимо только задеплоить его в общий удаленные репозитарий.

Maven2::Part #0

Общая информация

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

систем автоматической сборки проектов на Java сущетсвует наверняка очень много. но самыми популярными и используемыми являются Ant и Maven2 (актуальным проектом является Maven2, Maven is dead и это было предрешено). собственно обе системы являются Java-приложениями и обе системы разработаны Apache Sotware Foundation. более того, Maven2 умеет вызывать изнутри себя Ant.

Spring MVC: не очевидное

Есть ряд совершенно не очевидных вещей внутри Spring MVC, например
1) чтобы форма работала и обрабатывалась нормально нужно, чтобы у нее обязательно были прописаны id и name. и то, и другое, одновременно. иначе возможны сбои
2) чтобы механизм автоматического binding'а элементов формы работал, нужно, чтобы имена полей формы совпадали с именами полей класса, в который они байндятся. Т.е.

Java class:
public class BackingBean {
    private long id;
    private String name;

    public void setId(long id) {
        this.id = id;
    }
 
    public long getId() {
        return id;
    }

    public void setName(String name) {
        this.name = name;
    }
 
    public long get() {
        return name;
    }
}

JSP:
<form id="foo" name"foo" method="post" action="/somewhere-on-server">
    <spring:bind path="backingBean.id">
        <input type="text" name="id"/>
    </spring:bind>
    <spring:bind path="backingBean.name">
        <input type="text" name="name"/>
    </spring:bind>
</form>

5) метод formBackingObject всегда создает новый экземпляр объекта, если его перегрузить таким образом, чтобы он делал проверку наличия уже созданного объекта в аттрибутах запроса, это позволит уменьшить количество объектов в памяти и сократить время, необходимое для создания этого объекта
4) в Spring Portlet MVC метод onSubmitRender вызывается только в том случае, когда состояние формы было изменено. поэтому в этом методе нельзя реализовывать обработку RenderRequest's, общих для всего контроллера. для обработки общих запросов можно использовать методы showForm, handleRenderRequestInternal, handleRenderRequest
p.s. а в многом остальном Spring MVC прекрасен, как и весь Spring пожалуй