maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marat Abrarov (Jira)" <j...@apache.org>
Subject [jira] [Comment Edited] (MEAR-267) assembly.xml contains incorrect references to modules
Date Sat, 26 Sep 2020 22:31:00 GMT

    [ https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202689#comment-17202689
] 

Marat Abrarov edited comment on MEAR-267 at 9/26/20, 10:30 PM:
---------------------------------------------------------------

I added integration test deploying WildFly 20.0.1.Final (the latest version of WildFly ex
JBoss AS) and EAR into that WildFly instance here (is based on [my master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1]
with [workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]

Test can be executed with simple (requires JDK 1.8):
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of JBoss AS I
was able to run on Oracle JDK 1.7) and EAR into that JBoss AS instance here (is based on my
master branch with workaround): [https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]

Test can be executed with this command (tested on OpenJDK 1.8 + Oracle JDK 1.7 as {{jboss.java.home}}
maven property and on Oracle JDK 1.7):
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7. {{jboss.java.home}} maven property
may be omitted if Maven runs on Oracle JDK 1.7.

Without [workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN  [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0059:
Class Path entry guava-19.0.jar in XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
 does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN  [org.jboss.as.server.deployment] (MSC service thread 1-5) Class Path entry
guava-19.0.jar in "XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
 does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
 # this bug doesn't cause error / deployment failure on semi-modern and modern Java EE application
servers
 # [workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
exists

One more thing I found with JBoss AS/ WildFly is that this Maven EAR Plugin configuration
{code:xml}
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-ear-plugin</artifactId>
    <version>3.0.2</version>
    <configuration>
        ...
        <outputFileNameMapping>@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@</outputFileNameMapping>
    </configuration>
</plugin>
{code}
is not sufficient to solve these warnings - we need to provide "lib/" prefix for class-path
entries to make JBoss AS / WildFly happy.


was (Author: abrarovm):
I added integration test deploying WildFly 20.0.1.Final (the latest version of WildFly ex
JBoss AS) and EAR into that WildFly instance here (is based on [my master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1]
with [workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]

Test can be executed with simple (requires JDK 1.8):
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of JBoss AS I
was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS instance here (is based on my
master branch with workaround): [https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]

Test can be executed with this command (tested on OpenJDK 1.8 + Oracle JDK 1.7 as {{jboss.java.home}}
maven property and on Oracle JDK 1.7):
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7. {{jboss.java.home}} maven property
may be omitted if Maven runs on Oracle JDK 1.7.

Without [workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN  [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0059:
Class Path entry guava-19.0.jar in XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
 does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN  [org.jboss.as.server.deployment] (MSC service thread 1-5) Class Path entry
guava-19.0.jar in "XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
 does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
 # this bug doesn't cause error / deployment failure on semi-modern and modern Java EE application
servers
 # [workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
exists

One more thing I found with JBoss AS/ WildFly is that this Maven EAR Plugin configuration
{code:xml}
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-ear-plugin</artifactId>
    <version>3.0.2</version>
    <configuration>
        ...
        <outputFileNameMapping>@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@</outputFileNameMapping>
    </configuration>
</plugin>
{code}
is not sufficient to solve these warnings - we need to provide "lib/" prefix for class-path
entries to make JBoss AS / WildFly happy.

> assembly.xml contains incorrect references to modules
> -----------------------------------------------------
>
>                 Key: MEAR-267
>                 URL: https://issues.apache.org/jira/browse/MEAR-267
>             Project: Maven Ear Plugin
>          Issue Type: Bug
>    Affects Versions: 3.0.0
>            Reporter: Leonid Rozenblyum
>            Priority: Major
>
> SCENARIO:
> Create a EAR project with maven-ear-plugin 3.0.0
> execute mvn ear:ear
> EXPECTED:
> assembly.xml contains reference to the jar/war equivalent to their physical names inside
> the EAR
> (e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml reference would
be:
> {quote}{{<module>}}
> <ejb>tryEar-ejb-1.0-SNAPSHOT.jar</ejb>
>  </module>
> {quote}
> (this worked in 2.10.1)
> ACTUALLY:
>  assembly.xml contains reference
> {quote}<module>
>  <ejb>com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar</ejb>
>  </module>
> {quote}
>  
> Due to this difference - JBoss/WildFly cannot deploy the EAR.
> (it's easy to reproduce: you may create a ear project from some standard ones from maven-archetypes
and change maven-ear-plugin version to 3.0.0).
>  
> UPDATE: Sorry, maybe it's a bug in M2E-WTP plugin of Eclipse. I tried this scenario in
standalone mode without Eclipse - and assembly.xml is consistent with the jar files



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message