net.ltgt.gwt.maven과 org.codehaus.mojo GWT Maven 플러그인의 차이점은 무엇입니까?

Question

분명히, 두 받는다는는 GWT에 대한 플러그인이 있습니다 :

이 하나

<groupId>net.ltgt.gwt.maven</groupId> 
<artifactId>gwt-maven-plugin</artifactId> 
<version>1.0-rc-6</version> 

이 하나

<groupId>org.codehaus.mojo</groupId> 
<artifactId>gwt-maven-plugin</artifactId> 
<version>2.8.0-SNAPSHOT</version> 

의 차이점은 무엇입니까?

Answer 1

면책 조항 : 저는 org.codehaus.mojo 플러그인의 전 관리자이며, 작성자는 net.ltgt.gwt.maven입니다.

플러그인은 Maven에서 GWT를 사용하는 것과 매우 다른 접근 방식을 사용합니다. 나는 여기서 가장 중요한 것을 요약하려고 노력할 것이다.

먼저 org.codehaus.mojo은 특정 버전의 GWT에 연결됩니다. 이는 차이점을 설명하기 위해 GWT의 새 버전이 출시 될 때마다 플러그인의 새 버전이 릴리스되어야 함을 의미합니다. 반면, Maven 문서 (mvn gwt:help) 등을 사용하여 구성 속성으로 모든 GWT 옵션/플래그를 표시합니다. 플러그인에서 버그가 수정되면 이는 또한 다음 플러그인 릴리스에서 사용되는 버전과 일치하도록 GWT 버전을 업데이트해야 함을 의미합니다. 항상 최신 GWT 버전을 사용해야하지만, 새로운 버전 등과 호환되지 않는 다른 의존성 때문에 신속하게 업데이트 할 수 없을 수도 있습니다. 따라서 "버전 충돌 지옥"에있을 수 있습니다.
net.ltgt.gwt.maven 플러그인은 GWT의 최신 버전 2 개와 호환되는 것을 목표로하고 있지만 더 많은 플러그인과 호환 될 수 있습니다 (테스트/보증되지 않은 것). 즉, GWT와는 별도로 플러그인을 업데이트 할 수 있습니다.
org.codehaus.mojo 플러그인은 gwt-dev 및 gwt-user (및 gwt-servlet!) 의존성을 가져 오므로 프로젝트 종속성과의 충돌이 발생할 수 있습니다. 또한 Maven이 작동하는 방식 때문에 다른 groupId에서 GWT의 자체 분기 된 버전을 사용하는 경우 플러그인 종속성에서 제외 할 수 없습니다 (com.google.gwtgroupId을 사용하거나 종속성을 변경하려면 플러그인을 포크해야 함) .

net.ltgt.gwt.maven 플러그인은 gwt-lib 및 gwt-app에 대해 맞춤 packaging을 제공합니다. Maven으로 GWT 애플 리케이션을 어떻게 처리해야하는지에 대해 상당히 의구심이 있습니다. 클라이언트와 서버 (및 공유) 코드를 별도의 Maven 모듈로 분리합니다 (실제로 Maven Way ™를 따르고 있습니다 : 별도의 클래스 패스가 필요하면 다른 Maven 모듈 각각 종속 관계가 있음). 물론 이러한 패키지를 사용하지 않아도되며 적절한 기본값과 규칙을 설정하여 POM의 구성을 상당히 줄일 수 있습니다.

마지막으로, 때문에 "프로젝트 레이아웃"에 명시된 위 - 자기 의견을 고집하는 견해는 net.ltgt.gwt.maven 플러그인은 멀티 모듈 예를 들어, gwt:run이되고있다는 org.codehaus.mojo 플러그인에 반하는 (일명 원자로) 구축을 지원하도록 설계 클라이언트와 서버 코드가 모두 "라이브"인 프로젝트에서 실행됩니다. (예 : gwt:run은 애그리 게이터 모듈에서 호출 할 수 없기 때문에) mvn install의 모든 종속성 모듈을 가지고 있고 원활한 개발 경험을 위해 build-helper-maven-plugin을 사용하여 다른 모듈의 클라이언트 소스를 가져 오는 것과 같이 다중 모듈 빌드에서 무서운 해킹을 불러옵니다.

당신은 GWT-받는다는-원형에 this commit에 (면책 조항 : 나는 저자 해요) 플러그인의 차이를 볼 수 net.ltgt.gwt.maven 플러그인에 org.codehaus.mojo로 전환.