如何从 MAven+BND 生成的 OSGI 包中排除 GWT 依赖代码?
我的根 pom.xml 文件中有几个具有 Vaadin 库依赖项的 Maven 模块。
我正在尝试使用 Maven+BND 构建一组 OSGI 捆绑包(每个 Maven 模块 1 个)。
我将其添加到我的“根”pom.xml 文件中:
<dependencies>
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin</artifactId>
<version>6.6.6</version>
</dependency>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-user</artifactId>
<version>2.3.0</version>
</dependency>
<dependency>
<groupId>org.apache.felix</groupId>
<artifactId>org.osgi.core</artifactId>
<version>1.0.0</version>
</dependency>
</dependencies>
不幸的是,生成的 JAR 文件(捆绑包)包含 GWT (com.google.gwt) 类。这 1) 使捆绑包变得巨大,并具有大量重复的依赖项。 2)生成了数千个有关“拆分包”的构建警告。
问题:如何防止将 GWT 类添加到我的 Jar 文件中?
我尝试将 GWT 的“范围”设置为“提供”,将“类型”设置为“捆绑”,甚至可选= true - 没有帮助。
这是我的根 pom.xml 的一部分,它负责 Vaadin/GWT 的内容:
<plugins>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.3.5</version>
<extensions>true</extensions>
<configuration>
<instructions>
<Export-Package>mycompany.*</Export-Package>
<Private-Package>*.impl.*</Private-Package>
<Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>
<!-- <Bundle-Activator>com.alskor.publicpackage.MyActivator</Bundle-Activator>-->
</instructions>
</configuration>
</plugin>
<!-- Compiles your custom GWT components with the GWT compiler -->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<!-- Version 2.1.0-1 works at least with Vaadin 6.5 -->
<version>2.3.0-1</version>
<configuration>
<!-- if you don't specify any modules, the plugin will find them -->
<!--modules>
..
</modules-->
<webappDirectory>${project.build.directory}/${project.build.finalName}/VAADIN/widgetsets
</webappDirectory>
<extraJvmArgs>-Xmx512M -Xss1024k</extraJvmArgs>
<runTarget>clean</runTarget>
<hostedWebapp>${project.build.directory}/${project.build.finalName}</hostedWebapp>
<noServer>true</noServer>
<port>8080</port>
</configuration>
<executions>
<execution>
<goals>
<goal>resources</goal>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- Updates Vaadin 6.2+ widgetset definitions based on project dependencies -->
<plugin>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-maven-plugin</artifactId>
<version>1.0.1</version>
<executions>
<execution>
<configuration>
<!-- if you don't specify any modules, the plugin will find them -->
<!--
<modules>
<module>${package}.gwt.MyWidgetSet</module>
</modules>
-->
</configuration>
<goals>
<goal>update-widgetset</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
I have several Maven modules with Vaadin library dependency in the root pom.xml file.
I'm trying to build a set of OSGI bundles (1 per Maven module) using Maven+BND.
I added this to my "root" pom.xml file:
<dependencies>
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin</artifactId>
<version>6.6.6</version>
</dependency>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-user</artifactId>
<version>2.3.0</version>
</dependency>
<dependency>
<groupId>org.apache.felix</groupId>
<artifactId>org.osgi.core</artifactId>
<version>1.0.0</version>
</dependency>
</dependencies>
unfortunately, the resulting JAR files (bundles) include GWT (com.google.gwt) classes. This
1) makes the bundles huge, with lots of duplicated dependencies.
2) generated thousands of build warnings about "split packages".
QUESTION: how to prevent adding GWT classes into my Jar files?
I tried setting "scope" of GWT to "provided", setting "type" to "bundle", and even optional=true - didn't help.
here's the part of my root pom.xml, which is responsible for Vaadin/GWT stuff:
<plugins>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.3.5</version>
<extensions>true</extensions>
<configuration>
<instructions>
<Export-Package>mycompany.*</Export-Package>
<Private-Package>*.impl.*</Private-Package>
<Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>
<!-- <Bundle-Activator>com.alskor.publicpackage.MyActivator</Bundle-Activator>-->
</instructions>
</configuration>
</plugin>
<!-- Compiles your custom GWT components with the GWT compiler -->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<!-- Version 2.1.0-1 works at least with Vaadin 6.5 -->
<version>2.3.0-1</version>
<configuration>
<!-- if you don't specify any modules, the plugin will find them -->
<!--modules>
..
</modules-->
<webappDirectory>${project.build.directory}/${project.build.finalName}/VAADIN/widgetsets
</webappDirectory>
<extraJvmArgs>-Xmx512M -Xss1024k</extraJvmArgs>
<runTarget>clean</runTarget>
<hostedWebapp>${project.build.directory}/${project.build.finalName}</hostedWebapp>
<noServer>true</noServer>
<port>8080</port>
</configuration>
<executions>
<execution>
<goals>
<goal>resources</goal>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- Updates Vaadin 6.2+ widgetset definitions based on project dependencies -->
<plugin>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-maven-plugin</artifactId>
<version>1.0.1</version>
<executions>
<execution>
<configuration>
<!-- if you don't specify any modules, the plugin will find them -->
<!--
<modules>
<module>${package}.gwt.MyWidgetSet</module>
</modules>
-->
</configuration>
<goals>
<goal>update-widgetset</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
您的导出包和私人包声明中的通配符让我觉得非常危险。由于 Private-Package 中的
*.impl.*
模式,GWT 包可能被拖入。此外,您不应该在 Export-Package 中使用通配符:导出应该受到严格控制和版本控制。
The wildcards in your Export-Package and Private-Package statements strike me as exceedingly dangerous. It's possible that the GWT packages are being dragged in because of the
*.impl.*
pattern in Private-Package.Also you should never use wildcards in Export-Package: exports should be tightly controlled and versioned.
的
元素添加到相关依赖项来压制它。<excludes/>
element with an appropriate<exclude/>
to the dependency in question to suppress it.我也遇到过类似的问题,因为最终的 war 文件几乎超过了 90MB!
罪魁祸首之一是前面提到的罐子,所以我这样做了:
I've had similar problem, as final war file exceeded almost 90MB !
One of the culprit was aforementioned jar, so I did this :