You are viewing a plain text version of this content. The canonical link for it is here.
Posted to announce@maven.apache.org by Karl Heinz Marbaise <kh...@apache.org> on 2018/03/12 21:04:23 UTC
[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:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<version>3.0.0</version>
</plugin>
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
Re: Re: [ANN] Apache Maven EAR Version 3.0.0 Released
Posted by Thorsten Heit <th...@vkb.de>.
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 <outputFileNameMapping> 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
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
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:
>
> (...)
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-ear-plugin</artifactId>
> <version>2.10.1</version>
> <configuration>
> <version>5</version>
> <filtering>true</filtering>
> <displayName>${project.artifactId}-${project.version}</
> displayName>
> <generateApplicationXml>true</generateApplicationXml>
> <modules>
> <webModule>
> <groupId>${project.groupId}</groupId>
> <artifactId>myapp-war</artifactId>
> <contextRoot>/APP</contextRoot>
> </webModule>
> </modules>
> </configuration>
> </plugin>
> (...)
>
>
> <dependencies>
> <dependency>
> <groupId>${project.groupId}</groupId>
> <artifactId>myapp-war</artifactId>
> <version>${project.version}</version>
> <type>war</type>
> </dependency>
> </dependencies>
>
> Behaviour with m-ear-p 2.10.1:
>
> Deploying the EAR to Wildfly creates a folder <myear> in <wildfly-home>/
> standalone/deployments/, and in this folder my war is extracted in a
> folder myapp-war-<version>.war. This is also referenced in the generated
> application.xml:
> web-uri: myapp-war-<version>.war
>
> So far, so good.
>
>
> Behaviour with m-ear-p 3.0.0:
>
> The same folders are generated, i.e. <myear> in
> <wildfly-home>/standalone/deployments/ and myapp-war-${version}.war inside
> it, but the generated application.xml now has a different web-uri:
> web-uri: <groupId>-myapp-war-<version>.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 <outputFileNameMapping> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [ANN] Apache Maven EAR Version 3.0.0 Released
Posted by Thorsten Heit <th...@vkb.de>.
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:
(...)
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<version>2.10.1</version>
<configuration>
<version>5</version>
<filtering>true</filtering>
<displayName>${project.artifactId}-${project.version}</
displayName>
<generateApplicationXml>true</generateApplicationXml>
<modules>
<webModule>
<groupId>${project.groupId}</groupId>
<artifactId>myapp-war</artifactId>
<contextRoot>/APP</contextRoot>
</webModule>
</modules>
</configuration>
</plugin>
(...)
<dependencies>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>myapp-war</artifactId>
<version>${project.version}</version>
<type>war</type>
</dependency>
</dependencies>
Behaviour with m-ear-p 2.10.1:
Deploying the EAR to Wildfly creates a folder <myear> in <wildfly-home>/
standalone/deployments/, and in this folder my war is extracted in a
folder myapp-war-<version>.war. This is also referenced in the generated
application.xml:
web-uri: myapp-war-<version>.war
So far, so good.
Behaviour with m-ear-p 3.0.0:
The same folders are generated, i.e. <myear> in
<wildfly-home>/standalone/deployments/ and myapp-war-${version}.war inside
it, but the generated application.xml now has a different web-uri:
web-uri: <groupId>-myapp-war-<version>.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