Re: [ANN] Apache Maven EAR Version 3.0.0 Released

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Apache Maven EAR Version 3.0.0 Released

Thorsten Heit-3
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
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Apache Maven EAR Version 3.0.0 Released

Karl Heinz Marbaise-3
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: [ANN] Apache Maven EAR Version 3.0.0 Released

Thorsten Heit-3
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