Vaadin std prod项目包括vaadin-client-compiler和jetty? [英] Vaadin std prod project includes vaadin-client-compiler and jetty?

查看:91
本文介绍了Vaadin std prod项目包括vaadin-client-compiler和jetty?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

I get vaadin-client-compiler artifact (which brings Jetty with it) included with my production project. Am I supposed to ?

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

To reproduce I'm starting from scratch and letting Maven generate a Vaadin multimodule project for me:

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

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

Then in the parent project I execute:

mvn -Pproduction clean install 

完成此操作后,我查看了"xxx-production"项目中生成的WAR文件,并注意到该文件包含vaadin-client-compiler,Jetty等.

After this is done I look into the WAR file generated in the "xxx-production" project and notice it contains vaadin-client-compiler, Jetty, and what not.

我找到了这张票,通过查看最近的评论,我似乎不应该我的作品《战争》中没有类似的内容.我犹豫要更改我的POM,因为它们是由原型生成的,所以我认为在某种程度上应该代表Vaadin最佳实践方法.我不想再次猜测.还是?

I've found this ticket and by looking at the last comment it seems I shouldn't have anything like that in my production WAR. I hesitate to change my POMs as they are generated by the archetype and I guess at some level supposed to represent kind of a Vaadin best-practice approach. I wouldn't want to second guess that. Or ?

这些工件属于类路径的问题是

The problem with these artifacts being part of the classpath is that

  1. 它膨胀了战争的规模
  2. 它会在 Atmosphere 上产生一些问题,因为它在类路径中找到了Jetty,所以人们对此感到困惑. (Vaadin在引擎盖下使用大气)
  1. it balloons the size of the WAR
  2. it creates some problems wrt Atmosphere which supposedly gets confused because it finds Jetty on the classpath. (Atmosphere is used under the hood by Vaadin)

结果是,在Tomcat 8上进行部署时,您将在日志中收到类似SEVERE的严重错误:

The result is that you'll get SEVERE error like this in the log when deploying on 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. 如何解决?
  1. Is it correct that I'm not supposed to have these artifacts in a Vaadin 7.6.2 production project ?
  2. How to solve ?

推荐答案

我相信已经找到了答案. Vaadin团队似乎/已经完全意识到了这一点,但这与过去存在某种烦人的bug时的情况一样.

I believe I've found the answer. It seems Vaadin team was/is fully aware of this but it is kind of a left-over from the old days when there was some kind of annoying bug.

在您的xxx-widgetset项目中,您将在该项目的POM中看到以下内容:

In your xxx-widgetset project you'll see something like this in the POM for that project:

<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注释?? 好吧,恰好发生了,至少在 ticket 14788 中提到的错误不再发生了不在7.6.2上.因此,您现在可以安全地执行TODO注释中所述的内容.

See the TODO comments ?? Well, it just so happens that the bug mentioned in ticket 14788 doesn't happen anymore, at least not on 7.6.2. So you can now safely do what the TODO comment says.

这使我的WAR尺寸减少了50-70 pct.

This has reduced my WAR size by 50-70 pct.

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

It seems to me there's no longer any good reason why this archetype generation doesn't actually do what TODO comment says. Currently you'll have to manually correct it every time you generate a new project skeleton.

这篇关于Vaadin std prod项目包括vaadin-client-compiler和jetty?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆