【问题标题】:Vaadin std prod project includes vaadin-client-compiler and jetty?Vaadin std prod 项目包括 vaadin-client-compiler 和 jetty?
【发布时间】:2016-02-14 17:23:59
【问题描述】:

我的生产项目中包含了vaadin-client-compiler 工件(它带来了 Jetty)。我应该吗?

为了重现,我从头开始,让 Maven 为我生成一个 Vaadin 多模块项目:

mvn
-DarchetypeGroupId=com.vaadin 
-DarchetypeArtifactId=vaadin-archetype-application-multimodule 
-DarchetypeVersion=7.6.2 
-DarchetypeRepository=http://repo.maven.apache.org/maven2/ 
-DgroupId=com.acme 
-DartifactId=VaadinTest1 
-Dversion=1.0.0-SNAPSHOT 
-Dpackage=com.acme.vaadintest1 
-Dbasedir=D:\\dev\\java 
-DthemeName=mytheme 
-DwidgetsetName=MyAppWidgetset 
-DuiName=MyUI 
-Darchetype.interactive=false 
--batch-mode archetype:generate

然后在我执行的父项目中:

mvn -Pproduction clean install 

完成后,我查看在“xxx-production”项目中生成的 WAR 文件,并注意到它包含 vaadin-client-compiler、Jetty 等等。

我找到了this ticket,通过查看最后一条评论,我的生产 WAR 中似乎不应该有类似的东西。我犹豫要更改我的 POM,因为它们是由原型生成的,我想在某种程度上应该代表一种 Vaadin 最佳实践方法。我不想再猜测了。还是?

这些工件作为类路径的一部分的问题在于

  1. 它会膨胀 WAR 的大小
  2. 它会产生一些问题 wrt Atmosphere,因为它在类路径上找到了 Jetty,因此可能会感到困惑。 (气氛被 Vaadin 在引擎盖下使用)

结果是在 Tomcat 8 上部署时,您会在日志中收到类似这样的严重错误:

14-Feb-2016 16:42:30.368 SEVERE [localhost-startStop-1] org.atmosphere.cpr.DefaultAsyncSupportResolver.newCometSupport Failed to create comet support class: class org.
atmosphere.container.JettyServlet30AsyncSupportWithWebSocket, error: null

总结一下:

  1. 应该将这些工件放在一个 Vaadin 7.6.2 生产项目?
  2. 如何解决?

【问题讨论】:

    标签: maven vaadin


    【解决方案1】:

    我相信我已经找到了答案。似乎 Vaadin 团队已经/完全意识到了这一点,但它是旧时代的遗留物,当时存在某种令人讨厌的错误。

    在您的 xxx-widgetset 项目中,您会在该项目的 POM 中看到类似的内容:

    <dependencies>
        <!-- Versions for these are configured in the parent POM -->
        <dependency>
            <groupId>com.vaadin</groupId>
            <artifactId>vaadin-client</artifactId>
            <!-- TODO this should have scope provided once http://dev.vaadin.com/ticket/14788 is resolved -->
            <!-- <scope>provided</scope> -->
        </dependency>
        <dependency>
            <groupId>com.vaadin</groupId>
            <artifactId>vaadin-client-compiler</artifactId>
            <!-- TODO this should have scope provided once http://dev.vaadin.com/ticket/14788 is resolved -->
            <!-- <scope>provided</scope> -->
        </dependency>
    
        ... you'll see more deps here if you've added 
        ... Vaadin add-ons to your project.
    </dependencies>
    

    看到 TODO cmets 了吗? 好吧,碰巧ticket 14788 中提到的错误不再发生,至少在 7.6.2 上不会发生。所以你现在可以安全地按照 TODO 评论所说的去做。

    这将我的 WAR 大小减少了 50-70%。

    在我看来,这个原型一代实际上并没有按照 TODO 评论所说的那样去做,没有任何充分的理由。目前,每次生成新的项目骨架时,您都必须手动更正它。

    【讨论】:

      【解决方案2】:

      如果您使用不同的网络服务器(在您的情况下为 Tomcat 8),则不需要提供的 jetty-plugin。

      由于原型具有一些码头依赖性,您可以使用 Maven POM 文件中的排除标记。

      示例

      <groupId>com.vaadin</groupId>
      <artifactId>vaadin-client-compiler</artifactId>
      <version>${vaadin.version}</version>
      <exclusions>
          <exclusion>
              <groupId>org.eclipse.jetty</groupId>
              <artifactId>jetty-servlets</artifactId>
          </exclusion>
          <exclusion>
              <groupId>org.eclipse.jetty</groupId>
              <artifactId>jetty-annotations</artifactId>
          </exclusion>
          <exclusion>
              <groupId>org.eclipse.jetty</groupId>
              <artifactId>jetty-util</artifactId>
          </exclusion>
      </exclusions>
      

      此外,删除/注释掉模块 POM 文件中发现的所有不必要的“jetty”依赖项。

      【讨论】:

      • 明白,但为什么不简单地确保 vaadin-client-compiler 依赖是非传递的 as in this ?通过这样做,我仍然可以在 Jetty 上进行一些开发和测试……如果我愿意的话。
      • 您的码头错误在范围调整后消失了吗?
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2019-02-24
      • 1970-01-01
      • 1970-01-01
      • 2018-07-18
      • 1970-01-01
      • 2017-12-25
      • 1970-01-01
      相关资源
      最近更新 更多