[ANN] Apache Maven EAR Plugin 3.3.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven EAR Plugin, version 3.3.0 This plugin generates Java EE Enterprise Archive (EAR) file. https://maven.apache.org/plugins/maven-ear-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-ear-plugin 3.3.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-ear-plugin/download.html Release Notes - Maven EAR Plugin - Version 3.3.0 ** Bug * [MEAR-297] - failure when building javadoc: maven-plugin-tools-javadoc:jar:3.6.0 is missing * [MEAR-301] - wrong repackaging when defaultLibBundleDir start with dot ** New Feature * [MEAR-302] - jakarta EE 9 EAR compatibility * [MEAR-309] - Support JakartaEE 10 ** Improvement * [MEAR-298] - Improving EAR packaging performance with ZipFileSystem * [MEAR-319] - Remove generated MANIFEST from outdated resources * [MEAR-321] - Remove not implemented parameter - useBaseVersion ** Task * [MEAR-304] - Update dependencies used in IT tests * [MEAR-311] - Require Java 8 * [MEAR-318] - Require Maven 3.2.5 ** Dependency upgrade * [MEAR-310] - Upgrade Parent to 37 * [MEAR-312] - Upgrade Maven Verifier to 2.0.0-M1 * [MEAR-313] - Bump maven-filtering from 3.2.0 to 3.3.0 * [MEAR-314] - Bump plexus-archiver from 4.2.4 to 4.5.0 * [MEAR-315] - Bump maven-archiver from 3.5.1 to 3.6.0 * [MEAR-316] - Bump plexus-io from 3.2.0 to 3.4.0 * [MEAR-317] - Bump maven-shared-utils from 3.3.3 to 3.3.4 * [MEAR-320] - Bump plexus-utils from 3.3.0 to 3.4.2 Enjoy, -The Apache Maven team
Re: jakarta ee 9 ear compatibility
Hello, I would like to let you know that I have created this issue (https://issues.apache.org/jira/browse/MEAR-302) with a test app as you requested. Thank you Dionysos On 2021/06/15 05:51:48, Olivier Lamy wrote: > Hi > We should definitely support jakarta namespace as well. > Can you create an issue with a sample project? > > > On Tue, 15 Jun 2021 at 15:38, d kech wrote: > > > Hello, > > > > I have been trying to build an ear project after I upgraded it to jakarta > > ee 9 and tried to deploy it on Glassfish 6.1 but it seems ear plugin does > > not support ee 9 yet. Specifically the war module was not getting packaged > > in contrast to the ejb module. > > I would like to know if maven-ear-plugin is going to support jakarta ee > > 9 soon or if there is any other way to build ear with maven. > > > > Thanks in advance. > > Dionysos > > > > > -- > Olivier Lamy > http://twitter.com/olamy | http://linkedin.com/in/olamy > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: jakarta ee 9 ear compatibility
Hi We should definitely support jakarta namespace as well. Can you create an issue with a sample project? On Tue, 15 Jun 2021 at 15:38, d kech wrote: > Hello, > > I have been trying to build an ear project after I upgraded it to jakarta > ee 9 and tried to deploy it on Glassfish 6.1 but it seems ear plugin does > not support ee 9 yet. Specifically the war module was not getting packaged > in contrast to the ejb module. > I would like to know if maven-ear-plugin is going to support jakarta ee > 9 soon or if there is any other way to build ear with maven. > > Thanks in advance. > Dionysos > -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
jakarta ee 9 ear compatibility
Hello, I have been trying to build an ear project after I upgraded it to jakarta ee 9 and tried to deploy it on Glassfish 6.1 but it seems ear plugin does not support ee 9 yet. Specifically the war module was not getting packaged in contrast to the ejb module. I would like to know if maven-ear-plugin is going to support jakarta ee 9 soon or if there is any other way to build ear with maven. Thanks in advance. Dionysos
[ANN] Apache Maven EAR Plugin 3.2.0 Released
The Maven team is pleased to announce the release of the Apache Maven EAR Plugin, version 3.2.0 This plugin generates a J2EE Enterprise Archive (EAR) file. https://maven.apache.org/plugins/maven-ear-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-ear-plugin 3.2.0 Release Notes - Apache Maven EAR Plugin - Version 3.2.0 Bug * [MEAR-294] JAR with provided scope should be removed from Class-Path entry of EAR module MANIFEST.mf * [MEAR-292] skipClassPathModification option should prevent adding Class-Path entry into MANIFEST.mf * [MEAR-289] skinnyWars issue with finalName for Jar module * [MEAR-288] SNAPSHOT dependency JAR having timestamp name in WAR is not removed from WAR when skinnyWars option is turned on * [MEAR-287] Failed to create target directory when run without clean * [MEAR-286] filtered resources not copied if run-its profile not activated * [MEAR-272] SNAPSHOT dependencies are copied with timestamp * [MEAR-267] assembly.xml contains incorrect references to modules Improvement * [MEAR-216] Unable to include dependencies of type test-jar New Feature * [MEAR-166] 'skinnyWar' doesn't work well with dependencies of type 'ejb' * [MEAR-153] Skinny Modules -- not just WARs Task * [MEAR-296] Upgrade to maven-filtering 3.2.0 * [MEAR-295] Require Maven 3.1.1 Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: AW: Creating JAR file in WAR module leads to error in EAR creation
Hello Karl Heinz,
Hello Jörg,
Thanks for your replies to my problem.
@Jörg: I would have assumed - as the EJB plugin also uses the type explicitly
defined by the type of used module - that Maven would be able to resolve the
coordinates to the correct artifact (means GAV and type).
https://github.com/apache/maven-ear-plugin/blob/b289e6c271d50172c871e528105dda81d6f702b8/src/main/java/org/apache/maven/plugins/ear/AbstractEarModule.java#L144
But it seems not the case. Or that they share the same information which is
overwritten by the JAR installation / deployment.
The odd thing here is that everything works fine if I build the modules
one-by-one.
So it seems not to be a general problem, but just a problem in case you do that
in one build.
I would have expected that it always fails or always succeeds.
@Karl Heinz: Yes, the packaging is EJB.
That module is used in the web module and in the ear module as well as the
client (which is not part of that Maven project, but an own Maven project).
Currently I'm using version 3.1.0 of the maven-ejb-plugin.
But I'm not sure how that is related to the problem as in all iteration -
successful or not - I didn't change anything in aspect of the EJB.
Maybe you can elaborate on that a little bit?
In meantime I solved it with the maven-war-plugin's options:
XXX
XXX-pom
1.0.18
XXX-web
war
org.apache.maven.plugins
maven-war-plugin
${generated-webbapp-folder}
true
classes
This will create an additional XXX-web-1.0.18-classes.jar file.
The minus point is that this isn't as flexible as using the maven-jar-plugin.
But so far it works for me, also I have to do some copying via the
maven-antrun-plugin as I need more files in the JAR than just the classes.
I guess that solution is also what Jörg mentioned.
Best regards,
Gerrit
P.S.: I recognized that I had a typo in my previous mail.
Of course the artifactId of the XXX-ear module is
XXX-ear using ear.
Ups... But it is only in the excerpt. The real module's pom.xml is correct.
-Ursprüngliche Nachricht-
Von: Karl Heinz Marbaise
Gesendet: Donnerstag, 12. November 2020 20:35
An: Maven Users List ; Hohl, Gerrit
Betreff: Re: AW: Creating JAR file in WAR module leads to error in EAR creation
Hi,
On 12.11.20 14:13, Hohl, Gerrit wrote:
> Hello everyone,
>
>
> maybe some additional information will be helpful.
> The project structure is like (and also build in this order due to the
> dependencies of the modules):
>
> - XXX-pom
>- XXX-ejb
My assumption is that ejb project uses packaging: ejb?
Where is the ejb module used? And how?
Which version of maven-ejb-plugin have you defined in your build?
>- XXX-web
>- XXX-ear
>
> Here the excerpt from the pom.xml of the XXX-web module:
>
>
>
> XXX
> XXX-pom
> 1.0.18
>
> XXX-web
> war
>
>
>
>
> org.apache.maven.plugins
> maven-war-plugin
>
>
>
>
> ${generated-webbapp-folder}
>
>
>
>
>
> org.apache.maven.plugins
> maven-install-plugin
>
>
>
> jar-install
> install
>
> install-file
>
>
>
> ${project.build.directory}/${project.artifactId}-${project.version}.jar
> jar
>
> ${project.build.directory}/${project.artifactId}-${project.version}-javadoc.jar
>
> ${project.build.directory}/${project.artifactId}-${project.version}-sources.jar
>
Re: AW: Creating JAR file in WAR module leads to error in EAR creation
Hi,
On 12.11.20 14:13, Hohl, Gerrit wrote:
Hello everyone,
maybe some additional information will be helpful.
The project structure is like (and also build in this order due to the
dependencies of the modules):
- XXX-pom
- XXX-ejb
My assumption is that ejb project uses packaging: ejb?
Where is the ejb module used? And how?
Which version of maven-ejb-plugin have you defined in your build?
- XXX-web
- XXX-ear
Here the excerpt from the pom.xml of the XXX-web module:
XXX
XXX-pom
1.0.18
XXX-web
war
org.apache.maven.plugins
maven-war-plugin
${generated-webbapp-folder}
org.apache.maven.plugins
maven-install-plugin
jar-install
install
install-file
${project.build.directory}/${project.artifactId}-${project.version}.jar
jar
${project.build.directory}/${project.artifactId}-${project.version}-javadoc.jar
${project.build.directory}/${project.artifactId}-${project.version}-sources.jar
This does not make sense. If you like to create and deploy a separate
jar file of the classes which are being compiled in the war module you
should use:
true
true
configuration of the maven-war-plugin which will do and create an
appropriate jar file for those classes.
I strongly recommend to upgrade maven-war-plugin, maven-ear-plugin
versions to the most recent ones...
org.apache.maven.plugins
maven-deploy-plugin
jar-deploy
deploy
deploy-file
${project.build.directory}/${project.artifactId}-${project.version}.jar
${project.groupId}
${project.artifactId}
${project.version}
jar
false
${project.build.directory}/${project.artifactId}-${project.version}-javadoc.jar
${project.build.directory}/${project.artifactId}-${project.version}-sources.jar
${project.distributionManagement.repository.id}
${project.distributionManagement.repository.url}
Same as above... remove this part...
Manually calling install-file/deploy-file is in 99.999% of the cases
simply wrong...
And here the excerpt from the pom.xml of the XXX-ear module:
XXX
XXX-pom
1.0.18
XXX-web
war
XXX
XXX-web
${project.version}
war
org.apache.maven.plugins
maven-ear-plugin
XXX
XXX-web
XXX-web-${project.version}.war
Re: AW: Creating JAR file in WAR module leads to error in EAR creation
Am Donnerstag, 12. November 2020, 14:13:42 CET schrieb Hohl, Gerrit: > Hello everyone, > > > maybe some additional information will be helpful. > The project structure is like (and also build in this order due to the > dependencies of the modules): > > - XXX-pom > - XXX-ejb > - XXX-web > - XXX-ear [snip] You should not mix-up both artifacts for Maven. From Mavens PoV they are the same (because they have the same G:A:V). Look at the configuration options for the WAR plugin. You can generate automatically a jar file for the classes with an own classifier which is automatically attached. Use that one to refer in your EAR build. Cheers, Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: Creating JAR file in WAR module leads to error in EAR creation
Hello everyone,
maybe some additional information will be helpful.
The project structure is like (and also build in this order due to the
dependencies of the modules):
- XXX-pom
- XXX-ejb
- XXX-web
- XXX-ear
Here the excerpt from the pom.xml of the XXX-web module:
XXX
XXX-pom
1.0.18
XXX-web
war
org.apache.maven.plugins
maven-war-plugin
${generated-webbapp-folder}
org.apache.maven.plugins
maven-install-plugin
jar-install
install
install-file
${project.build.directory}/${project.artifactId}-${project.version}.jar
jar
${project.build.directory}/${project.artifactId}-${project.version}-javadoc.jar
${project.build.directory}/${project.artifactId}-${project.version}-sources.jar
org.apache.maven.plugins
maven-deploy-plugin
jar-deploy
deploy
deploy-file
${project.build.directory}/${project.artifactId}-${project.version}.jar
${project.groupId}
${project.artifactId}
${project.version}
jar
false
${project.build.directory}/${project.artifactId}-${project.version}-javadoc.jar
${project.build.directory}/${project.artifactId}-${project.version}-sources.jar
${project.distributionManagement.repository.id}
${project.distributionManagement.repository.url}
And here the excerpt from the pom.xml of the XXX-ear module:
XXX
XXX-pom
1.0.18
XXX-web
war
XXX
XXX-web
${project.version}
war
org.apache.maven.plugins
maven-ear-plugin
XXX
XXX-web
XXX-web-${project.version}.war
XXX-web-${project.version}.war
/XXX
/
The specifies that the type of the artifact must be WAR.
So the maven-ear-plugin tries to match that against the artifacts of the
project (means the ).
And that also works.
But it seems that the maven-install-plugin and / or maven-deploy-plugin
overwrite the file-path of the WAR at runtime of the Maven build in memory.
I don't know why and I also don&#
Creating JAR file in WAR module leads to error in EAR creation
Hello everyone, I have a project consisting of several modules, one being a WAR module and one being an EAR module. The EAR module has a dependency on the WAR module. It turned out that I need the classes of that WAR module also as a JAR file for our UI project. So I added a install-file goal for the maven-install-plugin and a deploy-file goal for the maven-deploy-plugin. The WAR module build now creates the JAR file successfully and also deploys it. But now my EAR module fails: Failed to execute goal org.apache.maven.plugins:maven-ear-plugin:3.0.2:ear (default-ear) on project XXX-ear: Cannot copy a directory: C:\XXX\XXX-pom\XXX-web\target\classes; Did you package/install XXX:XXX-web:war:1.0.18:compile? -> [Help 1] I looked up the code of the maven-ear-plugin. It seems it the following line is the problem: https://github.com/apache/maven-ear-plugin/blob/b289e6c271d50172c871e528105dda81d6f702b8/src/main/java/org/apache/maven/plugins/ear/EarMojo.java#L424 For some reason the file attribute of the Artifact object seems to contain the path to the classes directory if the JAR file is build. If I uncomment the JAR file creation in the WAR module it seems it contains the WAR file path. Things get even more interesting: When I created the JAR file, but build the WAR and the EAR independently (not by building the parent project), it works perfectly. Seems something overwrites that information (the path of the WAR) and that information is kept also during the build step of the EAR file. So I'm not sure what I'm doing wrong or how I can fix it. Anyone faced a similar problem in the past? Best regards, Gerrit
Maven EAR Plugin 3.2.0 with skinnyModules option
Hi users of Apache Maven, We are working on MEAR-153 (https://issues.apache.org/jira/browse/MEAR-153) to implement skinnyModules option for the Maven EAR Plugin. Refer to https://github.com/apache/maven-ear-plugin/pull/24 for the changes which can be used to try skinnyModules option which is a logical extension of the skinnyWars option. Unfortunately, we have no real code which uses SAR, HAR, RAR and WSR modules of EAR to test the changes on working code and to ensure that things work as expected, so we appreciate help of volunteers to: 1. Test https://github.com/apache/maven-ear-plugin/pull/24 with skinnyModules option turned off (default behavior) and turned on (new behavior) for the case when EAR archive contains WAR, SAR, HAR, RAR and WSR modules. 2. Review changes in documentation of Maven EAR Plugin where skinnyModules option of Maven EAR Plugin configuration is described. 3. Review changes in documentation of Maven EAR Plugin where libDirectory property of Maven EAR Plugin module configuration is described. Thank you. Regards, Marat Abrarov. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [ANN] Apache Maven EAR Plugin 3.1.2 Released
for those interested, issue created and being worked on: https://issues.apache.org/jira/browse/MEAR-287 I suppose this is a blocker that will require a new release soon, isn't it? please help us by testing as early as possible, to find such issues ASAP and ideally before the release Regards, Hervé Le jeudi 1 octobre 2020, 09:16:12 CEST Martin Höller a écrit : > Hi! > > On 01. Okt. 2020 Hervé Boutemy wrote: > > The Maven team is pleased to announce the release of the Apache Maven EAR > > Plugin, version 3.1.0 > With maven-ear-plugin 3.1.0 I get this exception on a project that built > fine with 3.0.2: > > $ mvn -X install > [...] > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-ear-plugin:3.1.0:ear (default-ear) on > project demo-ear: Failed to create directory > /home/martin/idea/demo/demo-ear/target/temp/my.domain.demo-demo-webapp-new- > 3.0-SNAPSHOT.war -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-ear-plugin:3.1.0:ear (default-ear) on > project demo-ear: Failed to create directory > /home/martin/idea/demo/demo-ear/target/temp/my.domaon.demo-demo-webapp-new- > 3.0-SNAPSHOT.war at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:215) at > org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:156) at > org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:148) at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:117) at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:81) at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBu > ilder.build (SingleThreadedBuilder.java:56) at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute > (LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute > (DefaultMaven.java:305) at org.apache.maven.DefaultMaven.doExecute > (DefaultMaven.java:192) at org.apache.maven.DefaultMaven.execute > (DefaultMaven.java:105) at org.apache.maven.cli.MavenCli.execute > (MavenCli.java:957) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:193) > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.java:62) at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke > (Method.java:566) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced > (Launcher.java:282) at > org.codehaus.plexus.classworlds.launcher.Launcher.launch > (Launcher.java:225) at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode > (Launcher.java:406) at > org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347) > Caused by: org.apache.maven.plugin.MojoFailureException: Failed to create > directory > /home/martin/idea/demo/demo-ear/target/temp/my.domain.demo-demo-webapp-new- > 3.0-SNAPSHOT.war at > org.apache.maven.plugins.ear.EarMojo.changeManifestClasspath > (EarMojo.java:763) at org.apache.maven.plugins.ear.EarMojo.copyModules > (EarMojo.java:466) at org.apache.maven.plugins.ear.EarMojo.execute > (EarMojo.java:336) at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo > (DefaultBuildPluginManager.java:137) at > org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:210) at > org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:156) at > org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:148) at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:117) at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:81) at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBu > ilder.build (SingleThreadedBuilder.java:56) at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute > (LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute > (DefaultMaven.java:305) at org.apache.maven.DefaultMaven.doExecute > (DefaultMaven.java:192) at org.apache.maven.DefaultMaven.execute > (DefaultMaven.java:105) at org.apache.maven.cli.MavenCli.execute > (MavenCli.java:957) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:193) > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method
Re: [ANN] Apache Maven EAR Plugin 3.1.2 Released
Hi! On 01. Okt. 2020 Hervé Boutemy wrote: > The Maven team is pleased to announce the release of the Apache Maven EAR > Plugin, version 3.1.0 With maven-ear-plugin 3.1.0 I get this exception on a project that built fine with 3.0.2: $ mvn -X install [...] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-ear-plugin:3.1.0:ear (default-ear) on project demo-ear: Failed to create directory /home/martin/idea/demo/demo-ear/target/temp/my.domain.demo-demo-webapp-new-3.0-SNAPSHOT.war -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-ear-plugin:3.1.0:ear (default-ear) on project demo-ear: Failed to create directory /home/martin/idea/demo/demo-ear/target/temp/my.domaon.demo-demo-webapp-new-3.0-SNAPSHOT.war at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957) at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289) at org.apache.maven.cli.MavenCli.main (MavenCli.java:193) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke (Method.java:566) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282) at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406) at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347) Caused by: org.apache.maven.plugin.MojoFailureException: Failed to create directory /home/martin/idea/demo/demo-ear/target/temp/my.domain.demo-demo-webapp-new-3.0-SNAPSHOT.war at org.apache.maven.plugins.ear.EarMojo.changeManifestClasspath (EarMojo.java:763) at org.apache.maven.plugins.ear.EarMojo.copyModules (EarMojo.java:466) at org.apache.maven.plugins.ear.EarMojo.execute (EarMojo.java:336) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957) at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289) at org.apache.maven.cli.MavenCli.main (MavenCli.java:193) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke (Method.java:566) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282) at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406) at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347) [ERROR] [ERROR] [ERROR] For more informat
[ANN] Apache Maven EAR Plugin 3.1.2 Released
The Maven team is pleased to announce the release of the Apache Maven EAR Plugin, version 3.1.0 This plugin generates a J2EE Enterprise Archive (EAR) file. https://maven.apache.org/plugins/maven-ear-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-ear-plugin 3.1.0 Release Notes - Apache Maven EAR Plugin - Version 3.1.0 Bug * [MEAR-285] EarMojo fails to handle assorted IO Errors * [MEAR-283] Not reproducible builds when skinnyWars option turned on * [MEAR-278] Ear plugin includes the same artifact twice if used without clean Improvement * [MEAR-279] make build Reproducible * [MEAR-194] Output during creation of Ear is not correct New Feature * [MEAR-280] Reproducible Builds: make entries in output ear files reproducible (order + timestamp) Task * [MEAR-284] Tests fail at HEAD on Linux * [MEAR-276] Upgrade maven-archiver to 3.4.0 Thank you to all contributors who helped to make this release. Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: maven-ear-plugin bundleFileName don't change the name of the war i want to bundle with the ear
This is totally wired
im debugging the plugin and I see that it ignores and don’t load what I
configured
under :
Nothing . it is using some kind of default parameters .
why does it ignore the configuration ?
-Original Message-
From: Karl Heinz Marbaise
Sent: Thursday, 4 June 2020 17:18
To: Maven Users List ; Bram Patelski
Subject: Re: maven-ear-plugin bundleFileName don't change the name of the war i
want to bundle with the ear
Hi,
On 04.06.20 14:17, Bram Patelski wrote:
> You can use the finalName property in the build-section of the Maven
> pom-file:
>
>
>test
> . . .
This will only change the name in target directory but not the name in the EAR
file ...
Kind regards
Karl Heinz Marbaise
>
>
> https://stackoverflow.com/questions/14488509/maven-how-to-rename-the-w
> ar-file-for-the-project
>
>
> PGP key:
> https://keys.mailvelope.com/pks/lookup?op=get&search=0xF31094A567CE732
> E
>
>
> On Wed, Jun 3, 2020 at 9:44 PM Meir Yanovich
> wrote:
>
>> im using the latest version of the maven-ear-plugin i like to bundle
>> the test.war into my ear but the output is always :
>>
>> test1-test21999.test-SNAPSHOT.war
>>
>> which is always the default :
>>
>> outputFileNameMapping = @{groupId}@-@{artifactId}@-@{version}@
>> @{dashClassifier?}@.@{extension}@
>>
>> how do i force it to be:test.war
>>
>> > xmlns="http://maven.apache.org/POM/4.0.0"; xmlns:xsi="
>> http://www.w3.org/2001/XMLSchema-instance";
>> xsi:schemaLocation="
>> http://maven.apache.org/POM/4.0.0
>> http://maven.apache.org/maven-v4_0_0.xsd
>> ">
>>
>> 4.0.0
>>
>>
>> com.test.id
>> artifact_name
>> 1999_app
>>
>>
>> Test
>> ear
>> Test
>>
>>
>>
>>
>> ${project.groupId}
>> test1
>> war
>>
>>
>>
>> myapp
>>
>>
>> myapp
>>
>>
>>
>>
>>org.apache.maven.plugins
>>
>>maven-ear-plugin
>>
>>
>>
>>
>>
>>
>>
>> test1
>>
>>
>> Test1
>>
>>
>> test.war
>>
>>
>> test.war
>>
>>
>> /myapp
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> here is the log after running with -X:
>> please notice when it copy and ignoring the renaming
>>
>> [INFO] Copying artifact [war:test1:test2:1999.test-SNAPSHOT] to
>> [test1-test21999.test-SNAPSHOT.war]
>>
>> [INFO] --- maven-ear-plugin:3.0.1:ear (default-ear) @
>> web-pserver-ear
>> ---
>> [DEBUG] Configuring mojo
>> org.apache.maven.plugins:maven-ear-plugin:3.0.1:ear from plugin realm
>> ClassRealm[plugin>org.apache.maven.plugins:maven-ear-plugin:3.0.1, parent:
>> sun.misc.Launcher$AppClassLoader@4e25154f]
>> [DEBUG] Configuring mojo
>> 'org.apache.maven.plugins:maven-ear-plugin:3.0.1:ear' with basic
>> configurator -->
>> [DEBUG] (f) earSourceDirectory = C:\foo\ear\src\main\application
>> [DEBUG] (f) earSourceIncludes = **
>> [DEBUG] (f) encoding = UTF-8
>> [DEBUG] (f) escapedBackslashesInFilePath = false
>> [DEBUG] (f) filtering = false
>> [DEBUG] (f) finalName =
>> web-pserver-ear-2020.vanilla-engage.1-SNAPSHOT
>> [DEBUG] (f) generatedDescriptorLocation = C:\foo\target
>> [DEBUG] (f) includeLibInApplicationXml = false
>> [DEBUG] (f) outputDirectory = C:\foo\target
>> [DEBUG] (f) outputFileNameMapping = @
Re: maven-ear-plugin bundleFileName don't change the name of the war i want to bundle with the ear
Hi,
On 04.06.20 14:17, Bram Patelski wrote:
You can use the finalName property in the build-section of the Maven
pom-file:
test
. . .
This will only change the name in target directory but not the name in
the EAR file ...
Kind regards
Karl Heinz Marbaise
https://stackoverflow.com/questions/14488509/maven-how-to-rename-the-war-file-for-the-project
PGP key:
https://keys.mailvelope.com/pks/lookup?op=get&search=0xF31094A567CE732E
On Wed, Jun 3, 2020 at 9:44 PM Meir Yanovich
wrote:
im using the latest version of the maven-ear-plugin
i like to bundle the test.war into my ear
but the output is always :
test1-test21999.test-SNAPSHOT.war
which is always the default :
outputFileNameMapping = @{groupId}@-@{artifactId}@-@{version}@
@{dashClassifier?}@.@{extension}@
how do i force it to be:test.war
http://maven.apache.org/POM/4.0.0"; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="
http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd
">
4.0.0
com.test.id
artifact_name
1999_app
Test
ear
Test
${project.groupId}
test1
war
myapp
myapp
org.apache.maven.plugins
maven-ear-plugin
test1
Test1
test.war
test.war
/myapp
here is the log after running with -X:
please notice when it copy and ignoring the renaming
[INFO] Copying artifact [war:test1:test2:1999.test-SNAPSHOT] to
[test1-test21999.test-SNAPSHOT.war]
[INFO] --- maven-ear-plugin:3.0.1:ear (default-ear) @ web-pserver-ear
---
[DEBUG] Configuring mojo
org.apache.maven.plugins:maven-ear-plugin:3.0.1:ear from plugin realm
ClassRealm[plugin>org.apache.maven.plugins:maven-ear-plugin:3.0.1, parent:
sun.misc.Launcher$AppClassLoader@4e25154f]
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-ear-plugin:3.0.1:ear' with basic
configurator -->
[DEBUG] (f) earSourceDirectory = C:\foo\ear\src\main\application
[DEBUG] (f) earSourceIncludes = **
[DEBUG] (f) encoding = UTF-8
[DEBUG] (f) escapedBackslashesInFilePath = false
[DEBUG] (f) filtering = false
[DEBUG] (f) finalName =
web-pserver-ear-2020.vanilla-engage.1-SNAPSHOT
[DEBUG] (f) generatedDescriptorLocation = C:\foo\target
[DEBUG] (f) includeLibInApplicationXml = false
[DEBUG] (f) outputDirectory = C:\foo\target
[DEBUG] (f) outputFileNameMapping = @{groupId}@-@{artifactId}@
-@{version}@@{dashClassifier?}@.@{extension}@
[DEBUG] (f) project = MavenProject: foo-ear:1999.foo1-SNAPSHOT @
C:foo\ear\pom.xml
[DEBUG] (f) session =
org.apache.maven.execution.MavenSession@7569ea63
[DEBUG] (f) skinnyWars = false
[DEBUG] (f) skipClassPathModification = false
[DEBUG] (f) tempFolder =C:\foo\target
[DEBUG] (f) useJvmChmod = true
[DEBUG] (f) version = 7
[DEBUG] (f) workDirectory = C:\foo\target\foo-SNAPSHOT
[DEBUG] -- end configuration --
[DEBUG] Resolving artifact type mappings ...
[DEBUG] Initializing JBoss configuration if necessary ...
[DEBUG] Initializing ear execution context
[DEBUG] Resolving ear modules ...
[INFO] Copying artifact [war:test1:test2:1999.test-SNAPSHOT] to
[test1-test21999.test-SNAPSHOT.war]
[INFO] Copy ear sources to C:\foo\target\foo-SNAPSHOT
[DEBUG] Jar archiver implementation
[org.codehaus.plexus.archiver.jar.JarArchiver]
[DEBUG] Excluding [] from the generated EAR.
[DEBUG] Including [**] in the generated EAR.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-ear-plugin bundleFileName don't change the name of the war i want to bundle with the ear
You can use the finalName property in the build-section of the Maven
pom-file:
test
. . .
https://stackoverflow.com/questions/14488509/maven-how-to-rename-the-war-file-for-the-project
PGP key:
https://keys.mailvelope.com/pks/lookup?op=get&search=0xF31094A567CE732E
On Wed, Jun 3, 2020 at 9:44 PM Meir Yanovich
wrote:
> im using the latest version of the maven-ear-plugin
> i like to bundle the test.war into my ear
> but the output is always :
>
> test1-test21999.test-SNAPSHOT.war
>
> which is always the default :
>
> outputFileNameMapping = @{groupId}@-@{artifactId}@-@{version}@
> @{dashClassifier?}@.@{extension}@
>
> how do i force it to be:test.war
>
>
> http://maven.apache.org/POM/4.0.0"; xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="
> http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd
> ">
>
> 4.0.0
>
>
>com.test.id
> artifact_name
>1999_app
>
>
> Test
> ear
> Test
>
>
>
>
> ${project.groupId}
> test1
> war
>
>
>
> myapp
>
>
> myapp
>
>
>
> org.apache.maven.plugins
>
> maven-ear-plugin
>
>
>
>
>
>
>
> test1
>
> Test1
>
>
> test.war
>
>
> test.war
>
>
> /myapp
>
>
>
>
>
>
>
>
>
>
>
>
>
> here is the log after running with -X:
> please notice when it copy and ignoring the renaming
>
> [INFO] Copying artifact [war:test1:test2:1999.test-SNAPSHOT] to
> [test1-test21999.test-SNAPSHOT.war]
>
> [INFO] --- maven-ear-plugin:3.0.1:ear (default-ear) @ web-pserver-ear
> ---
> [DEBUG] Configuring mojo
> org.apache.maven.plugins:maven-ear-plugin:3.0.1:ear from plugin realm
> ClassRealm[plugin>org.apache.maven.plugins:maven-ear-plugin:3.0.1, parent:
> sun.misc.Launcher$AppClassLoader@4e25154f]
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-ear-plugin:3.0.1:ear' with basic
> configurator -->
> [DEBUG] (f) earSourceDirectory = C:\foo\ear\src\main\application
> [DEBUG] (f) earSourceIncludes = **
> [DEBUG] (f) encoding = UTF-8
> [DEBUG] (f) escapedBackslashesInFilePath = false
> [DEBUG] (f) filtering = false
> [DEBUG] (f) finalName =
> web-pserver-ear-2020.vanilla-engage.1-SNAPSHOT
> [DEBUG] (f) generatedDescriptorLocation = C:\foo\target
> [DEBUG] (f) includeLibInApplicationXml = false
> [DEBUG] (f) outputDirectory = C:\foo\target
> [DEBUG] (f) outputFileNameMapping = @{groupId}@-@{artifactId}@
> -@{version}@@{dashClassifier?}@.@{extension}@
> [DEBUG] (f) project = MavenProject: foo-ear:1999.foo1-SNAPSHOT @
> C:foo\ear\pom.xml
> [DEBUG] (f) session =
> org.apache.maven.execution.MavenSession@7569ea63
> [DEBUG] (f) skinnyWars = false
> [DEBUG] (f) skipClassPathModification = false
> [DEBUG] (f) tempFolder =C:\foo\target
> [DEBUG] (f) useJvmChmod = true
> [DEBUG] (f) version = 7
> [DEBUG] (f) workDirectory = C:\foo\target\foo-SNAPSHOT
> [DEBUG] -- end configuration --
> [DEBUG] Resolving artifact type mappings ...
> [DEBUG] Initializing JBoss configuration if necessary ...
> [DEBUG] Initializing ear execution context
> [DEBUG] Resolving ear modules ...
>
>
> [INFO] Copying artifact [war:test1:test2:1999.test-SNAPSHOT] to
> [test1-test21999.test-SNAPSHOT.war]
>
>
> [INFO] Copy ear sources to C:\foo\target\foo-SNAPSHOT
> [DEBUG] Jar archiver implementation
> [org.codehaus.plexus.archiver.jar.JarArchiver]
> [DEBUG] Excluding [] from the generated EAR.
> [DEBUG] Including [**] in the generated EAR.
>
>
maven-ear-plugin bundleFileName don't change the name of the war i want to bundle with the ear
im using the latest version of the maven-ear-plugin
i like to bundle the test.war into my ear
but the output is always :
test1-test21999.test-SNAPSHOT.war
which is always the default :
outputFileNameMapping =
@{groupId}@-@{artifactId}@-@{version}@@{dashClassifier?}@.@{extension}@
how do i force it to be:test.war
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
com.test.id
artifact_name
1999_app
Test
ear
Test
${project.groupId}
test1
war
myapp
myapp
org.apache.maven.plugins
maven-ear-plugin
test1
Test1
test.war
test.war
/myapp
here is the log after running with -X:
please notice when it copy and ignoring the renaming
[INFO] Copying artifact [war:test1:test2:1999.test-SNAPSHOT] to
[test1-test21999.test-SNAPSHOT.war]
[INFO] --- maven-ear-plugin:3.0.1:ear (default-ear) @ web-pserver-ear ---
[DEBUG] Configuring mojo
org.apache.maven.plugins:maven-ear-plugin:3.0.1:ear from plugin realm
ClassRealm[plugin>org.apache.maven.plugins:maven-ear-plugin:3.0.1, parent:
sun.misc.Launcher$AppClassLoader@4e25154f]
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-ear-plugin:3.0.1:ear' with basic configurator
-->
[DEBUG] (f) earSourceDirectory = C:\foo\ear\src\main\application
[DEBUG] (f) earSourceIncludes = **
[DEBUG] (f) encoding = UTF-8
[DEBUG] (f) escapedBackslashesInFilePath = false
[DEBUG] (f) filtering = false
[DEBUG] (f) finalName = web-pserver-ear-2020.vanilla-engage.1-SNAPSHOT
[DEBUG] (f) generatedDescriptorLocation = C:\foo\target
[DEBUG] (f) includeLibInApplicationXml = false
[DEBUG] (f) outputDirectory = C:\foo\target
[DEBUG] (f) outputFileNameMapping =
@{groupId}@-@{artifactId}@-@{version}@@{dashClassifier?}@.@{extension}@
[DEBUG] (f) project = MavenProject: foo-ear:1999.foo1-SNAPSHOT @
C:foo\ear\pom.xml
[DEBUG] (f) session = org.apache.maven.execution.MavenSession@7569ea63
[DEBUG] (f) skinnyWars = false
[DEBUG] (f) skipClassPathModification = false
[DEBUG] (f) tempFolder =C:\foo\target
[DEBUG] (f) useJvmChmod = true
[DEBUG] (f) version = 7
[DEBUG] (f) workDirectory = C:\foo\target\foo-SNAPSHOT
[DEBUG] -- end configuration --
[DEBUG] Resolving artifact type mappings ...
[DEBUG] Initializing JBoss configuration if necessary ...
[DEBUG] Initializing ear execution context
[DEBUG] Resolving ear modules ...
[INFO] Copying artifact [war:test1:test2:1999.test-SNAPSHOT] to
[test1-test21999.test-SNAPSHOT.war]
[INFO] Copy ear sources to C:\foo\target\foo-SNAP
Re: maven-ear-plugin: Cannot copy a directory
Hi, I think I found the reason. In the verify phase, I am executing errorprone, which uses the maven-compiler-plugin. Although I compile to target/classes-ep (instead of target/classes), somehow this seems to un-append artifacts. I think that the execution of an addition compilation should not un-append artifacts from the project build, should it? Ben Am Mo., 3. Feb. 2020 um 11:08 Uhr schrieb Benjamin Marwell : > > Hi all, > > since today my ear-plugin configuration does not work anymore and > stops with an exception. > > I pull in a dependency (type war) from another module in the same > reactor. I also pull the same dependency in again with a classifier > and another type to be used with the maven-assembly-plugin. > > Anyway, maven-ear-plugin does not try to pull in the war file, but the > target/classes directory instead: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-ear-plugin:3.0.1:ear (default-ear) on > project ear: Cannot copy a directory: > $HOME/svn/project/web/ui-v2/target/classes; Did you package/install > project:webui-v2:war:1.4.0-SNAPSHOT:compile? -> [Help 1] > > As I am using verify as goal. I checked that both the packages were > created in the referenced module. > > Any ideas where to look next? > > Thanks, > Ben - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-ear-plugin: Cannot copy a directory
Hi all, since today my ear-plugin configuration does not work anymore and stops with an exception. I pull in a dependency (type war) from another module in the same reactor. I also pull the same dependency in again with a classifier and another type to be used with the maven-assembly-plugin. Anyway, maven-ear-plugin does not try to pull in the war file, but the target/classes directory instead: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-ear-plugin:3.0.1:ear (default-ear) on project ear: Cannot copy a directory: $HOME/svn/project/web/ui-v2/target/classes; Did you package/install project:webui-v2:war:1.4.0-SNAPSHOT:compile? -> [Help 1] As I am using verify as goal. I checked that both the packages were created in the referenced module. Any ideas where to look next? Thanks, Ben - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: ear without libraries
Read the documentation http://maven.apache.org/plugins/maven-ear-plugin/examples/excluding-files-from-ear.html https://maven.apache.org/plugins/maven-resources-plugin/examples/include-exclude.html On Fri, Jun 8, 2018, 12:58 PM Aitor Iturriondobeitia, wrote: > hello > i am trying to use the maven ear for building my ear but into the ear the > lib directory must be without libraries but i cannot make it > how must y use the ear pluging for exclude all dependencies ? > > thanks >
Re: ear without libraries
Hi, Are you using skinnyWars option? Do you have dependencies in your ear project? Can you show your pom file? On 08/06/18 19:58, Aitor Iturriondobeitia wrote: hello i am trying to use the maven ear for building my ear but into the ear the lib directory must be without libraries but i cannot make it how must y use the ear pluging for exclude all dependencies ? thanks Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
ear without libraries
hello i am trying to use the maven ear for building my ear but into the ear the lib directory must be without libraries but i cannot make it how must y use the ear pluging for exclude all dependencies ? thanks
[ANN] Apache Maven EAR Version 3.0.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven EAR Plugin Version 3.0.1 This plugin generates Java EE Enterprise Archive (EAR) file. It can also generate the deployment descriptor file (e.g. application.xml). https://maven.apache.org/plugins/maven-ear-plugin/ Important Note since 3.0.1: * Maven 3.X only * JDK 7 minimum requirement You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-ear-plugin 3.0.1 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-ear-plugin/download.cgi Release Notes Maven EAR Plugin 3.0.1 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317422&version=12342882 Improvements: * [MEAR-265] - Add documentation information for GitHub * [MEAR-266] - Upgrade mave-surefire/failsafe-plugin 2.21.0 Dependency upgrade: * [MEAR-268] - Upgrade plexus-archiver to 3.6.0 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: [ANN] Apache Maven EAR Version 3.0.0 Released
Hi,
> On 15/03/18 12:51, Thorsten Heit wrote:
> > Hi,
> >
> >> The Apache Maven team is pleased to announce the release of the
> >> Apache Maven EAR Plugin Version 3.0.0
> >
> > First of all thanks for releasing a new version of this plugin!
> >
> > I just gave it a try in an internal multi-module project, but now I
can't
> > deploy the EAR anymore to Wildfly 11 server from within Eclipse:
>
>
> Sorry to say...you have expected that major version change to not change
> something ? ...Maybe I misunderstand a thing here...
That was absolutely not my intention :-)
I don't mind if there are changes when a major version is released.
> > Result:
> > After the copying process has finished, Wildfly doesn't start the EAR
> > because it cannot find the WAR module that is referenced in the
> > application.xml....
>
> If I correctly understand that's only happening within Eclipse?
Yes, that's what I'm seeing. Building the EAR from the command line works
(as expected).
> The 3.0.0 version contains a change to handle all the time by default a
> full mapping of artifact names which is noticed on the start page:
>
> http://maven.apache.org/plugins/maven-ear-plugin/
>
> There is which by default contains:
>
> @{groupId}@-@{artifactId}@-@{version}@@{dashClassifier?}@.@{extension}@
>
> So if you like to go back just change this configuration in your build
> and it should work as before but with the risk of failing in case of
> same artifactId's..
Ok, thanks, I'll give this a try.
I guess I won't have failing builds because that's what would already have
happened actually with m-ear-p 2.10.1 ;-)
OTOH, do you know who is responsible for the now invalid output file
mapping with m-ear-p 3.0.0 when I'm deploying the EAR in Eclipse to a
Wildfly server instance? It seems to me that at least in this part there's
a bug (?) because the (change in the) output file name mapping isn't
respected...
Side note:
I like the idea of having the group Id in the file name for artifacts. Is
something similar planned for m-war-p?
Regards
Thorsten
Re: [ANN] Apache Maven EAR Version 3.0.0 Released
Hi,
On 15/03/18 12:51, Thorsten Heit wrote:
Hi,
The Apache Maven team is pleased to announce the release of the
Apache Maven EAR Plugin Version 3.0.0
First of all thanks for releasing a new version of this plugin!
I just gave it a try in an internal multi-module project, but now I can't
deploy the EAR anymore to Wildfly 11 server from within Eclipse:
Sorry to say...you have expected that major version change to not change
something ? ...Maybe I misunderstand a thing here...
Environment:
Eclipse Oxygen.2 (4.7.2, Build id: 20171218-0600)
Wildfly 11
Java 8u162
m2e 1.8.2.20171007-0217
m2e-wtp 1.3.3.20171208-1305
Snippet from my pom.xml:
(...)
org.apache.maven.plugins
maven-ear-plugin
2.10.1
5
true
${project.artifactId}-${project.version}
true
${project.groupId}
myapp-war
/APP
(...)
${project.groupId}
myapp-war
${project.version}
war
Behaviour with m-ear-p 2.10.1:
Deploying the EAR to Wildfly creates a folder in /
standalone/deployments/, and in this folder my war is extracted in a
folder myapp-war-.war. This is also referenced in the generated
application.xml:
web-uri: myapp-war-.war
So far, so good.
Behaviour with m-ear-p 3.0.0:
The same folders are generated, i.e. in
/standalone/deployments/ and myapp-war-${version}.war inside
it, but the generated application.xml now has a different web-uri:
web-uri: -myapp-war-.war
Result:
After the copying process has finished, Wildfly doesn't start the EAR
because it cannot find the WAR module that is referenced in the
application.xml
If I correctly understand that's only happening within Eclipse?
The 3.0.0 version contains a change to handle all the time by default a
full mapping of artifact names which is noticed on the start page:
http://maven.apache.org/plugins/maven-ear-plugin/
There is which by default contains:
@{groupId}@-@{artifactId}@-@{version}@@{dashClassifier?}@.@{extension}@
So if you like to go back just change this configuration in your build
and it should work as before but with the risk of failing in case of
same artifactId's..
Who is causing this strange behaviour? The JBoss/Wildfly integration in
Eclipse? m2e? ...?
And what can I do to make it work again (apart from sticking with m-ear-p
2.10.1)?
Interesting side effect:
Building the EAR via command line works and generates a correct EAR, i.e.
contains the WAR module with the groupId in its name.
Kind regards
Karl Heinz Marbaise
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: [ANN] Apache Maven EAR Version 3.0.0 Released
Hi,
> The Apache Maven team is pleased to announce the release of the
> Apache Maven EAR Plugin Version 3.0.0
First of all thanks for releasing a new version of this plugin!
I just gave it a try in an internal multi-module project, but now I can't
deploy the EAR anymore to Wildfly 11 server from within Eclipse:
Environment:
Eclipse Oxygen.2 (4.7.2, Build id: 20171218-0600)
Wildfly 11
Java 8u162
m2e 1.8.2.20171007-0217
m2e-wtp 1.3.3.20171208-1305
Snippet from my pom.xml:
(...)
org.apache.maven.plugins
maven-ear-plugin
2.10.1
5
true
${project.artifactId}-${project.version}
true
${project.groupId}
myapp-war
/APP
(...)
${project.groupId}
myapp-war
${project.version}
war
Behaviour with m-ear-p 2.10.1:
Deploying the EAR to Wildfly creates a folder in /
standalone/deployments/, and in this folder my war is extracted in a
folder myapp-war-.war. This is also referenced in the generated
application.xml:
web-uri: myapp-war-.war
So far, so good.
Behaviour with m-ear-p 3.0.0:
The same folders are generated, i.e. in
/standalone/deployments/ and myapp-war-${version}.war inside
it, but the generated application.xml now has a different web-uri:
web-uri: -myapp-war-.war
Result:
After the copying process has finished, Wildfly doesn't start the EAR
because it cannot find the WAR module that is referenced in the
application.xml
Who is causing this strange behaviour? The JBoss/Wildfly integration in
Eclipse? m2e? ...?
And what can I do to make it work again (apart from sticking with m-ear-p
2.10.1)?
Interesting side effect:
Building the EAR via command line works and generates a correct EAR, i.e.
contains the WAR module with the groupId in its name.
Best regards
Thorsten
[ANN] Apache Maven EAR Version 3.0.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven EAR Plugin Version 3.0.0 This plugin generates Java EE Enterprise Archive (EAR) file. It can also generate the deployment descriptor file (e.g. application.xml). https://maven.apache.org/plugins/maven-ear-plugin/ Important Note since 3.0.0: * Maven 3.X only * JDK 7 minimum requirement You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-ear-plugin 3.0.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-ear-plugin/download.cgi Release Notes Maven EAR Plugin 3.0.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317422&version=12330696 Bugs: * [MEAR-171] - Full customization of FileNameMapping is needed * [MEAR-217] - Snapshot dependencies are not deleted from skinny WARs * [MEAR-243] - Skinny WARs - JAR not removed from WAR if scope in EAR is set to provided * [MEAR-244] - Remove link to non-existing Codehaus wiki * [MEAR-246] - Upgrade the EAR lifecycle to use the maven-resources-plugin 3.0.2. * [MEAR-250] - IT skinny-wars-javaee5 fails while running with JDK 9 New Features: * [MEAR-247] - resource-ref in generated application.xml * [MEAR-248] - Support lookup-name in env-entry section Improvements: * [MEAR-198] - Add LifecycleMapping and ArtifactHandler from maven-core to target packaging plugin * [MEAR-223] - Link to wiki on documentation page is pointing to shutdown codehaus * [MEAR-226] - bundleFileName functionality for the acr plugin * [MEAR-228] - Remove manifestFile parameter * [MEAR-229] - Change default value for version parameter * [MEAR-232] - Remove param properties that doesn't make sense for CLI usage * [MEAR-234] - Upgrade maven-shared-components parent to version 30 * [MEAR-241] - Change package to o.a.m.plugins * [MEAR-242] - Update lifecycle mapping plugin version * [MEAR-254] - Support JavaEE version 8 * [MEAR-258] - Upgrade site skin to 1.7 * [MEAR-260] - Remove finalName as a parameter * [MEAR-261] - In cases where fileNameMapping is used fail the build * [MEAR-262] - Missing since for outputFileNameMapping parameter * [MEAR-263] - Wrong docs in examples/customize-file-name-mapping.html Tasks: * [MEAR-207] - Remove the JavaModule/Ejb3Module which are marked deprecated * [MEAR-208] - Upgrade to Maven 3.0 compatiblity + JDK 6 * [MEAR-209] - Change and use a internal unique id instead of artifactId only * [MEAR-259] - Fix formatting date issues in apt files Dependency upgrades: * [MEAR-224] - Upgrade plexus-archiver from 2.10.3 to 3.0.1 * [MEAR-233] - Upgrade plexus-archiver from 3.0.3 to 3.1.1 * [MEAR-235] - Upgrade maven-archiver to 3.1.0 * [MEAR-236] - Upgrade maven-filtering to 3.1.1 * [MEAR-237] - Upgrade plexus-archiver to 3.3 * [MEAR-238] - Upgrade of plexus-archiver to 3.4. * [MEAR-240] - Upgrade of maven-archiver to 3.1.1. * [MEAR-245] - Upgrade of plexus-interpolation to 1.24. * [MEAR-251] - Upgrade maven-archiver to 3.2.0 * [MEAR-252] - Upgrade plexus-archiver to 3.5. * [MEAR-253] - Upgrade plexus-utils to version 3.1.0 * [MEAR-255] - Upgrade parent to 31 * [MEAR-256] - Upgrade maven-verifier component * [MEAR-257] - Upgrade JUnit to 4.12 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Customize the bundleFilename template used by the maven-ear-plugin?
Yeah - I was actually just about to respond to my own mail to indicate
exactly that. I don't know how I missed that the first time through the
doc - I think I was looking for a property named something differently.
That's exactly what I was looking for.
Thanks!
Eric
On Tue, Jun 20, 2017 at 1:25 PM, Karl Heinz Marbaise
wrote:
> Hi,
>
> Have you checked the documentation about.. fileNameMapping
>
> the following from the docs:
>
> The file name mapping to use for all dependencies included in the EAR
> file. The following values are valid standard, {code no-version}, full,
> no-version-for-ejb. The standard means the filename is the artifactId incl.
> the version of the artifact. The no-version means the files is only the
> artifactId without the version. The full means the filename is the
> groupId+artifactId+version of the artifact. The no-version-for-ejb means
> the filename is the artifactId without the version in case of EJB type.
>
>
> Are you looking for something like that?
>
>
> Kind regards
> Karl Heinz Marbaise
>
>
>
> On 20/06/17 19:21, Eric B wrote:
>
>> Is there a way to customize the filename used by the maven-ear-plugin for
>> the different modules but in a general template way?
>>
>> At the moment, the bundleFilename by default seems to be:
>> ${artifactId}-${version}.${packaging}
>>
>> I would like to prepend it with a $[groupId} as well.
>> ${groupId}-${artifactId}-${version}.${packaging}
>>
>> where the groupId/artifactId/version/packaging belong to the module in
>> question.
>>
>>
>> However, I do not want to manually specify each module bundleFilename
>> manually.
>>
>> Is there a way to configure this using parameterization?
>>
>> ex:
>>
>> maven-ear-plugin
>>
>>
>> ${groupId}-${artifactId}-${version}.
>> ${packaging}
>> ??
>>
>>
>>
>>
>> Anything remotely similar exist, or anyway to achieve a similar
>> functionality? If I use ${groupId}/etc in the module definition, it
>> actually uses the ${project.groupId} instead of the webmodule.groupId.
>>
>> Thanks,
>>
>> Eric
>>
>>
Re: Customize the bundleFilename template used by the maven-ear-plugin?
Hi,
Have you checked the documentation about.. fileNameMapping
the following from the docs:
The file name mapping to use for all dependencies included in the EAR
file. The following values are valid standard, {code no-version}, full,
no-version-for-ejb. The standard means the filename is the artifactId
incl. the version of the artifact. The no-version means the files is
only the artifactId without the version. The full means the filename is
the groupId+artifactId+version of the artifact. The no-version-for-ejb
means the filename is the artifactId without the version in case of EJB
type.
Are you looking for something like that?
Kind regards
Karl Heinz Marbaise
On 20/06/17 19:21, Eric B wrote:
Is there a way to customize the filename used by the maven-ear-plugin for
the different modules but in a general template way?
At the moment, the bundleFilename by default seems to be:
${artifactId}-${version}.${packaging}
I would like to prepend it with a $[groupId} as well.
${groupId}-${artifactId}-${version}.${packaging}
where the groupId/artifactId/version/packaging belong to the module in
question.
However, I do not want to manually specify each module bundleFilename
manually.
Is there a way to configure this using parameterization?
ex:
maven-ear-plugin
${groupId}-${artifactId}-${version}.${packaging}
??
Anything remotely similar exist, or anyway to achieve a similar
functionality? If I use ${groupId}/etc in the module definition, it
actually uses the ${project.groupId} instead of the webmodule.groupId.
Thanks,
Eric
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Customize the bundleFilename template used by the maven-ear-plugin?
Is there a way to customize the filename used by the maven-ear-plugin for
the different modules but in a general template way?
At the moment, the bundleFilename by default seems to be:
${artifactId}-${version}.${packaging}
I would like to prepend it with a $[groupId} as well.
${groupId}-${artifactId}-${version}.${packaging}
where the groupId/artifactId/version/packaging belong to the module in
question.
However, I do not want to manually specify each module bundleFilename
manually.
Is there a way to configure this using parameterization?
ex:
maven-ear-plugin
${groupId}-${artifactId}-${version}.${packaging}
??
Anything remotely similar exist, or anyway to achieve a similar
functionality? If I use ${groupId}/etc in the module definition, it
actually uses the ${project.groupId} instead of the webmodule.groupId.
Thanks,
Eric
Using maven-ejb-plugin and creating an EAR
Hi,
I've got a JEE project that has EJBs being accessed both locally and
remotely. But I'm not entirely sure how to use the ejb-plugin and the
ear-plugin to create my ear.
At the moment, I'm using the ejb-plugin to create my EJB artifact:
4.0.0
root.project
ejbs
ejb
1.0
enterprise java beans
...
...
maven-ejb-plugin
3.0
true
I am then including the generated ejb in my WAR as follows:
4.0.0
root.project.servlets
servlet
war
servlet
...
root.project
ejbs
${project.version}
ejb
...
...
Finally, in my EAR, I have the following:
4.0.0
root.project
ear
ear
1.0
ear assembly
root.project
ejbs
ejb
root.project.servlets
servlet
war
maven-ear-plugin
lib/
true
true
The EAR builds properly. The issue that I have is that is that the EJB
module is added in both the root of my EAR and in the
servlet.war/WEB-INF/lib folder. The classloader then finds 2 copies of the
classes in my application - one from the WAR and the one from the EAR.
Obviously, this is not right. But I am not sure what the right way to do
this is. Am I obliged to generate an ejb-client and include the ejb-client
in my WAR only? However, then I will still have 2 copies of the interface -
one in the ejb jar and one in the ejb-client.jar. How does this improve the
situation of duplicate classes in the classloader?
Furthermore, I noticed that the ejb-plugin doesn't just put the EJB
interfaces in the client package. By default it puts any Bean inner
classes as well as utility classes, etc. I realize that I can manually
configure the plugin to specify exactly which classes to include or
exclude, but that seems like it is not following the maven conventions over
configuration principles.
What are the best practices and approaches for using EJBs with Maven? What
is the best way to build a WAR/EAR with Maven?
Thanks,
Eric
Re: Building WAR files with/without EAR context
On Fri, 18 Nov 2016 11:17:08 +0100 Stefan Seidel wrote: > you don't usually depend on EJBs in your WARs. That's actually right. You depend on the API (interfaces) of the EJBs. This is usually in separate JAR (but it is not required to be). > You should depend on > ejb- client. IIRC you'll have to explicitely configure your EJB > project to create an ejb-client artifact. You mean this: http://maven.apache.org/plugins/maven-ejb-plugin/examples/generating-ejb-client.html That's one possibility to separate interfaces and classes. But IMHO this only sufficies very simple scenarios. I usually separate the classes and interfaces by hand and have different modules for them. - martin pgpQF_XDm17wF.pgp Description: Digitale Signatur von OpenPGP
Re: Building WAR files with/without EAR context
Hi, you don't usually depend on EJBs in your WARs. You should depend on ejb- client. IIRC you'll have to explicitely configure your EJB project to create an ejb-client artifact. I just tried that though, and the ejb-client JAR is still kept inside the WAR. Are you planning to deploy your WAR files also in a servlet container? Because if not, you could mark the ejb/ejb-client dependency as provided. That's how we solved that. Stefan - On Thursday 17 November 2016 15:07:31 Stefan Seidel wrote: > On 17 Nov 2016, Clemens von Musil wrote: > > We pushed a very minimal example project to a public github repo located > > here: > > > > https://github.com/kr1schan/mavenToy > > > > The project consists of an ear, two war modules, one ejb module and one > > plain jar artifact. > > Both war modules depend on the ejbmodule as well as on the jar artifact. > > SkinnyWar is enabled and configured in all conscience. > > > > After 'mvn clean package', the resulting ear shows correct handling of the > > jar dependency. > > The ejb dependency remains in both war files. > > Good to have a minimal example showing the problem! I confirm that I can > reproduce the buggy (?) behavior. > > Unfortunately I can reproduce it and can't see the error when looking > into it for 5 minutes. Don't have time for a close look right now, sorry. > > - martin
Re: Building WAR files with/without EAR context
On 17 Nov 2016, Clemens von Musil wrote: > We pushed a very minimal example project to a public github repo located > here: > > https://github.com/kr1schan/mavenToy > > The project consists of an ear, two war modules, one ejb module and one > plain jar artifact. > Both war modules depend on the ejbmodule as well as on the jar artifact. > SkinnyWar is enabled and configured in all conscience. > > After 'mvn clean package', the resulting ear shows correct handling of the > jar dependency. > The ejb dependency remains in both war files. Good to have a minimal example showing the problem! I confirm that I can reproduce the buggy (?) behavior. Unfortunately I can reproduce it and can't see the error when looking into it for 5 minutes. Don't have time for a close look right now, sorry. - martin pgpmDxkBhdffg.pgp Description: Digitale Signatur von OpenPGP
Re: Building WAR files with/without EAR context
We pushed a very minimal example project to a public github repo located here: https://github.com/kr1schan/mavenToy The project consists of an ear, two war modules, one ejb module and one plain jar artifact. Both war modules depend on the ejbmodule as well as on the jar artifact. SkinnyWar is enabled and configured in all conscience. After 'mvn clean package', the resulting ear shows correct handling of the jar dependency. The ejb dependency remains in both war files. Can you please point us our error? Thanks a lot, Clemens von Musil P.S: There is a branch called 'ejb-skinny-wars' showing the workaround I described in my latest post. 2016-11-16 10:39 GMT+01:00 Martin Hoeller : > On 16 Nov 2016, Clemens von Musil wrote: > > > This is true for jar dependencies. > > > > But if the war file depends on an artifact with type ejb > > (ejb), the skinnywar-option ignores this dependency and let > it > > remain in war/lib. > > This is not true in general, it works for me! > Did you declare the dependency correct with ejb in *all* > places (WAR and EAR, and maybe a parent POM)) where you reference it? > > > And if there are two war files WAR1 and WAR2 depending on the same > artifact > > with type ejb, the ear isn't deployable as the beans within the > > ejb-artifact resist in WAR1/lib _and_ WAR2/lib. The container tries to > > deploy beans from both loations and struggles as it cannot deploy the > same > > bean twice. > > This is a logical result from the above problem. > > > We found a workaound. We define all dependencies without the type-tag to > > keep the skinnywar-option working. To avoid malicious packaging inside > the > > EAR, we define all these dependencies as jarmodules with explicit deploy > > path and entry in the application.xml. Such a definition looks like > > > > > > groupid > > artifactid > > true > > / > > > > > > Ugly but working. > > This shouldn't be necessary. I really think you have a configuration bug > and missed the ejb in some places. > > - martin > -- Clemens von Musil - mu...@sipgate.de Telefon: +49 (0)211-63 55 56-85 Telefax: +49 (0)211-63 55 55-22 sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391 www.sipgate.de - www.sipgate.at - www.sipgate.co.uk
Re: Building WAR files with/without EAR context
On 16 Nov 2016, Clemens von Musil wrote: > This is true for jar dependencies. > > But if the war file depends on an artifact with type ejb > (ejb), the skinnywar-option ignores this dependency and let it > remain in war/lib. This is not true in general, it works for me! Did you declare the dependency correct with ejb in *all* places (WAR and EAR, and maybe a parent POM)) where you reference it? > And if there are two war files WAR1 and WAR2 depending on the same artifact > with type ejb, the ear isn't deployable as the beans within the > ejb-artifact resist in WAR1/lib _and_ WAR2/lib. The container tries to > deploy beans from both loations and struggles as it cannot deploy the same > bean twice. This is a logical result from the above problem. > We found a workaound. We define all dependencies without the type-tag to > keep the skinnywar-option working. To avoid malicious packaging inside the > EAR, we define all these dependencies as jarmodules with explicit deploy > path and entry in the application.xml. Such a definition looks like > > > groupid > artifactid > true > / > > > Ugly but working. This shouldn't be necessary. I really think you have a configuration bug and missed the ejb in some places. - martin pgpqa8E2V9Nlr.pgp Description: Digitale Signatur von OpenPGP
Re: Building WAR files with/without EAR context
This is true for jar dependencies. But if the war file depends on an artifact with type ejb (ejb), the skinnywar-option ignores this dependency and let it remain in war/lib. And if there are two war files WAR1 and WAR2 depending on the same artifact with type ejb, the ear isn't deployable as the beans within the ejb-artifact resist in WAR1/lib _and_ WAR2/lib. The container tries to deploy beans from both loations and struggles as it cannot deploy the same bean twice. We found a workaound. We define all dependencies without the type-tag to keep the skinnywar-option working. To avoid malicious packaging inside the EAR, we define all these dependencies as jarmodules with explicit deploy path and entry in the application.xml. Such a definition looks like groupid artifactid true / Ugly but working. 2016-11-16 9:24 GMT+01:00 Martin Hoeller : > On 14 Nov 2016, Clemens von Musil wrote: > > > Hi again, > > > > thanks a lot for your advice, Martin. > > > > We spent a lot of time into skinny wars but stuck with ejb dependencies. > > > > The EAR contains several WAR modules and these WAR modules share several > > EJB modules. > > Unfortunately, the skinny war option seems to ignore transitive EJB > > dependencies so that we get errors with duplicate beans on startup. > > The skinnyWar-option should just remove JARs from the WAR that are also > defined in the POM of the EAR module. Nothing special about transitive > dependencies here I' guess. > > Try this again: > https://maven.apache.org/plugins/maven-ear-plugin/ > examples/skinny-wars.html > > If you list a dependency in the EAR, it should then be removed from the > WAR that is bundled with the EAR (this not the WAR installed in your > local repo!). > > If this is not the case, there is either a bug, or you are doing > something wrong. But you would need to provide more details: POMs of the > WAR and the EAR and a listing of the relevant EAR and WAR contents. > > hth, > - martin > -- Clemens von Musil - mu...@sipgate.de Telefon: +49 (0)211-63 55 56-85 Telefax: +49 (0)211-63 55 55-22 sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391 www.sipgate.de - www.sipgate.at - www.sipgate.co.uk
Re: Building WAR files with/without EAR context
On 14 Nov 2016, Clemens von Musil wrote: > Hi again, > > thanks a lot for your advice, Martin. > > We spent a lot of time into skinny wars but stuck with ejb dependencies. > > The EAR contains several WAR modules and these WAR modules share several > EJB modules. > Unfortunately, the skinny war option seems to ignore transitive EJB > dependencies so that we get errors with duplicate beans on startup. The skinnyWar-option should just remove JARs from the WAR that are also defined in the POM of the EAR module. Nothing special about transitive dependencies here I' guess. Try this again: https://maven.apache.org/plugins/maven-ear-plugin/examples/skinny-wars.html If you list a dependency in the EAR, it should then be removed from the WAR that is bundled with the EAR (this not the WAR installed in your local repo!). If this is not the case, there is either a bug, or you are doing something wrong. But you would need to provide more details: POMs of the WAR and the EAR and a listing of the relevant EAR and WAR contents. hth, - martin pgpt83DaVhmrL.pgp Description: Digitale Signatur von OpenPGP
Re: Building WAR files with/without EAR context
Hi again, thanks a lot for your advice, Martin. We spent a lot of time into skinny wars but stuck with ejb dependencies. The EAR contains several WAR modules and these WAR modules share several EJB modules. Unfortunately, the skinny war option seems to ignore transitive EJB dependencies so that we get errors with duplicate beans on startup. All workarounds we could imagine do not work properly. Recently we tried to omit the "ejb" on all EJB dependencies and put all libs into the EAR-root folder. This "hack" leads our wildfly into some unpredictable (and completely messed up state) deploying all beans into any random module... Some sites advice to exclude $(war_module)/lib completely what makes the WAR module undeployable in standalone mode. Could you please point us any direction to get skinny wars working with shared EJB modules? Thanks a lot, Clemens von Musil 2016-11-09 9:18 GMT+01:00 Martin Hoeller : > Hi! > > On 08 Nov 2016, Clemens von Musil wrote: > > > I am working on a multimodule maven project consisting of several EJB, > WAR > > and an EAR module. The EJB modules contain shared functionality. > > > > To increase development speed, I want the WAR modules build in a way that > > allows me to bundle them into the EAR as well as deploy them standalone > in > > my EE container. > > Wrong approach! Build the WAR as you would need it in standalone-mode and > configure the maven-ear-plugin to make the WAR a skinny war. > > Details can be found here: > https://maven.apache.org/plugins/maven-ear-plugin/ > examples/skinny-wars.html > > hth, > - martin > -- Clemens von Musil - mu...@sipgate.de Telefon: +49 (0)211-63 55 56-85 Telefax: +49 (0)211-63 55 55-22 sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391 www.sipgate.de - www.sipgate.at - www.sipgate.co.uk
Re: Building WAR files with/without EAR context
Hi! On 08 Nov 2016, Clemens von Musil wrote: > I am working on a multimodule maven project consisting of several EJB, WAR > and an EAR module. The EJB modules contain shared functionality. > > To increase development speed, I want the WAR modules build in a way that > allows me to bundle them into the EAR as well as deploy them standalone in > my EE container. Wrong approach! Build the WAR as you would need it in standalone-mode and configure the maven-ear-plugin to make the WAR a skinny war. Details can be found here: https://maven.apache.org/plugins/maven-ear-plugin/examples/skinny-wars.html hth, - martin pgp2_fx7oPWiR.pgp Description: Digitale Signatur von OpenPGP
Building WAR files with/without EAR context
Hi all, I am working on a multimodule maven project consisting of several EJB, WAR and an EAR module. The EJB modules contain shared functionality. To increase development speed, I want the WAR modules build in a way that allows me to bundle them into the EAR as well as deploy them standalone in my EE container. I figured out how to accomplish this with profiles. If I build a WAR to be bundeled into the EAR, I'll activate a profile that sets the scope 'provided' for all EJB dependencies. Since the profile activation is somewhat cumbersome (and profiles are somewhat bunt in my company), I am searching for another solution. Does maven provide any handy mechanism? Or is there any plugin doing the work? Thanks a lot, Clemens
Re: Maven ear,jar and war packaging
Not sure how you plan on packaging jars in another jar. That is not allowed per the jar spec, as far as I'm aware. What are you actually doing here? As for packaging only certain jars in an ear or war, that is controlled by the scope for the dependency declared in your pom. This is standard, built-in functionality of Maven and already well documented online if you spend 5 minutes looking for it and reading. Wayne On Fri, Sep 11, 2015 at 10:32 PM, aalok singhvi wrote: > hello, > > I have a project where i want to package certain jars only in an ear , jar > or war . > Any suggestion and best practices. > > Any useful links will really help. > > Thanks > > -- > Aalok Singhvi - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven ear,jar and war packaging
hello, I have a project where i want to package certain jars only in an ear , jar or war . Any suggestion and best practices. Any useful links will really help. Thanks -- Aalok Singhvi
[ANN] Apache Maven EAR Plugin Version 2.10.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven EAR Plugin Version 2.10.1. Sorry the link to the plugin was wrong. The link correctly looks like this: http://maven.apache.org/plugins/maven-ear-plugin/ Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven EAR Plugin Version 2.10.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven EAR Plugin Version 2.10.1. This plugin generates Java EE Enterprise Archive (EAR) file. It can also generate the deployment descriptor file (e.g. application.xml). http://maven.apache.org/maven-ear-plugin/ Release Notes - Apache Maven EAR Plugin - Version 2.10.1 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317422&version=12330698 Bug: * [MEAR-214] - RarModule not seen as standard artifact type Improvements: * [MEAR-159] - encoding when filtering resources * [MEAR-218] - Upgrade plexus-archiver to 2.10.3 * [MEAR-219] - Upgrade to fluido skin * [MEAR-220] - Upgrade plexus-utils to 3.0.22 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven EAR Plugin Version 2.10 Released
The Apache Maven team is pleased to announce the release of the Apache Maven EAR Plugin, version 2.10 This plugin generates Java EE Enterprise Archive (EAR) file. It can also generate the deployment descriptor file (e.g. application.xml). http://maven.apache.org/plugins/maven-ear-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-ear-plugin 2.10 Release Notes - Maven EAR Plugin - Version 2.10 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11132&version=20436 Bugs: * [MEAR-180] - Artifacts with same artifactId/version are ignored in packaging * [MEAR-183] - Extra 'temp' directory created in wrong place * [MEAR-188] - Project property cannot be resolved inside element Improvements: * [MEAR-182] - Skinny WAR's - Skip Class-Path Modification in Manifest * [MEAR-191] - Set prerequisites to Maven 2.2.1 * [MEAR-192] - Update version of plexus-archiver to 2.5 * [MEAR-195] - Removed dependency plexus-container-default:1.0-alpha-9-stable-1 * [MEAR-196] - Update version of plexus-archiver to 2.6.1 * [MEAR-197] - Update version of plexus-archiver to 2.6.2 * [MEAR-199] - Fix integration test which is currently ignored * [MEAR-200] - Upgrade to plexus-archiver 2.7 * [MEAR-202] - Upgrade to maven-plugins version 25 to 26 * [MEAR-203] - Upgrade maven-filtering to 1.3 * [MEAR-204] - Upgrade maven-archiver dependency to v2.6 * [MEAR-205] - Upgrade to maven-plugins parent version 27 * [MEAR-210] - Following naming conventions of maven-surefire/failsafe-plugin New Feature: * [MEAR-181] - Adding ejb-ref in application.xml Tasks: * [MEAR-176] - Upgrading maven-filtering breaks IT * [MEAR-190] - Remove the alias of defaultLibBundleDir Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Bug? maven-ear-plugin 2.9.1 behaves different to 2.9
Hi Karl Heinz! On 26 Nov 2014, Karl Heinz Marbaise wrote: > Hi Martin, > > first can you create a project which reproduces the problem...otherwise > it's really hard to drill down the issue... I don't know if I can create such a project. I'll try and start with a simple project as described in my original post. We'll see if this suffices... > Furthermore have you defined the dependencies in your ear module which > should be skinnyfied... I just checked and I do have most of the dependencies listed in the EAR but some are missing. I'll fix this and see if this changes anything. > Does you ear module contain other dependencies which could have the jars > you don't like to have in your ear as a transitive dependency? Sorry, I don't get you. I want JARs *to be* in the EAR and no to "not be in the EAR". > Can you post your pom file ? Well, the actual project has more than 150 modules without the dependencies. I don't think posting the whole pom makes sense. I'll try to create a sample project instead (could take me some time). If you just want some m-ear-p configuration or the like, just let me know. I could of course post this. [...] > > I'd be happy to provide a sample project but I'm not sure how to > > provide this as it also seems to depend on the infrastructure. > > Hm...you say on one side it's a bug of maven-ear-plugin but here you say > different... ?... As changing the version of the m-ear-p is enough to fix the problem I really do think it's a bug in the ear plugin. But the bug only triggers in situations that depend on the infrastructure. Does this make more sens to you? - martin signature.asc Description: PGP signature
Re: Bug? maven-ear-plugin 2.9.1 behaves different to 2.9
Hi Martin, first can you create a project which reproduces the problem...otherwise it's really hard to drill down the issue... Furthermore have you defined the dependencies in your ear module which should be skinnyfied... Does you ear module contain other dependencies which could have the jars you don't like to have in your ear as a transitive dependency? Can you post your pom file ? On 11/26/14 3:31 PM, Martin Hoeller wrote: Hi! I'm using the maven-ear-plugin to create an EAR with a skinny WAR. This worked fine till I did an update from version 2.9 to version 2.9.1. The actual problem is quite hard to explain, so I'll try and start with an abstract and provide details below. The problem is, the skinny WAR contains a lot more JARs than it should, but not all that are in the original WAR artifact. So it seems the m-ear-p does build a skinny WAR but the decisions what JARs to pack into the WAR are wrong. Changing the used m-ear-p back to version 2.9 fixes the problem, so this is definitely a regression in v2.9.1. The really strange thing is, this does not happen always! It only happens when I build my project the first time a day and a recent version of dependency of the project was not locally installed but was obtained from our local nexus. So it seems version information (or timestamps as all versions are SNAPSHOTs) of the dependencies matters. A concrete example to make this more clear: * My Project E is the EAR. * E depends on an artifact W, a WAR. * E and W have a common dependency D which is also a project of mine. * E, W and D are all built by a CI-server (jenkins) and SNAPSHOTs are deployed to nexus during the night. In the WAR there is D.jar packaged in WEB-INF/lib. In the EAR there is D.jar packaged in lib/ and the skinny WAR should no longer contain D.jar. With m-ear-p 2.9 this worked as expected. With version 2.9.1 when I build E with "mvn clean install" and D was not locally installed earlier this day, the skinny WAR is not skinny. It contains D.jar! Thus, D.jar is located twice in the EAR which is a bug. That sound really strange cause maven-ear-plugin itself does not download artifacts...but we should try to drill down the problem... As soon as I do a "mvn clean install" for D, the building of E starts to work and the WAR is skinny again... till a nightly deploy provides a newer SNAPSHOT of D. Any ideas what could be wrong here? I'd be happy to provide a sample project but I'm not sure how to provide this as it also seems to depend on the infrastructure. Hm...you say on one side it's a bug of maven-ear-plugin but here you say different... ?... TIA, - martin PS: I reported a (maybe) related issue half a year ago without any feedback. Not sure if this could provide some extra info: http://maven.40175.n5.nabble.com/bug-in-maven-ear-plugin-with-skinny-war-td5792646.html Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Bug? maven-ear-plugin 2.9.1 behaves different to 2.9
Hi! I'm using the maven-ear-plugin to create an EAR with a skinny WAR. This worked fine till I did an update from version 2.9 to version 2.9.1. The actual problem is quite hard to explain, so I'll try and start with an abstract and provide details below. The problem is, the skinny WAR contains a lot more JARs than it should, but not all that are in the original WAR artifact. So it seems the m-ear-p does build a skinny WAR but the decisions what JARs to pack into the WAR are wrong. Changing the used m-ear-p back to version 2.9 fixes the problem, so this is definitely a regression in v2.9.1. The really strange thing is, this does not happen always! It only happens when I build my project the first time a day and a recent version of dependency of the project was not locally installed but was obtained from our local nexus. So it seems version information (or timestamps as all versions are SNAPSHOTs) of the dependencies matters. A concrete example to make this more clear: * My Project E is the EAR. * E depends on an artifact W, a WAR. * E and W have a common dependency D which is also a project of mine. * E, W and D are all built by a CI-server (jenkins) and SNAPSHOTs are deployed to nexus during the night. In the WAR there is D.jar packaged in WEB-INF/lib. In the EAR there is D.jar packaged in lib/ and the skinny WAR should no longer contain D.jar. With m-ear-p 2.9 this worked as expected. With version 2.9.1 when I build E with "mvn clean install" and D was not locally installed earlier this day, the skinny WAR is not skinny. It contains D.jar! Thus, D.jar is located twice in the EAR which is a bug. As soon as I do a "mvn clean install" for D, the building of E starts to work and the WAR is skinny again... till a nightly deploy provides a newer SNAPSHOT of D. Any ideas what could be wrong here? I'd be happy to provide a sample project but I'm not sure how to provide this as it also seems to depend on the infrastructure. TIA, - martin PS: I reported a (maybe) related issue half a year ago without any feedback. Not sure if this could provide some extra info: http://maven.40175.n5.nabble.com/bug-in-maven-ear-plugin-with-skinny-war-td5792646.html signature.asc Description: PGP signature
Re: Replacing token in WAR web.xml from EAR pom.xml
Certainly not ideal. I'm very surprised that maven doesn't profile finer
grained phases. If there a way to have my EAR pom set a property that is
shared by it's dependencies? Perhaps I can then filter the web project
with such a global property.
On Mon, Sep 22, 2014 at 3:12 AM, Anders Hammar wrote:
> The solution that comes to my mind is to have one common war module and
> then use war overlays and create separat war modules for each "flavor" of
> the webapp you need (one for each ear I guess). It means many modules
> unfortunately, but is somewhat the Maven way.
>
> Google on "maven war overlay" for more info.
>
> /Anders
>
> On Sat, Sep 20, 2014 at 5:16 AM, Grover Blue
> wrote:
>
> > Hello, I'm new to maven, and trying to navigate all the plugins and
> > syntax. Forgive me if this has been asked previously, but I can't seem
> to
> > things to work.
> >
> > I have a root/parent project that contains several EAR projects, all
> which
> > use the same WAR project. I need to customize the contents of web.xml
> for
> > each EAR build/package. I'm not clear on the steps to do this. I tried
> > copying my ANT script over to the pom, but even though I could update the
> > copied web.war, it never carries over to the final *.ear package.
> >
> > Here is what I'm attempting (shortcut.targetFull and realmName are
> defined
> > properties in this pom):
> >
> >
> >
> >
> > org.apache.maven.plugins
> > maven-antrun-plugin
> > 1.7
> >
> >
> >
> >
> >
> >
> > *
> > rename-realm
> >
> >
> > > src="${shortcut.targetFull}/web-${project.version}.war" dest="${*
> > *shortcut.targetFull}/web"/> > file="${*
> > *shortcut.targetFull}/web/WEB-INF/web.xml" token="@REALM_NAME@"
> > value="${realmName}"/>
> > > basedir="${*
> > *shortcut.targetFull}/web" /> > dir="${*
> >
> >
> >
> >
> >
> > *shortcut.targetFull}/web" />
> >
> >
> > run
> > *
> >
> > rename-package
> >
> >
> >
> >
> > > pattern="MMdd-HHmmss" locale="en,US"/>
> >
> > > file="${project.build.directory}/${project.build.finalName}.ear"
> > tofile="${project.build.directory}/${project.name
> > }-${project.version}-${TODAY_BUILD}.ear"/>
> >
> >
> >
> >
> >
> >
> > org.apache.maven.plugins
> > maven-compiler-plugin
> > 3.1
> >
> > 1.7
> > 1.7
> >
> >
> >
> > org.apache.maven.plugins
> > maven-ear-plugin
> > 2.9
> >
> > 6
> > lib
> > myweb
> > true
> >
> >
> > ${project.groupId}
> > lib1
> >
> > false
> >
> >
> > ${project.groupId}
> > ejb1
> >
> >
> > ${project.groupId}
> > web
> > /myweb
> >
> >
> >
> >
> >
> >
> >
>
--
“If the American people ever allow private banks to control the issue of
their currency, first by inflation, then by deflation, the banks...will
deprive the people of all property until their children wake-up homeless on
the continent their fathers conquered... The issuing power should be taken
from the banks and restored to the people, to whom it properly belongs."
-- Thomas Jefferson
"Government big enough to supply everything...is big enough to take
everything you have. The course of history shows that as a government
grows, liberty decreases" --- Thomas Jefferson
www.CampaignForLiberty.org
Re: Replacing token in WAR web.xml from EAR pom.xml
The solution that comes to my mind is to have one common war module and
then use war overlays and create separat war modules for each "flavor" of
the webapp you need (one for each ear I guess). It means many modules
unfortunately, but is somewhat the Maven way.
Google on "maven war overlay" for more info.
/Anders
On Sat, Sep 20, 2014 at 5:16 AM, Grover Blue wrote:
> Hello, I'm new to maven, and trying to navigate all the plugins and
> syntax. Forgive me if this has been asked previously, but I can't seem to
> things to work.
>
> I have a root/parent project that contains several EAR projects, all which
> use the same WAR project. I need to customize the contents of web.xml for
> each EAR build/package. I'm not clear on the steps to do this. I tried
> copying my ANT script over to the pom, but even though I could update the
> copied web.war, it never carries over to the final *.ear package.
>
> Here is what I'm attempting (shortcut.targetFull and realmName are defined
> properties in this pom):
>
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.7
>
>
>
>
>
>
> *
> rename-realm
>
>
> src="${shortcut.targetFull}/web-${project.version}.war" dest="${*
> *shortcut.targetFull}/web"/> file="${*
> *shortcut.targetFull}/web/WEB-INF/web.xml" token="@REALM_NAME@"
> value="${realmName}"/>
> basedir="${*
> *shortcut.targetFull}/web" /> dir="${*
>
>
>
>
>
> *shortcut.targetFull}/web" />
>
>
> run
> *
>
> rename-package
>
>
>
>
> pattern="MMdd-HHmmss" locale="en,US"/>
>
> file="${project.build.directory}/${project.build.finalName}.ear"
> tofile="${project.build.directory}/${project.name
> }-${project.version}-${TODAY_BUILD}.ear"/>
>
>
>
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.1
>
> 1.7
> 1.7
>
>
>
> org.apache.maven.plugins
> maven-ear-plugin
> 2.9
>
> 6
> lib
> myweb
> true
>
>
> ${project.groupId}
> lib1
>
> false
>
>
> ${project.groupId}
> ejb1
>
>
> ${project.groupId}
> web
> /myweb
>
>
>
>
>
>
>
Replacing token in WAR web.xml from EAR pom.xml
Hello, I'm new to maven, and trying to navigate all the plugins and
syntax. Forgive me if this has been asked previously, but I can't seem to
things to work.
I have a root/parent project that contains several EAR projects, all which
use the same WAR project. I need to customize the contents of web.xml for
each EAR build/package. I'm not clear on the steps to do this. I tried
copying my ANT script over to the pom, but even though I could update the
copied web.war, it never carries over to the final *.ear package.
Here is what I'm attempting (shortcut.targetFull and realmName are defined
properties in this pom):
org.apache.maven.plugins
maven-antrun-plugin
1.7
*
rename-realm
run
*
rename-package
org.apache.maven.plugins
maven-compiler-plugin
3.1
1.7
1.7
org.apache.maven.plugins
maven-ear-plugin
2.9
6
lib
myweb
true
${project.groupId}
lib1
false
${project.groupId}
ejb1
${project.groupId}
web
/myweb
[ANN] Apache Maven EAR Plugin 2.9.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven EAR Plugin, version 2.9.1 This plugin (insert short description of the plugin's purpose). http://maven.apache.org/plugins/maven-ear-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-ear-plugin 2.9.1 Release Notes - Maven EAR Plugin Plugin - Version 2.9.1 Bug * [MEAR-189] - fileNameMapping set to no-version breaks skinnyWars feature Task * [MEAR-185] - Deprecated reference to 'defaultJavaBundleDir' in plugin documentation Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-ear-plugin fileNameMapping set to no-version breaks skinnyWars
I have my plugin configured as: maven-ear-plugin 2.9 lib/ true no-version And the inclusion of no-version which I need, causes all the wars to fat. How can I fix this? Is this a known bug? -Dave
bug in maven-ear-plugin with skinny war?
Hi! I see strange behavior when using the maven EAR plugin with the skinnyWar [1] feature, which might be a bug. Here is the (simplified) module-structure I have: core +-- core-shared web +-- backend +-- war ee +-- ear Usually all modules share the same version (let's say 1.0) number. My "ear" module includes a skinny version of the war module, "core-shared" and some other 3rd-party dependencies. This works fine. However, when I update all modules to version 2.0-SNAPSHOT but keep the dependency on the "war" in the "ear" to version 1.0, the skinny war is no longer skinny. Instead the "war" 1.0 in the "ear" contains "core-shared" 1.0 dependency but the "ear" contains core-shared 2.0-SNAPSHOT. Thus, the dependency is included twice with different versions. IMHO the EAR plugin doesn't respect artifact's version information when removing JARs from the skinny war, but only removes JARs that match exactly (including version string). I'd consider this a bug. Or at least a missing feature in the EAR plugin. What do others think? Should I create a JIRA entry? thx, - martin [1] http://maven.apache.org/plugins/maven-ear-plugin/examples/skinny-wars.html signature.asc Description: PGP signature
Re: maven-ear-plugin silently overrides libraries
I confirm that the use case you mention is supposed to work transparently. This most likely looks like a bug. Thanks for reporting this. S. On Fri, Feb 7, 2014 at 3:21 PM, Reto Hablützel wrote: > Hi there, > > I built an ear using the maven-ear-plugin (version 2.6). > > The ear is configured such that it includes two libraries into the lib > folder, both with the same artifactId as well as the same version, but a > different groupId. Now if I simply call 'mvn package' only the first one is > included, but no warning whatsoever appears. Only once I turn on debugging > (mvn --debug package), I see one subtle message: > [DEBUG] Skipping artifact [jar:com.foo:bar:1.0] as it is already up to date > at [lib/bar-1.0.jar] > > Wouldn't it make sense to either include the groupId in the filename or at > least make a check (that includes the groupId) beforehand if there are any > conflicts? > > Cheers, > Reto >
Re: maven-ear-plugin silently overrides libraries
Thank you, Anders. I reported the issue: http://jira.codehaus.org/browse/MEAR-180 - Reto On Fri, Feb 14, 2014 at 7:52 AM, Anders Hammar wrote: > You need to create an account at Codehaus Xircles. Go to > http://jira.codehaus.org and there is more info in the top left hand > gadget/box. > > /Anders > > > On Fri, Feb 14, 2014 at 7:46 AM, Reto Hablützel wrote: > > > Is JIRA open for public registration / issue creation? I could not find a > > link to sign up.. > > > > Anyways, I attached a sample project. Please follow these steps to > > recreate the issue (btw. I think the whole naming thing is also a problem > > if you are referencing two ejbs with the same artifactId and version): > > > > Install 'utilities' project in 'collections': > > collections/utilities> mvn install > > > > Install 'utilities' project in 'email': > > email/utilities> mvn install > > > > Package 'ear' project: > > ear> mvn package > > > > Look at contents of ear and notice how only one jar is included: > > ear> unzip -v target/ear-1.0.0.ear > > > > Now use the debug flag to see why only one gets included: > > ear> mvn --debug clean package > > > > Partial output: > > [INFO] Copying artifact [jar:ch.rethab.email:utilities:1.0.0] to > > [utilities-1.0.0.jar] > > [DEBUG] Skipping artifact [jar:ch.rethab.collections:utilities:1.0.0], > > as it is already up to date at [utilities-1.0.0.jar] > > > > > > > > > > On Thu, Feb 13, 2014 at 7:32 PM, Baptiste Mathus >wrote: > > > >> That's the way to go. Even more if you're able to attach a test project. > >> One report without report is far less likely to be worked on. > >> Cheers > >> Le 13 févr. 2014 14:06, "Reto Hablützel" a écrit : > >> > >> > So what's the status on this? Shall I create a ticket? > >> > > >> > > >> > On Fri, Feb 7, 2014 at 5:04 PM, Ron Wheeler > >> > wrote: > >> > > >> > > Exclusions will not help in this case. > >> > > Looking through the dependency hierarchy will at least get you to > see > >> the > >> > > problem earlier which I think was the nature of your question. > >> > > > >> > > It appears from my brief reading and fun with making servlets run in > >> > > production that classloaders merge classes by name. > >> > > Maven does not. > >> > > > >> > > I am a bit surprised that groupId does not count. > >> > > > >> > > If one uses a lot of third -party libraries, it would seem > inevitable > >> > that > >> > > you could need com.artifact-software:utilities:1.0 at the same time > as > >> > > ch.rethab:utilities:1.0 at the same time. > >> > > The classloader is not going to cause any problem but if Maven > throws > >> out > >> > > one of these as a duplicate, you will be missing classes at > run-time. > >> > > > >> > > It is difficult to force everyone to create unique artifactIds > unless > >> you > >> > > get rid of the GroupId altogther and make GAV -> and put the > >> group > >> > > name into the artifactID. > >> > > > >> > > This seems to be a design flaw if it is true. > >> > > > >> > > Ron > >> > > > >> > > > >> > > On 07/02/2014 9:43 AM, Reto Hablützel wrote: > >> > > > >> > >> Sure, but exclusions don't do the trick if you need both of them, > do > >> > >> they? I am talking about completely independent libraries that > >> happen to > >> > >> have the same artifactId. > >> > >> > >> > >> Those were actually both libraries of mine and I could obviously > fix > >> > this > >> > >> issue rather simply, but I was just thinking that it would be > >> helpful to > >> > >> have at least a warning or something from maven - regardless of the > >> IDE. > >> > >> > >> > >> - Reto > >> > >> > >> > >> > >> > >> On Fri, Feb 7, 2014 at 3:33 PM, Ron Wheeler > >> >> > >> com <mailto:rwhee...@artifact-software.com>> wrote: > >> > >> > >> > >>
Re: maven-ear-plugin silently overrides libraries
You need to create an account at Codehaus Xircles. Go to http://jira.codehaus.org and there is more info in the top left hand gadget/box. /Anders On Fri, Feb 14, 2014 at 7:46 AM, Reto Hablützel wrote: > Is JIRA open for public registration / issue creation? I could not find a > link to sign up.. > > Anyways, I attached a sample project. Please follow these steps to > recreate the issue (btw. I think the whole naming thing is also a problem > if you are referencing two ejbs with the same artifactId and version): > > Install 'utilities' project in 'collections': > collections/utilities> mvn install > > Install 'utilities' project in 'email': > email/utilities> mvn install > > Package 'ear' project: > ear> mvn package > > Look at contents of ear and notice how only one jar is included: > ear> unzip -v target/ear-1.0.0.ear > > Now use the debug flag to see why only one gets included: > ear> mvn --debug clean package > > Partial output: > [INFO] Copying artifact [jar:ch.rethab.email:utilities:1.0.0] to > [utilities-1.0.0.jar] > [DEBUG] Skipping artifact [jar:ch.rethab.collections:utilities:1.0.0], > as it is already up to date at [utilities-1.0.0.jar] > > > > > On Thu, Feb 13, 2014 at 7:32 PM, Baptiste Mathus wrote: > >> That's the way to go. Even more if you're able to attach a test project. >> One report without report is far less likely to be worked on. >> Cheers >> Le 13 févr. 2014 14:06, "Reto Hablützel" a écrit : >> >> > So what's the status on this? Shall I create a ticket? >> > >> > >> > On Fri, Feb 7, 2014 at 5:04 PM, Ron Wheeler >> > wrote: >> > >> > > Exclusions will not help in this case. >> > > Looking through the dependency hierarchy will at least get you to see >> the >> > > problem earlier which I think was the nature of your question. >> > > >> > > It appears from my brief reading and fun with making servlets run in >> > > production that classloaders merge classes by name. >> > > Maven does not. >> > > >> > > I am a bit surprised that groupId does not count. >> > > >> > > If one uses a lot of third -party libraries, it would seem inevitable >> > that >> > > you could need com.artifact-software:utilities:1.0 at the same time as >> > > ch.rethab:utilities:1.0 at the same time. >> > > The classloader is not going to cause any problem but if Maven throws >> out >> > > one of these as a duplicate, you will be missing classes at run-time. >> > > >> > > It is difficult to force everyone to create unique artifactIds unless >> you >> > > get rid of the GroupId altogther and make GAV -> and put the >> group >> > > name into the artifactID. >> > > >> > > This seems to be a design flaw if it is true. >> > > >> > > Ron >> > > >> > > >> > > On 07/02/2014 9:43 AM, Reto Hablützel wrote: >> > > >> > >> Sure, but exclusions don't do the trick if you need both of them, do >> > >> they? I am talking about completely independent libraries that >> happen to >> > >> have the same artifactId. >> > >> >> > >> Those were actually both libraries of mine and I could obviously fix >> > this >> > >> issue rather simply, but I was just thinking that it would be >> helpful to >> > >> have at least a warning or something from maven - regardless of the >> IDE. >> > >> >> > >> - Reto >> > >> >> > >> >> > >> On Fri, Feb 7, 2014 at 3:33 PM, Ron Wheeler >> > > >> com <mailto:rwhee...@artifact-software.com>> wrote: >> > >> >> > >> If your IDE supports Maven (Eclipse/STS for example), you will >> see >> > >> the conflict in the dependency hierarchy view and you can fix it >> > >> with the right exclusions. >> > >> >> > >> It is almost always worth a quick look through the dependency >> > >> hierarchy view if you use a lot of third party libraries. >> > >> Not everyone updates their dependencies when they build a >> > >> shareable library. >> > >> You can sometimes get some pretty old versions of things dragged >> > >> in with the latest version of otherwise we
Re: maven-ear-plugin silently overrides libraries
That's the way to go. Even more if you're able to attach a test project. One report without report is far less likely to be worked on. Cheers Le 13 févr. 2014 14:06, "Reto Hablützel" a écrit : > So what's the status on this? Shall I create a ticket? > > > On Fri, Feb 7, 2014 at 5:04 PM, Ron Wheeler > wrote: > > > Exclusions will not help in this case. > > Looking through the dependency hierarchy will at least get you to see the > > problem earlier which I think was the nature of your question. > > > > It appears from my brief reading and fun with making servlets run in > > production that classloaders merge classes by name. > > Maven does not. > > > > I am a bit surprised that groupId does not count. > > > > If one uses a lot of third -party libraries, it would seem inevitable > that > > you could need com.artifact-software:utilities:1.0 at the same time as > > ch.rethab:utilities:1.0 at the same time. > > The classloader is not going to cause any problem but if Maven throws out > > one of these as a duplicate, you will be missing classes at run-time. > > > > It is difficult to force everyone to create unique artifactIds unless you > > get rid of the GroupId altogther and make GAV -> and put the group > > name into the artifactID. > > > > This seems to be a design flaw if it is true. > > > > Ron > > > > > > On 07/02/2014 9:43 AM, Reto Hablützel wrote: > > > >> Sure, but exclusions don't do the trick if you need both of them, do > >> they? I am talking about completely independent libraries that happen to > >> have the same artifactId. > >> > >> Those were actually both libraries of mine and I could obviously fix > this > >> issue rather simply, but I was just thinking that it would be helpful to > >> have at least a warning or something from maven - regardless of the IDE. > >> > >> - Reto > >> > >> > >> On Fri, Feb 7, 2014 at 3:33 PM, Ron Wheeler >> com <mailto:rwhee...@artifact-software.com>> wrote: > >> > >> If your IDE supports Maven (Eclipse/STS for example), you will see > >> the conflict in the dependency hierarchy view and you can fix it > >> with the right exclusions. > >> > >> It is almost always worth a quick look through the dependency > >> hierarchy view if you use a lot of third party libraries. > >> Not everyone updates their dependencies when they build a > >> shareable library. > >> You can sometimes get some pretty old versions of things dragged > >> in with the latest version of otherwise well-written libraries. > >> Exclusions need to be added to get what you want in your artifacts. > >> > >> Ron > >> > >> > >> On 07/02/2014 9:21 AM, Reto Hablützel wrote: > >> > >> Hi there, > >> > >> I built an ear using the maven-ear-plugin (version 2.6). > >> > >> The ear is configured such that it includes two libraries into > >> the lib > >> folder, both with the same artifactId as well as the same > >> version, but a > >> different groupId. Now if I simply call 'mvn package' only the > >> first one is > >> included, but no warning whatsoever appears. Only once I turn > >> on debugging > >> (mvn --debug package), I see one subtle message: > >> [DEBUG] Skipping artifact [jar:com.foo:bar:1.0] as it is > >> already up to date > >> at [lib/bar-1.0.jar] > >> > >> Wouldn't it make sense to either include the groupId in the > >> filename or at > >> least make a check (that includes the groupId) beforehand if > >> there are any > >> conflicts? > >> > >> Cheers, > >> Reto > >> > >> > >> > >> -- Ron Wheeler > >> President > >> Artifact Software Inc > >> email: rwhee...@artifact-software.com > >> <mailto:rwhee...@artifact-software.com> > >> > >> skype: ronaldmwheeler > >> phone: 866-970-2435, ext 102 > >> > >> > >> > - > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> <mailto:users-unsubscr...@maven.apache.org> > >> > >> For additional commands, e-mail: users-h...@maven.apache.org > >> <mailto:users-h...@maven.apache.org> > >> > >> > >> > > > > -- > > Ron Wheeler > > President > > Artifact Software Inc > > email: rwhee...@artifact-software.com > > skype: ronaldmwheeler > > phone: 866-970-2435, ext 102 > > > > >
Re: maven-ear-plugin silently overrides libraries
So what's the status on this? Shall I create a ticket? On Fri, Feb 7, 2014 at 5:04 PM, Ron Wheeler wrote: > Exclusions will not help in this case. > Looking through the dependency hierarchy will at least get you to see the > problem earlier which I think was the nature of your question. > > It appears from my brief reading and fun with making servlets run in > production that classloaders merge classes by name. > Maven does not. > > I am a bit surprised that groupId does not count. > > If one uses a lot of third -party libraries, it would seem inevitable that > you could need com.artifact-software:utilities:1.0 at the same time as > ch.rethab:utilities:1.0 at the same time. > The classloader is not going to cause any problem but if Maven throws out > one of these as a duplicate, you will be missing classes at run-time. > > It is difficult to force everyone to create unique artifactIds unless you > get rid of the GroupId altogther and make GAV -> and put the group > name into the artifactID. > > This seems to be a design flaw if it is true. > > Ron > > > On 07/02/2014 9:43 AM, Reto Hablützel wrote: > >> Sure, but exclusions don't do the trick if you need both of them, do >> they? I am talking about completely independent libraries that happen to >> have the same artifactId. >> >> Those were actually both libraries of mine and I could obviously fix this >> issue rather simply, but I was just thinking that it would be helpful to >> have at least a warning or something from maven - regardless of the IDE. >> >> - Reto >> >> >> On Fri, Feb 7, 2014 at 3:33 PM, Ron Wheeler > com <mailto:rwhee...@artifact-software.com>> wrote: >> >> If your IDE supports Maven (Eclipse/STS for example), you will see >> the conflict in the dependency hierarchy view and you can fix it >> with the right exclusions. >> >> It is almost always worth a quick look through the dependency >> hierarchy view if you use a lot of third party libraries. >> Not everyone updates their dependencies when they build a >> shareable library. >> You can sometimes get some pretty old versions of things dragged >> in with the latest version of otherwise well-written libraries. >> Exclusions need to be added to get what you want in your artifacts. >> >> Ron >> >> >> On 07/02/2014 9:21 AM, Reto Hablützel wrote: >> >> Hi there, >> >> I built an ear using the maven-ear-plugin (version 2.6). >> >> The ear is configured such that it includes two libraries into >> the lib >> folder, both with the same artifactId as well as the same >> version, but a >> different groupId. Now if I simply call 'mvn package' only the >> first one is >> included, but no warning whatsoever appears. Only once I turn >> on debugging >> (mvn --debug package), I see one subtle message: >> [DEBUG] Skipping artifact [jar:com.foo:bar:1.0] as it is >> already up to date >> at [lib/bar-1.0.jar] >> >> Wouldn't it make sense to either include the groupId in the >> filename or at >> least make a check (that includes the groupId) beforehand if >> there are any >> conflicts? >> >> Cheers, >> Reto >> >> >> >> -- Ron Wheeler >> President >> Artifact Software Inc >> email: rwhee...@artifact-software.com >> <mailto:rwhee...@artifact-software.com> >> >> skype: ronaldmwheeler >> phone: 866-970-2435, ext 102 >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> <mailto:users-unsubscr...@maven.apache.org> >> >> For additional commands, e-mail: users-h...@maven.apache.org >> <mailto:users-h...@maven.apache.org> >> >> >> > > -- > Ron Wheeler > President > Artifact Software Inc > email: rwhee...@artifact-software.com > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > >
Re: maven-ear-plugin silently overrides libraries
Exclusions will not help in this case.
Looking through the dependency hierarchy will at least get you to see
the problem earlier which I think was the nature of your question.
It appears from my brief reading and fun with making servlets run in
production that classloaders merge classes by name.
Maven does not.
I am a bit surprised that groupId does not count.
If one uses a lot of third -party libraries, it would seem inevitable
that you could need com.artifact-software:utilities:1.0 at the same time
as ch.rethab:utilities:1.0 at the same time.
The classloader is not going to cause any problem but if Maven throws
out one of these as a duplicate, you will be missing classes at run-time.
It is difficult to force everyone to create unique artifactIds unless
you get rid of the GroupId altogther and make GAV -> and put the
group name into the artifactID.
This seems to be a design flaw if it is true.
Ron
On 07/02/2014 9:43 AM, Reto Hablützel wrote:
Sure, but exclusions don't do the trick if you need both of them, do
they? I am talking about completely independent libraries that happen
to have the same artifactId.
Those were actually both libraries of mine and I could obviously fix
this issue rather simply, but I was just thinking that it would be
helpful to have at least a warning or something from maven -
regardless of the IDE.
- Reto
On Fri, Feb 7, 2014 at 3:33 PM, Ron Wheeler
<mailto:rwhee...@artifact-software.com>> wrote:
If your IDE supports Maven (Eclipse/STS for example), you will see
the conflict in the dependency hierarchy view and you can fix it
with the right exclusions.
It is almost always worth a quick look through the dependency
hierarchy view if you use a lot of third party libraries.
Not everyone updates their dependencies when they build a
shareable library.
You can sometimes get some pretty old versions of things dragged
in with the latest version of otherwise well-written libraries.
Exclusions need to be added to get what you want in your artifacts.
Ron
On 07/02/2014 9:21 AM, Reto Hablützel wrote:
Hi there,
I built an ear using the maven-ear-plugin (version 2.6).
The ear is configured such that it includes two libraries into
the lib
folder, both with the same artifactId as well as the same
version, but a
different groupId. Now if I simply call 'mvn package' only the
first one is
included, but no warning whatsoever appears. Only once I turn
on debugging
(mvn --debug package), I see one subtle message:
[DEBUG] Skipping artifact [jar:com.foo:bar:1.0] as it is
already up to date
at [lib/bar-1.0.jar]
Wouldn't it make sense to either include the groupId in the
filename or at
least make a check (that includes the groupId) beforehand if
there are any
conflicts?
Cheers,
Reto
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
<mailto:rwhee...@artifact-software.com>
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
<mailto:users-unsubscr...@maven.apache.org>
For additional commands, e-mail: users-h...@maven.apache.org
<mailto:users-h...@maven.apache.org>
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: maven-ear-plugin silently overrides libraries
Robert Scholte wrote: > Hi, > > See > http://maven.apache.org/plugins/maven-ear-plugin/examples/customize-file-name-mapping.html > for custom filename mapping. Hmmm, IIRC the war plugin will automatically prepend the groupId for all jars with clashing name. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-ear-plugin silently overrides libraries
Hi Robert, this sure is an option but only once you know where all those ClassNotFoundExceptions are coming from. I would like to avoid them in the first place ;) - Reto On Fri, Feb 7, 2014 at 3:43 PM, Robert Scholte wrote: > Hi, > > See http://maven.apache.org/plugins/maven-ear-plugin/ > examples/customize-file-name-mapping.html for custom filename mapping. > > Robert > > Op Fri, 07 Feb 2014 15:21:54 +0100 schreef Reto Hablützel < > ret...@rethab.ch>: > > > Hi there, >> >> I built an ear using the maven-ear-plugin (version 2.6). >> >> The ear is configured such that it includes two libraries into the lib >> folder, both with the same artifactId as well as the same version, but a >> different groupId. Now if I simply call 'mvn package' only the first one >> is >> included, but no warning whatsoever appears. Only once I turn on debugging >> (mvn --debug package), I see one subtle message: >> [DEBUG] Skipping artifact [jar:com.foo:bar:1.0] as it is already up to >> date >> at [lib/bar-1.0.jar] >> >> Wouldn't it make sense to either include the groupId in the filename or at >> least make a check (that includes the groupId) beforehand if there are any >> conflicts? >> >> Cheers, >> Reto >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: maven-ear-plugin silently overrides libraries
Sure, but exclusions don't do the trick if you need both of them, do they? I am talking about completely independent libraries that happen to have the same artifactId. Those were actually both libraries of mine and I could obviously fix this issue rather simply, but I was just thinking that it would be helpful to have at least a warning or something from maven - regardless of the IDE. - Reto On Fri, Feb 7, 2014 at 3:33 PM, Ron Wheeler wrote: > If your IDE supports Maven (Eclipse/STS for example), you will see the > conflict in the dependency hierarchy view and you can fix it with the right > exclusions. > > It is almost always worth a quick look through the dependency hierarchy > view if you use a lot of third party libraries. > Not everyone updates their dependencies when they build a shareable > library. > You can sometimes get some pretty old versions of things dragged in with > the latest version of otherwise well-written libraries. > Exclusions need to be added to get what you want in your artifacts. > > Ron > > > On 07/02/2014 9:21 AM, Reto Hablützel wrote: > >> Hi there, >> >> I built an ear using the maven-ear-plugin (version 2.6). >> >> The ear is configured such that it includes two libraries into the lib >> folder, both with the same artifactId as well as the same version, but a >> different groupId. Now if I simply call 'mvn package' only the first one >> is >> included, but no warning whatsoever appears. Only once I turn on debugging >> (mvn --debug package), I see one subtle message: >> [DEBUG] Skipping artifact [jar:com.foo:bar:1.0] as it is already up to >> date >> at [lib/bar-1.0.jar] >> >> Wouldn't it make sense to either include the groupId in the filename or at >> least make a check (that includes the groupId) beforehand if there are any >> conflicts? >> >> Cheers, >> Reto >> >> > > -- > Ron Wheeler > President > Artifact Software Inc > email: rwhee...@artifact-software.com > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: maven-ear-plugin silently overrides libraries
Hi, See http://maven.apache.org/plugins/maven-ear-plugin/examples/customize-file-name-mapping.html for custom filename mapping. Robert Op Fri, 07 Feb 2014 15:21:54 +0100 schreef Reto Hablützel : Hi there, I built an ear using the maven-ear-plugin (version 2.6). The ear is configured such that it includes two libraries into the lib folder, both with the same artifactId as well as the same version, but a different groupId. Now if I simply call 'mvn package' only the first one is included, but no warning whatsoever appears. Only once I turn on debugging (mvn --debug package), I see one subtle message: [DEBUG] Skipping artifact [jar:com.foo:bar:1.0] as it is already up to date at [lib/bar-1.0.jar] Wouldn't it make sense to either include the groupId in the filename or at least make a check (that includes the groupId) beforehand if there are any conflicts? Cheers, Reto - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-ear-plugin silently overrides libraries
If your IDE supports Maven (Eclipse/STS for example), you will see the conflict in the dependency hierarchy view and you can fix it with the right exclusions. It is almost always worth a quick look through the dependency hierarchy view if you use a lot of third party libraries. Not everyone updates their dependencies when they build a shareable library. You can sometimes get some pretty old versions of things dragged in with the latest version of otherwise well-written libraries. Exclusions need to be added to get what you want in your artifacts. Ron On 07/02/2014 9:21 AM, Reto Hablützel wrote: Hi there, I built an ear using the maven-ear-plugin (version 2.6). The ear is configured such that it includes two libraries into the lib folder, both with the same artifactId as well as the same version, but a different groupId. Now if I simply call 'mvn package' only the first one is included, but no warning whatsoever appears. Only once I turn on debugging (mvn --debug package), I see one subtle message: [DEBUG] Skipping artifact [jar:com.foo:bar:1.0] as it is already up to date at [lib/bar-1.0.jar] Wouldn't it make sense to either include the groupId in the filename or at least make a check (that includes the groupId) beforehand if there are any conflicts? Cheers, Reto -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-ear-plugin silently overrides libraries
Hi there, I built an ear using the maven-ear-plugin (version 2.6). The ear is configured such that it includes two libraries into the lib folder, both with the same artifactId as well as the same version, but a different groupId. Now if I simply call 'mvn package' only the first one is included, but no warning whatsoever appears. Only once I turn on debugging (mvn --debug package), I see one subtle message: [DEBUG] Skipping artifact [jar:com.foo:bar:1.0] as it is already up to date at [lib/bar-1.0.jar] Wouldn't it make sense to either include the groupId in the filename or at least make a check (that includes the groupId) beforehand if there are any conflicts? Cheers, Reto
Re: turns EAR into an OSGi
Thank you very much for all your responses. -- View this message in context: http://maven.40175.n5.nabble.com/turns-EAR-into-an-OSGi-tp5781929p5782017.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: turns EAR into an OSGi
> have all the poms that build my whole project. I would like to know If > making only some changes in my pom.xml that package a "ear" I could change > it into an osgi bundle. I don't want to change my architecture or design This is not an unreasonable question, but you just might not get an answer to your question here. I have never (thus far) needed to do such a thing, so while I know a lot about Maven and plugins etc, I have no idea how to turn an EAR into an OSGi module. You may have better luck asking this question on an OSGi list somewhere - perhaps there is an OSGi plugin for Maven and you could ask their user/dev list? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: turns EAR into an OSGi
Hi thank you very much for your response. Maybe I asked in a wrong way but I have everything made yet with maven. I have all the poms that build my whole project. I would like to know If making only some changes in my pom.xml that package a "ear" I could change it into an osgi bundle. I don't want to change my architecture or design only add the necessary OSGi metadata to my project. Thank you very much. -- View this message in context: http://maven.40175.n5.nabble.com/turns-EAR-into-an-OSGi-tp5781929p5781991.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: turns EAR into an OSGi
Hi, Seems not so much a maven question. More an OSGi one. IMO, you should start by thinking about or explaining what you would expect maven to do. Knowing both Java EE and OSGi (here it's bundles) a bit, I can't see even doing it manually anything obvious to something approaching a conversion. Le 20 janv. 2014 18:39, "acostela" a écrit : > Hi everybody. > > I'm a bit new with maven. I've worked with it before but no in the depth > that I need now. I have searched trough internet and inside this forum and > I > didn't found anything conclusive to my question. > > I have an Enterprise Java application that it's build with Maven and it has > several modules in it. I have some EJBs other kind of classes and packages > like Jars etc. I use an ear package to build all together into an .ear > package. I would like to turns this into an OSGi. Can I do this with maven? > What it's the best way to achieve this? > > Thank you very much to everybody. > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/turns-EAR-into-an-OSGi-tp5781929.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
turns EAR into an OSGi
Hi everybody. I'm a bit new with maven. I've worked with it before but no in the depth that I need now. I have searched trough internet and inside this forum and I didn't found anything conclusive to my question. I have an Enterprise Java application that it's build with Maven and it has several modules in it. I have some EJBs other kind of classes and packages like Jars etc. I use an ear package to build all together into an .ear package. I would like to turns this into an OSGi. Can I do this with maven? What it's the best way to achieve this? Thank you very much to everybody. -- View this message in context: http://maven.40175.n5.nabble.com/turns-EAR-into-an-OSGi-tp5781929.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Ear Plugin 2.9 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Ear Plugin, version 2.9 This plugin generates a Java EE Enterprise Archive (EAR) file. It can also generate the deployment descriptor file (e.g. application.xml). http://maven.apache.org/plugins/maven-ear-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-ear-plugin 2.9 Release Notes - Apache Maven Ear Plugin - Version 2.9 ** Bug * [MEAR-149] - skinnyWars and SNAPSHOT unique dependencies * [MEAR-158] - Elements library-directory and env-entry out of sequence in application.xml for JEE 6 * [MEAR-160] - Performance regression while copying artifacts into ear * [MEAR-162] - skinnyWars with wars without manifest Class-Path attribute * [MEAR-167] - Classes from different modules with the same artifactId are merged when skinnyWars set to TRUE ** Improvement * [MEAR-88] - Improve documentation on combining Eclipse and Maven Integration * [MEAR-164] - support for useJvmChmod in archiver and true per default * [MEAR-169] - Add support for EAR 7 * [MEAR-172] - Enhance the exception thrown when the EAR plugin can not map an included artifact * [MEAR-174] - generate-application-xml does not support the definition of an application id * [MEAR-178] - Change "J2EE" and sun link on index page Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-ear-pugin modify applicaion.xml
thanks used following setting to get it work. src/main/resources/META-INF/application.xml On Thu, Oct 17, 2013 at 6:26 PM, Wayne Fay wrote: > > I have requirement to exclude some entries in application.xml during ear > > build. > ... > > In my case I need to maintain the same EAR structure in the build but > have > > to exclude entries Alpha.jar and Beta.jar from application.xml during > build. > > I am fairly certain you can provide an application.xml rather than > just taking the one that Maven generates for you. Check the > configuration options & documentation for m-ear-p. > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: maven-ear-pugin modify applicaion.xml
> I have requirement to exclude some entries in application.xml during ear > build. ... > In my case I need to maintain the same EAR structure in the build but have > to exclude entries Alpha.jar and Beta.jar from application.xml during build. I am fairly certain you can provide an application.xml rather than just taking the one that Maven generates for you. Check the configuration options & documentation for m-ear-p. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-ear-pugin modify applicaion.xml
Hi, I have requirement to exclude some entries in application.xml during ear build. application.xml generated by maven-ear-plugin is as follows http://java.sun.com/xml/ns/javaee"; xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation=" http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_5.xsd"; version="5"> The EAR packaging for the server side of Application ApplicationEAR Alpha.jar Beta.jar Theta.jar Delta.war /Delta/root With EAR structure ApplicationEAR |--Alpha.jar |--Beta.jar |--Theta.jar |--Delta.jar In my case I need to maintain the same EAR structure in the build but have to exclude entries Alpha.jar and Beta.jar from application.xml during build. How can I achive the same?
Maven ear plugin: cannot generate ejb-local-refs?
Wanted to confirm that although you can generate elements using the Maven ear plugin, you cannot generate in the application.xml from the plugin itself. My only alternative is to own the whole application.xml, i.e. disable its generation, yes? Thanks, Best, Laird -- http://about.me/lairdnelson
Re: Using Maven to produce an EAR
On Wed, Jun 12, 2013 at 7:17 AM, rdiddly wrote: > Thanks Laird, that did the trick. BTW, I didn't specify the dependency in > the > EAR's pom. It's specified in the EJB-jar's pom and that dependency is > apparently being picked up when building the EAR. > There you go. If it helps, my .ear file pom.xmls usually only have EJB modules (.wars, EJBs) listed in them; everything else is included transitively. Best, Laird -- http://about.me/lairdnelson
Re: Using Maven to produce an EAR
Thanks Laird, that did the trick. BTW, I didn't specify the dependency in the EAR's pom. It's specified in the EJB-jar's pom and that dependency is apparently being picked up when building the EAR. -- View this message in context: http://maven.40175.n5.nabble.com/Using-Maven-to-produce-an-EAR-tp5759041p5759127.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Using Maven to produce an EAR
A clean build revealed many problems building the different artifacts due to other small changes along the way. I'll have to do this more frequently as I develop this mechanism. I have resolved each of those issues and you were right, the jar got removed from the root. Next I will try the default lib approach. -- View this message in context: http://maven.40175.n5.nabble.com/Using-Maven-to-produce-an-EAR-tp5759041p5759125.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Using Maven to produce an EAR
On Tue, Jun 11, 2013 at 1:26 PM, rdiddly wrote: > I found that if I didn't use the jarModule in the configuration, > thirdparty.jar was put into the root directory of the ear instead of in the > lib folder (which is where I believe I want it), so I added the jarModule > block to specify that the thirdparty.jar should be put in the lib > directory. > It is now put in the lib directory. Great. But, it's also in the root > directory. > You're probably missing the defaultLibBundleDir configuration option, documented here: http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#defaultLibBundleDir Here's more or less what you want: whatever someWar someVersion war whatever someEJB someVersion ejb whatever *someOrdinaryJar* someVersion ** maven-ear-plugin *lib* *6* No modules necessary (at this level of configuration); no other configuration. Of note: the version parameter defaults to something godawful like 1.3, which is why you have to specify it here. The defaultLibBundleDir has no default, so you have to specify "lib". I regard both of these things as bugs. Hope that helps you out. Best, Laird -- http://about.me/lairdnelson
Re: Using Maven to produce an EAR
> I can build all of the sub-modules without any problems. Here's my pom to > build the ear (missing the open/close tags from XML, using ':' to separate > opening tag from content): Don't bother with this next time. Just post the XML. (Why did you feel the need to strip the tags? Nabble fixed their code so xml should pass thru properly.) > I found that if I didn't use the jarModule in the configuration, > thirdparty.jar was put into the root directory of the ear instead of in the > lib folder (which is where I believe I want it), so I added the jarModule > block to specify that the thirdparty.jar should be put in the lib directory. > It is now put in the lib directory. Great. But, it's also in the root > directory. Most likely you have not run "mvn clean" in a while so the jar is still in /target and thus its showing up in the root directory. I bet it will only be in lib if you run "mvn clean package" instead. Try it and report back. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Using Maven to produce an EAR
Hello Maven mavens, Forgive me if this is a duplicate. I sent it by email, but didn't see it show up on the Nabble site, so I don't know if sending it to the list via email works or not. Good documentation on the maven ear plugin is not easy to find. Most posts are from 2005. I've got a multi-module POM. It has 6 sub-modules: client.war client-ejb.jar admin.war common-ejb.jar app.ear command.jar I want to build client.war, client-ejb.jar, admin.war, and common-ejb.jar into bundle.ear. common-ejb.jar has a compile time dependency on thirdparty.jar (which is in my local repository). (command.jar is a command-line java utility class that's used to execute jobs from a remote client.) I can build all of the sub-modules without any problems. Here's my pom to build the ear (missing the open/close tags from XML, using ':' to separate opening tag from content): project modelVersion:4.0.0/modelVersion parent groupId:com.company/groupId artifactId:jewels/artifactId version:1.0-SNAPSHOT/version /parent groupId:com.company/groupId artifactId:bundle/artifactId version:1.0-SNAPSHOT/version packaging:ear/packaging name:bundle/name properties project.build.sourceEncoding:UTF-8/project.build.sourceEncoding /properties dependencies dependency groupId:com.company/groupId artifactId:client/artifactId version:1.0-SNAPSHOT/version type:war/type /dependency dependency groupId:com.company/groupId artifactId:client-ejb/artifactId version:1.0-SNAPSHOT/version type:ejb/type /dependency dependency groupId:com.company/groupId artifactId:admin/artifactId version:1.0-SNAPSHOT/version type:war/type /dependency dependency groupId:com.company/groupId artifactId:common-ejb/artifactId version:1.0-SNAPSHOT/version type:ejb/type /dependency /dependencies build plugins plugin groupId:org.apache.maven.plugins/groupId artifactId:maven-ear-plugin/artifactId version:2.8/version configuration modules jarModule groupId:third.party/groupId artifactId:thirdparty/artifactId bundleDir:lib/bundleDir /jarModule /modules /configuration /plugin /plugins /build /project I found that if I didn't use the jarModule in the configuration, thirdparty.jar was put into the root directory of the ear instead of in the lib folder (which is where I believe I want it), so I added the jarModule block to specify that the thirdparty.jar should be put in the lib directory. It is now put in the lib directory. Great. But, it's also in the root directory. I'm sure I'm doing something wrong, but it's hard to tell what given the dearth of good examples. Can anyone lend some assistance? Thanks, Richard P.S. I'm in the very early stages of trying to move this project from Ant to Maven. If there's anything about what you see here that you think I should be doing differently (not that I've given the whole story, but from this excerpt), please don't hesitate to let me know. -- View this message in context: http://maven.40175.n5.nabble.com/Using-Maven-to-produce-an-EAR-tp5759041.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: cargo:deploy ear on parent pom
Hi, I'm having this same problem. Did you resolve? Could you share with me the solution? -- View this message in context: http://maven.40175.n5.nabble.com/cargo-deploy-ear-on-parent-pom-tp124132p5738792.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven - maven-ear-plugin - packagingIncludes not working
Hello,
I am having difficulties using the packagingIncludes existing in the ear
plugin.
Here is part of my pom file:
org.apache.maven.plugins
maven-ear-plugin
2.5
lib/
lib/
${basedir}
**/META-INF/**
**/CVS/**,**/target/*
1.4
lu.ept.tmp
SoaWebServices
SoaWebServices
SoaWebServices.war
lu.ept.tmp
NGOSSAdapterEJB
lib
**/*SNAPSHOT.jar,**/*SNAPSHOT.war
What I expect, is to have an /lib folder containing only jar ending with
SNAPSHOT.jar but I currently get all the transitives dependencies.
Any help would be grateful welcome :)
Vaneri
--
View this message in context:
http://maven.40175.n5.nabble.com/maven-maven-ear-plugin-packagingIncludes-not-working-tp5728847.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Manifest of WAR contains wrong references to SNAPSHOT-versions of EAR-based libaries
Just resending the part of Michael's email/post that was eaten by Nabble and not forwarded... You just have to add the following entry to your manifest configuration bundled with the maven war plguin: true false Wayne On Fri, Oct 5, 2012 at 5:03 AM, Michael Feichtegger wrote: > Probable you know already the reason why there is a timestamp and a > buildnumber being attached to your Manifest classpath but for all those who > will have the same issue I will provide a solution: > > You just have to add the following entry to your manifest configuration > bundled with the maven war plguin: > > > > Setting the "useUniqueVersions" flag to "false", which is "true" by default, > instructs maven to use the SNAPSHOT-jar in the manifest classpath. > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Manifest-of-WAR-contains-wrong-references-to-SNAPSHOT-versions-of-EAR-based-libaries-tp5717908p5724922.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Manifest of WAR contains wrong references to SNAPSHOT-versions of EAR-based libaries
Probable you know already the reason why there is a timestamp and a buildnumber being attached to your Manifest classpath but for all those who will have the same issue I will provide a solution: You just have to add the following entry to your manifest configuration bundled with the maven war plguin: Setting the "useUniqueVersions" flag to "false", which is "true" by default, instructs maven to use the SNAPSHOT-jar in the manifest classpath. -- View this message in context: http://maven.40175.n5.nabble.com/Manifest-of-WAR-contains-wrong-references-to-SNAPSHOT-versions-of-EAR-based-libaries-tp5717908p5724922.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Ear Plugin skinnyWars EJB problem
Not sure what you mean. A brief sample config? -- View this message in context: http://maven.40175.n5.nabble.com/Ear-Plugin-skinnyWars-EJB-problem-tp563p5723651.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Ear Plugin skinnyWars EJB problem
In that case WAR Overlays[1] come into picture. Markku [1] http://maven.apache.org/plugins/maven-war-plugin/overlays.html On 09/25/2012 05:57 PM, nskmda wrote: Well, okay, I read that instruction. But I may also need to have a WAR artifact including all dependent EJBs in case I want to deploy it as WAR only, no EAR. In this case I still need to preserve original WAR dependencies. And I need m-ear-p to strip them if they're a listed as EAR dependencies (when I configure m-ear-p to produce "skinnyWar" modules). This doesn't really work. Whatever jar dependencies I have in my EAR artifact get stripped from the WAR. But no ejb EAR dependencies get stripped from WAR. And I can't do a jar on them because I will loose the capability (to generate proper application.xml). I guess, there was something in mind when making m-ear-p to skip those ejb dependencies when stripping down WAR artifact. -- View this message in context: http://maven.40175.n5.nabble.com/Ear-Plugin-skinnyWars-EJB-problem-tp563p5723616.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Ear Plugin skinnyWars EJB problem
Well, okay, I read that instruction. But I may also need to have a WAR artifact including all dependent EJBs in case I want to deploy it as WAR only, no EAR. In this case I still need to preserve original WAR dependencies. And I need m-ear-p to strip them if they're a listed as EAR dependencies (when I configure m-ear-p to produce "skinnyWar" modules). This doesn't really work. Whatever jar dependencies I have in my EAR artifact get stripped from the WAR. But no ejb EAR dependencies get stripped from WAR. And I can't do a jar on them because I will loose the capability (to generate proper application.xml). I guess, there was something in mind when making m-ear-p to skip those ejb dependencies when stripping down WAR artifact. -- View this message in context: http://maven.40175.n5.nabble.com/Ear-Plugin-skinnyWars-EJB-problem-tp563p5723616.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven EAR Plugin 2.8 Released
The Maven team is pleased to announce the release of the Maven EAR Plugin, version 2.8 The plugin generates a JavaEE Enterprise Archive (EAR) file. http://maven.apache.org/plugins/maven-ear-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-ear-plugin 2.8 Release Notes - Maven 2.x Ear Plugin - Version 2.8 ** Bug * [MEAR-147] - wrong DOCTPYE in jboss-app.xml for 4.2 * [MEAR-151] - Allow empty library-directory element in application.xml ** Improvement * [MEAR-141] - No way to configure generate env-entry elements in generated application.xml * [MEAR-145] - Add Maven version used to Created-By entry in manifest * [MEAR-146] - Expose parameter to not write library-directory element in application.xml ** New Feature * [MEAR-150] - Support new 'no-version-for-ejb' file name mapping ** Task * [MEAR-152] - use maven-plugin-tools' java 5 annotations Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [SOLVED] maven-ear-plugin is not including jarModule into application.xml
mvn help:effective-pom is your friend here.
S.
On Thu, Aug 23, 2012 at 5:20 PM, Stuart Stephen
wrote:
> I worked it out. I was being an idiot as usual. User error.
>
> Strangely it was producing the EAR file pretty much correctly, even though my
> plugin wasn't configured properly.
>
> I replaced...
>
> maven-ear-plugin
> maven-ear-plugin
> with...
>
> org.apache.maven.plugins
> maven-ear-plugin
> Then changed...
>
> true
> to...
>
> true
>
> Suddenly it did what I asked. Clever that.
>
> -Original Message-
> From: Stuart Stephen [mailto:stuart.step...@tracegroup.com]
> Sent: 23 August 2012 16:01
> To: users@maven.apache.org
> Subject: maven-ear-plugin is not including jarModule into application.xml
>
> Hi,
>
> [This question is also on StackOverflow:
> http://stackoverflow.com/questions/12093346/maven-ear-plugin-is-not-including-jarmodule-into-application-xml]
>
> I've been following the example on the maven-ear-plugin site that [shows how
> to add third-party libraries to the generated application.xml][1]. However,
> it does not appear to be working as I expected. Similarly the web module
> [contextRoot][2] is being ignored.
>
> According to the [documentation][3] what I am trying to do should be entirely
> possible.
>
> The context root of a Web module might be customized using the contextRoot
> parameter.
> Please note that third party libraries (i.e. JarModule) are not included in
> the generated application.xml (only ejb-client should be included in a java
> entry). However, a jar dependency could be included in the generated
> application.xml by specifying the includeInApplicationXml flag.
>
> I have the following output when it executes the build in my application.xml.
>
>
> "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN"
> "http://java.sun.com/dtd/application_1_3.dtd";>
>
> MyApp.EAR
>
> MyApp.jar
>
>
>
> MyApp.war
> /MyApp.Web
>
>
>
>
> From the following maven configuraton (pom.xml).
> ...
> 4.0.0
> com.blah
> MyApp.EAR
> 1.0
> ear
>
>
>
>
> maven-ear-plugin
> maven-ear-plugin
> 2.7
>
> MyApp
>
>
> com.blah
> MyApp.EJB
>
>
> com.blah
> MyApp.Web
> MyApp
>
>
> org.slf4j
> slf4j-simple
>
> true
>
>
>
>
>
> ${weblogic.version}
>
>
>
>
>
>
>
>
>
>
> com.blah
> MyApp.EJB
> 1.0
> ejb
>
>
> com.blah
> MyApp.Web
> 1.0
> war
>
>
> ...
>
> It is immediately obvious that the application.xml is not being generated as
> I intended.
> 1. The contextRoot supplied is not correct in the application.xml, instead
> the default name of MyApp.Web is output instead of the specified MyApp.
> 2. The org.slf4j jarModule specified is missing entirely from the
> application.xml.
> What am I doing wrong?
> Debug from Maven is shown below.
>
> [DEBUG]
> -------
> [DEBUG] Goal:
> org.apache.maven.plugins:maven-ear-plugin:2.4.2:generate-application-xml
> (default-generate-application-xml)
> [DEBUG] Style: Regular
> [DEBUG] Configuration:
> ${project.description}
> ${project.artifactId}
>
>
> ${project.build.directory}
>
> ${project}
>
>
> ${project.build.directory}/${project.build.finalName}
>
>
> [1]:
> http://maven.apache.org/plugins/maven-ear-plugin/examples/including-a-third-party-library-in-application-xml.html
> [2]: http://maven.apache.org/plugins/maven-ear-plugin/modules.html#webModule
> [3]:
> http://maven.apache.org/plugins/maven-ear-plugin/usage.html#Advanced_ConfigurationDisclaimer:
>
> The contents of this E-mail plus any attachment is intended for the use of
> the addressee only and is confidential, proprietary and may be privileged. It
> will not be binding upon Trace Group or any group company (Trace). Opinions,
> conclusions, contractual
Re: [SOLVED] maven-ear-plugin is not including jarModule into application.xml
Hi Stuart,
> org.apache.maven.plugins
> maven-ear-plugin
FWIW you can leave off the groupId if it begins with
"org.apache.maven.plugins" and Maven will figure out what you mean. Very
handy since the vast majority of the plugins you typically want to
configure are the core ones from that groupId.
-Curtis
On Thu, Aug 23, 2012 at 10:20 AM, Stuart Stephen <
stuart.step...@tracegroup.com> wrote:
> I worked it out. I was being an idiot as usual. User error.
>
> Strangely it was producing the EAR file pretty much correctly, even though
> my plugin wasn't configured properly.
>
> I replaced...
>
> maven-ear-plugin
> maven-ear-plugin
> with...
>
> org.apache.maven.plugins
> maven-ear-plugin
> Then changed...
>
> true
> to...
>
> true
>
> Suddenly it did what I asked. Clever that.
>
> -Original Message-
> From: Stuart Stephen [mailto:stuart.step...@tracegroup.com]
> Sent: 23 August 2012 16:01
> To: users@maven.apache.org
> Subject: maven-ear-plugin is not including jarModule into application.xml
>
> Hi,
>
> [This question is also on StackOverflow:
> http://stackoverflow.com/questions/12093346/maven-ear-plugin-is-not-including-jarmodule-into-application-xml
> ]
>
> I've been following the example on the maven-ear-plugin site that [shows
> how to add third-party libraries to the generated application.xml][1].
> However, it does not appear to be working as I expected. Similarly the web
> module [contextRoot][2] is being ignored.
>
> According to the [documentation][3] what I am trying to do should be
> entirely possible.
>
> The context root of a Web module might be customized using the contextRoot
> parameter.
> Please note that third party libraries (i.e. JarModule) are not included
> in the generated application.xml (only ejb-client should be included in a
> java entry). However, a jar dependency could be included in the generated
> application.xml by specifying the includeInApplicationXml flag.
>
> I have the following output when it executes the build in my
> application.xml.
>
>
> "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN"
> "http://java.sun.com/dtd/application_1_3.dtd";>
>
> MyApp.EAR
>
> MyApp.jar
>
>
>
> MyApp.war
> /MyApp.Web
>
>
>
>
> From the following maven configuraton (pom.xml).
> ...
> 4.0.0
> com.blah
> MyApp.EAR
> 1.0
> ear
>
>
>
>
> maven-ear-plugin
> maven-ear-plugin
> 2.7
>
> MyApp
>
>
> com.blah
> MyApp.EJB
>
>
> com.blah
> MyApp.Web
> MyApp
>
>
> org.slf4j
> slf4j-simple
>
> true
>
>
>
>
>
> ${weblogic.version}
>
>
>
>
>
>
>
>
>
>
> com.blah
> MyApp.EJB
> 1.0
> ejb
>
>
> com.blah
> MyApp.Web
> 1.0
> war
>
>
> ...
>
> It is immediately obvious that the application.xml is not being generated
> as I intended.
> 1. The contextRoot supplied is not correct in the application.xml, instead
> the default name of MyApp.Web is output instead of the specified MyApp.
> 2. The org.slf4j jarModule specified is missing entirely from the
> application.xml.
> What am I doing wrong?
> Debug from Maven is shown below.
>
> [DEBUG]
> -------
> [DEBUG] Goal:
> org.apache.maven.plugins:maven-ear-plugin:2.4.2:generate-application-xml
> (default-generate-application-xml)
> [DEBUG] Style: Regular
> [DEBUG] Configuration:
>
> ${project.description}
> ${project.artifactId}
>
>
> ${project.build.directory}
>
> ${project}
>
>
> ${project.build.directory}/${project.build.finalName}
>
>
> [1]:
> http://maven.apache.org/plugins/maven-ear-plugin/examples/including-a-third-party-library-in-application-xml.html
> [2]:
> http://maven.apache.org/plugins/maven-ear-plugin/modules.html#webModule
> [3]:
> http://maven.apache.org/plugins/maven-ear-plugin/usage.html#Advanced_ConfigurationDisclaimer
> :
>
> The contents of
RE: [SOLVED] maven-ear-plugin is not including jarModule into application.xml
I worked it out. I was being an idiot as usual. User error.
Strangely it was producing the EAR file pretty much correctly, even though my
plugin wasn't configured properly.
I replaced...
maven-ear-plugin
maven-ear-plugin
with...
org.apache.maven.plugins
maven-ear-plugin
Then changed...
true
to...
true
Suddenly it did what I asked. Clever that.
-Original Message-
From: Stuart Stephen [mailto:stuart.step...@tracegroup.com]
Sent: 23 August 2012 16:01
To: users@maven.apache.org
Subject: maven-ear-plugin is not including jarModule into application.xml
Hi,
[This question is also on StackOverflow:
http://stackoverflow.com/questions/12093346/maven-ear-plugin-is-not-including-jarmodule-into-application-xml]
I've been following the example on the maven-ear-plugin site that [shows how to
add third-party libraries to the generated application.xml][1]. However, it
does not appear to be working as I expected. Similarly the web module
[contextRoot][2] is being ignored.
According to the [documentation][3] what I am trying to do should be entirely
possible.
The context root of a Web module might be customized using the contextRoot
parameter.
Please note that third party libraries (i.e. JarModule) are not included in the
generated application.xml (only ejb-client should be included in a java entry).
However, a jar dependency could be included in the generated application.xml by
specifying the includeInApplicationXml flag.
I have the following output when it executes the build in my application.xml.
http://java.sun.com/dtd/application_1_3.dtd";>
MyApp.EAR
MyApp.jar
MyApp.war
/MyApp.Web
>From the following maven configuraton (pom.xml).
...
4.0.0
com.blah
MyApp.EAR
1.0
ear
maven-ear-plugin
maven-ear-plugin
2.7
MyApp
com.blah
MyApp.EJB
com.blah
MyApp.Web
MyApp
org.slf4j
slf4j-simple
true
${weblogic.version}
com.blah
MyApp.EJB
1.0
ejb
com.blah
MyApp.Web
1.0
war
...
It is immediately obvious that the application.xml is not being generated as I
intended.
1. The contextRoot supplied is not correct in the application.xml, instead the
default name of MyApp.Web is output instead of the specified MyApp.
2. The org.slf4j jarModule specified is missing entirely from the
application.xml.
What am I doing wrong?
Debug from Maven is shown below.
[DEBUG] ---
[DEBUG] Goal:
org.apache.maven.plugins:maven-ear-plugin:2.4.2:generate-application-xml
(default-generate-application-xml)
[DEBUG] Style: Regular
[DEBUG] Configuration:
${project.description}
${project.artifactId}
${project.build.directory}
${project}
${project.build.directory}/${project.build.finalName}
[1]:
http://maven.apache.org/plugins/maven-ear-plugin/examples/including-a-third-party-library-in-application-xml.html
[2]: http://maven.apache.org/plugins/maven-ear-plugin/modules.html#webModule
[3]:
http://maven.apache.org/plugins/maven-ear-plugin/usage.html#Advanced_ConfigurationDisclaimer:
The contents of this E-mail plus any attachment is intended for the use of the
addressee only and is confidential, proprietary and may be privileged. It will
not be binding upon Trace Group or any group company (Trace). Opinions,
conclusions, contractual obligations and other information in this message in
so far as they relate to the official business of Trace must be specifically
confirmed in writing by Trace. If you are not the intended recipient you must
not copy this message or attachment, use or disclose the contents to any other
person, but are requested to telephone or E-mail the sender and delete the
message and any attachment from your system. Trace takes all reasonable
precautions to ensure that no virus or defect is transmitted via this e mail,
however Trace accepts no responsibility for any virus or defect that might
arise from opening this E-mail or attachments.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.orgDisclaimer:
The contents of this E-mail plus any attachment is intended for the use of the
addressee only and is confidential, proprietary and may be privil
maven-ear-plugin is not including jarModule into application.xml
Hi,
[This question is also on StackOverflow:
http://stackoverflow.com/questions/12093346/maven-ear-plugin-is-not-including-jarmodule-into-application-xml]
I've been following the example on the maven-ear-plugin site that [shows how to
add third-party libraries to the generated application.xml][1]. However, it
does not appear to be working as I expected. Similarly the web module
[contextRoot][2] is being ignored.
According to the [documentation][3] what I am trying to do should be entirely
possible.
The context root of a Web module might be customized using the contextRoot
parameter.
Please note that third party libraries (i.e. JarModule) are not included in the
generated application.xml (only ejb-client should be included in a java entry).
However, a jar dependency could be included in the generated application.xml by
specifying the includeInApplicationXml flag.
I have the following output when it executes the build in my application.xml.
http://java.sun.com/dtd/application_1_3.dtd";>
MyApp.EAR
MyApp.jar
MyApp.war
/MyApp.Web
>From the following maven configuraton (pom.xml).
...
4.0.0
com.blah
MyApp.EAR
1.0
ear
maven-ear-plugin
maven-ear-plugin
2.7
MyApp
com.blah
MyApp.EJB
com.blah
MyApp.Web
MyApp
org.slf4j
slf4j-simple
true
${weblogic.version}
com.blah
MyApp.EJB
1.0
ejb
com.blah
MyApp.Web
1.0
war
...
It is immediately obvious that the application.xml is not being generated as I
intended.
1. The contextRoot supplied is not correct in the application.xml, instead the
default name of MyApp.Web is output instead of the specified MyApp.
2. The org.slf4j jarModule specified is missing entirely from the
application.xml.
What am I doing wrong?
Debug from Maven is shown below.
[DEBUG] ---
[DEBUG] Goal:
org.apache.maven.plugins:maven-ear-plugin:2.4.2:generate-application-xml
(default-generate-application-xml)
[DEBUG] Style: Regular
[DEBUG] Configuration:
${project.description}
${project.artifactId}
${project.build.directory}
${project}
${project.build.directory}/${project.build.finalName}
[1]:
http://maven.apache.org/plugins/maven-ear-plugin/examples/including-a-third-party-library-in-application-xml.html
[2]: http://maven.apache.org/plugins/maven-ear-plugin/modules.html#webModule
[3]:
http://maven.apache.org/plugins/maven-ear-plugin/usage.html#Advanced_ConfigurationDisclaimer:
The contents of this E-mail plus any attachment is intended for the use of the
addressee only and is confidential, proprietary and may be privileged. It will
not be
binding upon Trace Group or any group company (Trace). Opinions, conclusions,
contractual obligations and other information in this message in so far as they
relate to
the official business of Trace must be specifically confirmed in writing by
Trace. If you
are not the intended recipient you must not copy this message or attachment,
use or
disclose the contents to any other person, but are requested to telephone or
E-mail
the sender and delete the message and any attachment from your system. Trace
takes all reasonable precautions to ensure that no virus or defect is
transmitted via
this e mail, however Trace accepts no responsibility for any virus or defect
that might
arise from opening this E-mail or attachments.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: Manifest of WAR contains wrong references to SNAPSHOT-versions of EAR-based libaries
This is a known bug. See:
http://jira.codehaus.org/browse/MJAR-156
http://jira.codehaus.org/browse/MACR-4
Please comment and vote these bugs that you also suffer from this problem
and want to see it fixed.
> -Original Message-
> From: it-media.k...@daimler.com [mailto:it-media.k...@daimler.com]
> Sent: Mittwoch, 22. August 2012 15:18
> To: users@maven.apache.org
> Subject: Manifest of WAR contains wrong references to SNAPSHOT-versions
> of EAR-based libaries
>
> Hello,
>
> I've come across a rather sever problem in our environment. We create
> EAR-projects that contain WAR-modules and use the old-fashioned way to
> handle skinny WAR-files by denoting the maven-war-plugin to exclude all
> jar-files and rather put them in the EAR-lib-directory. This is done by
> the following plugin configurations for EAR and WAR:
>
> EAR-pom.xml
>
>
> org.apache.maven.plugins
> maven-ear-plugin
>
> 6
> lib/
>
> true
>
>
> DAAS BE Implementation-Title>
> ${project.version}
> ${timestamp}
>
>
>
>
> CONFIG
>
>
> WEBSERVICE_GET
>
>
> WEBSERVICE_SET
>
>
>
>
> daas-backend
> daas-backend-war
> Daas
> daas-backend-war.war bundleFileName>
>
>
> daas-backend
> daas-backend-
> system
> daas-backend-system.jar bundleFileName>
>
>
>
>
>
> WAR-pom.xml:
>
>
> org.apache.maven.plugins
> maven-war-plugin
>
> false
> WEB-INF/lib/*.jar packagingExcludes>
>
>
> true
> lib/
>
>
>
>
>
> However, in case a SNAPSHOT-version of a dependency is added to both,
> the EAR and the WAR, the corresponding MANIFEST-ClassPath-Entry of the
> dependency is created wrong as shown below:
>
> Generated ClassPath:
>
> Class-Path: daas-backend-system.jar lib/websphere-admin-client-2012.2.
> 0-SNAPSHOT.jar lib/logging-5.0.0.jar lib/util-5.0.0.jar lib/jaxb2-bas
> ics-runtime-0.6.3.jar lib/websphere-admin-client-2012.2.0-20120822.03
> 1057-2.jar lib/poi-3.7.jar lib/commons-beanutils-1.8.3.jar lib/jbpm-j
> pdl-4.5-20120709.122214-1.jar lib/jbpm-api-4.5-20120709.122204-2.jar
> lib/jbpm-pvm-4.5-20120709.122211-1.jar lib/jbpm-log-4.5-20120709.1222
> 06-2.jar lib/hibernate-core-3.6.7.Final.jar lib/antlr-2.7.6.jar lib/c
> ommons-collections-3.1.jar lib/dom4j-1.6.1.jar lib/hibernate-commons-
> annotations-3.2.0.Final.jar lib/hibernate-jpa-2.0-api-1.0.1.Final.jar
> lib/slf4j-api-1.6.1.jar lib/slf4j-jdk14-1.6.2.jar lib/commons-lang-2
> .6.jar lib/soap-2.3.1.jar lib/guava-11.0.1.jar lib/jsr305-1.3.9.jar
>
> Here the snapshots have been created as:
>
> lib/websphere-admin-client-2012.2.0-20120822.031057-2.jar
> lib/jbpm-jpdl-4.5-20120709.122214-1.jar
> lib/jbpm-api-4.5-20120709.122204-2.jar
> lib/jbpm-pvm-4.5-20120709.122211-1.jar
> lib/jbpm-log-4.5-20120709.122206-2.jar
>
> But the EAR-lib directory contains them as
>
> lib/websphere-admin-client-SNAPSHOT.jar
> lib/jbpm-jpdl-4.5-SNAPSHOT.jar
> lib/jbpm-api-4.5-SNAPSHOT.jar
> lib/jbpm-pvm-4.5-SNAPSHOT.jar
> lib/jbpm-log-4.5-SNAPSHOT.jar
>
> The only solution that I could think of to this is to manually add the
> wrong dependencies by adding the following to the maven-war-plugin
> configuration:
>
>
> org.apache.maven.plugins
> maven-war-plugin
>
> false
> WEB-INF/lib/*.jar packagingExcludes>
>
>
> true
> lib/
>
>
Manifest of WAR contains wrong references to SNAPSHOT-versions of EAR-based libaries
Hello,
I've come across a rather sever problem in our environment. We create
EAR-projects that contain WAR-modules and use the old-fashioned way to
handle skinny WAR-files by denoting the maven-war-plugin to exclude all
jar-files and rather put them in the EAR-lib-directory. This is done by
the following plugin configurations for EAR and WAR:
EAR-pom.xml
org.apache.maven.plugins
maven-ear-plugin
6
lib/
true
DAAS BE
${project.version}
${timestamp}
CONFIG
WEBSERVICE_GET
WEBSERVICE_SET
daas-backend
daas-backend-war
Daas
daas-backend-war.war
daas-backend
daas-backend-system
daas-backend-system.jar
WAR-pom.xml:
org.apache.maven.plugins
maven-war-plugin
false
WEB-INF/lib/*.jar
true
lib/
However, in case a SNAPSHOT-version of a dependency is added to both, the
EAR and the WAR, the corresponding MANIFEST-ClassPath-Entry of the
dependency is created wrong as shown below:
Generated ClassPath:
Class-Path: daas-backend-system.jar lib/websphere-admin-client-2012.2.
0-SNAPSHOT.jar lib/logging-5.0.0.jar lib/util-5.0.0.jar lib/jaxb2-bas
ics-runtime-0.6.3.jar lib/websphere-admin-client-2012.2.0-20120822.03
1057-2.jar lib/poi-3.7.jar lib/commons-beanutils-1.8.3.jar lib/jbpm-j
pdl-4.5-20120709.122214-1.jar lib/jbpm-api-4.5-20120709.122204-2.jar
lib/jbpm-pvm-4.5-20120709.122211-1.jar lib/jbpm-log-4.5-20120709.1222
06-2.jar lib/hibernate-core-3.6.7.Final.jar lib/antlr-2.7.6.jar lib/c
ommons-collections-3.1.jar lib/dom4j-1.6.1.jar lib/hibernate-commons-
annotations-3.2.0.Final.jar lib/hibernate-jpa-2.0-api-1.0.1.Final.jar
lib/slf4j-api-1.6.1.jar lib/slf4j-jdk14-1.6.2.jar lib/commons-lang-2
.6.jar lib/soap-2.3.1.jar lib/guava-11.0.1.jar lib/jsr305-1.3.9.jar
Here the snapshots have been created as:
lib/websphere-admin-client-2012.2.0-20120822.031057-2.jar
lib/jbpm-jpdl-4.5-20120709.122214-1.jar
lib/jbpm-api-4.5-20120709.122204-2.jar
lib/jbpm-pvm-4.5-20120709.122211-1.jar
lib/jbpm-log-4.5-20120709.122206-2.jar
But the EAR-lib directory contains them as
lib/websphere-admin-client-SNAPSHOT.jar
lib/jbpm-jpdl-4.5-SNAPSHOT.jar
lib/jbpm-api-4.5-SNAPSHOT.jar
lib/jbpm-pvm-4.5-SNAPSHOT.jar
lib/jbpm-log-4.5-SNAPSHOT.jar
The only solution that I could think of to this is to manually add the
wrong dependencies by adding the following to the maven-war-plugin
configuration:
org.apache.maven.plugins
maven-war-plugin
false
WEB-INF/lib/*.jar
true
lib/
daas-backend-system.jar
lib/websphere-admin-client-2012.2.0-SNAPSHOT.jar
lib/jbpm-api-4.5-SNAPSHOT.jar lib/jbpm-log-4.5-SNAPSHOT.jar
lib/jbpm-jpdl-4.5-SNAPSHOT.jar lib/jbpm-pvm-4.5-SNAPSHOT.jar
What did I do wrong here? I cannot imagine this happend before. I'm
clueless on how to handle this any better.
Please help!
Thank you very much.
Best regards,
Heiko
If you are not the intended addressee, please inform us immediately that you
have received this e-mail in error, and delete it. We thank you for your
cooperation.
Re: How to deploy EAR from dependency ?
Please keep in mind that you pay A LOT OF money for having support on WebLogic. I'd file a ticket with Oracle to get professional help on this. /Anders On Wed, Aug 22, 2012 at 8:49 AM, Xavier NOPRE wrote: > Hi Anders, > > Thank you for your fast reply ! > > I'm not surprised with your proposition, but is there anyone who did this > (add properties out of the archive) with WebLogic ? > > Thanks, > > Xavier > > > > 2012/8/22 Anders Hammar > >> Although it is possible to unpack, update and then re-pack, I strongly >> suggest you try to change this behavior of having environment specific >> properties file bundled with the EARs/WARs/etc. There has been >> numerous discussion around this on this mailing list (search achive) >> and best practice is to keep configuration outside of the archive. I >> normally suggest reading the configuration from the classpath where >> you then could put these config files in some folder of the app server >> where they are added to the classpath (all servers should support >> this), but it is also possible to read configuration from JNDI for >> example. >> >> When you do this, deploying is as simple as grabbing the archive from >> the repo and copy/deploy to the server. No tweaking of the files in >> the archive. >> >> /Anders >> >> On Wed, Aug 22, 2012 at 8:21 AM, Xavier NOPRE wrote: >> > Hi, >> > >> > I want to use Maven to retrieve some dependencies, like JAR, WAR, EAR >> (from >> > Archiva), and I want to deploy them to tests servers (Weblo) and to >> Archiva. >> > >> > My problem is that I have to change some properties files in the EAR, >> with >> > my own properties, depending on target test server. >> > >> > Is it possible to do that ? How ? >> > >> > I think, perhaps, I have to "extract" the EAR, and then, repack it with >> wy >> > filtered properties ? >> > >> > Thanks for your help, >> > >> > Xavier >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to deploy EAR from dependency ?
Hi Anders, Thank you for your fast reply ! I'm not surprised with your proposition, but is there anyone who did this (add properties out of the archive) with WebLogic ? Thanks, Xavier 2012/8/22 Anders Hammar > Although it is possible to unpack, update and then re-pack, I strongly > suggest you try to change this behavior of having environment specific > properties file bundled with the EARs/WARs/etc. There has been > numerous discussion around this on this mailing list (search achive) > and best practice is to keep configuration outside of the archive. I > normally suggest reading the configuration from the classpath where > you then could put these config files in some folder of the app server > where they are added to the classpath (all servers should support > this), but it is also possible to read configuration from JNDI for > example. > > When you do this, deploying is as simple as grabbing the archive from > the repo and copy/deploy to the server. No tweaking of the files in > the archive. > > /Anders > > On Wed, Aug 22, 2012 at 8:21 AM, Xavier NOPRE wrote: > > Hi, > > > > I want to use Maven to retrieve some dependencies, like JAR, WAR, EAR > (from > > Archiva), and I want to deploy them to tests servers (Weblo) and to > Archiva. > > > > My problem is that I have to change some properties files in the EAR, > with > > my own properties, depending on target test server. > > > > Is it possible to do that ? How ? > > > > I think, perhaps, I have to "extract" the EAR, and then, repack it with > wy > > filtered properties ? > > > > Thanks for your help, > > > > Xavier > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
